Stay on the cutting edge. Subscribe to our blog.
Cloud-native security must account for the highly dynamic nature of continuous application development cycles. This means that applications’ identities must be adaptive, portable, and resilient to change (e.g., software updates), but reliable enough that attackers cannot affect modifications like adding malware, injecting malicious commands, or redirecting data-rich applications towards attacker-managed command and control. As such, immutable application identity becomes evermore important as IP addresses lose their trustworthiness. Applications and services can be defined by their aggregated cryptographic properties plus baseline intended behavior (again, instead of the network paths they travel), which results in an improved ability to determine the true identity of an application/service. The more information you have about the identity of the application or service trying to communicate on your cloud network, the better your ability to quickly notice abnormal behavior, investigate, and take declarative action.
Establishing an application's identity and using it for security control is not something humans can accomplish. Software automation is critical in this endeavor. From assessing which assets are present in the environment to building application identities and setting application controls, automation can be a security or network operator’s best friend. Automation does not alleviate the requirement for configuring the environment properly or reviewing alerts, but in today’s cloud-native world, too many applications and services are developed and deployed to have the security or networking team creating and tuning policies each time a new (or “new”) asset appears on the network. Dynamic ecosystems require integrated security, meaning that security controls are embedded into the build process rather than bolted onto applications once they’re in the environment, and this can only be accomplished through automation.
What’s more, security policies must automatically adapt, regardless of the cloud platform or operating system, which is yet another argument for application-centric control.
Last but certainly not least, the ephemeral nature of the cloud is an attacker’s paradise. Traditional security tooling works on a trust model that is no longer valid in today’s threat landscape. Perimeters have all but disappeared, encryption makes traffic inspection difficult, and classifying distributed data is resource intensive. All of this means that, even if traffic were to pass through a north-south perimeter gateway, identifying and stopping “bad” would be challenging. However, most traffic in a cloud-native environment is east-west—where traditional security controls do not apply.
This is why implementing zero trust is necessary for the security of cloud-native applications. In short, a zero trust network means:
- Assume the network is hostile; internal and external traffic are treated equally.
- Verify workloads at both ends of a network communication each time it tries to communicate.
- Implement least privilege access for users, devices, AND workloads: applications, workloads, and their relationships across environments all require authorization and authentication to function. Access control isn’t a user-only security policy.
- Dynamically update and adapt security policies using machine learning so that applications can withstand dynamic changes inherent in a cloud-native environment.
How to operate in an untrusted environment
Cloud networks and cloud-native applications require different security approaches than traditional, static solutions can provide. Access controls must be dynamic and application-centric rather than network-focused. Using an application identity-based approach coupled with zero trust will allow companies to adapt to progressively more complex environments and relationships between workloads without introducing impediments to the application development lifecycle.