• Phil Venables

Security for More than Security’s Sake - The Need for Adjacent Benefits

Truly excellent security programs deliver more than security risk mitigation. I know it is kind of ridiculous to say that when doing the basics of risk mitigation is hard enough, but there are two reasons this is important:

  • Obviously, delivering adjacent benefits in addition to the primary objectives of security controls is a commercial / organizational bonus which all will appreciate. It really does position security as an enabler of business (as opposed to this simply being a catch-phrase for impact avoided).

  • Less obviously, simply trying to do this even without success is still valuable as it shows you care about the wider commercial outcomes of the organization. This will increase buy-in for what you want to get done. It positions you with the overall goals of the organization even if, in the end, your contribution still remains solidly on defense. 

Seeking to deliver adjacent benefits as you deliver security controls can be small or large wins. Let’s look at the basic themes for this:


1. Use risk assessments to keep risk levels the same - but change controls 


There's a tendency when doing risk assessments to always look for a means to reduce risk further, to add more controls or create more issues. But it is important in these moments to also consider that the risk levels may be about right, or maybe some things can even be relaxed to take some more, appropriate, risk.


In doing this you can’t just end the assessment and move on. There is a tremendous opportunity to now look at the controls that sustain the current risk level and assess whether any of them can be replaced, consolidated or improved to deliver adjacent benefits:

  • 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.

  • 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.

  • 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.

  • Change false positive / false negative rates to tilt in the favor of improved customer / user experience in fraud or suspicious activity monitoring.

  • Use suspicious activity monitoring to alert customers to other issues they might have beyond your own channels.

  • Look at the impact of controls on IT / security operations and redesign for ease of monitoring and support.

  • 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”.

  • 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.

  • Enhance access controls, encryption, tokenization, and the use of differential privacy techniques to open up access to data historically locked in silos.

  • 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.

2. Highlight / optimize for knock-on effects. Never be silently awesome. 

There are many natural benefits due to the security controls we deploy. We often take these for granted and each new generation of stakeholders may need reminding of these. Even if they do already get this it is not actually redundant to remind people, rather - it shows we care. For example:

  • Solid security controls bolster effective change management processes (make sure changes go through the authorized controlled path) and thus increase system reliability.

  • An SDLC with appropriate processes and tooling for security reviews, design reviews and other processes is, of course, going to yield less of other defects over time.

  • Well constructed baseline levels of security increase the options for realizing resilience, such as use of broader resilience options for cloud delivery.

  • Least privilege controls reduce the blast radius of security events.

  • Security instrumentation can produce event streams that improve overall lT observability for preemptive fault identification.

3. Realize efficiencies. 

Naturally, we should be constantly optimizing the controls we deploy, for example: 

  • Reduce the cost to sustain or upgrade controls and direct those savings to other improvements.

  • Couple or layer controls with other controls that often go together to reduce implementation complexity.

  • Identify and put in place more secure defaults to reduce the effort of implementing controls.

  • 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.

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

  • Consolidate controls into platforms e.g. identity and access, cloud, data, API.

  • Seek architectural defenses for whole classes of attacks as a way of realizing control consolidation.

  • Increase levels of automation for basic tasks.


Bottom line: seek to deliver adjacent benefits in how you put in place controls to mitigate risk. You might not always be successful but the mere act of trying will enhance relationships with the wider organization. This will feed back to sustain support for your basic control objectives: win - win. 

574 views

Recent Posts

See All

Vulnerability Management - Updated

It still surprises me that much of the tone of vulnerability management is about patch/bug fix vs. detecting broader configuration and architectural problems. I’ve always found it more useful to think

Subscribe for updates.

© 2020 Philip Venables.