Security/Reviews/CloudServices/OperatorShelfTools
Contents
Status
Cloud Services - Marketplace - Operator Shelf Tools | |
---|---|
Tracker Bug | [1] |
Stage | In Progress |
Status | Green (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
An operator shelf is a collection-like object that provides a centralized place for operators to showcase content (feed) to their customers.
The feed is a stream of content relevant to the user displayed on the Marketplace home page. The feed is comprised of a number of feed items, each containing a singular of piece of content.
The goals is for Operators to be able to maintain their own "shelves" for geographic regions, phone types, etc.
Operator Shelf Tools
Source code: - marketplace-operator-dashboard
API (Zamboni)
Documentation: - accounts - feed
Staging test environment:
- https://marketplace.allizom.org/operators/login
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
Also inherits threats from Marketplace Frontend
ID | Title | Threat | Proposed Mitigations | Threat Agent | Rating | Likelihood | Notes | Impact | Notes |
1 | Authorization Failure | Inappropriate user is able to manipulate or insert arbitrary content into an Operator Shelf Feed | Application authorization checks. | Unauthorized users. Authenticated, but unauthorized users, on a per-shelf basis. | Rating # | Likelihood # | Notes. | Impact Score # – Impact | We could receive negative press. |
2 | Title text | Threat description | Proposed mitigation. | Threat agents | Rating # | Likelihood # | Notes. | Impact 4 – Reputation | 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 |
[[2]] | Title | Status(Open/Closed) | Summary. |
[[3]] | 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 | - |