Cloud-native applications are a rapidly growing trend. They provide customers with a better time-to-market strategy, and allow them to build more robust, resilient, scaleable, and cost-effective applications.
However, cloud-native architectures and applications come with a risk: maintaining robust security.
In this article, we’ll explore the fundamental principles of cloud-native security, and give you some tips about how to use it most efficiently. Let’s start by discussing cloud-native applications.
What Are Cloud-Native Applications?
Cloud-native applications offer the benefits of cloud computing by providing applications as small microservices (either containers or serverless), and managing them through DevOps processes. To build these applications, organizations need a cloud-native infrastructure which provides flexibility and enough services for developers. Cloud-native infrastructures should provide a platform for the build and release team to effectively perform continuous delivery of its applications, with close to zero human intervention.
Making the move to cloud-native applications requires a mindset change — all the way from top management to developers. In order to make the best decisions, organizations must understand the real benefits of cloud-native applications and the impact they can have.
Benefits These Applications Provide
- Faster time-to-market: The continuous build, integration, and development capabilities enable organizations to take their new products and services to the market faster. Why sit on a release for months when you can deploy your application numerous times per day? Also, a shorter release cycle (when combined with proper processes) provides rollback confidence, allowing companies to experiment with tactics and strategies in a way not possible before.
- Resiliency: Cloud-native applications can be designed to handle failures, so that problems within a component won’t bring down the entire application.
- Automation: This removes the manual tasks from the develop & release process, replacing them with scripts and code.
- Consistency: Cloud-native applications provide consistency — from development to deployment — by allowing developers to package dependencies with containers or serverless architecture.
Security Challenges They Introduce
Cloud-native applications offer many benefits, but they also introduce a few challenges. One of the most important is security.
For traditional or VM-based cloud environments, there are established security practices and tools with rich feature sets available. Agent-based monitoring tools provide complete infrastructure and application performance visibility, while other host-based security solutions ensure the environment is protected from malware, intrusion, and detection. Governance tools perform integrity monitoring and log inspection for any changes or threats. Network perimeter tools secure the entire network and provide complete visibility.
However, a cloud-native environment is a collection of small microservices tied together. These cannot take advantage of the toolsets and procedures designed for monolithic environments. Moreover, fast and frequent releases mean that the environment is always susceptible to changing.
Thus, a new security approach is needed.
First, Make Attacks Difficult
Just as cloud-native applications change frequently, so too should their security environment. One important purpose for this is to make it difficult for attackers to gain and maintain a foothold.
This is the primary purpose for the “3 Rs” of enterprise security: Repair, Repave, and Rotate.
- Repair: For robust security, you must monitor your systems and software for vulnerabilities, and fix them as soon as they become known. Doing this consistently requires a team to be assigned to (and accountable for) monitoring vendor announcements, cross-checking new vulnerabilities against the systems you’re using, and installing relevant patches immediately. Although this sounds obvious, there are many organizations for whom security is claimed to be a priority, but in practice, it is at best a secondary concern. Don’t be among them.
- Repave: Repaving is a regular, frequent process that restores an environment back to its original state. This provides several benefits. First, it removes any drift from the environment, so applications can rely on it being in a baseline state. Second, if an attacker were to somehow gain control of an environment, it limits the time within which damage can be done. Lastly, in regulated industries, customers have to go through audits to confirm that they are maintaining compliance standards. Regular repaving ensures that a compliant environment remains in its desired state. Overall, the more you repave an application and infrastructure regularly from a known good state, the better.
- Rotate: This refers to credential rotation: the regular, frequent changing of valid system credentials. This ensures that even if valid credentials were compromised, the attacker would have little time to exploit them. Rotation is required for credentials such as CSP IAM users’ API keys, SSH/RDP credentials, and database credentials. As with other cloud-native procedures, this process should be automated, and tools are available for this. (For example, AWS launched Secrets Manager for automatic database password rotation.) In general, the shorter the credentials’ lifespan, the better.
Second, Bake Security into the Entire Application Lifecycle
Organizations need to incorporate security into the entire application development, integration, and deployment lifecycle.
Your organization has probably already embraced DevOps, or is in the process of doing so. By infusing DevOps practices with effective security practices, your organization will effectively adopt DevSecOps practices as well, with all the benefits that these provide.
We’ve previously written about the benefits of adopting DevSecOps, and how to solve a common challenge when doing it.
Third, Ensure You’re Using the Right Cloud Platform(s)
Since cloud-native environments are a mix of VMs, containers, and serverless, it is important to use the right cloud platform. This doesn’t have to be a public cloud environment; it can be hybrid, or even multiple cloud providers stitched together. What’s important is to carefully evaluate the platform and validate whether it has the right security and automation capabilities.
Sometimes, organizations try to reinvent the wheel by building their own automation frameworks or services. This is usually not necessary. Instead, choose a CSP that has the right cloud-native security features to protect the workloads running on it. It should also have the ability to secure the application at all layers of the infrastructure, providing holistic security. Furthermore, it should be able to integrate security guidelines and vulnerabilities from various sources, and provide remediation for those vulnerabilities. Lastly, the cloud platform should be continuously evolving with emerging workload patterns — and supporting them.
(The Reblaze support team has years of experience helping customers sort through these sorts of issues. Feel free to contact them with any questions about these topics.)
Fourth, Build a Cloud-Native Team
Many organizations are trying to go cloud-native, even though their teams are still structured traditionally.
In the traditional environment, separate teams operate the build, and implement, manage, and secure the application. In such cases, each team does its work, adding layers as necessary to complete and meet its roles and responsibilities. (For example, a security team might add a web application firewall on top of the already implemented application.) This is like adding a bolt of cloth to a piece of furniture after it is built and ready to use.
For the cloud-native environment, this has to change. DevSecOps requires security to be built into the entire CI/CD pipeline, and that’s best done when the entire process is continuous, driven by the same team from start to finish.
The Rewards of Doing All This
Cloud-native adoption yields multiple benefits, including a better go-to-market strategy and improved security. It also offers:
- Flexibility to choose the right secure platform: With the ability to run workloads across multiple cloud platforms, cloud-native security allows organizations to choose the secure platform that best fits their applications. For example, if a cloud provider has a more secure container-as-a-service solution, it makes more sense to run container workloads on that solution, while the other components run across other cloud platforms, providing better guardrails around the serverless environments.
- Faster recovery: With automation and DevSecOps pipelines, cloud-native security allows engineers to recover faster and fix security holes in the environment. It is not easy to achieve perfect security posture, but when rollouts are performed frequently (maybe even numerous times a day), it is easy to immediately detect a security gap, provide a feedback loop for the respective teams, fix in minutes to hours, and roll out to market. The automatic detection, feedback loop, and recovery process all reduce the blast radius of a bad security event, so that there is limited impact on your organization.
- Better monitoring and visibility: With continuous integration & deployment pipelines and built-in security, cloud-native security allows you to aggregate information from all layers, and provides complete end-to-end visibility about the environment. This real-time view enables real-time decision making.
Cloud-native applications are still fairly new, but adoption is occurring at a fast pace. With the right security controls embedded (starting at the design and development stage, all the way through to delivery), cloud-native security allows organizations to detect security gaps and to fix and secure their environments quickly.
Want more detailed information on this topic? See our previous post on DevSecOps: Solving a Very Common Challenge. Or feel free to reach out to us directly with specific questions: https://www.reblaze.com/contact-us/.
image credit: insspirito