‹ Blogs

Mastering the Cloud Native Wave: Security Resilience in Modern Systems

Featured Image
Published on June 28, 2024
Author By Rob Kenefeck

Infosecurity Europe brings together the industry’s leading cybersecurity professionals to share their experience and support others in overcoming cyber security challenges; and this is what brought Rob Kenefeck to stage at the event in June 2024 to summarise ways to reduce the gap between technical teams and decision makers. A gap which may have been introduced by unstructured cloud native adoption.

ControlPlane has over 200 years of combined cloud native experience, which means we have seen and experienced many of the positives and negatives that it can bring to the table. While many people think cloud native is just about running in a Cloud Providers data centre, it is much more than that. Cloud native allows you to develop, build and deploy workloads in computing environments to meet organisational needs, whether those environments are public, private or hybrid cloud. It’s a fast paced ecosystem with multiple updates every year to the core products as well as new ancillary features appearing or maturing all the time. We also see a multitude of different teams within an organisation trying to adopt different cloud native tools at the same time, which leads to risk management challenges. We see these key challenge areas:

Adopt Open Source

With how prevalent open source is becoming, the question is no longer whether you should adopt it, but rather how you should adopt it without introducing unmanaged operational and security risk. Risk calculations are different for open source vs internally written software vs commercial licensed software, so one adoption approach is to implement a risk-driven ingestion with dynamic risk calculations. At a minimum you should be automatically scanning software before storing it in a centralised secure repository instead of pulling the latest available version directly into your environment. An alternative to taking this operational overhead on directly is to use vendor-supported open source software. There is a cost to this, and this needs to be weighed up against the cost of doing it yourself correctly. Do you have the expertise and experience to do it?

Innovate

AI has taken the world by storm over the past few years, and made everyone think if you’re not already doing it, you’ve missed out. Reality is that many organisations have already been running Machine Learning practises and merely need to combine their DataML and DevOps practises to accelerate innovation and get the value out rapidly. But it’s not enough to just combine the two together, we need to apply the same approach as we have for years with DevOps, expanding security left to secure each stage of the Software Delivery Life Cycle. Cloud native tooling enables you to do this rapidly and securely, and ensures that AI/ML enabled platforms are truly secure-by-design and secure-by-default.

MLDevOps Cycle

source: https://www.ml4devs.com/articles/mlops-machine-learning-life-cycle/#mlops-lifecycle

Detect

Locking everything down will only get you so far. We’ve already explained this is a rapidly evolving ecosystem which means you need to be able to respond and adapt as the ecosystem changes. This is where cloud native threat modelling1 plays its part. Threat modelling allows you to identify the potential security risks in a systematic way, drawing on the expertise of your whole team and focusinG on the flow of data. A threat model allows you to identify what targets exist in your systems, what threat actors might be eyeing you up and what attack paths you have or should have controls for. This should all then get mapped to your existing Risk Management Framework to enrich what you already have.

Correct

Once you have a threat model, it’s easier to build a roadmap of where improvements are needed. Mapping technical improvements to threats which are in turn linked to business risks allows you to start reducing the gap between technical teams and decision makers. Introducing additional automation where it makes sense, working in a model where everything in your system can be declared as code and progressing along the Zero-Trust2 journey are all ways that smart engineering can help to ensure that you have corrected what you have detected.

Protect

With a hardened system, with known threats and associated risks its time to start planning how to protect. Cloud Native tooling in this space can be both a blessing and a curse. On one hand, there are heaps of new tools and methods for observing what is happening, but on the other hand there is so much more to observe. Containers are ephemeral by nature, which is great for resilience and scaling but terrible when it comes to applying traditional incident response techniques. Once incident responders are trained in the new technology stack, introducing tabletop exercises and tailored response runbooks provide a great way for the teams to practise the skills they need to use under pressure. Being able to simulate attacks (which of course you have already identified as part of your threat model) or introducing a ‘Red Team’ to attack the system (hopefully using an attack path already identified in your threat model) will help to ensure that when the time comes, you have the systems and processes in place to respond rapidly and effectively.

What comes next?

ControlPlane, with all of its years of experience, is best placed to help with all of the scenarios identified in this post - please check out our solutions to learn more and get in touch to share with us your own unique cloud security and engineering challenges that we can help you solve.


  1. Threat modelling finds and addresses problems early in the SDLC. ↩︎

  2. ControlPlane has authored hands-on training on how to architect Zero Trust networks ↩︎