Security Team Handbook

Curation

Please coordinate updates and changes with acooper@wikimedia.org.

Version 1.0

Mission

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.

Team Ideals

These are the expected behaviors for anyone on the WMF Security team:

Trust

For us to be successful folks have to trust us and we need to trust each other.

We are all in this together and “ teamwork” extends beyond the security team.
We each have a job to do, and while you may feel your approach is the best, we need to respect each other. Allow others to do their job.

Adaptability

We value self-starters, collaboration, and initiative.

Solving problems is tricky - don’t be afraid to take a 1st step.
Perfect is the enemy of good.

Constructive discourse

Is based on active listening, clear documentation, and doesn’t shy away from conflict when appropriate. We aim to be compassionate.

Behaviors such as being combative, strawdogging, bikeshedding, and fixed thinking do not help forward the solution.

Move on

Strive for improvement, forgive, forget and start new. A single interaction with someone does not define who they are.

Culture of Learning

Don’t be afraid to push yourself, take on stretch goals.
Share the knowledge you have, share your successes and your failures.
Be receptive to learning from others. Nobody knows everything.
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!
- Tell someone! You’re not alone with your failure as soon as you share it
- Don’t let your manager be surprised - let them be your advocate.

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.

Be sure to follow guidelines and procedures where applicable

Practice gratitude

Be thankful. We have a great team filled with super awesome folks. Don't let negativity chart your or our path forward.

Make the effort to thank people. Do this publicly when that would be appreciated.
Speak with your manager if you feel as though additional recognition is warranted.

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

Goals and Development

Team Level: OKR's, KR's, and Goals

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

The Security team has a top-level (Foundation level) annual plan Objective and related KR
On an All-Security team level, we will have a Quarterly Goal (KR) that works towards the high-level annual plan KR/ Objective

Individual: KR's, Goals, and Development Plans

On an Individual level, we will have Quarterly Goals that are either in line with Personal Development Plans and geared towards personal growth, OR are focused on helping to improve services.
Individual goals will be created with input from the team member's Director / Manager.
Individual goals should be entered in Betterworks and properly aligned with team goals as early as possible in the new quarter.
Updates to percentages and comments are to be entered in Betterworks monthly, at a minimum.
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 their manager. The purpose of this development plan is to help inform areas where each team member would like to grow.

20% Time

What is it?

All members of the Security team are expected to spend 8 hours (20%) per week on work that either:

is related to Capabilities Management / MTP work
furthers Personal Development Plan goals

When is it?

Team members are expected to adjust their schedule to accommodate 20% time however, several members of the team are dedicating Fridays as a way to prioritize and to commit to this work.

What else do I need to know?

20% time work should be documented on the team 20% Time Asana board
While 20% work may span multiple weeks, broad / general tickets are not appropriate documentation. Every week there should be sufficient planning and detail that is it clear what you are hoping to accomplish.
If you would like to create an epic-style multi-week ticket for your 20% Time project, then weekly subtasks would be needed to meet the requirement of specificity and documentation.
Collaboration is encouraged. Encouraging collaboration is encouraged.
20% time requires workload management so that you are not working 100% plus 20% time. If you find you are struggling to create space for 20% work, please speak with your manager.

Communications

Monday Heartbeat

Who: All-Security
What: Using Know Your Team, the weekly heartbeat is an opportunity to share the work that is being done and to learn about what others are doing.
When / Where: Mondays via Know Your Team

1:1

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

AppSec Stand-Up

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

Team Newsletter

Who: Director / Manager w/ team contributions as desired
What: This monthly email newsletter is intended to provide relevant and timely news and shoutouts as well as reminders and upcoming events.
When : TBD

"What's Happening?"

Who: All-Security
What: "What's Happening" is an opportunity for teams and individuals to present what they have been working on over the last quarter. Reflecting on goal progression, successes and failures, and celebrating hard work is all encouraged.
When / Where: This meeting is held at the end of each quarter via Google Meet (invite only)

Quarterly Retros

Who: Individual teams
What: A quarterly opportunity for teams to reflect on and discuss what does and does not work well. Action items should be created and owned to facilitate improvement.
When / Where: This meeting is held at the end of each quarter in Retrium. (invite only)

Annual Retro

Who: All-Security
What: An annual opportunity to come together and reflect / discuss what does and what does not work well from an All-Security perspective. Action items should be created and owned to facilitate improvement.
When: Q4

Meeting Protocol

We subscribe to the notion of fewer, better meetings. We will make every effort not to schedule meetings that could be emails or slack messages, and not to invite people to meetings unless their attendance is essential.
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
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

Consistency

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.

Commitment

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 meetings 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.

Communication

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.

Work Hours & PTO

We support the following philosophy, as stated by Gitlab: "Not taking time off is viewed as a weakness and people shouldn't boast about it. It is viewed as a lack of humility about your role, not fostering collaboration in training others in your job, and not being able to document and explain your work. You are doing the company a disservice by being a single point of failure. The company must be able to go for long periods without you. We don't want to lose you permanently by you burning yourself out by not taking regular time off."
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 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 :)

Recognized Communication Channels & Workflow

Slack

#security-team: 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 , #app-sec, and #talk-to-security.

Email

security@: Triage emails during weekly Clinic meetings (at a minimum).

security-council@wikimedia.org: Working group team list.

security-help@: Triage emails during Clinic meetings (at a minimum).

security-team@: 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.

Gerrit

https://wikitech.wikimedia.org/wiki/Gerrit_Notification_Bot

Getting Code reviewed

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.

Phabricator

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.

Workboards

Taxonomy

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

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.
Waiting: 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.
Watching: 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.
Frozen: Tasks for which there have been no updates, and no progress but are if they become activated are critical enough to keep tabs on.

Anti-Patterns

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.

Projects

Security: 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.

security-team: 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.

secscrum: Tasks in default intake column will be triaged during specific review clinic scrum meetings

privacy: Privacy by itself does not indicate any specific team or function resourcing within the Wikimedia movement. See #privacy-engineering.

Security-Team-Services: Subprojects will track work associated with defined Services and follow the regular security-team workflow unless otherwise specified.

privacy-engineering: Tasks in default intake column will be triaged during clinics and managed by the privacy-engineering workflow. See Asana section.

Task Tracking

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

Asana is used to manage a variety of goals and projects across All-Security, individual teams, and members.

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

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

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:

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.
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.

Documentation

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

Expectations

If you are creating new Policy or SOP then create a page either on mediawiki.org (to work on it in public) or office.wikimedia.org (to work in semi-private). It is preferred that policy and newly created content first be published on office.wikimedia.org.
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.

Wikimedia Security Team/Handbook