In 2016, Mayhem — then still a research prototype — showed that fully autonomous cybersecurity was possible. This was just the first step.
Today, I’m thrilled to announce the next phase in the ForAllSecure journey: Mayhem is now available to any DoD or intelligence community organization via a $45 million ceiling contract. Mayhem is deployed and already helping the DoD in DevSecOps, for T&E (Test and Evaluation), and cybersecurity teams make the world safer.
In the remainder of the post, I want to share why we are working with the DoD. Our partnership with the DoD up until today has renewed our mission and informed our tech. I’m extremely proud of the growth we’ve made in the product and the company. I am grateful to my ForAllSecure family, our DIU partners, and our strong believers in the DoD. Here’s to quick reflection on our journey to today.
Nuclear submarines. The B2 bomber. Special operations command. The national security agency. As a young professor, I spent 4 weeks every summer visiting these sites as part of the (unremarkably named) Computer Science Study Group, a research program run by DARPA and the Institute for Defense Analysis. I have unforgettable memories from these trips. I remember the first time I was staring at the earth through a glass window as an airplane slowly moved up for an air-to-air refueling from a KC-135. Did I also mention that they let me take MILAIR (Military Aircraft Transportation)? I didn’t even have to turn off my electronics during takeoff!
When I recount these memories, they’re met with many oohs and aahs. For some of us, they might even be the reason to engage the DoD. Admittedly, it’s a welcome side effect for me, but it’s not the reason. There is something very special about securing a physical object — something you can point to and touch. The systems the DoD builds are safety-critical, designed to last decades, and required to be secure against nation state actors. I assure you, this is no exaggeration. It’s not commonplace to have the opportunity to secure something that flies at Mach 2!
Take the F-15, for example. The F-15 was designed over 45 years ago, before the Morris internet worm. The USS Nimitz is just as old; it was commissioned in 1975. The F-22 Raptor first flew in 1997 — well before format string vulnerabilities were widely studied. All of these systems need to last decades. This is unthinkable today. With the advent of IoT, as soon as the software is outdated, the technology is considered disposable. It’s refreshing to have technology seen as non-disposable, even though it has a 3 year lifetime at best.
I say 3 years at best, because cybersecurity is evolving. We can’t “build once secure” forever; that just doesn’t work. It presumes you know what science will come up with in the future, whether it be cache-based timing attacks or ROP exploitation.
What I mean by this is: it’s not a surprise these systems are vulnerable; we simply didn’t know as much about cybersecurity today as then. That doesn’t mean the original designers were dumb or negligent; it just means they built the system in a different time. In the old days, we used to say “you need to build secure”. That doesn’t work. What we’ve learned (and it’s hilariously obvious now) is that cyber is continuously evolving.
I wanted to work with the DoD because they were committed to making technology last. If vulnerabilities were to be found in a F-22, their solution wouldn’t be to get rid of it. They are a team committed to iterating. I’d rather work with a team committed to iterating than an armchair quarterback commenting from the sidelines any day. The men and women I’ve had the opportunity to meet (and I’m including you here, intelligence community) have a sense of ownership. And, it may not seem obvious on the surface, but their dedication also means they are making a personal commitment to making the world a safer place. That’s something special and a team I’d like to work with.
We take pride at ForAllSecure to help find solutions. We believe, as do our partners in the DoD, that we must start moving faster than the adversary. Mayhem helps them do that. We built Mayhem around that idea of continuous security.
In 2016, we showed fully autonomous security was possible at the DARPA Cyber Grand Challenge, and Mayhem was the winning approach. Mayhem had three key components:
- Discovery. Mayhem automatically found new vulnerabilities in commercial-off-the-shelf (COTS) software, even without developer participation.
- Patching. Mayhem automatically patched (to the security expert, a better term is probably “harden”) programs.
- Strategy. The goal of cyber is to beat the attacker while still meeting mission/business objectives. If uptime wasn’t a consideration, you could simply use wire-cutters on your CAT-5 cable to “secure” the system. Strategy means you need to be smart about both offense and defense.
DARPA billed Mayhem, along with our competitors, as “Artificial Intelligence”. The competition was seen as a big step forward in the cybersecurity world, and the innovative technology that came out of the event as significant as those that came out of their self-driving car challenge. (Note: I still prefer the word “autonomous”, but the fact Mayhem made decisions a human would normally make qualifies. That’s a discussion for another time).
It’s a long road from research to practice. I hoped the brilliant, talented team at ForAllSecure would be able to defy historical trends by using our smarts to quicken our way to practice, and in so many ways we have. To put it in perspective, the first autonomous car challenge was in 2004. Now over 15 years later, we’re just starting to see the full vision in practice with Uber, Tesla, Argo.ai, Aptiv, and others. Our rapid path to today couldn’t have happened without our loyal believers within the DoD.
It was critical to our success to find two types of DoD advocates: a transition advocate and a design partner. I don’t think these are special; the same thing happens in commercial space when you talk about “who is the buyer” vs. “who is the user”.
Transition advocates help you work through DoD rules and regulations. All that red tape has a noble purpose: protect the American taxpayer (keep reminding yourself of that when it gets annoying). Traditional DoD defense contractors have experience navigating those rules themselves; startups don’t have the bandwidth or time commitment to tackle the federal acquisition regulation (F.A.R.). The Defense Innovation Unit (DIU) has been a great partner to help us sail the federal waters, but there are others, such as In-q-tel and sofwerx.
Design partners are the users. They help refine your research prototype. We tackled a hard, ambitious, big problem. Our design partners help us break the problem and prioritize. They also help work through issues you may not think about, such as how you deploy, how you upgrade, and even what tutorials you need.
One thing we learned from our design partners was to focus on autonomous vulnerability identification. Mayhem did three things in the Cyber Grand Challenge: vulnerability identification, patching, and strategy. Each one is a multi-year journey to break research into production for the end user. You won’t satisfy everyone, but you will learn what solves the largest problem for the most people.
We also learned to make sure your design partners commit to help you with the iterations. That’s a nice way of saying “you will fail a few times when deploying new tech; you need a friend.” Many of our partners have seen and provided feedback on dozens of iterations of Mayhem. I remember Mayhem 0.4; it was terrible in more than one dimension. We’re now on 1.4; it’s wonderful thanks to their feedback and our team, who took many hours to truly listen to and understand their needs.
The time and commitment of early design partners pays off: they get a solution that works really well for them, and also have the confidence ForAllSecure is committed to them over the long term. We don’t believe in dumping technology in your lap and walking off.
ForAllSecure’s go-to-market is unique. We started working with the DoD even before commercial customers. Many are perplexed to learn that we want to address the federal market first. Why did we do that?
In his Secret Tesla Motors Master Plan, Elon Musk says “almost any new technology initially has a high unit cost before it can be optimized.” This is coming from a company that is creating self-driving tech a decade after autonomous vehicles were first shown possible in the DARPA challenge. ForAllSecure, and our path from the Cyber Grand Challenge, is similar. We had new tech; we couldn’t just throw a cheap UI on our DARPA prototype and call it done.
To solve such a problem, you need to find an initial market whose value received is greater than the initial product R&D costs. The DoD is responsible for billion-dollar, safety-critical equipment and missions. A single flaw in a system not only costs money, it puts their mission at risk. Match made. Since then, we’ve found other markets where software can make or break the mission, such as in aerospace, automotive, and core internet infrastructure. But having those first adopters who see the value, and know it’s not $5/month initially, is important.
Some are confused when I call the DoD a market. I call it a market because the DoD is a market. It’s not a single buyer. Many people call it one buyer, and that’s patently wrong. The fact that the entire DoD is funded by the taxpayer seems to be the red herring.
DoD organizations buy separately and have different missions. I’m not talking at the level of the Air Force vs. the Navy. I’m talking at the unit level. For example, we work with multiple units within the Navy — some have a cybersecurity mission, some are doing DevOps, and some are doing test and evaluation to make sure what the government buys is fit for purpose. Mayhem has shown value across all these buyers and use cases.
We also chose to work with the DoD because we knew several of their use cases are applicable to other industries, making it easier to expand to other markets. At ForAllSecure, we were careful to do partnerships in both the DoD and commercial industry to ensure we designed Mayhem to hit a broad need. We think this is important. For example, both the DoD and commercial industry needed tools that provided actionable results for vulnerabilities. However, there were several differences. For example, they differed on deployment models. The DoD focuses on deploying on-site, often on highly secured networks. Indeed, actionable results like Mayhem can be classified. Industry, however, often deploys on Google GKE or Amazon AWS. We carefully built out Mayhem so we could deploy in either scenario. It took maybe 20% longer to do, but it was worth it.
ForAllSecure is continuing to advance the art of the possible in autonomous cybersecurity. There are three parts in our strategy.
- Build a community. The love and support of our users, and the community of researchers and visionaries working on next-generation fuzzing and symbolic execution is critical. Betamax failed over VHS; and the best solution to make sure the best tech wins is to build a community around it. That’s why we support efforts like FuzzCon, fuzzing meetups, and education.
- Adapt Mayhem to other languages and OSes. Mayhem today supports compiled languages, such as Go, Rust, C, C++, and so on on Linux. It proves vulnerabilities. A fully autonomous system can’t be guessing whether a vulnerability is real (and we believe neither should your business). However, the way you prove a vulnerability changes from a compiled binary to an interpreted language such as Java. We are building Mayhem to support more languages, and in the long term, more operating systems. We’re not a simple scanner, so this requires a deep analysis that actually understands how programs execute.
- Build out autonomous vulnerability remediations. Here is a secret from CGC: one of the key advantages to our system is we autonomously tested patched before deploying. We were really good at it. Mayhem could tell you whether a Mayhem-generated patch would have 2% or 5% performance impact. We’ve already built in the ability to perform regression testing into Mayhem to support the full software lifecycle. But there is more. Our initial market research indicates the world is not ready for fully autonomous patching — not for tech reasons, but for legal reasons. The thesis among lawyers is that if Mayhem patches the software as in CGC (even when reliable and performant), you may be violating your EULA or may no longer be entitled to support. Without revealing too much, we think we can solve this problem.
Early adopters, such as our initial commercial customers and DoD customers will get a first look at this technology. If you are interested in participating, let us know.
It’s been a long, but rewarding road to hitting this significant milestone. It couldn’t have happened without my ForAllSecure team and our DoD partners. I’m so proud of what we’ve accomplished so far, because I see it so clearly as a foundational component to making the world’s software more secure, safe, and resilient. Thank you to all those who supported us along the way.
It fills me with great pleasure to say: join me, as we unleash Mayhem!
*** This is a Security Bloggers Network syndicated blog from ForAllSecure Blog authored by David Brumley. Read the original post at: https://blog.forallsecure.com/mayhem-moves-to-production-with-the-department-of-defense