114 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
◾ If the risk analysis is put in order of overall severity according to the project
and its environment, what is the maximum acceptable risk for the project?
◾ If a mitigation is made, what is the new severity of that risk, and is it below
the acceptable risk for the project?
Require Security Reviews—In some cases security reviews will be a known
requirement due to legal or regulatory requirements. In this case, you need to gather
the development team and make its members aware of the requirements the project
must meet and how it will be tested.
If there is no externally mandated security review, is there a company policy
in place that requires security reviews and sets the requirements the project must
meet? If there is, then the development team must be made aware of them.
If there are no mandates, then a decision must be made based on multiple
factors like budget, internal resources and knowledge, and the security risks of
the project about whether to conduct a formal security review of the project as a
requirement to it being released.
Some of the important questions to ask about security reviews for your project
are as follows:
◾ Is there a legal or regulatory requirement for a security review and, if so, what
are the requirements that have to be met, and who has to conduct the review?
◾ Is there a company policy or requirement for a security review and, if so, what
are the requirements that have to be met, and who has to conduct the review?
◾ If there is no external requirement for a security review, is the project sensitive
enough to warrant a formal security review as a requirement for release? If so,
what should the criteria be, and who should conduct the review?
◾ How many security reviews should be held?
Protect Source Code—An aspect of secure development that is often overlooked
is the need to protect the source code of the project, both as it is being developed and
afterward. Leaks or releases of source code can result in a huge security breach, so
access to the source code should be limited to only those people who actually require
that access to perform their job functions, and all other access should be denied.
Protect Defect Details—Another aspect to security during development is the
need to protect the defect database and details contained in it, especially those
relating to security. Most defect reports contain a sample of how to cause the defect
to manifest itself, and exposure of that database can lead to exploitation of those
defects later.
e defect database should be locked down, and only those people who require
access to the defect database to perform their job functions should be given access
to it. If there is a need to have other people le defect reports, it may be a worth-
while risk mitigation to set up a method just for that purpose.