One old card game that could be what DevSecOps has been looking for

The news seems to be full of companies suffering serious breaches of security. As a consumer of their various services I am left baffled, bewildered and disappointed. At the same time, as a participant in the process of delivering online services I understand their thoroughly complicated internal architecture and can understand, if not forgive, a lot of what is going on (with the possible exception of the Facebook “View As” breach).

How we outgrow this

One of the things this industry has become good at is retrospecting and improving. This is thanks to the empirical agile mindset in general. Particular thanks is also owed to the efforts of a network of coaches and intellectuals who make a living bringing smart solutions to common problems, and the publications and conferences that curate and popularise their ideas.

A theme in this network, since at least 2009, has been the coaching of historically separate teams of developers, and operations personnel into a more aligned team structure and a more open collaborative culture. Dubbed “DevOps”, this change has brought the best out of each of these separate functions, ensured everyone’s incentives are aligned.

What is DevOps?

Having worked in a DevOps context, running what I was building, and building our own pipeline, I know that while tooling is useful it is the cultural alignment which really matters.

I’m not the only one:

“If you think DevOps is a toolkit and not a practice you’re missing the point. If you think it’s a role and not collaboration between roles you’re missing the point. If you think it’s a team and not an organisational feedback loop you’re missing the point. The goal of that journey is the acknowledgement and recognition that software is safer when people with complementary skillsets in technical operations and software development work together, not apart”

Enter DevOpsSec

Next, starting no later than 2012 someone (I am not sure who, but there is a manifesto) came up with DevOpsSec. According to Shannon Lietz it has the goal of:

“safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required”

That sounds like another cultural realignment to me. You cannot direct creativity by pushing responsibilities onto people. At some level people have to embrace these responsibilities to be able to uphold them. That means slowly and respectfully educating and incentivising a change in mindset.

Elevation of Privilege

It is with this understanding that I was very excited to spot the security card game “ Elevation of Privilege”. It was invented in 2010 by Adam Shostack at Microsoft. It is a gorgeously produced card deck at the centre of a gamification of a security checklist, modelled after the game called Spades. This game precedes DevSecOps perhaps by two years and it seems it has been somewhat overlooked. Yet this game was designed from the outset with the goal of creating a cultural alignment:

“Elevation of Privilege, a game designed to draw people who are not security practitioners into the craft of threat modeling. The game uses a variety of techniques to do so in an enticing, supportive and non-threatening way.”

Of course, threat modelling is not a whole security solution, but it is the beginning of the process of identifying the work needed to make something more secure. Getting new people into the problem of doing Ops is what DevOps guru’s have been discussing for years and it may be just what DevSecOps gurus need to help distribute “security decisions at speed and scale to those who hold the highest level of context” as Lietz put it.

How Elevation of Privilege works

There are a few subtle reasons why I felt EoP would help create this alignment, which were called out by Shostack in his whitepaper:

Elevation of Privilege works, in part, because it provides structure and constraints to the successive evaluation activity. This aids in balancing ability and challenge in those learning to threat model.

That structure divides up a huge base of knowledge about recognisable threats, mistakes and anti-patterns and helps people like me to access it. It is dumbing down without loss of detail.

Also Shostack felt that the cards are effective boundary objects:

A boundary object is one that is used in different ways by different communities, and allows members of different communities to refer to some [concept] at the boundary of their intersection … In threat modeling, where security and software engineering communities come together, there are several important boundary objects, including software diagrams, bugs, and (potentially) Elevation of Privilege cards. The cards were designed to work as one of these boundaries, with a need to provide affordances to members of both communities

One of those affordances might be for a developer to take a card that represents something meaningful or concerning to them, and wave it at a security expert who is able to validate or reject the developer’s suspicions and assist them in focusing on the correct actions to take for their project. If this sounds like a useful feature of of your team culture, then you need this card deck.

The game requires 3 to 5 developers, which means I am unable to play it here at Agile Stationery. However, looking the cards is itself an educational process and a cognitive call to action. We have produced a small stock and I am looking forward to introducing this game to the London scene. Initial reactions have been very favourable, and I hope to organise a play-testing session at the Agile Games Workshop soon.

I went looking for Elevation of Privilege as a new product to sell for purposes of making a profit. It would delight me beyond words if that search resulted in meaningful security mitigations being put in place and real progress in the application of software security.

Originally published at https://agilestationery.co.uk.