Wikimedia Security Team/Handbook

Jump to navigation Jump to search

Security Team Handbook[edit]


Please coordinate updates and changes with

Version 1.0


The security organization exists to serve and guide the community and foundation by providing security services to inform risk and to cultivate a culture of security


We seek to secure access to and the integrity of free knowledge.

Team Ideals[edit]

These are the kinds of behavior we as a team need to hold each other accountable for:

  • Integrity: For us to be successful folks have to trust us and we need to trust each other.  
  • Efficacy: in service and in self
  • Constructive conflict: is healthy and promotes a growth mindset. Challenging each other is a good thing and makes us all better.
  • Move on: Let go of the past, forgive, forget and start new.
  • Sharing: Share the knowledge you have, share your successes and your failures
  • Learning: be receptive to learning from others. Nobody knows everything
  • Healthy body, mind and team:  If you are stressed out, sick or just need a break, feel free to get away from all of this!  That doesn’t mean you can ignore your work forever but get out of here for a while and go for a walk, read a book, take a nap, stare at the clouds.  We need you but we need you healthy, none of this work is going anywhere and we will survive while you are gone. Part of building trust is being able to be vulnerable so it’s ok to talk about it and from time to time to step away from all this.
  • Reflection:  What went well, what didn’t, what should I do next time?  Everyday is an opportunity and you will both fail and succeed on a regular basis, adversity is your friend, failures are expected, cherished, a blessing and an opportunity.  Now get out there and mess some stuff up!
  • Teamwork: We are all in this together and the concept of teamwork extends beyond the security team. We each have a job to do here and while you may feel your approach is the best we need to respect each other and allow everyone to do their job.
  • Problem Solving: Solving problems can be tricky and is usually iterative so don’t be afraid to take a 1st step. Behaviors such as being combative, strawdogging, bikeshedding, and fixed thinking do not help forward the solution. Perfect is the enemy of good.
  • Practice gratitude: Be thankful. We have a great team filled with super awesome folks. Don't let negativity chart your or our path forward.

Please remember you are representing the entire team. Patience and civility are requirements for all communications.

Quarterly Goals, OKRs and development[edit]

This information evolves and new initiatives evolve and is subject to (potentially frequent) change.

  • Quarterly goal should be sized to be executed in roughly 6 weeks.
  • Goal will be developed with guidance from the Director regarding current priorities and needs.
  • Goal should be entered in Betterworks and properly aligned with team goals as needed prior to the beginning of the quarter. Exact dates for relevant meetings, dates, etc. will be provided by PM.
  • Updates to percentages and comments are to be entered in Betterworks monthly, at a minimum.

In addition to quarterly goals and OKRs, each staff member will have a personal development plan. These are reviewed and updated quarterly. It is the responsibility of each team member to complete these and review with the director of security. The purpose of this development plan is to help inform areas where each team member would like to grow.


Standing Meetings[edit]


  • Who: individual team member and Director
  • What: Come with your own agenda and if you don't have one the Director will provide one.
  • When / Where: Cadence TBD by team member but not to exceed 1 month w/out meeting.

AppSec Stand-Up[edit]

  • Who: Application Security engineers and PM
  • What: Review of ticket status, clearing of blockers, and triage if needed.
  • When / Where: Tuesdays at 8:45am PT via Google Hangout (invite only)

Team Meeting[edit]

  • Who: Security Team members and Director
  • What: This weekly meeting is intended to serve as an all-team touchpoint where news, shoutouts, and guest speakers provide relevant and timely information and general questions can be addressed.
  • Note: Asynchronous agenda building and communication via the Team Meeting Asana board is highly encouraged.
  • When / Where: Tuesdays at 9:05am PT via Google Hangout (invite only)

Fusion Center[edit]

  • Who: TBD
  • What: The Security team’s Fusion Center provides several functions, one of which is to serve as the intake point for work from all sources. This function is still being developed with more information to come soon.
  • When / Where: Usually on Mondays at 8:00am PT via Google Hangout (invite only)

Quarterly Retro[edit]

  • Who: Security Team members
  • What: A quarterly opportunity for the team to reflect on and discuss what does and does not work well. Action items are created to facilitate improvement.
  • When / Where: This meeting is held at the end of each quarter in Retrium, by invite only.

Meeting Protocol[edit]

  • Meetings are an important part of our team dynamic and should be accepted or declined asap, and at least 24 hours prior to meeting time.
  • Meetings are not optional unless you are specifically invited as an optional attendee.
    • The exception to this rule is 1:1 meetings.
  • Being late is sometimes unavoidable but do your best to be on time as a sign of respect to others.
  • We generally try to live by the 5 minute rule. If someone is 5 minutes late for a meeting we start without them.

Workflow and Intake[edit]


Intake channels must flow into the #security-team Phabricator workboard as canonical if they are to be triaged as part of Wikimedia Security Team work. Exceptions such as Privacy Engineering in Asana (and Phab), or #secscrum must be clearly and explicitly defined.

We need to have anonymous (as in non-community and non-staff) and external user support in limited cases.

We need to have support for non-Tech users to submit general requests for service.


Incoming work that follows a recognized workflow will be (at a minimum) discussed by the Security Team during our team weekly (or the appropriately designated) meeting.

These meeting may sometimes be delayed or canceled due to travel or other circumstances. The Security Team will do our best to communicate when circumstances result in longer than expected delays.

The Security Team is a limited component within Wikimedia Foundation and tasks that cannot be resourced or are not part of the team charter will be left with the general #security project attached as appropriate.


Ticket status should always be easily discernible by all stakeholders. This includes accurate and current board placement, priority, and privacy settings.

Team members should update/comment on tickets to which they are assigned monthly (at a minimum) and regardless of progress made. Not meeting this minimum of communication will result in the ticket displaying as "moldy" in the weekly team "Peek" report.

Work Hours[edit]

  • If you are going on vacation or will be out for half a day or longer, update the team calendar to reflect that you are out of office.
    • Create an event in the team calendar and then invite yourself to the event to have an easily updated entry on both calendars.
    • Do not provide additional details.
  • If you are sick drop a note to our team mailing list or Slack channel so folks are not trying to track you down.
  • If you take vacation time then you need to really take vacation time. This means disconnecting and spending your time away from work. If something bad happens we’ll figure it out. Enjoy your time off, you earned it!
  • As a corollary to the previous statement, if you feel like you cannot take off we need to discuss this as a team and make sure everyone has a backup. If you don’t have a backup now, let’s get that fixed ASAP.
  • If you are taking a remote training course, or working on remote continuing education this is is work time. Count it as work time. If you are in a week long remote SANS course, for example, you are not available for regular work and should concentrate on the material at hand. A rising tide lifts all boats :)
Service Backups Alt
Application Security Scott <-> Sam John
Security Risk John James
Privacy James John
SIR David<->Sam John
Security Governance David John
Security Engineering James Scott
Project Mgmt Jennifer James
Audit Scott Sam
Clinic David<->Sam Scott
Architecture James John
Vulnerability Mgmt Sam Scott

Recognized Communication Channels & Workflow[edit]


Team channel. It is expected that team members will be logged in and responding to Slack conversation during their personal work hours. :Additional team channels include #privacy-engineering and #app-sec.


Triage emails during weekly Clinic meetings (at a minimum).
Working group team list.
Triage emails during Clinic meetings (at a minimum).
Informal discussions only. Internal team list.
Email to individual team members
Any significant work is CC’d back to security-team@ with an associated task and standard triage workflow.


Getting Code reviewed[edit]

Significant code review work needs to follow the Security Readiness Review SOP.

Changsets must have an associated task (Bug XXX), that task needs to have the appropriate security service tag for relevant needs.

Changesets need to add the Wikimedia Security group as reviewers. No single team member should be singled out for review.


Many (if not most) of the tickets in Phabricator are publicly accessible. Special care should be taken to maintain professionalism in all on-ticket communications. This includes response time, tone, and content.

When protecting an existing task we strongly advise use of the ‘Protect as Security Issue’ feature rather than utilizing adhoc ACL and project combinations. This is on the right hand side of every task for escalation.



  • Incoming (default) =>
  • Back Ordered =>
  • Waiting=>
  • In Progress =>
  • Our Part Is Done
  • => Watching (Optional column for external to the team tasks we want to keep getting updates on)
  • => Frozen (Optional column for boards for long waiting work / work that may be abandoned by externals)

Rules of Engagement[edit]

Incoming (default)
When the workboard project is added to a task, or on task creation with the project they show up here. Tasks are meant to be triaged out of this column in the regular team or scrum meetings.
Back Ordered
This is the backlog of tasks to be assigned.
Tasks on which progress cannot be made due to a blocker. The blocker should be noted on the task. This is not the same as the stalled task state, although the two can mean similar things. Setting stalled here is appropriate for longer delayed work or to signal to external stakeholders progress is not forthcoming without intervention.
In Progress
Tasks currently assigned. Updates are expected at a minimum of every 10 working days. No tasks here should be unassigned.
Our Part Is Done
The scope of a task can include more than Security Team and so we name this column appropriately. Ideally, tasks are scoped so that our team's portion is a distinct task, but either way tasks that are 'done' go here.
Tasks for which the Security Team is a stakeholder but not an individual contributor. Tasks should be evaluated here for relevance on a regular basis. Tasks without updates in 180 days will be automatically removed with a note from the Security Team and the removal of our project tag. This column should not be used as a dumping ground for random security-related tasks.  If a task clearly has little probability of becoming a Security Team Back Order item or will likely never be followed up or re-engaged by a Security Team member, then our team tag should simply be removed.
Tasks for which there have been no updates, and no progress but are if they become activated are critical enough to keep tabs on.


Please avoid these patterns, and if possible automated or manual action should be taken to intervene where they exist. Tasks missing an expected update timeline are considered moldy, moldy tasks prevent an accurate picture of current workload and activity.

  • Assigned tasks that have no updates for 30 days. These really moldy tasks should be prioritized or unassigned for Back Order.
  • In Progress without an update in 10 working days.
  • In Progress without an assignee
  • Watching tasks with no meaningful updates in 180 days. (Unless a member of the Security Team is the author, and then it should probably be in backlog or closed.)
  • >10 tasks assigned to a single person at one time
  • Tasks where the Security Team is the clear owner which have been moved out of Incoming (default) with Needs Triage remaining as priority.
  • Tasks assigned to members of the Security Team without a relevant tag documented in our handbook. This is considered untracked work.


Security by itself does not indicate any specific team or function resourcing within the Wikimedia movement. Tasks reported via the official form will have the security-team tag added and will fall into normal weekly review queue.

Tasks converted via the ‘Protect task’ function will fall into normal weekly review queue.

Tasks in the ‘Incoming’ column of the kanban workboard will fall into normal weekly review queue. Tasks not #security-team are triaged to other tags with a comment as appropriate.
Tasks in default intake column will be triaged during specific review clinic scrum meetings
Privacy by itself does not indicate any specific team or function resourcing within the Wikimedia movement. See #privacy-engineering.
Subprojects will track work associated with defined Services and follow the regular security-team workflow unless otherwise specified.
Tasks in default intake column will be triaged during clinics and managed by the privacy-engineering workflow. See Asana section.

Task Tracking[edit]

The Rules of Engagement and Anti-Patterns may bristle against work or outcomes a member of the team wants to keep track of or further themselves. A comment on a task to that effect when unassigning is an effective means of signaling to the future. Task attributes are a part of team communications. This includes assignee.

Two features in Phabricator allow for personal task curation:

  • User projects: have been used for years by individuals who have a personal workflow and curation process. This is still technically in beta, but has been consistently recognized as valid for many years. This means having a User-<username> project to assign and manage. Everyone can see your project and workboards.
  • Flags: Are an individual way to bookmark objects within Phabricator. No one else can see what you have flagged.


Asana is used to create an agenda for the weekly Team Meeting, and to track any ongoing tasks that are created as a result of that call.

Asynchronous communication via Asana tickets is highly encouraged. Assigned tickets are to be kept current with regards to status.

Optional: if you would prefer to track ideas, tasks, and self-defined projects for yourself in Asana, please do! Talk to your Project Manager to get help setting up a system that will meet both team and personal needs.

Privacy Intake Form[edit]

Form submissions are triaged as part of privacy work board in Asana.

Asana is used by the team to track work related to our quarterly goals, as well as other work not being tracked in Phabricator.

We are continuously assessing our Asana practices, so expectations will be updated as we refine our team process.

Maintained Code[edit]

The Security Team typically works to review and assign risk to code we do not own in any way. However, there are a few code bases that we directly maintain:

  1. The wikimedia/security repository: this is a repository for mostly shell and python scripts, tools and apps which we use for various tasks and efforts. Please view the README within the tooling directory for more information as to our basic process.
  2. The SecurityCheckPlugin - A Phan plugin which performs security-focused static analysis, particularly optimized for MediaWiki-related code.

It is important to note that there are many security-related extensions, components and tools within the Wikimedia universe which the Security Team does not own in any way, though we may, from time to time, be expected to help improve or maintain.


As a team we have a documentation strategy. We also maintain a glossary of definitions and common language.


  • If you are creating new Policy or SOP then create a page either on (to work on it in public) or (to work in semi-private). It is preferred that policy and newly created content first be published on
  • Please watch the pages for the wikimedia security team category so that we can help maintain them and deal with vandalism as a team.
  • Updates to this team page should be vetted with project management with others within our purview as needed for clarity and current practice.