top of page
  • Phil Venables

Incentives for Security: Flipping the Script

We’re getting it wrong on the messaging for incentives to do security - and people are pretending it’s landing when it isn’t. 


There are 5 main categories of security incentives:


  1. Loss avoidance. The problem is many losses don’t outweigh the potential accumulated actual or opportunity costs of the mitigations that would have been needed to avoid the loss.

  2. Reputational risk / brand protection. The problem is most people forget these issues, and are acclimated to it (e.g. identity theft protection). Besides, often a company comes out looking better if they respond to a crisis well enough.

  3. ROSI (Return on Security Investment). The problem is it should be useful but it mostly isn’t because the calculations are often soft, something like “if I deploy MFA then I save 5 mins per month on Help Desk support time per person which equates to 5-person years which means a saving of $500k p.a.”….the problem is rarely is the cost of the 5 people actually removed from the budget. 

  4. Security as an enabler. The problem is people probably were going to go ahead, do just enough tactically and punt the risk to another cycle, in any case. 

  5. Regulatory compulsion. The problem is complying with the letter of the law or regulation doesn’t always achieve the sustainable spirit of what is needed. 


Of these 5, the one I see most effective in driving large scale action in organizations is regulatory (or legislative) compulsion especially when the consequences are sufficiently large fines or, even more motivating, when licenses to operate in certain markets can be revoked. The problem remains, even in these circumstances, engineering the “right solution” might still not be done. Checking the boxes in rigorous ways can meet the goals even if what is really needed is to do some work such that the boxes are checked as a mere side-effect of more sustained and cohesive risk mitigation. 


Instead, to get organizations to be truly incentivized to do security we need to focus on 5 things:


  1. Don’t just focus on security

  2. Focus on tail risks

  3. Deliver real and big enough savings

  4. Improve measurable customer experience

  5. Address status-quo disincentives

Let’s explore these. 


1.Don’t Just Focus on Security

Instead, focus on selling the need for things that deliver massive commercial (or mission) benefits and also - perhaps incidentally - deliver improvements in security and resilience. Some examples:


  • Software reproducibility. Having all your software under control and capable of being reproducibly built and reliably deployed in an integrated delivery pipeline delivers increased reliability, product agility, efficiency and other benefits. But, clearly, this also brings huge security and resilience benefits as vulnerabilities can be more easily discovered, common security flaws systematically solved, patches applied with less fear of change risk and in various disaster scenarios there is the confidence systems can be rebuilt / redeployed in predictable time.

  • Infrastructure reproducibility. Likewise, adopting an infrastructure-as-code approach (on premise or in cloud) can achieve similar commercial or mission benefits as software reproducibility - it could even be the same pipeline - with just as strong security and resilience benefits. Effective infrastructure and software reproducibility is a boon to ensuring recoverability in the event of extreme outages e.g. ransomware events. 


  • Preventative maintenance. A big root cause of many of wider systems issues (of which security is a side-effect) is insufficient budget or resources. Lack of resources reduces the ability of a team to undertake activities like maintenance, technical debt pay down, or other work that would in other realms be considered preventative maintenance. There’s likely no correct level for this but it’s reasonable for there to be an assigned budget amount, expressed as a percentage of the wider operating budget, that can go up or down each year (or quarter depending on your budget processes). It’s reasonable for management or the Board to dictate that this budget increases according to prior failures (a signal that more maintenance is needed) or it can decrease because of the positive effect of maintenance once that has been fully demonstrated (to avoid premature cutting). The key point here is to make that budget eat into or free up the operating capital or expenditure of that business / department so there are aligned incentives.

 

  • Reduce potential blast radius. In the face of expected events, including security events, identify the means of reducing the impact of those events. Reducing the blast radius of non-security events (e.g. reliability and performance at peak customer demand) can often be more cost justified than security, but the blast radius reduction if done in the right way can also reduce consequences from security events.  

  • Inventory Triangulation. Building inventories to identify and cost-manage assets can provide tremendous returns as well as the incidental security benefits of having precise knowledge of what is in your environment. This can deliver more benefit at less cost by taking advantage of the network effect of linking (or triangulating) multiple inventories together. I’ve seen many organizations remove $M’s in unused assets simply from discovering them.


2.Focus on Tail Risks

Identity existential risks to the company, that which if they were realized would end the company. Then, of course, work to reduce the likelihood of these. But, most importantly work to cap the impact so that they’re not existential even if realized. 


A big part of this focus on tail risks is to get to the right risk transparency. There is often a gap between top layers of management and teams closer to where the actual operations of the organization are. When lower levels of the organization have a clear view of what might be existential risks there can be a sense of amazement that the “higher ups” don’t want to do something about those risks, or somehow don’t have enough incentives to do so. 


In reality, the actual issue is the senior leadership doesn't have the right visibility to such risks. When they do, there are often very clear and personal incentives to do something about it, either to mitigate the risk by implementing controls and adding resilience, or to take steps to cap the consequences of the tail risk such that it is not existential if realized. The question then, is how to increase the flow of risk information up the organization in the face of powerful forces that oppose this, like the tendency to exaggerate upward reporting of good news and to downplay bad news. There are a few techniques to this:


  • Define minimum viable delivery objectives. Use some kind of operational resilience framework. This encourages the whole organization to explore beyond the boundaries of day to day resilience to more severe but plausible events.

  • Conduct stress tests. Do these for real in test environments, through simulations or tabletop exercises. Again, so leadership and teams at all levels can come together to confront the reality by exploring the edges of accepted risk.

  • Fast(er) escalation. Sometimes, though, this alignment of incentives only works at the right level in the organization. Decisions taken lower down, where constraints overlap and disincentives are in play, are reversed higher up by people who have more personal skin in the game should the risk manifest itself. So, thinking of it this way, the escalation of significant risk issues is a service for leadership, in other words it is “escalation as a service”.


3.Deliver Real and Big Enough Savings

Figure out ways security can actually reduce cost - not just a percentage of headcount saved by time that is just funny money - but actual savings by reducing, for example, capacity, capital equipment, operational expenses, insurance premiums, withheld risk capital etc. Other examples can be of stacked small improvements as long as they do actually reduce costs with lower budget, returned capital and expenses or otherwise tangibly show other approved budgets can now be reduced. For example:


  • Reduce the cost of controls. Either by replacing controls with more modern designed-in controls or by coupling/layering controls with other controls that often go together to reduce implementation complexity. Make controls cheaper to integrate by embedding them in other components so they become more of an ambient control - and then available in other contexts where they previously weren't affordable.

  • Secure defaults. Identify and put in place more secure defaults to reduce the effort of implementing controls. Seek architectural defenses for whole classes of attacks as a way of realizing control consolidation.

  • Reduce the number of products. Strive to take two products out for every new product/service added. Utilize other service-native (e.g. cloud) features where feasible. Consolidate controls into platforms e.g. identity and access, cloud, data, API.

  • Converge processes. Converge different risk assessment processes and implement systematic / continuous control monitoring to reduce bureaucratic overhead.

  • Automate. Increase levels of automation for basic tasks, especially realizing the opportunities of Generative AI.


4.Improve Measurable Customer Experience

Improve customer or employee experience, reduce friction, improve support, reduce transaction costs in actual measurable ways that reveal tangible business or mission success. For example:


  • Improve customer experience. Deliver the same risk level but improve the usability of controls - including reducing friction for the customer to sign-up for services or new features. This also applies to sign-on/authentication, authorization, access delegation and fraud prevention controls. Use suspicious activity monitoring to alert customers to other issues they might have beyond your own channels. Make available to customers and employees some control configuration options (e.g. like a privacy check-up) as part of a wider customer trust and transparency program.

  • Improve operations experience. Change false positive / false negative rates to tilt in the favor of improved customer / user experience in fraud or suspicious activity monitoring. Look at the impact of controls on IT / security operations and redesign for ease of monitoring and support.

  • Improve developer experience. Take the perspective of internal and 3rd party developers and ask, how can you adjust your controls to improve the mean time to “hello world”. Use new controls to open up API / platform access to 3rd party developers or even just broaden out access to services to a wider population of innovators / engineers across your own organization.

  • Reduce inherent risk. Reduce inherent risk by removing sensitive data fields, constraining where such data is replicated to and reducing the time it is kept. For example, doing this across your supply chain could help with supplier substitutability that can lead to reduced costs from increased negotiating power.


5.Address Status Quo Disincentives

Implicitly incentivize the right behaviors by setting up disincentives for the wrong behaviors. For example:


  • Financial accounting. Use financial accounting processes to align with risk outcomes. Make the secure path the easiest and cheapest path - also make the insecure path the hardest and most expensive. The best example I saw of this in one organization was in a program to reduce legacy systems (the stagnant unmaintained and risky type) where the combined cost of a common legacy system was shared equally among the departments that used or had dependencies on that system. As each department eliminated their dependency the fixed cost of the legacy system was re-apportioned across those remaining. Thus as each department got off the legacy the remaining had their pro-rata costs increase significantly. It then became a race to get off the legacy.

  • Promotions and rewards. Amend the promotion, broader compensation, and other rewards programs to explicitly recognize the right risk reducing behavior. Even just removing the disincentives where promotion criteria entails doing things that actively work against security, like recognizing flaws in design that need to be addressed, doing little about it, because it might impact a schedule or trigger a cost over-run.

  • Encourage escalation. Escalation to attend to unusual or otherwise extraordinary risks can be done through pre-defined constructs (e.g. a risk committee, SLA review process etc.) or as a specific management escalation to be brought to the attention of someone more urgently. Escalation can be uncomfortable as it is sometimes seen as by-passing people and might make subsequent working relationships difficult and so putting in processes that make this happen by default, despite social pressure, is vital. 


Bottom line: Many organizations have framed security incentives poorly. It has been positioned as loss avoidance, regulatory compliance, brand protection and return on security investment by saving “soft dollars” that don’t actually generate the stated return. These incentives can be powerful enough (especially regulatory) to drive many positive outcomes, but, a better way of looking at incentives is to ask what are the things we can do that deliver significant commercial (or mission) outcomes in and of themselves such that we’d do them no matter what. Then, do those in ways that deliver massive adjacent security and resilience benefits. 

2,788 views0 comments

Recent Posts

See All

Going Faster: Isochrones and “Time to Hello World”

When you strip away all the fluff, security succeeds when: You are moving quicker than attackers - mitigating specific attacks ahead of, or just in time, through fast detection, containment and recove

Security and Ten Laws of Technology 

There are many well known, so called, laws of technology. Moore’s law being particularly emblematic. Let’s look at some of them and see what the security implications have been for each and what might

Comentários


Os comentários foram desativados.
bottom of page