Jeremiah Grossman said:
The part you mentioned I that find interesting is,
"familiarity with the code", which I have question about. Is
this a good thing when it comes to auditing code? Are code
audits more effective with a fresh set of eyes or someone
already familiar with the software? It seems to me that both
have benefits, though I'm not certain on what they might be.
From this perspective It doesn't matter if the person is
in-house or out-house.
(assuming they both have the same 'analytical' skills) I think an
external person is far less effective primarly because the only way to
realise a problem within an application is to know it's context. And
an outsider can't know the context of all the code, and may diagnose
bugs, or at least waste alot of time researching bugs, which aren't a
problem due to code somewhere else in the application.
The answer I've heard most often in organizations is that you
want "developers" writing code, not auditing code, because
you lose they're productivity. Auditing code should be done
by someone else (Who really doesn't exist in most cases). Not
that I agree with the premise, but this is what I hear. :)
I think it's more important that companies allow developers the time
to _FIX_ bugs. Deadlines are the biggest cause of security problems :)
Of course, having them look for security problems during "code
reviews" is nice too, but I think alot of the time the programmers may
be aware of some problems themselves, but simply not have time to fix
them.
A nicer idea instead of outside 'code audits' is to have training.
Train the programmers to write 'secure' code. I think the
organisations should look at it not from "oh, we have to pay for the
programmers to understand this 'secure programming' stuff now" but
from the angle or teaching the programmers to program _CORRECTLY_.
After all, this is all 'secure programming' is. In this way, I think
it's an appropriate way to spend the business money.
I don't particularly like the idea of using "App scanners" and other
things as a final layer, because it lets the programmers be lazy, and
lets their problems live on forever in the application, possibly
causing more problems in the future, and a 'culture' of insecure
programming within the organisation.
Defense in Depth is good, but as long as it doesn't encourage bad
programming to continue to exist. Which I believe it does, currently.
-- Michael
