Amazon Web Services and Microsoft Azure are the two most common cloud services used in practice. While many people will be familiar with Microsoft language for Active Directory users and groups, Group Policies, virtual machines, IIS webservers and SQL databases, the language used by AWS and the services provided are quite different in many cases. Reflecting this in practice is Microsoft’s support of the hybrid cloud whereas moving to AWS is typically a more complete migration or separation.
Many businesses have been slow to move their operations to the cloud and security has oft been cited as a key reason for this. In recent years, cloud providers have demonstrated their commitment to security by increasingly adhering to industry best practice and compliance requirements as well as providing customers with guidance on the delineation of responsibilities between the Cloud Service Provider and the customer. To quote the Amazon security whitepaper which considers the Shared Responsibility Model, while AWS manages security of the cloud, security in the cloud is the responsibility of the customer. This platitude is the same for Azure.
I’ll start by explaining some of the terms witch will be used when discussing AWS environments.
S3 stands for Simple Storage Services. S3 is presented to users as buckets which are object based storage repositories. These buckets can be publicly accessible or be restricted to role based access. A typical use case for these would be to store website data such as code, images and other relatively static content.
Virtual machines are provisioned via EC2 (elastic cloud computing) as Instances. Users can selected Instance images ranging from Amazon Machine Images to Red Hat, CentOS, Ubuntu, Microsoft Windows etc and can determine CPU, memory and capacity requirements. When an Instance is created it can be provided a role which determines resources it can access. Instances are also allocated Elastic Block Storage (EBS). EBS is magnetic or SSD provisioned volumes which can be used for storing data for that instance. These can be configured in RAID configuration and can be the root disk or separate volumes much as they would be in any multi-disk system. Instances are provided an elastic public IP address and an internal address – this is for instances in default VPCs only. The Instance can also be setup in a security group. Bootstrapping is also available to set certain configuration options from boot.
Security Groups determine the traffic allowed inbound or outbound from resources, thereby providing firewall functionality . In a default VPC (Virtual Private Cloud)), inbound traffic is denied and outbound traffic is permitted. In a custom VPC, internal IP address space must be provisioned and both inbound and outbound traffic is denied. Custom VPC subnets can be configured to be public or private and then require Internet gateways and/or NAT services to be configured along with appropriate security groups to permit inbound and/or outbound traffic.
IAM (Identity and Access Management) is the resource for managing users and access rights. Roles and associated permissions can be granted to users, password policies can be configured and multi-factor authentication can be enabled. Keys pairs used for accessing devices can also be configured and selected for use when provisioning new servers.
Cloudtrail allows you to capture user and application events and correlate this data into a logging solution.
It’s worth noting also that databases (relational: AWS Aurora, MS SQL, MySQL, Oracle, postgreSQL; non-relational: AWS DynamoDB)are provided as services abstract from infrastructure in that you can connect to and use databases without access to the underlying OS.
Now that we’ve covered the above, let’s go through how we review the following:
- Users and roles (IAM)
- Network rules (Security Groups)
- Data stores and data retention (S3, EBS, database)
- Encryption (CloudHSM)
- Logging (Cloudtrail)
Users and Roles
It is possible to download a credential report from IAM which shows your list of users, last logon, password rotation etc but it currently doesn’t appear to provide much use.
It is possible to use the GetAccountAuthorizationDetails API to get details of users, groups and roles but again from a usability perspective, this is not clear or intuitive.
As a security assessor, I’d need reports to be available which would clearly provide me specific information – e.g. what users have administrative or powerUser access, what users do.
Note – policy document for SecurityAudit role has not changed since 2012.
A clearer way to view users, groups, roles is as follows:
aws iam list-users | grep UserName
aws iam list-groups | grep GroupName
aws iam list-roles | grep RoleName
However, the above doesn’t provide details of which users are within which groups or how roles are allocated. Perhaps to do this we’d need a more complex tree structure to view.
We can see the groups to which a particular user belongs:
aws iam list-groups-for-user –user-name <username> | grep GroupName
We can see roles for a particular user:
aws iam list-attached-user-policies –user-name <username>
The attached user policy above references roles allocated to that user. I’m a little curious about the taxonomy as it seems policies and roles may be used interchangeably?
Password policies are available with the following command:
aws iam get-account-password-policy
Network rules
There does not appear to be a simple mechanism to download, extract or review security group rules. While security groups do have descriptions, it is not possible to comment against particular rules in order to link them to their justification or to a change tickets, disable etc.
Without specifying a region the below command states I need to specify a region for my request.
aws ec2 describe-security-groups
Using aws configure I set my region to us-east-1 and ran the above command successfully
The above enumerates the security groups, names, description and rules though it’s not very readable. It would be useful to be able to output this to a tabular format and include change references or rule justifications
I can simplify and see the names of the security groups and their descriptions using the following:
aws ec2 describe-security-groups | grep GroupName && aws ec2 describe-security-groups | grep Description
It is possible to list and view subnet details using the below command. A nice to have here would be a function or description of the subnet purpose:
aws ec2 list-subnets
Other useful commands in this section are below. Again it would be useful for some of these to have a reference point for these to reflect functionality.
aws ec2 describe-route-tables
aws ec2 describe-nat-gateways
aws ec2 describe-network-acls
aws ec2 describe-network-interfaces
aws ec2 describe-internet-gateways
For the above, if you want to know how many network acls you’ll be reviewing you can do as follows:
aws ec2 describe-network-acls | grep -c RuleNumber
Data stores and data retention
S3 – is it possible to use regular expressions to search through files within an S3 bucket? I don’t think you’d want to store sensitive data in a bucket. However, if you do, how do you find it?
Be careful of versioning on S3 buckets – legacy data may exist in previous versions.
It is possible to enable server side encryption on objects within S3 but not on S3 buckets themselves. Encryption is AES 256-bit.
EBS – search through mounted volume per any other system using regexes etc. Note that EBS volumes can be encrypted on creation. Encryption can use a default master key or you can create and specify a key to be used.
Database retention can be reviewed per usual – i.e. reviewing tables, fields and contents and viewing data as well as minimum date for that data.
Glacier is an additional archiving environment which may contain legacy data beyond data retention periods – related policies should be reviewed.
Encryption
It is possible to create an encryption key – see IAM dashboard option Encryption Keys. Here the key is allocated Key Administrators and Key Users (who can encrypt/decrypt using this key). It is also possible to configure a key rotation. It is not apparent what is the algorithm or key length.
Logging
Logs from Cloudtrail are stored in an S3 bucket (somewhat ironically logging is not enabled by default for S3 buckets) and are viewable via the Cloudtrail interface. To get useable information, you’ll want to be parsing these logs into a log repository with a log analysis tool for review. Note that Cloudtrail provides visibility of Amazon Resource Name activities within the account but does not provide visibility of what is going on within your systems. As you will want to monitor user activity on instances, logging solutions will need to be enabled and configured on these.
We will continue explaining PCI assessments in the cloud in future posts - please sign up using the form on the right of the page to be notified. Alternatively, contact us with any questions.
