Page MenuHomePhabricator

Establish secteam production norms
Closed, InvalidPublic0 Estimated Story Points

Description

Historically, there hasn't been much of a risk and compliance charter and the narrowly focused security team on the org side was not related to infrastructure. Additionally, there are already infrastructure and such roles that handle that burden under SRE. So with a slightly expanded secteam in existence now that has @chasemp and @Dsharpe and the possibility of expansion we need a more defined setup.

Current challenges:

  • security team members assist in incident response and investigation and especially in the coordination between various realms (onwiki, business, technical groups) but this work has largely been adhoc in process and method
  • secteam has one root of historical inheritance
    • This permission would not be given to the next security eng hire (meaning it's terrible to wrap process around)
    • There is no defined permissions for a security eng hire within the security team
    • Our own risk and compliance analysis process would put this in violation of least-privilege principle
  • technical secteam members can conceivably be useful in any context for information sharing and investigation but have a variety of shell presence (not meaning any privilege even just presence)
  • There are a few sensitive and/or private configurations (now and soon) that are being managed adhoc. The current options are to have root manage them (not practical or fair to SRE) or figure out better solution:
    • Elastalert rules that are to be kept private
    • modsec rules that are to be kept private for apache on developer tooling
    • logster alarm rules (if we want to keep this -- config files on mwlog* are owned by dev groups so that all of secteam can manage them, but this leaves them open for more users than desired)
  • Evidence collection and persistence norms do not really exist. This has become a fairly common process but still adhoc and as-of-now dependent on root presence within the security team which is noted above as bad)

Proposed outcomes:

  • T223463 Create a secteam shell group without privilege. This can be used for evidence sharing, config sharing, etc between members of the group.
  • TBD: Create a default process for evidence gathering that involves the secteam group.
  • T223463 Create secteam-admin (engineers, analysts) that has mostly RO/View type permissions for assisting in investigations or evidence gathering.
  • T224887: modsec rules deployment with scap
  • TBD: elastalert private rules deployment (scap or private gerrit repo?)
  • Remove root for @chasemp to comply with least-privilege

Event Timeline

chasemp triaged this task as Medium priority.Jun 3 2019, 2:29 PM
chasemp created this task.
sbassett changed the status of subtask T223463: (2019-09) Create secteam groups in admin.yaml and define permissions from Resolved to Invalid.
sbassett moved this task from Back Orders to Frozen on the Security-Team board.

Closing as invalid for now, as this is quite dated and much of this task would need to be re-reviewed at this point.