At GitLab, our Red Team conducts security exercises that emulate real-world threats. This gives us an opportunity to assess and improve our ability to deal with cyber attacks.
These types of exercises require a lot of planning, which is traditionally done by getting folks from multiple departments into the same room at the same time to discuss hypothetical scenarios and expected outcomes. Then, actually conducting the attacks and validating the detection/response capabilities is, once again, traditionally done by people who are physically sitting in the same space.
Like many things at GitLab, we are not quite so traditional.
Each member of our Red Team is separated from the others by a literal ocean, with about eight hours difference in local time between us. Our entire organization works remotely, and the various groups we need to involve in these exercises are spread across the world.
We understand our approach is unique. However, more of the workforce is moving to remote work models, so we recently spent some time writing down what works for us when doing these types of complex exercises asynchronously across time zones. Keep reading to see what we came up with and how you can use it yourself.
Defining an asynchronous workflow
If there is one thing we've learned about working remotely, it's that you need to write things down. In a traditional office, it's possible to have a back-and-forth conversation in a matter of minutes. Conversations across time zones and departments, however, can take days when you're not co-located. This is why we use our public handbook as a single source of truth for how we run the company and why we decided to use this same spot to document how our Red Team will work to propose, plan and execute operations.
Purple Team process
As you can see, we've broken down the process of "Purple Teaming" into nine unique stages. Each of these stages is supported with a GitLab issue template that clearly explains what must be completed in order to move to the next stage.
At GitLab, we use the term "Purple Teaming" to describe an exercise where emulated attacks are done in the open: Everyone involved knows what the attack is, when it is coming, and exactly what techniques will be involved. When we perform more traditional "Red Team" exercises where stealth is involved, we use roughly the same process; only with less active participants.
When we begin planning an operation, we open a new epic on gitlab.com. Inside that epic, we open nine new issues using the templates linked above. Everyone involved in the operation will have access to these issues, and everyone can clearly see what has been completed and what comes next.
New Red Team issue
While it may seem like a lot of stuffy process, this level of clarity and transparency gives us the freedom to focus more on the interesting work and less on figuring out who should be doing what next. Even better, the process is open source: Anyone with an idea for improvement can simply open a merge request to discuss. This includes you: We would love to hear from the community to continually improve this process.
Dive deeper into our workflows and templates
Our Red Team makes an effort to share resources that others may find useful. Here are some links to the items we've discussed above:
-
Purple Teaming in the GitLab handbook: what Purple Teaming means to us, why we do it, and what our workflow involves. We use roughly the same process for more traditional “Red Teaming” where stealth is involved.
-
Red Team issue templates: These templates break down the details required to progress through each stage of our process. Feel free to fork the project and use them as you see fit. We're open to contributions, so check out our tips on how to get started.
If you have thoughts about this process, or there are other Red Teaming topics you’d like us to tackle, please share in the comments below. Thank you for reading!
Cover image by Andrey Grushnikov on Pexels
