RE: Inspecting Code for Security

Hi,
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Tue, 21 Sep 2004 20:57:51 +0200, "Aleksander P. Czarnowski" said:
> > I would say that the final list of objectives should be business driven,
> The truly hard part is that usually the very top item of the list 
> is proclaimed
> by somebody very high up the totem pole, and is a variant on:
> "We must ship/deploy/whatever by next Thursday or we're screwed..."
This can be unfortunately true, however it comes down to you negotiation skills - sometimes you need to do a lot of customer education even on the upper management level before starting the project. 

Besides education which is one of most crucial parts of such project, you can also rearrange your project in such a way that both audit team and customer management goals are met. A good example might be how you align reporting phases: you can provide customer with short reports and work with dev teams on fixing vulnerabilities while providing full report - especially for upper management - later. 

> Admittedly, it's somewhat off-topic for a "code inspection", but 
> it's really
> somewhat pointless to do the inspection if you don't have at least a foggy
> idea of what you intend to do if you find a really bad gaping hole.
This is not always the case: you might be on the other side of barricade. For example you can call for audit before purchasing particular application to fulfill your business needs. In such case, your approach can lack remediation phase as you only advise customer if the security level of particular application meets their requirements.  

> First Law of Systems Programming: "Never test for error conditions that
> you don't know how to handle..."  :)
:)
Best Regards,
Aleksander Czarnowski
AVET INS