A bit of Mozilla history to brighten your tuesday. Since we're reminiscing about the old Mozilla days and how the Rapid Risk Assessment (RRA) method was created, I thought I would share how this methodology came to be.

Back in 2013, Mozilla Security was led by @_mwc and @jstevensen ran opsec. A bunch of us were grappling with the problem of triaging priorities across an ecosystem growing much faster than our security team.

We made a kickoff form to help with security review intake. Myself and others started thinking about ways to assign risk levels early on to drive engagement levels.

We were all preparing for a big workweek in Paris in September. @ygjb and @curtisko brainstormed ways to reduce our review backlog. @satefan and @psiinon prototyped risk visualization in Minion (remember Minion?).

We had no idea how important new initiatives were to the business at the time of scheduling reviews. A prototype was as important as a change to a core product.

I got fairly obsessed with the problem and, coming from a risk management background, started digging into my old books and manuals. French Mehari and Marion. Security Risk Assessment handbook. Etc.

I came up with something called ARUS that was trying to measure the security of a system. We never used this. It was kinda broken by design.

@kangsterizer visited me in Sarasota in the fall of 2013. We took long walks on the beach at sunset, talking about risk ranking. This is really when RRA was born as a concept (but it was only named that later).

We had tons of conversations and reviewed other methodology, like FAIR that @0x7eff contributed. Ultimately, we opted for something extremely minimal.

From the very beginning, "rapid" was a critical factor. We wanted to run those assessments in 30min to 1h, and it drove a lot of the design.

The first iterations, that we actually used for years, used spreadsheets and standard 4 level risk ranking. We tweaked the tables a bit, and talked to various stakeholders on which levels to use.

For example: financial loss. We went to talk to finance, and asked them what they consider high risk. Let's just say their scale was VASTLY different than ours!

The template we ended up with remained stable for years. I put those tables in Securing Devops because we still used them in 2016.

We started running RRAs internally. It was awkward at first. There was a distrust between security and engineering. A communication and priority gap we had to fix.

Bad management at the time made this worse and increased the divide by trying to turn the RRA into a business compliance process. Many of us pushed back, and brought it back to its true collaborative form.

This is an important lesson for security teams, by the way: focus on maintaining a collaborative culture before you try compliance. You CANNOT obtain compliance without the help of the organization.

@kangsterizer got a bit obsessed with improving the spreadsheet Here are some of the templates we used over the years.

@kangsterizer also spent a ton of time automating the parsing of RRA documents to build risk registers (which I cannot share). We're continuing that work today, and hopefully someday it'll be open source.

Some time around 2015, directors started asking for RRAs, engineers started to relax when they had to attend one, and conversations got more fluid.

At this point, I was more focused on cloud security (and writing Securing DevOps) so for a few years, @kangsterizer took the lead, ran hundreds of RRAs, wrote docs, and so on. He made this happen, really.

As I mention in the interview with @abhaybhargav, some teams started ASKING for RRAs around 2016/2017. We had managed to keep the process lightweight and enjoyable, so they wanted to threat model their apps.

Since the real strength of the RRA was the conversation with the engineers, @kangsterizer turned the spreadsheet into a google docs around 2018, released the 3 major version of our template. Methodology remained the same that you can find at https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html

I think this is it for the history of the RRA. We're certainly not done improving it. Automation and composing an org-wide risk register are still gaps.

But a couple takeaways in what I think made this successful: 1) there is no secret sauce here, but it's OUR sauce. It's made by Mozilla and for Mozilla. It fits nicely into our culture (chaotic-neutral).

2) Risk assessments and threat modeling is only as good as the data you get. And to get data, you need people to talk to you. Focus on good communication before anything else.

3) Similarly, people won't talk if they don't trust. Don't use risk assessments to stab people in the back, or force your agenda onto them. Build a culture, and issues will fix themselves.

4) Keep it lightweight. I ran perhaps two hundreds RRAs over the last 7 years, and it wouldn't have been possible if the process was any heavier.

That's All Folks. Go Forth and Model Threats!

Wait! There's more! @kangsterizer managed to dig up some old photos. Behold The RRA BrainStorm Of 2013!

And I wasn't kidding about those long walks on the beach...