For many of today’s organisations, managing threat exposure in the world of increasingly sprawling cloud-based systems has become a sizeable challenge.
Added to this, more and more businesses now operate in a fast-paced competitive environment of rapid software development and deployment – where maintaining unified visibility and control effectiveness can swiftly become unwieldy.
In this new age of accelerated-release cycles, cloud platforms and containers, cyber attacks against applications and exploitable code have spiralled.
For adversaries, software vulnerabilities – that have a bad habit of bedding in during the development process and only surfacing when an application has been deployed – are an open invitation to wreak the kind of widespread damage caused by SolarWinds, Log4j and Log4Shell.
For security teams – who fully comprehend the risks of releasing insecure code – the solution is straightforward: if only developers would code more carefully, there would be far fewer vulnerabilities in our cloud environments.
But for developers, who work under pressure to expedite time to market and help the organisation capitalise on the business benefits of the cloud, manual intervention degrades creativity and erodes the cloud’s overall value proposition.
And so it is that security teams increasingly find themselves at the centre of a clash of organisational priorities that is as much about the cultural differences between security and developers as it is about how best to capture value from the cloud.
While the rise of ‘Shift Left’ and DevSecOps has been largely in recognition of the urgent need to embed security in the developmental life-cycle – in actual practice, efforts to achieve this have been much harder.
Questions arise over where the responsibility for software security lies. Should the onus be on security teams, who already serve as the essential business ‘guardrails’ and who must increasingly articulate threat exposure to the organisation through the language of risk?
Security teams already carry a heavy-enough load, before being unfairly branded as ‘business bottlenecks’ or the “Department that says ‘no’”. And that’s before being burdened with rushed applications that require continual patching.
Or should the responsibility fall on developers to start comprehensively checking their own code, embracing the threat modelling that should be standard practise?
In this world of multi and hybrid-cloud environments, developers hugely outnumber security teams. Yet developers aren’t security experts; collectively, theirs is a mindset centred on speed and productivity, while security teams frequently lack the resources to continually test code, together with their other day-to-day tasks.
And there is no doubt that the speed of cloud adoption, together with fragmented and ineffective legacy toolsets and absent security verifications and practices – highlighted by the difficulty of pen-testing code – have compounded the difficulties.
Many security practices, such as threat modelling and conducting compliance tests, can be hard to automate, while issues of ownership of tasks further increases the blind-spots that can undermine the security of applications.
For ‘shift left’ to truly work, it is crucial that organisations adopt new security architectures and processes to protect their cloud workloads.
Successful cloud adoption should be about making all teams accountable. From a security standpoint, the challenge is to understand the difficult cultural mindsets and learn how to work WITH developers to build a safe organisational environment.
This means training developers to both understand data security, and that the purpose of security is to enable, rather than restrict the business. Meanwhile, enabling developers to use every possible tool – such as container scanning and static code analysis – that facilitates the writing of more secure code.
Just as importantly, the renowned tension between security and developers must be reconciled through effective leadership, training, and cross-team collaboration.This means baselining, and having a risk-based view of what that baseline should be, while being able to communicate this all in a language that resonates with the business.
So once again, we are reminded that the most successful cybersecurity strategies are those that take into account ALL operational assets – people, processes AND technology.
Accountability, policy and standards are vital components if the advancements in DevOps and emerging DevSecOps culture; the advanced tooling and automation needed to truly leverage the benefits of the cloud, are to succeed.
If you’d like to learn more about Cloud Security see our 4-part series on managing exposure in a cloud-smart world.
– Understanding Your Attack Surface
– Understanding & Managing Third Party Risk
– Identifying Misconfigurations & How to Fix Them
– 6 Key Security Monitoring Concepts
If you would like to find out how Adarma can help you with Cloud Security, please contact the Adarma team at hello@adarma.com.
Stay up-to-date with the latest threat insights from Adarma by following us on Twitter and LinkedIn.