I've noticed a trend among my peers in cybersecurity in recent years. It might be personal bias, or a symptom of the age and history of the people I tend to associate with, but increasingly they're asking themselves why the overall state of cybersecurity isn't improving.
That's a very good question, especially considering the talent of the people in the industry, how hard they work, and how much money is invested in both product and people.
My current answer goes something like this: People trying to excel at self-taught technical skills are suboptimal at the strategic decisions required for such a nebulous conflict, their emphasis should be on teamwork and on the strategies of, and constraints on, their adversaries; they should seek inspiration elsewhere.
Cybersecurity experts have—unintentionally—created an industry that advocates technology over process, individual technical skill over the so-called soft skills required for teamwork, and a bunker mentality that focuses on preventing any kind of compromise and strengthening perimeter defenses regardless of context or adversary. All of the strategic decisions seem kind of obvious, and seem as if they should work, yet seemingly devastating breaches are so commonplace they barely register.
This is the current strategy of the cybersecurity industry and its members. "Strategy" is as vague a term as "cyber"; it means different things to different people depending on their history and their context.
What we need are new strategies within security, and within DevOps and DevSecOps, to improve the overall security of our software products. Here's my punt on that.
Don't reinvent the DevSecOps wheel
The DevSecOps mentality and culture promote a rapid response to security issues and a mindset of continual improvement. Rather than expecting to foresee and prevent all possible attack methods by an adversary before a system is deployed, it promotes a more rapid response to security issues.
Also, the emphasis on the "continuous" side of CI and CD means that continuous assessment of possible security risks is seen as part of the normal development lifecycle.
The speed of DevOps is intimidating to a security mindset and doesn't fit in well with current security processes—from annual audits and penetration tests to vulnerability scans and similar processes.
But DevSecOps doesn't fix all of the security issues in our applications and infrastructure. We need to adopt "analogical thinking"—to look at those in situations similar to ours in some way, see what lessons they've learned, and then simply use their lessons in our own practice.
[ Special Coverage: DevSecCon Seattle 2019 ]
It's game on for red teams
One of the main sources I look to for new ideas and thinking on this is the study of warfare, particularly through the practice of wargaming. While the quality of software isn't defined solely by its ability to resist attack, from a security point of view all of the risk an application involves arises from the actions of an adversary of some kind.
I think that because wargamers have studied conflict in so many ways, they have much to teach us. One example is the emphasis on outthinking or outmaneuvering your opponent rather than simply trying to create a numerically and/or technically superior force.
Also I look to American football (as we call it here in the U.K.), which exemplifies the situation in which we find ourselves. There are clear roles for attackers and defenders, and incredible complexity in the makeup of teams and in the tactics and strategies that can be applied.
The primary idea to take from football is the use of a "scout team"—having your second-string players and other backups imitate a forthcoming opponent. Why practice against the strategies and tactics of all possible opponents, or concentrate solely on your own abilities and plays, when you know who you're going to face? Think of wargaming, of The Caffrey Triangle variety, an analysis of how you wish your practice adversary, your sparring partner, to behave.
But an analysis of how much you wish your practice opponent to imitate an adversary—and how much they should just defeat you in any way they can—would require its own article.
Go big or go home with DevSecOps
Apart from that I look, appropriately, to the philosophy and strategy of the Seattle Seahawks and Pete Carroll. I pick and choose a couple of the most appropriate aspects of the way they've played, especially during the "Legion of Boom" era. Most notable are the realization that giving up yards isn't the same as giving up points, and the emphasis on intimidating your opponent.
Of course, there are many aspects of the Seahawks, and the game of football, that aren't relevant to cybersecurity: You know who your opponent is, referees are the ultimate arbiters of what is and is not permitted, and so on. But I often find it useful to see where an analogy breaks, as well as where it applies. If we reject any other area as a source of ideas because they don't all apply, then the strategies will never change, and the level of compromise will continue.
I'm always interested in more theories and sources. Of course, the study of conflict is a huge undertaking, but I'm interested in the most basic concepts, with the most drastic changes.
Adopting the notion of counterattack
One of those basic concepts is the idea of a counterattack: simply launching an attack immediately after, or even during, your opponent's attack. Commonly derided with the standard objections to "hacking back," this is not an idea that cybersecuritiy teams commonly adopt.
Within their own estate or infrastructure or applications, defenders typically adopt a bunker mentality: build it as securely as you can, wait for it to be attacked, and if or when it fails, rebuild an even bigger, stronger bunker.
For inspiration from warfare, look to the evolution of German military tactics in World War I, as Germany's generals developed the idea of the Eingreif division, a unit specifically designed to counterattack and respond dynamically to opposing forces, even during the seemingly immobile environment of trench warfare.
For sports, look back to the Seahawks and note how their cornerbacks jammed the opposing receiver at the line of scrimmage. Why wait for the receiver to complete his route and react to the throw? Why not disrupt the "attack" as soon as it develops?
What your team can learn from conflict
The move from a default model of siloed waterfall development to DevSecOps' integration and velocity is conceptually simple, but drastic in its implications.
There are similarly sweeping changes that have been shown, in other areas of conflict, to have a significant influence on the effectiveness of defenses.
For something new, look at the emphasis on the "whiff punish" in fighting games such as Tekken and SoulCalibur—being ready to strike as soon as your opponent misses an attack while your opponent's character is still running through the graphic for that attack.
Maybe that seems like a silly example, but when video game players are more innovative than industry professionals, might we have a problem?
I will be presenting my latest thinking at DevSecCon Seattle on September 16. While the presentation is set, the thinking behind it isn't. I welcome your feedback on the latest iteration.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
