Hi,
-----Original Message-----
From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]
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
