Jason Coombs PivX Solutions said the following on Mon, Sep 20, 2004 at
07:39:54AM -1000,
[..]
It does appear ironic and absurd for management to then punish the
developers for meeting the schedule by having a code audit pick apart all
the things the developers were forced to skip over in order to finish on
time.
Where are you getting this assumption from the original mail? I read and
reread and found no evidence of it. Apart from the fact that developers make
lots of security mistakes without realising, it is not a given that speed over
quality will be prioritised (rightly or wrongly from a competitive point of
view).
The developers themselves can show you those things, since they probably
have them all memorized and documented.
Man, I want to audit this team's stuff. Where do they exist?
Now, if you are able to point out things that the developers truly did not
already know so that they learn something new, if you are able to document,
for the developers' benefit in their relationship with management, mistakes
and skipped steps and lack of understanding or lack of devotion to security
on the part of management at the same time, and in a balanced manner with a
presentation of indisputable facts, then developers will love you and
management will love you and both will gain new leverage in their ongoing
relationship with the other.
I find this very difficult to believe. Has it often worked for you like this
in the past? Pointing out management mistakes as opposed to just developer
mistakes means that you're also running the risk of pissing off management and
therefore risking not getting the buy in you need from them to continue to
carry out the audits. There are enough mentions of this phenomenon in the
books/articles I've read of this sort of reaction to lead me to think that it
is not just limited to my own experience.
If you are being asked to do code audits rather than forensic audits that
examine anything and everything your expertise guides you to examine, then
you are being manipulated by people who think that security is all about
finding the mistakes made by others rather than perfecting security starting
with themselves.
There's room for (and a purpose to) both. If we go back to your assumption
that the development team don't have time to fix known flaws then it seems
slightly contradictory to now suggest that they have time to perfect security
(not that I've heard of anyone doing this anyway). In that instance it is
either more practical (because the developers don't have the skills
themselves) or more economical (by deciding to employ someone to point out the
low hanging fruit) to get someone to do a code audit of a certain level of
detail. Of course, it's more economical and practical in the long term to
instruct the developers in how to avoid and detect such flaws, but it doesn't
sound like the original poster has that good a relationship with the team to
build up this sort of process effectively.
Perhaps I disagree so much because we live in different worlds. If you
inhabit companies where the development teams are this skilled and all
problems are down to pressures of time and failings of management, then this
all seems perfectly sound, but I don't think that most of the world is there
yet.
[earlier]
Then, instead of rushing to ship the code (remember Microsoft's motto in the
Netscape wars 'he who ships first, wins') the company with proper security
culture would second guess itself and remove half the code and reduce the
features and turn everything off by default and be absolutely certain that
the code that does ship does not expose, by default, any attack surface.
Microsoft won that browser war didn't they? I'd not fancy trying to convince
Microsoft (or any other company for that matter) that they should change their
priorities unless there's a financial or competitive advantage in the short,
medium or long term.
--
ejrry^[bxpZZ
