Security/Reviews/CloudServices/Marketplace Frontend

From MozillaWiki
Jump to: navigation, search

Status

Identity (TEMPLATE)
<thead> </thead> <tbody> </tbody>
Tracker Bug
-
Stage
Definition
-
Status
Red (Green, Yellow, Red?)
-
Release Target
-
Health
-
-
Status Note
-
}

Team

Product manager / Feature manager Lindsay Saunders, Stephanie Turner and Caitlin Galimidi.
Engineering lead
Engineering manager Payments - Andy McKay

Marketplace -

Security lead Adam Muntner
Privacy lead
Localization lead Peiying Mo
Accessibility lead -
QA lead Krupa Raj
UX lead Elizabeth Hunt
Product marketing lead
Additional members Amy Tsay - Community

Scott DeVaney - Editorial Manager

Open issues/risks

Stage 1: Definition

Introduction

Links

Related

Use Cases

Architecture Diagram

Marketplace Frontend is represented by the UI Layer.

Mkt layers.png

Stage 2: Design

Threat Model

ID Title Threat Proposed Mitigations Threat Agent Rating Likelihood Notes Impact <thead> </thead> <tbody> </tbody>
align="center" style="background:#f0f0f0;" Notes
1 |Elevation of Privilege||Inappropriate access to read or modify data that the present user context should not be able to perform.||Malicious users||Rating #||Likelihood #||Notes.||Impact Score # – Impact||Notes.
-
2 |Tampering||Modifying or editing elements of Marketplace Application records||Application logic checks for proper authorization for ||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.
-
4 |Title text||Threat description||Proposed mitigation.||Threat agents||Rating #||Likelihood #||Notes.||Impact Score # – Impact||Notes.
-
5 |Title text||Threat description||Proposed mitigation.||Threat agents||Rating #||Likelihood #||Notes.||Impact Score # – Impact||Notes.
-
}

The Firefox Accounts threat model is inherited by Marketplace Frontend.

File:TEMPLATE-Threat-Model.png
TEMPLATE Implementation Dataflow

User Interactions

ID Summary <thead> </thead> <tbody> </tbody>
align="center" style="background:#f0f0f0;" Description
1. | HTTPS Port || All pages accessible only via HTTPS, all access is filtered through this point.
-
2. | Anonymously accessible web pages||Searching the Marketplace for applications, Metrics & Statistics, portions of Developer Hub
-
3. | Authentication reqd pages||Curation Tools, Operator Tools, Reviewer Tools, Admin Tools, portions of Developer Hub
}

Client Interactions

ID Summary <thead> </thead> <tbody> </tbody>
align="center" style="background:#f0f0f0;" 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 <thead> </thead> <tbody> </tbody>
align="center" style="background:#f0f0f0;" 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 <thead> </thead> <tbody> </tbody>
tbd
-
Engineering
tbd
-
-
Engineering
tbd
-
-
Engineering
tbd
-
-
Engineering
tbd
-
-
Engineering
tbd
-
-
Engineering
tbd
-
-
Engineering
tbd
-
-
Engineering
tbd
-
}