Wikimedia Security Team/Handbook
Security Team Handbook
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.
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
- 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
Quarterly goals should be sized to be executed within 90 days.
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.
- 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.
Suspect or harmful parties
- Notes on officewiki
Workflow and Intake
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 #security-readiness-reviews 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.
- If you are on vacation update your calendar to reflect that you are out of office
- Please update the team meeting notes if you are going on vacation or will not be available at all
- If you are sick drop a note to our team mailing list 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.
|Application Security||Scott <-> Sam||John|
|Security Risk||Chase <->John||James|
Recognized Communication Channels & Workflow
- 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
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.
Rules of Engagement
TBD: rules on how long tasks can stay in columns and what the curation process is.
- Incoming (default) =>
- Back Ordered =>
- 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)
- 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 readiness clinic to intake column of #security-readiness-reviews.
- 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.
Quarterly goals should be created as “milestones” on the your personal work board. Work that is *unplanned* should be tracked on your recurring Unplanned Work ticket.
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.
- 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).
- Please watch the pages for the wikimedia security team category so that we can help maintain them and deal with vandalism as a team.
- Update this page and others within our purview as needed for clarity and current practice