RE: "Selling" a code-audit.

	Good afternoon, Yvan.

	In my experience, there is a very important piece of advice for code
auditors:

	During the auditing, fact gathering and interviews, make sure you DO
NOT raise your concerns. Keep your conclusions to yourself, be very
professional and resist the temptation to comment immediately on what you
find. Be very discreet.

	If you fail to do that, people will cease to be responsive after you
point out the first two or three issues. And then you will have the hardest
time finding the rest of them, because the developers will naturally try to
hide the problems from you.

	Programmers are naturally very suspicious of code auditors, always
believing they will try to look good by badmouthing them. Don't be one of
those, and let them know you won't do that. When you talk to a developer for
the first time, try to create some empathy with him and reassure him that
you are not a witch hunter. Tell him you have a job to do, and you need his
help to do it properly. If all goes well, your observations added with his
comments and suggestions will help create a better development model. No
programmer likes to be called to fix a bug in his code that caused a client
to lose money, his boss to lose his temper and him to lose his job. :-) Sell
him the idea that he has a chance to help prevent this from happenning, and
make sure you get his input on what's wrong or not.

	When you present your findings, be understanding and try not to make
any conclusions regarding the professionalism and quality of the developers.
People are not trained to code with quality and security in mind, and most
managers do not make that a priority when allocating resources. Developers
usually work under very tight deadlines, chase fast-moving targets and pray
to god their code works at all as a consequence.

	Make sure you mention in your presentation/report how helpful and
professional the developers were in helping your audit, and point out that
the budget and deadlines are probably not taking quality and security into
consideration appropriately. Don't restrict yourself to saying what's wrong.
Be positive and point out solutions and highlight any positive intiatives or
characteristics you find.

	This approach has been very successful with me in the past, and I
managed to keep on friendly terms with developers doing several audits of
their work, finding and reporting serious problems, and helping improve the
quality of the systems and development processes I worked on.

	I hope this answers your question. :-)

--
Alexandre Sieira, CISSP
Cipher - Segurança da Informação
+55-21-2529-2629
www.ciphersec.com.br
 
Esta mensagem eletrônica pode conter informações privilegiadas e/ou
confidenciais, portanto fica o seu receptor notificado de que qualquer
disseminação, distribuição ou cópia não autorizada é estritamente proibida.
Se você recebeu esta mensagem indevidamente ou por engano, por favor,
informe este fato ao remetente e a apague de seu computador imediatamente.
 
This e-mail message may contain legally privileged and/or confidential
information, therefore, the recipient is hereby notified that any
unauthorized dissemination, distribution or copying is strictly prohibited.
If you have received this e-mail message inappropriately or accidentally,
please notify the sender and delete it from your computer immediately.


-----Original Message-----
From: Yvan Boily [mailto:[email protected]] 
Sent: segunda-feira, 30 de agosto de 2004 14:45
To: [email protected]
Subject: "Selling" a code-audit.


One of my primary responsibilities with my employer is performing code
audits; so far I have been fairly effective in a technical capacity, however
on almost every single code audit I have participated in I have received
hostile responses from the development team.  I have tried a variety of
approaches to develop a stronger rapport with the development team, however
in spite of my best efforts I find that going into a code audit I am already
fighting against preconceptions about why the code audit is being performed.


I understand that many people feel threatened when work they have done is
criticized; what I need to know is how I can minimize this and coax the
development teams into being more interactive than defensive.  Any pointers?

Yvan Boily