top of page
  • Phil Venables

Cybersecurity Macro Themes for the 2020's

In this coming decade there will be 5 major themes that differentiate great security programs, products, features and processes. These are different from overall risk and control trends, rather, these are more about the way to develop and deploy those controls.

I covered the risk trends in a previous post. Control trends all center on continuity: continuous access assurance and least privilege, continuous software assurance and developer centric tooling, continuous and adaptive micro-segmentation / meshing, continuous control conformance monitoring, continuous anomaly detection and relentless processes to adapt control frameworks according to threat intelligence (macro and micro). But, it is becoming more important to consider how we deploy these, more than just doing so and walking away. The 5 themes, below, represent the needed evolution:

  1. Software reliability and security. Security goals should be encoded in software, made available to developers as APIs, libraries, toolkits, or design patterns. This should be pushed as early in the design lifecycle as possible. While security has different properties compared to many other risks it should still be presented as a reliability goal and security be fully enmeshed within overall testing frameworks. While there should be some degree of independent oversight of security, as there should be for other risks, the embedding of security engineering expertise in development teams (developer centric security engineers, or developers with nurtured security skills) is critically important. Tool integration becomes ever more vital when you observe that software is increasingly being developed beyond the bounds of engineering. No-code/low-code, scripting, analytics, AI/ML and other modeling environments need even tighter embedding.

  2. Usable security and ambient control. The user experience of our tools, whether they are customer, employee, partner, vendor or engineer centric need constant improvement. We need to embrace professional designers for critical components, not only to keep making the secure path the easiest (and default) path but also to create some, dare I say it, enjoyment in how people interact with security. However, we also need to recognize that the most usable security is that which simply blends into the background.  Creating such ambient control is extremely difficult and can require going against much accepted wisdom, especially when it relates to training people to not do things that simply should never be offered as options or should have no dire consequences anyway because of controls surrounding our people and customers.

  3. Continuous control monitoring, controls assurance and provable security. I talk about this a lot, for a reason, that most bad things happen not because we didn’t foresee the need for a control but rather that the control we thought we had in place was not present or operational when we needed it the most. We need to understand what controls we should have, constantly monitor for their correct presence and operation - treat failures as control incidents irrespective of whether they become security incidents. We should reject controls (products or features) that cannot constantly emit evidence of their presence and operation - irrespective of whether they are otherwise an effective control. Further, we should apply higher levels of assurance to constantly validate the effectiveness of our most critical controls using formal proofs, for example: AWS. Those of us with experience of cranking out formal validation on safety-critical systems back in the day should rightly be staggered by the advances made in tooling to support large-scale systems validation. The notion that formal methods don’t scale is going away and the impact on security, in the long run, will be profound.

  4. Operational resilience. This is not just another way of saying cyber-resilience. Rather, as described in a recent post this is taking a business service view of resilience across multiple risk types by considering more severe, but plausible, scenarios. New security controls implemented as products, features or processes must be used in support of defined operational resilience goals rather than increasing brittleness.

  5. Adjacent benefits. Implementing or sustaining a control that is effective is simply the start. It will be expected (if not outright demanded) that what we do also delivers one or more adjacent benefits, for example: reduce cost, increase efficiency, eliminate more than 1 prior product, increase productivity, reduce customer friction, break data out of silos while still preserving essential privacy properties, enable new business in new locations, permit products to launch that could not have previously been adequately protected, and so on.

Bottom line: more is rightly expected of us as individual professionals and collectively as an industry. Our goal is not to further set ourselves apart but rather to further embed ourselves. Following these 5 themes - with some fervor - will point us in the right direction.

2,048 views0 comments

Recent Posts

See All

Maturing a security program in any type of organization is not just to increase specific control effectiveness but also to increase its scale, predictability and reliability - otherwise that effective

Just over a year ago I put out this blog post on the 10 fundamental (but really hard) security metrics. Since then I’ve discussed this with a lot of people and have been thinking more about this in th

In the last post we talked about the challenges and opportunities of using individual and organizational incentives to ensure effective security risk management. This can be aided by the right design

bottom of page