Episode 78
Last week we started with AWS security by introducing Identity and Access Management in details. Today we will look at what’s else in the security services group and talk about how not to get hacked in the cloud in general.
Remaining named services we are interested in are Inspector, Certificate Manager, Directory Service, Web Application Firewall, Shield, Key Management Service, CloudHSM and Organizations. We will also look at Shared Responsibility Model.
Inspector
AWS Inspector is an automated auditing service. It uses a low-level agent deployed on EC2 instances to monitor system state, processes, network communication, installed software and other parameters in order to benchmark, spot security vulnerabilities and deviations from best practices. First we need to define an assessment template, which governs what targets should be tested, as well as subset of rules. There is plenty of rules, and new are added all the time by AWS researchers. After the initial configuration, an assessment run is performed and when it finishes we are presented with report consisting of list of findings and failed checks.
Certificate Manager
AWS Certificate Manager (ACM) is a tool for provisioning, managing and deploying Transport Layer Security (TSL) certificates also referred to by their predecessor name – Secure Socket Layer (SSL). Certificate is mechanism in asymmetric cryptography that allows to establish private, encrypted communication between a website and client browser as well as confirm identity of the host via a third party, trusted by both host and client, known as certificate authority. AWS certificate manager simplifies obtaining, configuring and maintaining such certificate, a task that had to be done manually otherwise. It works with Elastic Load Balancer, CloudFront, API Gateway and Elastic Beanstalk services and supports 2048 bit RSA keys and SHA-256.
Directory Service
AWS Directory Service is well… a directory service. A system that maps names of network resources to their addresses and facilitates organizing, managing and administrations. Resources include hardware and information, such as computers, volumes, printers, users, groups, files etc. AWS provides three options for that, we can use either AWS Directory Service for Microsoft Active Directory, Simple AD or AD Connector. The first one, aside for having a long name is a managed version of commercial product, as is the case with many other services in AWS. Aside for what Microsoft offers, we have built-in integration with AWS resources. It’s a recommended solution if we have more than 5000 users. Second option, Simple AD, is powered by Samba. It supports commonly used Active Directory features, but we can’t setup trust relationship between Simple AD and other Active Directory domains. We also lack dynamic DNS update, schema extensions, Multi-Factor authentication, communication over LDAP and few others. Simple AD is preferable for smaller organizations and is cheaper than Microsoft product. The third option, AD Connector, is a proxy service that allows to leverage an existing on-premise Microsoft Active Directory infrastructure. We can use existing corporate credentials to access AWS resources.
Web Application Firewall and Shield
AWS Web Application Firewall (WAF) is used to protect websites hosted on AWS from the higher end of the Internet protocol suite. While network Access Control List and Security Groups operates in the realm of IP addresses and ports, so the network and transport layers of ISO/OSI model, WAF operates on HTTP protocol in the application layer. It means that it has access to HTTP header, body and URI strings. It is also specific to services related with web hosting, so Elastic Load Balancer and CloudFront, not to generic network resources on AWS. It can be used to protect against attacks like SQL injection, Cross-site Scripting (XSS), block specific user-agents, bots, scrappers and such.
AWS Shield is yet another firewall type. In addition to web applications behind Elastic Load Balancer, CloudFront, like in case of WAF it also protects Route53 resources. Contrary to WAF however, it operates in transport and network layers of ISO/OSI stack. Shield is also specifically designed to mitigate Distributed Denial of Service (DDoS) attacks.
Key Management Service
AWS Key Management Service (KMS) purpose is to deal with symmetric cryptographic keys, that are part of AWS cryptosystem and are used to encrypt and decrypt data in various services, as well as outside of AWS. We can generate, exchange, store, delete and rotate keys. We can also exercise strict control over who has access to keys and log how they were used. The fundamental resource is the Customer Master Key (CMK), that never leaves AWS system and is used to encrypt Data Keys. When generating Data Key, we are given a plain text version and the version encrypted with CMK. We use plain text key to encrypt the data we want in our application, and discard it as soon as possible from memory (and obviously not store anywhere permanently). Then we can store encrypted version of the key, and whenever we want to decrypt our data, we send encrypted version of key to AWS and get plain text version. This way, the actual key is never stored anywhere and thus more secure. All cryptographic operations in AWS have encryption context that is passed as additional parameter, and is used for consistency control, logging and auditing.
CloudHSM
AWS CloudHSM is a service that facilitates Hardware Security Module, a dedicated cryptographic device that further increase our security. AWS uses Luna SA 7000 for that. After configuration, the device becomes a resource in our VPC and can be used for cryptographic operations. Keys are stored in physically isolated partition, and the device is physically temper-resistant. CloudHSM also allows us to host such device ourselves in on-premise data center and connect it to our VPC. This doesn’t necessarily mean that it is safer than in Amazon datacenter, but we have full control over it. Besides additional security, the common reason for using CloudHSM are corporate, contractual and regulatory compliance. Bureaucracy, you know.
Organizations
AWS Organizations is an account management service. While Identity and Access Management, that we covered in detail in the last episode, is applicable to user accounts created within a single AWS account, the Organizations service is about centrally managing a group of AWS accounts, each with it’s own billings, limits, root accounts (you don’t use root account, do you?) etc. We can centrally configure access policies for multiple AWS accounts, automate account creation, consolidate billing, create groups of accounts for different purposes and meet security and compliance regulations for large organizations. Nice toy for evil corporations indeed.
Shared Responsibility Model at the end
That would be all in the topic of services in security group on AWS for now. When I saw it first, it was kinda overwhelming and felt somewhat redundant, but when you dive a bit deeper in each one, it starts to make sense. After all, security is a broad and diverse topic, there is plethora of ways you and your organization can be screwed up in the cloud, so it’s probably a good idea to know what tools are there at your disposal to mitigate risks at different layers and in different domains of our systems.
AWS gives a lot out of the box, but we need to be aware about the Shared Responsibility Model. In short, AWS secures the infrastructure and provides tools, they are responsible for security of the cloud. We need to use correctly those tools, and any other means necessary, to secure whatever we put on top of this infrastructure. We are responsible for security in the cloud. Also, the best cloud security will not save you if you lose a sticky note with your root account credentials in the bar after a few drinks.
In the next episode, we are going to take a closer look at AWS messaging services. Stay safe!
Image sources:
How To Train Your Java 
2 responses to “Amazon Security Services, Part Two”