CEO SafeStack | Co-Author Agile Application Security.
As an industry, we spend much time debating why security has yet to become recognized as part of building quality software. We invest in tools and appliances that compensate for this gap and build programs encouraging our teams to embrace a more holistic approach to keeping our people, data and systems safe.
While many of these approaches have yielded results, particularly in our larger, more established organizations, for many companies, the gap between development and security remains broad and challenging to cross.
There are a range of views about what causes this divide. These range from lack of education and awareness to some (less healthy organizational cultures) and cultural toxicity that has formed over the last 20 years.
Misaligned Incentives Drive Adversarial Practices
At the heart of many of these cultural issues, particularly those with the most significant divides between software development teams and their security counterparts, are misaligned incentives.
Every role within our organization has a part to play in the overall success of its strategy. These are primarily encouraged in the form of roles and responsibilities and rewarded in the form of incentives. These individual incentives, such as bonuses and promotions, can be applied to a group.
In most organizations, people will focus on the responsibilities of their role and aim for their incentive package.
Understanding Software And Security Incentives
In software teams, we incentivize behaviors that drive innovation, product velocity and engagement. This drive toward “building amazing products at speed” allows our organizations to innovate and move quickly in a demanding market. It also suits the personality and motivations of many in the software industry.
As software professionals, we like solving problems, doing well and going fast. Ask a software engineer what causes them the most pain and friction in their role, and you will no doubt find factors like holding too many meetings, lack of focus time and uncertain direction or requirements—all items that get in the way of their core incentives—innovation and speed.
Within the security space, our responsibilities and incentives are very different. Our role in the organization is to understand and reduce risk. While this is a simplified description of what we do, we are rarely incentivized to go faster and innovate.
When security interacts with software, we see a very clear pattern emerge. The incentives of these two groups need to be more aligned so that it often results in conflict. The security team will aim to reduce risk by implementing intentional friction and vigilance throughout processes, often at the expense of speed. The software team is wired to see any friction or obstacle and engineer their way around it. It was never going to end well.
Finding Common Ground In Uncertainty
Underneath this misalignment, though, is a commonality that could hold the key to how we approach application security in the next 10 years.
That shared root is how we feel about uncertainty.
Security is the domain of uncertainty, of “it depends,” and of creative experimentation and unexpected use cases. Security issues exist because individuals and groups have strong enough motivation and opportunity to explore a system unexpectedly to further their ambitions.
An attacker doesn’t come with a single, foolproof plan. They come with creativity and flexibility centered around accepting uncertainty and experimenting.
This makes software development teams and security teams very uncomfortable.
As software developers, we enjoy solving problems—to a certain degree, this is a binary activity—the problem is either solved or not. We aim for the “happy path” or the elegant and frictionless solution to solving an organizational need. As mentioned earlier, we find it stressful when multiple paths or unclear requirements exist.
As security professionals, we need to reduce risk, but the biggest challenge in that space is not finding a solution; it’s identifying how our systems and processes can be used to cause our organizations harm. We refer to this as our attack surface, and as many of us know, this surface is a lot more challenging to understand and monitor than we would like. Additionally, the number of individuals and groups who may choose to act against us (whether opportunistic or deliberately) combined with the infinite range of motivations for doing so create massive uncertainty.
In both cases, this uncertainty results in the inability to meet our responsibilities and a failure to meet our incentives.
Can Changing The Way We See Uncertainty Lead To More Secure Software?
Sadly, no magic solution can remove uncertainty from software security risk. However, there are ways for us to change our teams and their incentives to make uncertainty less painful for everyone involved.
This starts with making uncertainty visible.
Threat modeling is a powerful tool for showing the breadth of possible issues and unexpected situations a system can face. Make the most of this process as a tool for facing and connecting over uncertainty.
1. Ensure that both software teams and security collaborate on these activities to share their viewpoints and connect over the absurdity of our challenge.
2. Don’t skip to solutions: The beauty of the threat model is understanding how our systems can be used and how this differs from our original intention—make sure you don’t assume that certain events are not possible or likely. Be creative in your initial ideas and discussion and only suggest solutions and security controls later in the process).
3. Incentivize the recognition of uncertainty, whether by recording security debt or potential threats or connecting over changes in the world of technology and how they could change your organization.
While our teams need to be more aligned regarding our overall incentives, at our core, we all feel uncomfortable with the chaos and uncertainty that is the risk we face every day. Use that to unite our teams; we may find security feels much more achievable and team-focused.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
