|
|
| (One intermediate revision by one other user not shown) |
| Line 162: |
Line 162: |
| === Threat Analysis === | | === 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:
| | A good deal of effort was put forth to reduce the amount of usable data and value of attack for this product. |
|
| |
|
| * [https://www.owasp.org/index.php/Threat_Risk_Modeling OWASP Threat Risk Modelling]
| | The service is designed to allow remote sites to "wake" an app on a user's device. All actual function happens on the client. If an attacker manages to either identify or use the two UUID4 entries, the most they could do is repeatedly wake an application until the app decides to re-register another ChannelID. An attacker could use this to possibly reduce battery life or increase data costs for a user, but even then, there are much more effective means of doing this. |
| * [http://msdn.microsoft.com/en-us/security/aa570413 Microsoft Application Threat Modelling]
| |
| * [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf NIST Risk Management Guide][pdf]
| |
| | |
| 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 [https://wiki.mozilla.org/Security/RiskRatings 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 [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model BrowserID Threat Analysis]:
| |
| | |
| {| border="1" class="fullwidth-table sortable"
| |
| | align="center" style="background:#f0f0f0;"|'''ID'''
| |
| | align="center" style="background:#f0f0f0;"|'''Title'''
| |
| | align="center" style="background:#f0f0f0;"|'''Threat'''
| |
| | align="center" style="background:#f0f0f0;"|'''Proposed Mitigations'''
| |
| | align="center" style="background:#f0f0f0;"|'''Threat Agent'''
| |
| | align="center" style="background:#f0f0f0;"|'''Rating'''
| |
| | align="center" style="background:#f0f0f0;"|'''Likelihood'''
| |
| | align="center" style="background:#f0f0f0;"|'''Notes'''
| |
| | align="center" style="background:#f0f0f0;"|'''Impact'''
| |
| | align="center" style="background:#f0f0f0;"|'''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 ====
| |
| * Mozilla F1 Threats [https://wiki.mozilla.org/Security/Reviews/F1#Threat_Model]
| |
| * BrowserID Threats [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model]
| |
|
| |
|
| === Security Testing === | | === 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. | | 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. |