WebApp Sec mailing list archives
RE: Solutions, Results, and Comments - Was [ISA Server and SQL Injection]
From: Michael Silk <michaelsilk () gmail com>
Date: Mon, 28 Feb 2005 09:52:51 +1100
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
Current thread:
- RE: Solutions, Results, and Comments - Was [ISA Server and SQL Injection] Michael Silk (Feb 28)