Security/ReviewProcess
This page contains draft documentation of our security review processes.
Security Review Processes
TBD
Security Review Documentation
Structure of a Security Review
This document covers five distinct activities and the documentation they produce when a security review is performed. Note that this guidance is prescriptive in that each component of a security review document should be produced, or a statement explaining why it wasn't should be included.
The goal of this document is to ensure that the Security Assurance team has a consistent format for the documentation we produce without enforcing a strict structure on how security review and testing is performed.
Architecture Diagram
An architecture diagram illustrates how the various components of the service communicate with one another.
The goal of the architecture diagram is to give the audience a high-level visual representation of how the different components of a system will interact together.
An example of this is the diagram below, which is from the old Mozilla F1 service.
Mozilla F1 Architecture Diagram
The F1 service had multiple components:
- a Firefox Add-on that hosted a pane loaded from the Mozilla F1 service that facilitated posting ('sharing') content across multiple services
- a back-end that abstracted the 'sharing' process such that a core set of common functions to facilitate easy incorporation of addition services without client updates
Rather than providing a detailed assessment of how messages are passed between the various components, this diagram illustrates how the different components interact with one another, but not details about the interactions, or what data is shared between them.
The goal of this diagram is to provide a concise overview of the system that provides a frame of reference when someone new to the system is reviewing supporting documentation or code.
Key Attributes
- Clarity; brief descriptions of which components are communicating
- Illustrates the boundaries between different services
Additional Examples
- BrowserID Protocol High Level
- Apps MarketPlace TODO - Replace Me With A Simple Diagram!
Detailed Application Diagram
A Detailed Application Diagram is essentially a Data-flow diagram; a data flow diagram enumerates each application or service that is a component of a system, and illustrates each of the paths data can flow through.
Note that a data-flow diagram is only one example of how this information. The goal is to effectively communicate to the audience how data moves through the system, where different operations are performed, and if detailed enough, how different roles within the system can access different operations.
When designing the detailed application diagram it can be useful to assemble a list of each of the subjects in a system.
TODO - add references for subject/object/operations in relation to access control models.
Key Attributes
- Clarity; labels for objects are brief, and contain clear references that can be used to cross-reference other documentation
- Detailed; ensure that all roles and operations are clearly presented
Additional Examples
Data-flow Enumeration
Data-flow enumeration is an important supplement to the Detailed Application Diagram; it acts as a reference for someone reading the diagram to look up the nature of what information is associated with a call or request between two components.
At a minimum, the flow enumeration should be a table indicating an identifier, subject, object, and the operation being performed.
In the example below, an excerpt from the BrowserID provisioning enumeration, the subject, object, and operation are labelled origin, destination, and description, respectively.
| ID | Origin | Destination | Description |
| 1.A | Relying Party | Implementation Provider | An interaction with the Relying party invokes the Implementation Provider (IP). |
| 1.B | Implementation Provider | Identity Authority | The IP either has an expired certificate, or no certificate, and directs the client to an Identity Authority landing page for authentication. This authentication process is out of scope of the protocol, and implementation dependent. |
| 1.C | Identity Authority | Identity Authority | Code from the IP landing page invokes genKeyPair() to generate a keypair. |
| 1.D | Identity Authority | Implementation Provider | The IP saves the keypair in the client |
In addition to including the subject, object, operation columns, it can be helpful to include an explicit list of fields which are considered sensitive.
Additional Examples
Threat Analysis
When performing a security review of an application one of the most important components is a threat analysis. There is a great deal of documentation on how to perform threat analysis, and a number of different techniques that can be used:
For the purposes of a Mozilla Security Review, the means by which someone identifies the threats and risks associated with an application is important, but not specified. If you have questions about how to perform this type of analysis, please contact a member of our team!
The resulting threat analysis should be formatted in a clear format, including the following details:
- ID - a identifier for the threat
- Title - a concise description of the threat
- Threat - a description of the threat
- Mitigations - a recommendation for a control that can be implemented [1]
- Threat Agent - a list of the potential actors considered that would exploit a vulnerability.
- Notes - Related comments that contribute to the analysis, but don't belong in other columns
- Rating - A qualitative scoring for a vulnerability in the context of this application [2]
- Impact - A qualitative score representing the impact should a vulnerability be exploited
- Likelihood - A qualitative score representing the likelihood of a vulnerability being exploited. [3]
See Risk Ratings for details of how to calculate the qualitative scores.
TODO - Glossary Threat, Threat Agent, Vulnerability, Exploit [1] In the case of a threat analysis that contains multiple threats that can be resolved by one or more different controls it may be beneficial to include a separate control table, and list references to controls in that table instead. [2] The rating is calculated by multiplying the impact by the likelihood. This is a naive method, but it's what we have! [3] In the case where different threat agents have different likelihoods, list the likelihoods highest to lowest, in the same order as the threat agents.
Below is an excerpt from the BrowserID Threat Analysis:
| ID | Title | Threat | Proposed Mitigations | Threat Agent | Rating | Likelihood | Notes | Impact | Notes |
| 1 | SIA may introduce compliance issues | Operating a Secondary Identity Authority may induce compliance requirements with regards to logging user information | Part of the goal of BrowserID is to have Primary Identity Authorities take on this risk as part of their other operations. This can be somewhat mitigated by eliminating support for the webfinger verification process. | Governments, Lawyers | 12 | 3 | Governments and other legal actors have the ability to request information from us, either through subpoenas, NSLs, etc. While we hold information that can link user identities to services this information will be a source of risk. | 4 – Reputation | Although we are required to comply, and Mozilla would fight such a request to the degree permitted, we would still receive negative press. |
| 2 | Webfinger Information Leak | Use of the webfinger service for verification discloses each authentication attempt from the Relying Party to the Identity Authority | Implement verification using certificates | Malicious Identity Authority | 25 | 5 | This information disclosure is a part of the protocol. | 5 – Privacy | This is probably a clear violation of our privacy policies. |
| 3 | Chrome Code Injection | Attacker controlled parameters could permit injection of script into browser chrome. | Ensure that any data controlled by the user or relying party is emitted using output encoding. | Malicious Relying Party, Malicious User, Malicious Identity Authority | 4 | 1 | Code review and testing should prevent this occuring. The technical complexity of this attack is higher than a vanilla XSS. | 4 – User | This gives an attacker the ability to execute code in the context of browser chrome. |
Additional Examples
Security Testing
The security test plan is a brief explanation of security testing that should be performed, and should include an explanation of what tasks are to be performed, and the approximate amount of time spent performing those tasks.