×

STAY TUNED


A SECURITY REVOLUTION
FOR YOUR CLOUD & DATA CENTER.


JUNE 11TH

Coming June 11th
 
 

Security in a Cloud-Native Environment

The term “cloud-native” has been the buzz in the security industry for a while now. In time, it’s likely that “cloud-native” will simply be a ubiquitous part of building and delivering network services and applications. More and more, companies are starting from a cloud point of view rather than migrating there from on-premises environments. While “cloud-native” implies starting in the cloud, it’s not necessarily the case. Today, having cloud-native applications can mean that an organization has sufficiently “lifted and shifted” and adapted processes to allow applications to work natively in the cloud, all without introducing extra burden (especially from security). Transforming to a cloud-native posture is both strategic and operational, and requires infrastructure and security teams to think carefully about how and where security is applied. Traditional network-based approaches don’t translate well into cloud environments which are elastic, loosely coupled to infrastructure, and do not have any reliable perimeter at which to place security controls. Whether building and deploying cloud-native apps and services or moving existing apps/service to the cloud and assimilating them to become “naturalized citizens,” cloud networks present the challenge of securing a dynamic ecosystem while also delivering uptime, availability, and resiliency.

Application-centric security

In a cloud-native environment, old-school monolithic applications are conceptually replaced with lightweight microservices. The resulting distribution of “pieces,” so to speak, increases the number of interfaces and endpoints which henceforth need to be secured throughout software’s lifecycle. The challenge is that in a cloud environment there aren't any fixed gateways, routes, or perimeters—the elements upon which firewalls, IDS/IPS, DLP, and the like depend to detect and protect from cyber intrusions. To compensate for these inadequacies, security teams have started placing more controls at each network layer, effectively creating smaller, perimeter-based segments around data, applications, the network, and so forth. However, these traditional tools continue to rely on network information—IP addresses, ports, and protocols—as the backbone of control. The unfortunate reality is that threat actors can blend into approved network traffic and move laterally towards their targets, ultimately causing a breach. Thus, it’s important that security teams do not try to simply replicate on-premises environments in the cloud with granular chunks of traditional security control.

Organizations must renovate the security program to accommodate cloud-native applications and services. Doing so depends on companies’ abilities to put applications, themselves, at the center of the protection plan; the new imperative is to move access controls away from the network paths applications traverse and tie them directly to the identity of communicating applications. It’s no longer sufficient to define an application by its traffic route. Security control must be application-centric and not coupled with the cloud platform, because applications in a cloud-native environment are not.


Subscribe to our newsletter:


Application identity

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.

Automation

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.

Zero trust

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:

  1. Assume the network is hostile; internal and external traffic are treated equally.
  2. Verify workloads at both ends of a network communication each time it tries to communicate.
  3. 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.
  4. 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.

Katherine Teitler, Director of Content

Written by Katherine Teitler, Director of Content

Katherine Teitler leads content strategy and development for Edgewise Networks. In her role as Director of Content she is a storyteller; a translator; and liaison between sales, marketing, and the customer. Prior to Edgewise, Katherine was the Director of Content for MISTI, a global training and events company, where she was in charge of digital content strategy and programming for the company's cybersecurity events, and the Director of Content at IANS, where she built, managed, and contributed to the company's research portal.