The Cloud Native Computing Foundation defines cloud native as technologies that, “empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach….”
Cloud native technologies like serverless in particular alleviate the burdens of infrastructure ops orchestration and monitoring. Without the need to focus on infrastructure, developers can dedicate time and energy to building the tools that power the business and generate revenue.
In a traditional IT approach, all responsibilities lie with the end user organization – everything from access control down to electricity and physical security of the facility. However, cloud computing offloads many of these tasks to the cloud provider. Many tasks – but not all. The end user organization retains responsibility for securing the data they put in the cloud in the well-known, “shared responsibility model.”
In securing cloud native infrastructure, it’s vital to understand exactly where the responsibilities lie, considering your responsibilities vary depending upon the services you’re consuming. Unfortunately, many organizations fall short. A variety of problems are lamentably common, including missing critical patches, potential account compromises, public exposure of cloud storage services, and accepting traffic to Kubernetes pods from any source. Gartner predicts that, through 2025, at least 99% of cloud failures will be the customer’s fault.
Legacy approaches involve building a wall around your infrastructure and observing and blocking from the outside. With the shift to some cloud native technologies like serverless, the perimeter dissolves. For example, a WAF will only protect functions which are API Gateway-triggered functions. Therefore, a WAF won’t help if your functions are triggered from different events sources, such as cloud storage events, stream data processing, and databases changes.
Furthermore, legacy external scanner and firewall approaches lack context to do security accurately. Scans and perimeter defenses lack understanding and insight into the resources they’re assessing and protecting. That lack of understanding leads to mistakes and false positives. Experts need to go fix them, find vulnerabilities and resolve gaps such as false negatives. Such processes heavy with human, manual efforts won’t scale.
Applications with a new, distinct structure require a distinct security approach. It’s impossible to use the same approach to secure compute as varied as:
As opposed to code tightly coupled to a monolith application database, shifting to microservices results in smaller bits of code along with smaller and easier coupling.
Cloud sprawl expands faster than the ability to secure it. Visibility – whether high fidelity or even mediocre fidelity – is challenging. And limited visibility that’s lacking broader context leads to flawed conclusions. A lack of centralized administration and visibility increases the likelihood of undetected misconfigurations, as well as the inability to quantify risk. Alerts that lack context require human intervention, resulting in delays in mitigation and alert fatigue.
Cloud native security must solve the context problem. Effective cloud native security requires details about suspicious activity usage. You need to know not just source IP, but destination, protocol, user and group, content and application function, and more.
“To close security gaps caused by rapidly changing digital ecosystems, organizations must adopt an integrated cloud-native security platform that incorporates artificial intelligence (AI), automation, intelligence, threat detection and data analytics capabilities, according to a newly released report from 451 Research.”
Securing public cloud requires continuous assessment and protection tightly integrated into the infrastructure and apps. The tools, security budget, and specialized staff isn’t rising as fast as the quantity of tools organizations are leveraging as part of their digital transformation.
Cloud Native refers to both platform and infrastructure security, as well as continuous application security.
The security must be built into the assets you’re working to secure. This applies to multiple layers, from OS to container to application. To protect an app, get inside it to understand the data flows and transactions in order to provide accurate assessment and protection. Integrated security also enables your workload to be mobile, from cloud to container. Security will go along with the application.
Threats are moving faster, and business critical apps and platforms have progressed to the point that legacy security approaches are no longer suitable. 451 Research writes, “It is clear that traditional security practices, strategies and technologies are no match for the sophisticated threats and complex hybrid IT ecosystems of today”
The use of legacy tools results in a huge complicated program consisting of a patchwork of multiple tools, all of which require dedicated staff to gain expertise. Such a program is also plagued with false positives and complex deployments.
Whereas the inside-out approach of modern cloud native tools serves as a force-multiplier. AI-driven models can observe app behavior post-deployment to effectively detect anomalous behavior.
Compute services in cloud-native applications are designed to be ephemeral and tend to have short lifespans. This is one of many attributes that makes cloud native applications inherently more secure . But as a new type of architecture, they present new security challenges and developers must act to mitigate risk. Read, “Cloud Native Security: What it Means” for some best practices to secure cloud-native applications.
The Check Point CloudGuard platform provides you cloud native security, with advanced threat prevention for all your assets and workloads – in your public, private, hybrid or multi-cloud environment – providing you unified security to automate security everywhere.