Post banner
Cloud Security 2 Min Read

Hierarchy of Cloud Security Needs

At Threat Stack, most of our customers are primarily cloud-based and are just getting started with security. Very often, they ask about solutions like “threat intelligence” or Network Intrusion Detection Systems (NIDS). Whereas one is overly complex (threat intelligence), the other (NIDS) has limited value in cloud environments.

So how does a company embarking on cloud security solutions reconcile the enormous amount of options available to them with what is best, specifically, for them? To better explain the processes behind cloud security selection, we’ve created the Hierarchy of Cloud Security Needs.

Hierarchy-of-cloud-security-needs-pyramid

Overview of the Needs

Protecting the Perimeter: This is the basic, foundational level of security that any cloud security operator should take on first. Technologies such as Amazon Web Services provide virtual private clouds (VPCs) and security groups provide simplistic ways to protect the perimeter, such as allowing only IPs that need to be allowed, etc.
Visibility into Workloads: The next step after VPCs is to understand the behavior of workloads. This is paramount before initiating any kind of security mechanism or technology. Knowing the baseline behavior of various types of systems will expose where irregularities can occur. Workload data includes:

  • Users who regularly log in and their expected activities
  • Processes running and forking on the system
  • Normal/expected in- and outbound network connections
  • Activity involving critical files on the system

Integration of Workload Behavior with Infrastructure Services: Once perimeter security is in place and visibility into workloads is achieved, integrating infrastructure services in order to monitor behavior changes gives the cloud operator further improved visibility. For instance, this integration will monitor:

  • If a user’s behavior on a workload is authorized by identity and access management (IAM) permissions
  • If the running of a workload is authorized by cloud identity services
  • If anything running on the infrastructure should not be there (like a web server) or anything is talking to it from outside of established boundaries

Integrate Workload Behavior with External Information Sources: Integrating workload behavior with external information sources will help the cloud operator know when abnormal workload behavior is actually the action of a known external behavior. For instance:

  • If the abnormal IP that a workload connects to is part of a botnet
  • If the abnormal socket opened on a workload is typical of a command and control channel

Integrate Workload Behavior with Community: Understanding what behaviors and threats are common to an industry arms the cloud operator with even more information in identifying attack behaviors. For instance, finding out if anyone else within the community has also observed an abnormal process fork activity may mean the difference of identifying a threat or a shared abnormality.

Conclusion

While there’s no one-size-fits-all approach to cloud security, the hierarchy of cloud security needs must be considered by all cloud operators before selecting a security service or tool. Much like Maslow’s Hierarchy of Needs, each of these steps should be seriously considered and in place before advancing to the next. Unlike Maslow, there’s no transcendence at the end. Cloud security measures will only evolve with the cloud itself and we may well be building on this pyramid for many years to come.