Security/Lightweight security process

Goals

• Ensure that, where possible, resources from the project team are used so the ability to perform regular security reviews scales with the organisation.
• Ensure the security processes are timely (Security should not hold things up - awaiting a secreview should not delay shipping something).
• Ensure security scrutiny of a change, feature or product is appropriate to the work being performed.
• Ensure that the proposed process reflects what happens most of the time (policies, processes and procedures that don’t reflect the realities of the organisation are broken).
• Give the developers of a feature or product the sense that they own the security of that feature or product (security should never be “someone else’s problem”).
• Provide clear guidelines on when to engage security specialists (and how).
• Free up specialist appsec resource for tasks which are a better use of time.

The process

For projects with a high risk rating or higher, the existing security review process should be followed including creating the currently expected review artifacts (architectural diagrams, etc), though it is suggested that developers on the project may want to play a more active role in this (since it will help their project teams in future security review efforts).

For medium rated projects, development teams should lead the security review themselves. Security review should be similar to (but separate from) the existing peer review mechanisms and will be guided (initially at least) by a security checklist.

The reason for a checklist is twofold:

1. A checklist enforces consistency. We can ensure that two reviewers will at least be looking for the same issues when they conduct their respective reviews (even if there’s some inevitable variation in how those issues are evaluated).
2. A checklist provides a useful means of ascertaining whether subsequent review is necessary.

Further involvement by security specialists is, of course, possible (and desirable) if the developer or reviewer would like security assistance.

Specialist documentation and procedures

Whilst concepts and high level process transfer well between development areas, specific details don’t always transfer as easily.

It would be necessary for checklists and supporting documentation to be specifically tailored for individual teams (e.g. specific checklists for mobile or devtools).

Decision making

There are two points at which decisions need to be made in the described process:

1. Does the feature or work require a review led by security assurance, or, can the development team lead the security review work?
2. A development team led review has been performed; is it necessary to get input from security specialists?

The first of these should be decided with the involvement of security. This could involve a regular point of contact (hopefully most development teams still talk to security people often) or could be part of a regularly scheduled security meeting (E.g. the security open mic).

The second could be driven by the set of security questions used to guide the review. If the questions are crafted such that they have ‘yes’ or ‘no’ answers, a ‘no’ response (for any or a specific question) could indicate security involvement is required.

Help and Support

For this process to work, it’s essential that timely support is available for people with security questions. There are a number of ways this can be achieved:

1. It is expected that security specialists will keep a watching brief on major product development areas. This provides two benefits: Firstly, someone with security knowledge is aware of new features early in the development cycle. Secondly, the project team has a familiar face to direct security questions to.
2. We’ve already started initiatives like the Security Open Mic sessions. An excellent benefit provided by these sessions is that developers with questions about the things they’re working on have a place to go to ask questions.
3. We already know we can do more to talk to the rest of the organisation about security. More frequent Brown Bags on security issues (including sessions specifically about particular areas; e.g. webdev, fennec, FxOS) will help with developers’ security knowledge.

An example

An example security checklist has been created for Firefox Mobile, which currently resides here.

Feedback and Adjustments

Documentation and checklists for various development teams should not be static. Once created, there will be a need for constant feedback and review.

There are 3 likely things that will result in modifications to these:

1. Vulnerabilities discovered (internally and externally)
2. Repeated problems (not necessarily directly exploitable vulnerabilities) - often patterns appear that, while not exploitable on their own, can easily become a source of security problems (e.g. use of innerHTML in chrome)
3. Areas of common confusion - when many people struggle with the same question or concept.

Ongoing processes

One of the benefits of more explicitly devolving responsibility of low and medium risk security review to individual teams is that security specialists previously tied up in feature based security review can spend more time on more detailed code audit tasks.