Security professionals have argued that security should be a consideration at the outset of application development, irrespective of the environment. Security by design or by default, as early in the development lifecycle as possible, is a long-held principle of application security. "Shifting left" is the term associated with testing for defects early in the cycle. But asking a security professional to shift left to account for cloud native security would catch many security folks by surprise.
Mature development and DevOps teams have adopted deployment through containerisation, with some standardisation of vulnerability management to help automate the process. Many decide to scan early in the delivery pipeline to minimise the opportunity for security weaknesses disrupting the continuous application delivery process. Well, that’s the idea, in principle. The State of Cloud Native Security 2020 report highlights that 45% of highly prepared companies have embedded security into DevOps processes, and 41% integrate security in at least four stages of the development lifecycle.
Context is a key component of understanding any vulnerability security posture and cloud native security is no different. Increased flexibility for homeworkers using cloud services as a result of Covid has added to an already complex security configuration. Without context, what do we secure? For example, am I using a corporate or private Microsoft One Drive service? Existing cloud security techniques can easily become outpaced when we look at cloud native security threats.
This should make security professionals sit up and take stock of emerging cloud native technologies and at its core, the principle of application deployment via containers. Accelerating left, and understanding application layer security deeper than OWASP, is an imperative to securing cloud native environments and enabling successful digital transformations in the enterprise.
How do we work together to meet this challenge?
Collaboration with a new calibre of cyber engineer could be part of the solution. The cyber engineer or DevSecEng is someone who actually understands the code, a Linux native who is comfortable with serverless functions, microservices, and infrastructure as code. Someone who can work with APIs, know what’s running inside the container and apply security measures – but crucially can influence and communicate in a common language. This isn’t a typical DevSecOps person, who is likely to be drowning in automated security reports and researching vulnerabilities that no-one has the time to fix. The DevSecEng cyber engineer is cross-cutting, with the insight to champion machine learning (ML) for integrated high-fidelity cloud security tasks, leaving capacity to support the developer community understand the dynamic nature of the threat. Leaving more time to focus on the high-touch human security engineering tasks, for example, automating workflows to codify security countermeasures. The cyber engineer will also be tooling for advantage to protect the workload but be mindful of the flaws. For example, Kubernetes has become the go-to for cloud native resilience, but has become the Achilles heel for those too trusting in silver bullets.
Attacks on cloud native security services tend to be more difficult to achieve but can be devastating, often taking advantage of the very nature of the cloud native architecture to achieve the compromise. The latest Aqua security research shows an increase in organised attacks on cloud native environments. Here is what they had to say about the heightened threat:
“The attacks we observed are a significant step up in attacks targeting cloud native infrastructure. We expect a further increase in sophistication, the use of evasion techniques and diversity of the attack vectors and objectives, since the widespread use of cloud native technologies makes them a more lucrative target for bad actors. Security teams are advised to take the appropriate measures both in their pipelines as well as runtime environments, to detect and intercept such attempts.”
Accelerate to the left
Technical security practitioners not able to shift left will be left on the shelf. Now is the time to re-invent or rediscover, notwithstanding the new normal. To take stock of the multiple cloud environments and the trade-off between agility and the expected environmental complexity. According to the latest IDG Cloud Computing Survey 2020, 54% of enterprises' cloud-based applications moved from an on-premises environment to the cloud, while 46% were purpose-built for the cloud.
Plugging the gap in cloud native security will follow through the combined use of niche cloud native security vendors and applied skills. You need continuous security with the agility to test, test again and fix fast, crucially at a service layer. A word of caution though: watch out for your favourite AppSec tools being consumed into large tech vendor platforms, testing your agility and service dependencies.
Crucially, the role of the DevSecEng cyber engineer or evolving DevSecOps community will be to provide oversight of the emerging cloud native space, which is evolving out of sight from many a CIO or CTO in the midst of a digital transformation. Cloud native is evolving at a rate – with serverless functions often containing thousands of lines of code, cloud native applications can use dozens of libraries. It’s this oversight and technical collaboration that will bring together communities who build, secure and deploy in a cloud native environment for competitive advantage.
Changing the narrative always takes time... if the backlog rules what gets done, improving security must be on the backlog. The DevOps and developer community should actively collaborate when it comes to threat modelling, let alone threat hunting, but not be left holding the can. If done properly, cloud native security can be more efficient and can reduce the attack surface pre-deployment. Security engineering, protecting the workload in service is a shared responsibility, accelerating left without compromising the benefits of cloud native architecture.
Cloud native security is a holistic problem and requires an adaptive approach that will likely challenge and disrupt an organisation's tech culture. If it doesn’t feel like that, then you are probably missing something, somewhere.
Richard Beck is Director of Cyber at QA. He works with customers to build effective and successful learning solutions tailored for business needs, helping to solve business problems. Richard has designed and architected numerous enterprise and nationwide cyber programmes for QA customers. Responsible for the QA cyber portfolio, products, proposition and cyber partner community. He has over 15 years' experience in senior Information Security roles.
Prior to QA, Richard was Head of Information Security for an organisation who underpin 20% of the UK's Critical National Infrastructure. Richard also held Security and Technical Management posts in Defence, Financial Services and HMG. He holds a number of leading cyber professional certifications, including CISSP, CISM, CISA.
Richard sits on a number of industry boards and security advisory panels, and previously chaired the Communication Industry Personnel Security Information Exchange (CPNI). He is the work stream lead for Cyber Skills & Diversity on the techUK Cyber Management Committee, in addition Richard is also supporting a work stream for the UK Cyber Security Council Formation project. Richard is a regular contributor for cyber insights and industry collaboration including speaker engagements.
He is also a STEM Ambassador working to engage and enthuse young people in the area of cyber security. Providing a unique perspective on the world of cyber security to teachers and encourage young people to consider a career in cyber security.
More articles by Richard
Cyber Pulse: Edition 145 | 19 February 2021
Cyber Pulse: Edition 144 | 5 February 2021
Cyber Pulse: Edition 143 | 27 January 2021
Cyber Pulse: Edition 142 | 18 January 2021
CISOs should prioritise the “human firewall” during Covid-19
Cyber Pulse: Edition 141 | 11 January 2021
Cyber Pulse: Edition 140 | 4 January 2021
Cyber Pulse: Edition 139 | 18 December 2020
Cyber Pulse: Edition 138 | 8 December 2020
Cyber Pulse: Edition 137 | 13 November 2020