As they move into the cloud, security teams continue to be concerned with confidentiality, integrity, and availability of information. Only now they just have to do it across a wider spectrum of technologies, new processes and methodologies, and new teams with different operating practices across their organizations.
Challenges Security Teams Face in the Cloud
Cloud native technologies and cloud computing bring a vast range of benefits to our business units and our organizations. This cuts across the people, processes and technology. Security teams now have to address:
- People
- New support matrices in the shared responsibility model
- Infrastructure management now delegated to different teams via Infrastructure as Code or DevOps/SRE teams
- Separated service-oriented teams; no longer specialist teams but multi-disciplined
- Processes
- Automated deployments
- Service consumption now single-click, not onboarding through multiple teams
- Immutable infrastructure
- Technology
- Virtual Machine OS shifts (Amazon Linux, Containerd)
- Containers
- Kubernetes
- Serverless
Organizations looking to replicate their data center setup in a public cloud misunderstand how to achieve the greatest benefits of public cloud, such as scalability, speed to market, and more. For example, AWS places emphasis on this in their modernization piece of the migration strategy: assess, mobilize, migrate and modernize.
This modernization work refactors your applications to be cloud native as opposed to “lifted and shifted” into a public cloud.
The security boundaries are redefined with account segregation, which offers blast radius protections. However, this also leads to the need for more complex best practices that security teams must understand and assess. For example, Azure landing zones provide an excellent example of how platform re-architecture, not just solution/application re-architecture, is necessary in the cloud. You can learn more about Azure landing zones here.
The threats have changed, too; bad actors are no longer just looking for financial or intellectual property opportunities but cloud account takeover. Not only are organizations targeted because of who they are but also the democratization of phishing and hacking toolsets have created cottage industries where access to networks is sold and persistent threat access is a commodity. Cybercrime-as-a-Service, where criminals can rent or purchase ready-made hacking tools, exploit kits, or botnets, enables them to launch attacks without significant technical expertise. This underground marketplace has created a thriving ecosystem for malicious activities.
Democratized hacking tools often come with automation capabilities as well, allowing bad actors to launch attacks quickly and efficiently. Automated tools can scan for vulnerabilities, perform brute-force attacks, or execute malicious activities at a much faster pace than manual methods. Our threat research team’s recent work on honeypots provides some excellent real world evidence.
Initial Security Vendors Brought a Legacy Approach to the Cloud
Legacy security vendors had a hammer and viewed all these issues as nails. They have taken these new challenges and looked at them through the lens of their existing products. I’ll discuss the cloud first approach in a moment, first let’s dive into how legacy vendors approached cloud security:
Legacy Security Vendor approach: Break cloud security down into component parts (listed below) and evaluate your product against these siloes. Where there is a gap, acquire a company to fill it. This leads to what I like to call “checkbox security,” – it’s great for an RFP but, in reality, creates pain points for security and remediation teams.
- Cloud Workload Protection Platform (CWPP)
- Cloud Security Posture Management (CSPM)
- Kubernetes Security Posture Management (KSPM)
- Data Security Posture Management (DSPM)
- Cloud Identity and Entitlement Management (CIEM)
- Shift Left Security
- Application Programming Interface (API) Security
- Cloud Detection and Response (CDR)
Cloud Native Security Deserves a Purpose-built CNAPP
Public cloud and cloud native present new opportunities and ways of working. Vendors willing to innovate and embrace these new technologies and processes have an opportunity to secure all aspects of the cloud in one solution, featuring:
- Coverage: Cloud security requires 100% visibility and coverage of the entire cloud estate.
- Comprehensive: The cloud must be secured holistically in one solution to detect all security risks.
- Context: Cloud security findings are best understood as attack vectors, rather than siloed alerts.
- Consumable: Ingest loads of data and make it consumable and actionable so that teams can use it to support decision making.
Building a checkbox security platform is more convenient for legacy security vendors, as they can maintain customer focus on their core products such as firewalls, monitoring software, VPN solutions, or proxies. They can then assert that their products are future-proofed by listing numerous features within each category.
It’s not about technology–it’s about how technology can be an enabler for the people and the process.
How Purpose-Built Platforms Solve Real World Problems
As the first cybersecurity vendor to deliver agentless SideScanning technology, the Orca Security founders identified the ways cloud native gave us an opportunity to do security better.
By developing a purpose-built product that leverages data and utilizes tools provided by cloud service providers (CSPs), a comprehensive overview of all services across accounts and public cloud providers can be created. Such a purpose-built platform has the capability to unify previously siloed areas (CSPM, CWPP, etc.) into a single, universal solution. Gartner refers to this as a Cloud Native Application Protection Platform.
This differs from the acquisition and feature-driven approach used by those legacy security vendors. A Cloud Native Application Protection Platform (CNAPP) is a unified and tightly integrated set of capabilities which exists to enable CISOs to understand risks across their existing estate, their development pipelines, and data spread to provide actionable insights and remediation steps.
It is impossible to build a fully-integrated CNAPP from a Frankenstein’s monster of acquired companies with separate datasets, schemas, and compliance configurations. Relying on traditional techniques (Configuration Management Databases (CMDBs), or deploying agents to assets) in an ephemeral, cloud native environment is, at best, naive.
Instead, by creating a purpose-built platform which is data driven, we can grow and adapt to new technology, new cloud providers, and new cloud services with ease.
I challenge you to see how customers like Lemonade get value from a true Cloud Native Application Protection Platform within minutes and how functionality is crucial, not a checkbox of individual features. And if you’re curious to learn more about what it means to be a true CNAPP, get your copy of the Gartner® Market Guide for Cloud-Native Application Protection Platforms (CNAPP).