Wikimedia Security Team/Goals 201516

= Goals =

All goals are in addition to training, reviews, and security bug work.

Q1 (July-Sept 2015)
1. Automated dynamic scanning of MediaWiki in beta. This is an area where the WMF trails industry practice. In addition to finding flaws before malicious users do, integrating dynamic scanning (along with static analysis) into the development process should allow teams to take more ownership of the security of their code and ensure security is not a blocker for teams to "deliver on-time and on-budget". Additionally, dynamic scanning will give the Security Team quantitative measurements related to the security of code produced by different teams, which may be useful in identifying trends over time. During this quarter, we will:
 * Pick tool to implement
 * Configure weekly automated scanning from labs of beta (coordinated with RelEng - )
 * Record baseline scan results for core and one extension

2. Document and report initial metrics for security bug handling. The security team currently operates without defined KPI's. Since security bug handling is a core process for the team, we will define metrics that may measure the health of this process.

The team will also support other teams in the following initiatives
 * 1) Support legal during rollout of email encryption initiative
 * 2) Support privacy for Analytics initiatives
 * 3) Support Reader Infrastructure in deploying AuthManager
 * 4) Support Fundraising Tech for PCI

Q2 (Oct-Dec 2015)
1. Automated security static analysis of MediaWiki (depends on budget request)
 * 1) Evaluate Checkmarx, Veracode, Pfff
 * 2) Setup weekly static scans of mediawiki core, critical extensions, and services (depends on 1.1)

2. Expand developer training 3. (stretch) Document and report initial metrics for security review process
 * 1) Present secure code and secure SDL training for community and staff
 * 2) (stretch) Develop and present security training materials for DevOps and Mobile (potentially outsource)

The Team will also support other teams in the following initiatives
 * 1) Support privacy for Analytics projects (Wikistats, Uniques)
 * 2) Support security and privacy for Services' event propagation
 * 3) Support security initiatives by Ops (Authn, logging)
 * 4) Support Auth improvements by Reading Infrastructure
 * 5) Anticipated Security reviews:
 * 6) Revscoring and Link Recommendations for Research
 * 7) Article Placeholder for Wikidata

Q3 (Jan-Mar 2016)

 * 1) Allow two-factor authentication for CentralAuth wiki accounts

The Team will also support other teams in the following initiatives
 * 1) Support Legal's implementation of Privacy by Design principles and training
 * 2) Support 3rd party security audit for Privacy
 * 3) Support Reading Infrastructure to deploy AuthManager in January
 * 4) Support FrTech finishing their PCI work
 * 5) Support Ops on codfw switch, Horizon
 * 6) Support OIT rollout of two-step authentication for google apps
 * 7) Support Analytics RfC on Unique Identifiers

Anticipated Security reviews:
 * 1) Reading - MobileFrontend / loading (client, maybe restbase work) (T120341)
 * 2) Reading - Hovercard+popups gadget merge (later in the quarter) (or alternative)
 * 3) Reading Infrastructure - AuthManager (continued)
 * 4) Reading Infrastructure - GPGMail (T114341)
 * 5) Discovery - Kartographer (T120922)
 * 6) ORES extension (T120922)
 * 7) Community Tech - "2 wishlist items"

Draft Q4 (Apr-Jun 2016)
(draft goals due March 11, 2016)

Potential goals for Q4:
 * .onion address for Tor readers. By encouraging readers to use Tor, we decrease the amount of sensitive information we collect on users, reducing the impact of a security breach.
 * Implement CSP report collection, enforce CSP headers on upload.wikimedia.org. CSP will help us reduce the impact of many XSS flaws, as well as preventing inclusion of 3rd-party hosted resources which impacts our user's privacy. Realistically, we could probably setup a report-collection endpoint, and enforce strict policies for upload.wikimedia.org in one quarter.
 * CentralAuth password authentication service. Reduce the impact of a security breach by isolating password hashes into a smaller, more well-defended cluster of servers. In a single quarter, it's likely we could get a PoC service written, and begin setting up a cluster within the production cluster to run the service and databases. This would require significant support from Ops, and some support from the Services team.
 * Improve dynamic testing to increase coverage. Instrument MediaWiki to enable coverage measurement (similar to bawolff's AFL instramentation) and measurably increase the coverage of what we scan each week.
 * Trial bug bounty program. We have multiple vendor offers to setup a program, and assist with triage of reports. The risk is that this would significantly increase the number of security bugs we have, which the team is already having trouble addressing.
 * Data access policy for all users with access to sensitive data. This is currently in progress, and planned for on the Privacy roadmap. This will ensure teams have a policy when they access sensitive data, and codify some of the security processes to secure that data.
 * Mobile security training. We have 6 engineers writing mobile code, and we currently provide very little support to those teams for security. This would likely be coordinated with a training provider, and the team would also support the mobile developers following up from the training. This would depend on support from Reading / Mobile teams.

The Team will also support other teams in the following initiatives:
 * 1) FrTech - PCI completion
 * 2) Legal - PbD implementation

Anticipated Security Reviews:
 * 1) Newsletter
 * 2) Indego-depict
 * 3) Reading - new service
 * 4) Reading - Hovercards
 * 5) Editing - ImageTweaks (T126492)
 * 6) Editing - UploadsLink (T129609)
 * 7) Discovery - DOMPurify (T125382)
 * 8) Discovery - json schema (T129426)

= Context & References =

Strategy
WMF Strategy Preview

Specific things called out that effect the Security Team:
 * The WMF can become a "Thought-lead on Privacy, Accessibility" (slide 56)
 * To "improve the core", there is emphasis on metrics for each department, specifically: (slide 61)
 * Score cards & KPIs
 * Outcome-based budgeting
 * Improved, clear success criteria for projects

2015 Call to Action
Strengthen Technology & Execution Focus on Community & Knowledge Experimentation & New Knowledge
 * We will define our commitments -- and deliver on-time and on-budget.
 * We will make our decisions based on data.
 * We will improve our process for community input and allocate dedicated technical resources to community requests.
 * We will update legacy architectures and deliver mobile-ready infrastructure and services to support structured data, user security, and a simplified user experience.
 * We will integrate across community engagement functions to improve communication and results.
 * We will create a central, multilingual hub for community support.
 * We will have a working plan to support emerging users and communities.
 * We will improve our measures of community health and content quality, and fund effective community and content initiatives.
 * We will integrate, consolidate, and pause or stop stalled initiatives.
 * We will create spaces for future community-led innovations and new knowledge creation.
 * We will facilitate and support new models and structures for knowledge curation.
 * We will strengthen partnerships with organizations that use or contribute free content, or are aligned with the WMF in the free-knowledge movement.