3 Layers of AWS and Azure Security

Managing Security At Scale

Host Layer Security

Host level security controls remain largely the same as they are outside of cloud environments such as AWS, Azure or GCE. However there are few important nuances that you need to be aware of.

HIDS

Host Based Intrusion Detection remains to be a critical security control even in cloud-based environments, however many “household” intrusion detection platforms have a common functional gap. They are all IP based and do not understand such concepts as AWS Instance ID or Azure VMID.

Many of our customers have 30+ AWS accounts and 100+ Azure subscriptions. Overlapping CIDR blocks are not uncommon. So when your IDS sends an alert that IP 10.3.21.17 is under attack, that is a meaningless alert and often it takes hours just to find out what the host is so there is degradation in response time.

To make matters worse, we cannot route security incidents based on instance tags or account membership.

IDS designed for AWS or Azure will specifically call out Account Name or Azure subscription id and cloud provider specific instance identifier for each IDS event. If your IDS does not do that, move on.

NIDS

Network based intrusion detection in cloud-based environments has limited usefulness because cloud tenant cannot sniff on traffic in the cloud. Network sniffers such as SNORT can be installed at ingress and egress points.

Vulnerability Scanning

Vendors such as Nessus, Qualys have done great job extending features to their products to appeal to IaaS cloud consumers but just like with the IDS there are several nuances you should watch out for.

Anything but agent based scan will require filing lengthy paper work with AWS and Azure security teams. If you do not, your scanning server will be blocked immediately. Cloud providers cannot distinguish between legitimate scan traffic and probing attacks.

Both Nessus and Qualys fall to the same weaknesses as most IDS solutions they are also IP based. Look for a solution that can tie vulnerability scan results to specific cloud provider host identifiers.

Cloudaware CMDB has plugins for Nessus, Qualys, Whitehat and Nexpose, allowing you to overlay scan results with data from cloud provider such as security group rules to establish true severity of the problem.

In this example we can see Cloudaware merging Nessus Scan Results with AWS Instance record which includes security group rules.

Multi-sourced richness of data allows us to make much better decisions about true severity of vulnerabilities. For example a host with severe vulnerabilities that does not even have a public IP would rank lower on the priority list than a host with public IP, wide open security group rules and mile severities.

Patch Management

There is not much about patch management in the cloud that is different from what you did outside of cloud. The only thing that I would pay attention to if you are leveraging Amazon Linux is the security advisory feed AWS has established specifically for Amazon Linux customers.

Application Layer Security

Application level security controls remain largely the same as they are outside of cloud environments. OWASP Top 10 is as relevant in the cloud as it is outside of it. Cloud providers such as AWS and Azure offer additional web application firewalls such as AWS WAF and Azure WAF. You should consider them however be aware that they require a lot of upfront work to extract any value.

Physical Security

Physical security is obviously no longer in scope. However if you’re using hardware tokens to login to AWS or Azure Management Console, existing procedures for issuing and recycling those hardware tokens should certainly be reused.

Last But Not Least — Actual Cloud Security.

Many vendors will try to sell you “cloud security” as either an IDS or Vulnerability scanning solution they already have and simply append the word cloud to it. I want to understand that just like the Physical Security is out, Cloud Security is in. It is a whole separate discipline with its own set of risks and controls.

Your cloud environment has state which is defined by VPC Peering connections, Network Policies, Security Group Rules, IAM Users, Groups and Policies. All of these cloud artifacts and their configuration determine your security stance. Average cloud deployment of 6 AWS accounts for example will have about 40,000 of those artifacts. There is no way to do this manually so we must rely on algorithmic checks such as AWS Trusted Advisor and Open Source projects like Scout to evaluate our environment for compliance.

For Cloud Security, Cloudaware support 4 distinct policy engines that algorithmically validate how close your environment complies with cloud provider specific best practices our technical requirements laid out by PCI, HIPAA, NIST, etc.

• AWS Trusted Advisor
• Scout2
• Azure Security Center
• Cloudaware Policy Engine

The outcome of these policy engines are policy violations which are then routed to specific teams and application owners. Here is a sample dashboard that is built from AWS and Scout policy violations for 6 AWS Accounts, 750 IAM users and approximately 5,000 EC2 Instances.

Find out more about Cloudaware here.