4 Reasons It Pays to Have an Internal Offensive Security Team Early
When I tell people about our Offensive Security (or OffSec) team, I’m often met with puzzled looks — even from the security community.
Most companies either use third-party Offensive Security teams or don’t engage them at all until the company is much larger. Cruise is still building a self-driving rideshare service, and it’s rare for a pre-revenue company to have a security team, let alone a 6 person OffSec team. But safety is a cultural tenet at Cruise, which is why we have an OffSec team to simulate the techniques of real adversaries to test our ability to detect and respond to attacks.
For those curious about this, I wanted to share four reasons why Cruise created a dedicated OffSec team before launching a public service. I’ll also explain how we fit into Cruise’s overall security strategy.
Having an OffSec team early means quicker impactful changes
When OffSec teams review software for vulnerabilities, they’re not typically involved until most of the software has been written and key architectural decisions have been made. Testing becomes difficult as projects grow because the software tends to accumulate external dependencies, customers, become more complex, etc. This makes it more expensive (in both engineering time and money) to change directions, so companies have started involving OffSec teams earlier in the software development process.
But OffSec teams don’t just review software. They also look for vulnerabilities in the company more generally, like its internal network or business processes. Similar to software projects, the later you find these problems, the more expensive they tend to be to fix because of inter-team dependencies, employee retraining, etc. Given that safety is a key value at Cruise, and the fact that we’re still a relatively small company (1000+ employees and growing), we’ve integrated OffSec not only at the beginning of our software development lifecycle, but also the beginning of our company’s lifecycle. This allows us to look at the company from an attacker’s perspective early enough to make big changes.
Offense-driven defense
Another core value at Cruise (and a big reason why I love working here) is “radical focus”. The entire security team is encouraged to be very particular about the projects we accept and devote ourselves fully to the few we do select. However, it’s not always obvious which vulnerabilities an attacker is most likely to exploit, making it difficult to prioritize effectively.
You could (and should) read reports on how real threat actors operate, or how companies are typically compromised, to inform your priorities, but often the best way to find out is to try it yourself and operate under similar motivations and constraints. This is exactly what our Offensive Security team does.
The rest of the security team uses that information to prioritize everything — from fixing vulnerabilities to large security initiatives — so we can tie everything we do to a realistic threat. Before Cruise’s self-driving rideshare service launches to the public, it’s critical that we work on the most effective security projects instead of mitigating vulnerabilities that are unlikely to be exploited. It’s challenging, but it helps us make the best use of our resources to keep the company safe.
In-house OffSec creates tighter integration and less abstraction
In the book Rework, Jason Fried and David Heinemeier Hansson discuss the idea that layers of abstraction can be harmful. For example, rather than writing a document describing the requirements for a web application’s home page, it might make more sense to draw it. The document is more abstract, which can be misinterpreted or ignored, which immediately brings to mind the long, wordy, abstract OffSec assessment reports we’re used to seeing. These tend to end up sitting on an open file share, collecting digital dust until the next red team finds them and uses the (still unfixed) vulnerabilities on its operation. Sound familiar?
Outputs from third party OffSec teams tend to produce these understandably abstract outputs because it’s costly to integrate with the large, diverse set of tools, software stacks, and engineering teams at each of their clients. Even if a third party wanted to dedicate a consultant to a client, it’s only temporary, and the knowledge about the environment they obtain tends to get lost when they transfer to a different client. It doesn’t have to be this way.
Cruise’s OffSec team removes that abstraction by integrating with the engineering teams, security tools, and technologies. If we find a vulnerability in Cruise software, rather than write a document describing the fix, we “draw it” by helping write the code to fix it and add tests to automatically verify the solution. If we find a vulnerability in software on the network that we can detect with a low false positive rate (to avoid endless triage queues), we write a plugin for our vulnerability scanner. If we find a gap in Cruise’s detection capabilities, we write a rule for our intrusion detection systems with accompanying tests in Metta. And if we really need to demonstrate value or build consensus for something, we produce something more abstract, like a presentation. “Drawing” outputs helps us make faster progress fixing security issues, clearly articulate the value of our work, and build trust with our engineers.
Team trust is built with internal OffSec teams
People think internal OffSec teams have fun breaking things and lobbing the unpredictable, tedious, and difficult work over to the rest of engineering. I’ve observed many OffSec teams have an adversarial relationship like this with other engineering groups and believe a collaborative, internal OffSec team can go a long way towards improving this relationship. That’s precisely what Cruise has done.
One way we do this is by being heavily involved in the remediation work we create (as mentioned above). We also collaborate with our engineering teams daily, integrating them throughout our operation lifecycle. We have established clear lines of communication with our defensive security teams to ensure we don’t waste their time investigating our activity when we’re not on a red team. We also contribute directly to their projects by writing intrusion detection rules, and deploying Metta.
Most importantly, we’re all deeply invested in the mission and the success of the company, so we’re committed to working together, learning from each other, and doing our best work.
We have more to come on the cool OffSec projects we’re working on and the tools we’re developing. If you’re interested in joining our Security team in the meantime, check our open roles — you’ll find us under the “Engineering — Product & Infrastructure” department.
