Security/Archived/Reviews/: Difference between revisions
(Added template link) |
|||
| Line 66: | Line 66: | ||
= | == Status == | ||
{| class="wikitable" | |||
|- | |||
! colspan="2" | Identity (TEMPLATE) | |||
|- | |||
| Tracker Bug | |||
| - | |||
|- | |||
| Stage | |||
| Definition | |||
|- | |||
| Status | |||
| Red (Green, Yellow, Red?) | |||
|- | |||
| Release Target | |||
| | |||
|- | |||
| Health | |||
| - | |||
|- | |||
| Status Note | |||
| - | |||
|} | |||
== Team == | |||
{| class="wikitable" | |||
|- | |||
| Product manager | |||
| | |||
|- | |||
|Feature manager | |||
| - | |||
|- | |||
| Engineering lead | |||
| | |||
|- | |||
| Security lead | |||
| | |||
|- | |||
| Product Security lead | |||
| | |||
|- | |||
|Privacy lead | |||
| | |||
|- | |||
|Localization lead | |||
| - | |||
|- | |||
|Accessibility lead | |||
| - | |||
|- | |||
|QA lead | |||
| - | |||
|- | |||
|UX lead | |||
| - | |||
|- | |||
|Product marketing lead | |||
| - | |||
|- | |||
|Additional members | |||
| - | |||
|} | |||
== Open issues/risks == | |||
== Stage 1: Definition == | |||
=== Introduction === | |||
Include brief summary of feature/project, and link back to core feature/product pages. | |||
=== Use Cases === | |||
=== Data Flows === | |||
==== Diagram ==== | |||
[[File:TEMPLATE-Protocol.png]] | |||
==== 1. Section 1 ==== | |||
{| border="1" class="fullwidth-table" | |||
| align="center" style="background:#f0f0f0;"|'''ID''' | |||
| align="center" style="background:#f0f0f0;"|'''Origin''' | |||
| align="center" style="background:#f0f0f0;"|'''Destination''' | |||
| align="center" style="background:#f0f0f0;"|'''Description''' | |||
|- | |||
|1.A||Abcdefg hij klmnop||Abcdefg hij klmnop|| Abcdefg hij klmnop. | |||
|- | |||
|1.B||klmnop||klmnop klmnop||klmnop klmnop klmnop klmnop. klmnop klmnopklmnopklmnop | |||
|} | |||
==== 2. Section 2 ==== | |||
{| border="1" class="fullwidth-table" | |||
| align="center" style="background:#f0f0f0;"|'''ID''' | |||
| align="center" style="background:#f0f0f0;"|'''Origin''' | |||
| align="center" style="background:#f0f0f0;"|'''Destination''' | |||
| align="center" style="background:#f0f0f0;"|'''Description''' | |||
|- | |||
|2.A||Abcdefg hij klmnop||Abcdefg hij klmnop|| Abcdefg hij klmnop. | |||
|- | |||
|2.B||klmnop||klmnop klmnop||klmnop klmnop klmnop klmnop. klmnop klmnopklmnopklmnop | |||
|} | |||
==== 3. Section 3 ==== | |||
{| border="1" class="fullwidth-table" | |||
| align="center" style="background:#f0f0f0;"|'''ID''' | |||
| align="center" style="background:#f0f0f0;"|'''Origin''' | |||
| align="center" style="background:#f0f0f0;"|'''Destination''' | |||
| align="center" style="background:#f0f0f0;"|'''Description''' | |||
|- | |||
|3.A||Abcdefg hij klmnop||Abcdefg hij klmnop|| Abcdefg hij klmnop. | |||
|- | |||
|3.B||klmnop||klmnop klmnop||klmnop klmnop klmnop klmnop. klmnop klmnopklmnopklmnop | |||
|- | |||
|} | |||
=== Architecture Diagram === | |||
== Stage 2: Design == | |||
=== Threat Model === | |||
{| 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||Title text||Threat description||Proposed mitigation.||Threat agents||Rating #||Likelihood #||Notes.||Impact Score # – Impact||Notes. | |||
|- | |||
| 2||Title text||Threat description||Proposed mitigation.||Threat agents||Rating #||Likelihood #||Notes.||Impact Score # – Impact||Notes. | |||
|- | |||
| 3||Title text||Threat description||Proposed mitigation.||Threat agents||Rating #||Likelihood #||Notes.||Impact Score # – Impact||Notes. | |||
|- | |||
| | |||
|} | |||
[[image:TEMPLATE-Threat-Model.png|thumb|TEMPLATE Implementation Dataflow]] | |||
==== User Interactions ==== | |||
{| border="1" class="fullwidth-table" | |||
| align="center" style="background:#f0f0f0;"|'''ID''' | |||
| align="center" style="background:#f0f0f0;"|''' Summary''' | |||
| align="center" style="background:#f0f0f0;"|'''Description''' | |||
|- | |||
| 1.A|| Summary||Description. | |||
|- | |||
| 1.B|| Summary||Description. | |||
|- | |||
| 2.A|| Summary||Description. | |||
|- | |||
| 2.B|| Summary||Description. | |||
|} | |||
==== Client Interactions ==== | |||
{| border="1" class="fullwidth-table" | |||
| align="center" style="background:#f0f0f0;"|'''ID''' | |||
| align="center" style="background:#f0f0f0;"|'''Summary''' | |||
| align="center" style="background:#f0f0f0;"|'''Description''' | |||
|- | |||
| 2.A|| Summary||Description. | |||
|} | |||
==== Server Interactions ==== | |||
{| border="1" class="fullwidth-table" | |||
| align="center" style="background:#f0f0f0;"|'''ID''' | |||
| align="center" style="background:#f0f0f0;"|'''Summary''' | |||
| align="center" style="background:#f0f0f0;"|'''Description''' | |||
| align="center" style="background:#f0f0f0;"|'''Path''' | |||
| align="center" style="background:#f0f0f0;"|'''Input''' | |||
| align="center" style="background:#f0f0f0;"|'''Output''' | |||
| align="center" style="background:#f0f0f0;"|'''CEF''' | |||
| align="center" style="background:#f0f0f0;"|'''CSRF''' | |||
|- | |||
| 3.A|| Summary||Description||Path||Input||Output||CEF||CSRF | |||
|- | |||
| 3.b|| Summary||Description||Path||Input||Output||CEF||CSRF | |||
|} | |||
CEF and CSRF columns indicate wether or not CEF logging or CSRF prevention is required for the interactions | |||
==== Security Recommendations / Open Issues ==== | |||
{| border="1" class="fullwidth-table" | |||
| align="center" style="background:#f0f0f0;"|'''ID''' | |||
| align="center" style="background:#f0f0f0;"|'''Title''' | |||
| align="center" style="background:#f0f0f0;"|'''Status''' | |||
| align="center" style="background:#f0f0f0;"|'''Summary''' | |||
|- | |||
| [[https://bugzilla.mozilla.org/show_bug.cgi?id=000000]]||Title||Status(Open/Closed)||Summary. | |||
|- | |||
| [[https://bugzilla.mozilla.org/show_bug.cgi?id=000000]]||Title||Status(Open/Closed)||Summary. | |||
|} | |||
==== CEF Logging Requirements ==== | |||
=== Business Test Cases === | |||
Document application specific test cases here | |||
=== Privacy Risk Analysis === | |||
(Status of and link to privacy review and outcome here) | |||
== Stage 3: Planning == | |||
=== Application Security Requirements === | |||
Document individual requirements for the application here (e.g. CEF logging, captcha, etc) | |||
=== Operation Security Requirements === | |||
Document network/platform security requirements here (e.g. IDS concerns, firewall changes, system hardening reqs, etc) | |||
====Mana Website Creation Form ==== | |||
* https://mana.mozilla.org/wiki/display/websites/Home | |||
=== Critical Security Requirements === | |||
Itemize individual security blockers here. Reference components in section AppSec or OpSec subsections. | |||
These blockers must be addressed before the product can go live. | |||
== Stage 4: Development == | |||
=== Repeatable Security Test Cases === | |||
Document individual repeatable security test cases here. Include a reference to the source repo, and documentation that governs how to execute test cases. | |||
=== Secure Coding Guidelines === | |||
Document specific secure coding guidelines to be followed and relate them to specific issues/requirements that are specified; capture bug ids related to those issues. | |||
=== Code Review Milestones === | |||
Table 1 - itemized list of code review milestones {i.e. breakdown of specific components that will be reviewed} | |||
Table 2 - list of app components/modules that should trigger additional security review (e.g. auth, csrf, file upload handling, etc) | |||
== Stage 5: Release == | |||
=== Application Security Verification === | |||
These subsections should contain a list of the steps to be taken, and the status of each activity | |||
==== Code Review ==== | |||
==== Automated Security Testing ==== | |||
* [https://wiki.mozilla.org/WebAppSec/garmr Garmr] | |||
==== Manual Security Testing ==== | |||
=== Operational Security Verification === | |||
==== ArcSight Information ==== | |||
==== Network Design Security Review ==== | |||
==== Database Security Review ==== | |||
==== Platform Security (Hardening & Specific Config Requirements) ==== | |||
=== Landing Criteria === | |||
This should be a table itemizing everything from Stage 3 - Critical Security Requirements, including status. | |||
For status Red=Unimplemented,Yellow=implemented,Green=tested and passed? | |||
== Stage 6: Post Implementation Review == | |||
=== Production Security Considerations === | |||
Document additional/ongoing work for this application (e.g. specific things to watch for in ArcSight, gaming behaviour, etc) | |||
=== Post Implementation Tasks === | |||
Itemize process/kb changes developed from this project (e.g. secure coding guidelines, policy stuff, etc) | |||
== Team status notes == | |||
{| class="wikitable" | |||
! | |||
!status | |||
!notes | |||
|- | |||
|Products | |||
|tbd | |||
| - | |||
|- | |||
|Engineering | |||
| tbd | |||
| - | |||
|- | |||
|Engineering | |||
| tbd | |||
| - | |||
|- | |||
|Engineering | |||
| tbd | |||
| - | |||
|- | |||
|Engineering | |||
| tbd | |||
| - | |||
|- | |||
|Engineering | |||
| tbd | |||
| - | |||
|- | |||
|Engineering | |||
| tbd | |||
| - | |||
|- | |||
|Engineering | |||
| tbd | |||
| - | |||
|- | |||
|Engineering | |||
| tbd | |||
| - | |||
|} | |||
Revision as of 04:19, 25 November 2012
Schedule
- Security Review Calendar (.ics)
- Security Review Calendar (HTML)
- Security Review Archive
- Security Review Template
The Security Review calendar is currently shared publicly for viewing. Those with higher rights must edit the calendar using zimbra. The calendar is shared via zimbra sharing and a standard welcome message:
Note: The standard message displays your name, the name of the shared item, permissions granted to the recipients, and login information, if necessary.
To edit a calendar event
* Double click event in Zimbra like you would any other event ** if the event asks if you want to edit the instance or the series you will in general only want the single instance * Edit the instance as needed and send then send (not save)
To Add a new event
* Create a new event just like you would on your own calendar * Under the "Calendar" pull down select "Security Review" * When done with all the details click send
IRC Channel
Unless otherwise noted on the agenda for a review the IRC channel for reviews shall be #security.
Performing a Security Review
You can find documentation on how security reviews are performed, including the steps we take, and what documentation we expect to produce in the course of the security review at Security Review Processes.
Scheduling a Review
Please use the instructions on this wiki: https://wiki.mozilla.org/Security/Reviews/Review_Request_Form
Design Review
All features regardless of size should have a design review. These should occur before any code is landed to Mozilla Central (MC), the goal is to find architectural flaws that may result in serious security issues. When a feature page is created a security contact should be specified for the feature to ensue the smoothest integration for security input and reviews. If you find you are missing such a contact please email secteam at mozilla dot com to have one assigned. The level of work required for design reviews will vary depending on such factors as complexity of the feature, changes to known fragile code, and/or features that alter the security posture of the product or of Mozilla as a whole. Design reviews may be followed up with implementation reviews, fuzz testing, outside code review or other security tasks as deemed necessary to ensure the safety and security of our users.
Implementation Review
Just as it sounds this is a review of a patch and its corresponding implementation prior to that patch landing in a widely use branches (MC, Aurora, Beta, etc). Not all patches will require a security review, however, if a patch is deemed to need a security review and one is not completed that patch may be backed out until such a review is completed. Patch owners will most often be contacted by the security team for such a review, however, we encourage patch authors to be proactive and contact secteam when they are in doubt or feel a security review would be beneficial.
Tracking Features for Review
Current features are being track for review here: https://wiki.mozilla.org/Security/Radar
Firefox
- Review archive
With the change to wikimedia search capable feature pages review archives will not be maintained in this format. Please use: Security Radar Complete
- about:telemetry
- Firefox 8
- Firefox 7
- Firefox 6
- Firefox 5
- Firefox4.next
- Firefox 4.0 Security Reviews
- Firefox 3.6 Security Reviews
- Firefox 3.5 Security Reviews
Mozilla Apps Project
BrowserID
Browser ID Security Review link
AppStore
AppStore Security Review link
DevTools
Responsive Mode Security Review link
SocialAPI
SocialAPI Security Review link
Status
| Identity (TEMPLATE) | |
|---|---|
| Tracker Bug | - |
| Stage | Definition |
| Status | Red (Green, Yellow, Red?) |
| Release Target | |
| Health | - |
| Status Note | - |
Team
| Product manager | |
| Feature manager | - |
| Engineering lead | |
| Security lead | |
| Product Security lead | |
| Privacy lead | |
| Localization lead | - |
| Accessibility lead | - |
| QA lead | - |
| UX lead | - |
| Product marketing lead | - |
| Additional members | - |
Open issues/risks
Stage 1: Definition
Introduction
Include brief summary of feature/project, and link back to core feature/product pages.
Use Cases
Data Flows
Diagram
1. Section 1
| ID | Origin | Destination | Description |
| 1.A | Abcdefg hij klmnop | Abcdefg hij klmnop | Abcdefg hij klmnop. |
| 1.B | klmnop | klmnop klmnop | klmnop klmnop klmnop klmnop. klmnop klmnopklmnopklmnop |
2. Section 2
| ID | Origin | Destination | Description |
| 2.A | Abcdefg hij klmnop | Abcdefg hij klmnop | Abcdefg hij klmnop. |
| 2.B | klmnop | klmnop klmnop | klmnop klmnop klmnop klmnop. klmnop klmnopklmnopklmnop |
3. Section 3
| ID | Origin | Destination | Description |
| 3.A | Abcdefg hij klmnop | Abcdefg hij klmnop | Abcdefg hij klmnop. |
| 3.B | klmnop | klmnop klmnop | klmnop klmnop klmnop klmnop. klmnop klmnopklmnopklmnop |
Architecture Diagram
Stage 2: Design
Threat Model
| ID | Title | Threat | Proposed Mitigations | Threat Agent | Rating | Likelihood | Notes | Impact | Notes |
| 1 | Title text | Threat description | Proposed mitigation. | Threat agents | Rating # | Likelihood # | Notes. | Impact Score # – Impact | Notes. |
| 2 | Title text | Threat description | Proposed mitigation. | Threat agents | Rating # | Likelihood # | Notes. | Impact Score # – Impact | Notes. |
| 3 | Title text | Threat description | Proposed mitigation. | Threat agents | Rating # | Likelihood # | Notes. | Impact Score # – Impact | Notes. |
User Interactions
| ID | Summary | Description |
| 1.A | Summary | Description. |
| 1.B | Summary | Description. |
| 2.A | Summary | Description. |
| 2.B | Summary | Description. |
Client Interactions
| ID | Summary | Description |
| 2.A | Summary | Description. |
Server Interactions
| ID | Summary | Description | Path | Input | Output | CEF | CSRF |
| 3.A | Summary | Description | Path | Input | Output | CEF | CSRF |
| 3.b | Summary | Description | Path | Input | Output | CEF | CSRF |
CEF and CSRF columns indicate wether or not CEF logging or CSRF prevention is required for the interactions
Security Recommendations / Open Issues
| ID | Title | Status | Summary |
| [[1]] | Title | Status(Open/Closed) | Summary. |
| [[2]] | Title | Status(Open/Closed) | Summary. |
CEF Logging Requirements
Business Test Cases
Document application specific test cases here
Privacy Risk Analysis
(Status of and link to privacy review and outcome here)
Stage 3: Planning
Application Security Requirements
Document individual requirements for the application here (e.g. CEF logging, captcha, etc)
Operation Security Requirements
Document network/platform security requirements here (e.g. IDS concerns, firewall changes, system hardening reqs, etc)
Mana Website Creation Form
Critical Security Requirements
Itemize individual security blockers here. Reference components in section AppSec or OpSec subsections. These blockers must be addressed before the product can go live.
Stage 4: Development
Repeatable Security Test Cases
Document individual repeatable security test cases here. Include a reference to the source repo, and documentation that governs how to execute test cases.
Secure Coding Guidelines
Document specific secure coding guidelines to be followed and relate them to specific issues/requirements that are specified; capture bug ids related to those issues.
Code Review Milestones
Table 1 - itemized list of code review milestones {i.e. breakdown of specific components that will be reviewed} Table 2 - list of app components/modules that should trigger additional security review (e.g. auth, csrf, file upload handling, etc)
Stage 5: Release
Application Security Verification
These subsections should contain a list of the steps to be taken, and the status of each activity
Code Review
Automated Security Testing
Manual Security Testing
Operational Security Verification
ArcSight Information
Network Design Security Review
Database Security Review
Platform Security (Hardening & Specific Config Requirements)
Landing Criteria
This should be a table itemizing everything from Stage 3 - Critical Security Requirements, including status. For status Red=Unimplemented,Yellow=implemented,Green=tested and passed?
Stage 6: Post Implementation Review
Production Security Considerations
Document additional/ongoing work for this application (e.g. specific things to watch for in ArcSight, gaming behaviour, etc)
Post Implementation Tasks
Itemize process/kb changes developed from this project (e.g. secure coding guidelines, policy stuff, etc)
Team status notes
| status | notes | |
|---|---|---|
| Products | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |
| Engineering | tbd | - |