GitLab's internal red team extends the objectives of penetration testing by examining the security posture of the organization and their ability to implement effective cyber defenses.
Penetration testing is a specialized type of assessment conducted on information systems or individual system components to identify vulnerabilities that could be exploited by adversaries. Such testing can be used to either validate vulnerabilities or determine the degree of resistance organizational information systems have to adversaries within a set of specified constraints (e.g., time, resources, and/or skills).
Red team exercises provide more comprehensive assessments that reflect real-world conditions over penetration testing. The exercises can further be used to improve security awareness and training and to assess levels of security control effectiveness. GitLab utilizes NIST 800-53 Revision 4 security control CA-8 to define the red team and their mission. The control can be found on NIST.gov.
The Red Team operates under a pre-defined set of rules of engagement. The rules of engagement exist to inform GitLab's team members on how the team operates during engagements. It provides guidelines for determining scope, the ethics we employ during our engagements, how we collaborate as a security team, and how we escalate vulnerabilities and exploits we discover during those engagements.
Further details can be found in the job family description.
Most Red Team operations are planned and approved before any actions are conducted (see Red Team Open Scope for more information). Each operations consists of the following steps:
GitLab maintains a document titled "Data Classification Policy" (team members can find this by searching Google Docs) that categorizes digital assets based on levels of sensitivity.
The Red Team maintains a secure project that builds threat models on top of these classification policies.
While planning a new operation, the first step is to ensure there is alignment with an existing threat model. If not, the existing model should be updated or a new model created.
Operations should have a clear goal, generally in alignment with one of the following:
Any GitLab team member can participate in the proposal or discussion of an upcoming operation. The process is as follows:
Ongoing operations are documented in GitLab projects in a group that is, by default, accessible only to the Red Team. Completed operations will be moved into a group that is accessible to all GitLab team members. Because of this, it is important to keep the following in mind:
New operations can be documented as follows:
An operation may be considered complete after the Red Team has worked through the proposed activities. There may still be work for the Blue Team to do (identifying activities in logs, etc), but this may be more productive after the operation is shared with all GitLab team members.
The following steps should be taken:
At this point, there is value in having the operation accessible to all GitLab team members.
The following steps should be taken:
GitLab values transparency and openness as part of our day to day business, it is one of our core values. The Red Team supports these values however there will be cases where we do not share information. In general if the details or output of a Red Team exercise introduces risk to GitLab customers, GitLab, or GitLab business partners we will choose to not publish or share that information until the risk has been mitigated. We will always strive to share our techniques and custom tooling but will sometimes need to keep results confidential for an extended period of time. In addition the Red Team will, when possible, share techniques and tooling via our Tech Notes.
Red Team will work with the SecOps and other teams as necessary to advise remediations. We attempt to automate as much of each operation as possible to aid in validating that remediation are, in fact, completed and effective. At this stage of an operation, all issues related to the operation are properly addressed and validated by the Red Team.
The steps to follow are:
The Red Team follows GitLab engineerings recommendation to perform regular retrospectives. These may be performed on a regular cadence or, at minimum, just prior to completing an individual operation depending on need. The objective is to improve the performance of the team by taking an honest look at what went well, what went poorly, and specific, actionable takeaways to iteratively improve the team in terms of our technical and collaborative skills.
The steps are all outlined in the link above. A new issue should be opened on the operation's project to ensure the retrospective is completed.
There are multiple reasons to iterate over past/completed operations. The GitLab environment is changing, new attack techniques are discovered, the Blue Team has improved detections and want to re-assess those regarding past scenarios/operations.
In those situations, the Red Team is creating a new branch in the chosen past operation project, naming the branch with an increased version number (i.e. v.1.x.x), and configuring the branch as the default one. This way, it is possible to iterate over past operations, make appropriate changes to the new versions and continue the cycle described above. Operations may therefore have multiple branches, having the initial operation in the master branch and the potential multiple versions/iteration that were performed over time on it in separate branches.
Some activities are considered open-scope, meaning that they can be conducted at any time, from any source IP address, and against any GitLab-managed asset without prior approval or notification. The output may or may not be included in the reporting for planned operations, depending on the results and whether or not it is helpful to the Blue Team.
If these activities are detected by SecOps, they should be treated as potentially malicious and acted upon appropriately. Unless part of a planned operation, there should never be an assumption that suspicious behaviour is a Red Team activity.
Conducting open-source intelligence (OSINT) gathering against non-GitLab managed assets, such as social media sites, is also considered open-scope and may be conducted outside of planned operations.
If an open-scope activity uncovers a vulnerability that puts GitLab at immediate risk of compromise, SecOps will be notified via the official paging procedures.