Security/SOP/Application Security Reviews

Review Required by: 12th February 2020

Purpose
The purpose of this Standard Operation Procedure (hereinafter referred to as SOP) is to document the requirements for individuals in need of a pre-deployment security code review.

Process
Before a new feature or significant change* to an existing feature or extension, service, or library is deployed or is intended to be deployed to production on SRE-managed hardware, it needs a security review by the Security Team.

Typically, WMF teams or individual MediaWiki developers embarking on a new project should plan to have 2 or 3 check-ins with the Security Team.
 * This SHALL NOT include routine changes which are typically submitted through Gerrit and handled via standard code review
 * This SHALL NOT include security patches or other discretely-deployed code
 * This SHALL NOT include apps running under Cloud VPS, even high-visibility apps like Quarry, etc.
 * This SHALL NOT include any user-JavaScript or Gadgets which may run on various Wikimedia wikis
 * This SHALL include various Node services and python applications or tooling which will run under SRE-managed hardware (in addition to MW core and extensions)

If there are any questions as to what constitutes the requirement for a security review, please contact the Security Team (security-team@undefinedwikimedia.org).

Concept review (optional)

When considering a new project, if there is any doubt that the feature might not be a good idea for security, or might negatively impact user privacy, you can optionally consult with the Security Team during the Concept phase of your project. Typically emailing the description of your project to the Security Team (security-team@undefinedwikimedia.org), or a 30-minute meeting with a team member, is enough to identify any potentially serious issues.

As an example, consider an extension that would allow users to include 's in wiki pages, to embed content from other sites. This would be a concept that would be inappropriate for Wikimedia, as it would allow leaking user IP addresses to third parties, in violation of our Privacy Policy. Having a concept review before any work is done on the extension would prevent wasted effort on an idea that is not-workable in the context of Wikimedia.

Design review (optional)

When you have completed enough planning for your project to know broadly which systems will be involved, what data will be handled by your project, and what new services or endpoints users will interact with, then you should have a design review with the Security Team. This review is to ensure that you have controls in place to address specific threats, based on your architecture. During this review (or the optional Concept review), the Security Team can also suggest a way to reduce the attack surface for your project, which will reduce the security requirements for your project.

Typically, this is a 60 minutes meeting between the technical or architectural leads for the project and a member of the Security Team. Although this review is optional, doing it allows issues to be identified early in the project, instead of at the end of the project.

Security review for deployment (mandatory)

Projects MUST have a "Security Readiness Review" task in Phabricator documenting that they have performed a pre-deployment security code review, and addressed any blockers before they can deploy a new extension or major feature.

This review will ensure that the controls identified in the design review have been implemented prior to implementation.

Additionally, the Security Team will attempt to ensure that the project avoids common implementation flaws.

There are three possible results of this review:


 * No issues found, extension can be deployed (provided other requirements at Review queue are met). (Example: T148583)
 * Only minor issues found, or any major issues found are straightforward fixes. Extension can be deployed once the found issues are fixed. (Example: T149808)
 * Major or complex security issues found. Once the identified issues are fixed, the extension will have to be re-reviewed. (Example: T133408)

Expectations

 * All code SHOULD avoid the top 25 CWEs, and comply with the requirements of Security for developers/Architecture.
 * Libraries SHOULD encourage safe practices by the developers who use them, or clearly document when misuse can result in a security flaw.
 * Services SHOULD use a standard framework or service template.
 * External applications (services, or applications such as media conversion utilities) used by the code SHOULD not have known, open security issues. The application SHOULD be supported by a competent security program.
 * For external application or libraries, a WMF team MUST be committed to being alerted about and fixing any security issues that are fixed by the upstream developers.
 * The people developing the code have already reviewed it, and believe it to be secure. See also Wikimedia Security Team/Security reviews/What we are looking forWikimedia_Security_Team/Security_reviews/What_we_are_looking_for

Review process

 * 1) At least 30 days prior to the estimated deployment date, the requester creates a Phabricator Task using the Security Readiness Review request form.


 * 1) Weekly, the Security Coordinator reviews Requests that come into the queue.
 * 2) The Security Readiness Review request MUST include the following information (as templated within the request form):
 * 3) Name of tool/project
 * 4) Description of the tool/project
 * 5) Description of how the tool will be used at WMF
 * 6) Name of the individual/group requesting review and primary contact
 * 7) Name of the individual/group responsible for tool/project after deployment and primary contact
 * 8) The target date for deployment (or approximate date deployed if already in production or labs)
 * 9) Information from any review of the tool that has already been conducted
 * 10) Working test environment
 * 11) Programming language(s) used
 * 12) Source code repository location
 * 13) Upstream project home page (if applicable)
 * 14) WMF project home page (if applicable)
 * 15) Related Phabricator tickets
 * 16) Related patch set(s)
 * 17) Security Coordinator checks that the Task is at least 30 days prior to deployment date or puts the Task in the queue for prioritization and contacts owner of the Task.
 * 18) Security Coordinator checks that Task has ALL required information; if the Task is missing information, the Security Coordinator sends the Task back to the owner and holds the Task for 3 days awaiting information.
 * 19) If the Task meets the requirements in items (4) and (5), then the Security Coordinator approves the Task, assigns it to a Security Team Engineer and places the Task in the  “In Progress” queue.
 * 20) See the #Security-Teams Readiness Reviews workboard for currently planned reviews.
 * 21) The “In Progress” queue reflects all active Security Readiness Reviews. These tasks typically have target completion dates of two to four weeks.
 * 22) A Security Team Engineer will review the Task and if approved, will comment on the Task and update the Task as resolved, if appropriate.
 * 23) If your project is not on the schedule and you believe it should be, or if you have any questions about the Security Teams Readiness Review process, please (contact the Security Team) as soon as possible.
 * 24) If your Task is reviewed by the Security Team Engineer and requires action on your part, the Task will be placed in the Waiting on Response/Mitigation queue. The Task may reside there for no more than 30 days.
 * 25) If the Security Team Engineer has not received a response within 30 days for the above, the Task will be moved to the Frozen column.
 * 26) Tasks that have been on the Frozen column for more than 180 days will be removed from the Security-Team-Reviews project.

Escalations
If there is a need for escalation of a Task, the Director of Security will review.