‘War games’ are military exercises that are used to test or improve tactics and strategy under combat conditions. They put soldiers into the position of fighting an ‘enemy’, and test them to see how they will react. These war games are an essential part of forces training, because it is nearly impossible to practise fighting in any other way—and it is important that soldiers and other military personnel are properly trained in what is a fundamental part of their job.
It is a basic principle that to find out what will happen in a particular circumstance, you need to test people under those conditions. This is the basis of any simulation. This idea of ‘testing people under fire’ has led to the introduction of simulation exercises in business. They have particularly been used to test crisis-handling skills, but also in change management scenarios—which, let’s face it, are seldom well-managed in reality. The thinking is that by being involved in a simulation, people will have a better understanding of what will be needed in practice—and will have developed the skills and experience to manage effectively.
Security testing
The idea of strategy or war games has also spread from basic military exercises to security testing more generally. A common practice in military exercises is the idea of ‘red vs. blue teams’. The ‘red team’ is the attacker—usually an external group brought in to challenge the ‘home team’, known as the ‘blue team’. In military exercises, the blue team would be the defenders, and the red team the attackers in a combat simulation.
There is definitely something unique about security of any kind. You simply cannot test your own security. It is impossible. By definition—and assuming you are good at your job—if you can identify a vulnerability, you will have fixed it. You will have set up your systems to avoid as many vulnerabilities as possible, and to enable you to identify and shut down attacks as quickly as possible—in your opinion. But what if someone else thinks in a very different way, and that opens up holes in your security? Security requires a unique approach to its testing: one that brings in outsiders. It is, in other words, the ideal place for using the idea of red and blue teams.
Indeed, in the US, security organisations have used the red and blue teams idea as a way to test cybersecurity. ‘Red teams’ are hired to attempt a cyber-attack on the organisation, with the ‘blue team’ being the team responsible for security. For added realism, the ‘blue team’ may not even be aware that the attack is a ‘red team’, and not a genuine attack. The idea is to test the organisation’s security against a cyber-attack, and particularly to identify vulnerabilities and allow them to be fixed ahead of any real attempt.
Change, DevOps and security
So far, so straightforward. You build in security, and then you test it. Simple.
Except. Except that how we develop software is changing. The new buzzword is DevOps, and it is all about developers and operational teams working together to produce software that works in practice, and does what is needed. Instead of being an iteration, it is an end-to-end process, and that means that security has to be built in from the very beginning: DevSecOps, if you like. This is hard, because we have traditionally relied on developers to think about that and do it.
In many organisations, this requires a massive culture change, from relying on the developers to ‘sort security’ towards a mindset of ‘security is everyone’s problem’. However, moving to this mindset means that there are more minds on security. In many ways, this could actually make the entire organisation into its own red team—and also the blue team in response. By getting everyone to think through vulnerabilities, and how the system could be attacked, it will be possible to develop a much better and more secure solution.
DevOps is, by its very nature, an agile approach. It is all about bringing the right people together to deliver quickly for the organisation. Incorporating the security aspects may be a bit more challenging, but creating an agile red-blue (purple?) team in this way could enable a much better outcome.
Taking this forward
We think there may be potential to use this kind of approach in many other sectors, businesses, and circumstances. But what other business use cases do you think could benefit from this approach?
