Information Security (InfoSec) teams are getting attacked (literally and figuratively) from both inside and outside the organization. Their budgets and head counts are getting slashed, and attackers are swimming in mature tools and technologies that give even fledgling hackers easy access to more and more systems. If your InfoSec team finds itself tasked to “do more with less,” there are few platforms better suited to that requirement than AWS.
Let’s examine the top concepts, services and tools that provide your AWS-hosted apps with the same enterprise level security that Amazon.com, itself, enjoys.
Security at AWS: The broad strokes
Before we delve into individual services and where each shines, it’s important that we take a holistic look at how security works in AWS. At its core, AWS implements security at the following layers.
• Service-level hardening
• Identity and access control
• Native encryption options for select services
• Network security
• Auditing and logging
• Security “wizards”
We’ll march through each below, calling out select services or concepts where they fit, but if you’re new to public cloud, or just new to AWS, you’ll also want to augment your understanding with AWS’ Security Center. Along with the Governance, Regulation, and Compliance Center, AWS gives excellent guidance on what they offer as well as how their products map to similar products you may have used in your own data center.
The most important thing about AWS Security is that the specifics for how to implement that security is different for each individual service.
Service-level hardening
Since Amazon.com uses many AWS services for its internal architectures, it only makes sense that AWS would harden select services, like CDN (via the service “CloudFront”) and Load Balancers (ALB, NLB, ELB for Application, Network, and Elastic Load Balancer) for all customers. In the case of CloudFront and the *LB services, AWS goes as far as to outright block UDP traffic (UDP is the protocol of choice for many DDoS attacks like amplification). Due to the sensitive nature of the data inside, AWS even forces on-the-wire (SSL/TLS) encryption when using services like their archival service, Glacier or their DNS service, Route 53. Glacier, which is used heavily to archive Governance, Regulation and Compliance (GRC) data, also goes one step further by natively encrypting all data at rest. Just by using any of the aforementioned services, one automatically blocks entire vectors of attack.
Identity and access control
AWS offers several services to authenticate and control access for both internal (administrators and developers) and external (end-users, customers or partners) users. At the heart of AWS’ access control is their holistic Identity and Access Management (IAM) service. This service allows you to create both long-standing and federated (short-term, expiring) accounts for both types of users, and it can lock down access (for most services) to both the individual API call (like “Start Instance” on EC2) and individual resource (like “instance id i-12345) or resource family (like “t2 family” of EC2). Federated access can be provided via social media network (for external users of, perhaps, a mobile game), Active Directory, or SAML. Mobile access can also be enabled by another service called Cognito which allows you to set up and manage entire fleets of potentially millions of users.
Native encryption options for select services
As stated earlier, AWS forces SSL/TLS for some sensitive services like Glacier and Route 53, but for other services where some customers may wish to selectively enable encryption, AWS offers both on-the-wire as well as at-rest encryption capabilities. Some services like EBS (SAN disk you can attach to EC2), S3 (AWS’ object store), and Redshift (AWS’ Data Warehouse) make at-rest encryption as easy as checking a box in a web form. For users requiring the highest level of at-rest encryption possible, AWS offers two key management services—KMS and HSM—which can be used to encrypt data (both natively for select service, and client side for non-native) at rest with user-controlled keys.
Additionally, every API endpoint AWS offers can be called over SSL/TLS, and some services (such as S3, Lambda, etc) can even block non-SSL calls.
Network security
To provide the best network security possible, AWS offers a service called Virtual Private Cloud (VPC), which allows users to create network topologies similar to ones they have used on-premise. VPC provides the ability to:
• Create subnets (both public and private)
• Use user-defined private IP address ranges
• Use point-and-click firewalls called Security Groups (at the instance level) or NACLs (at the subnet level)
• Publish both internal and external routes for traffic
• Use secure gateways (called “VPC Endpoints”) for access to internal services like S3
• Launch many services like A/E/NLBs, EC2, RDS, Redshift, Elasticache, EMR, and others inside the VPC
• Use VPN and other types of secure gateways between your data center and AWS.
Additionally, AWS offers Web Application Firewall (or WAF) services (via AWS WAF), as well as point-to-point fiber connectivity services (via DirectConnect) that give you a dedicated, secured channel between your on-prem resources and your AWS-side resources.
Auditing and logging
Many services (like S3, Redshift and others) provide the ability to turn on logging to track access and other activity of that individual service, but AWS also has several security-minded platform-wide auditing and logging services you should be aware of:
• CloudTrail: Wouldn’t it be nice to get detailed information about every API call (both successful and unsuccessful) that was made to your back-end? By turning on CloudTrail (must be turned on in every region you operate), you get exactly that—Apache Commons-type logging info (remote IP, user agent, credentials used, timestamp, etc.) for every single API call that anyone makes to any of the thousands of GA’d features that AWS provides. These logs, in combination with the output of AWS Config, are often all one needs to implement a large part of a GRC-related stack.
• CloudWatch Logs: CloudWatch Logs provide the ability to consume any log file format (even custom ones only your organization uses), from any source (on-premise or AWS-hosted), and trigger alarms and alerts on the data contained inside. One could use this service to raise both operational (e.g. resource scarcity) and security (e.g. hacking attempt) alerts on any data point coming from any product you use.
• AWS Config and Config Rules: The first time you point AWS Config at your account, it can do resource discovery and inventory, telling you everything you have deployed in AWS and how it is configured. AWS Config will then run periodically (about every 5-15 minutes) and capture the deltas from the previous config run. One could then hand the AWS Config snapshots to an auditor requesting the configuration of a certain resource on a certain day at a certain time. Config Rules takes this one step further by providing automated issue resolution when, for example, it detects that a disk which should be encrypted isn’t. Config Rules can automatically set that disk back to encrypted without any human intervention.
Security “wizards”
Hackers use no shortage of wizards and convenience tools to increase their efficiency. Why shouldn’t you do the same? With AWS, you have access to several such tools that allow even novice users the ability to implement powerful security. Here’s a list of a few.
• VPC Wizards: When standing up a VPC, you can now choose from a handful of pre-configured VPCs with a mixture of private and public subnets.
• AWS Inspector: If you’ve ever run a black-box penetration test of your systems using a tool such as Nessus, you know the vulnerabilities it can reveal. AWS Inspector provides similar capabilities by performing app-level vulnerability testing against industry best practice rule packages such as CIS and “Common Vulnerabilities and Exposures.” Inspector will then run on a user-defined periodic basis, kicking out reports of HIGH, MEDIUM, and LOW security issues with actionable advice for resolution.
• Amazon Macie: One of the most difficult duties of an InfoSec team is identifying, classifying, and blocking access to certain types of sensitive data such as customer phone numbers, social security numbers, and the like. The Macie service can assist with this by crawling your data sources, culling insight from them, and then making recommendations about which data needs further protections.
• Trusted Advisor: To assist new customers with understanding and resolving high-level issues, AWS has created, and aggressively updates, a document called the Well-Architected Framework—a treasure trove of best practices compiled from thousands of customer interactions. The Well-Architected Framework currently covers five high-level topics:
• Security
The Trusted Advisor service tracks all of the above via a periodically-updated web dashboard that lets you identify and resolve major issues in one of the categories. By no means should Trusted Advisor be used as your sole mechanism for identifying and resolving security issues, but it can (and should) be periodically checked to help you avoid making a glaring mistake (like opening your data warehouse firewall to the world). If you’re new to AWS, reading that Well-Architected Framework end-to-end should be the next thing you do after reading this blog.
There is no such thing as “perfect” security
“Security” in AWS is a topic that has high-level details, but a myriad of low-level ones as well. It’s our sincere hope that we gave you some actionable, big-ticket things to think about, but it’s important to remember that in AWS every single service has many settings and configurations that can dramatically impact its security.
Anyone who has had to implement security will tell you that “perfect” security doesn’t exist (unless you unplug your server and drop it to the bottom of the ocean!) It’s simply a matter of knowing what options exist and which ones you can implement cost-effectively. With the AWS platform changing so constantly and aggressively, knowing what options exist will be an ongoing battle that your InfoSec team needs to dedicate time and money to. Even if you start out knowing the full lay of the land, the land will change so much in a mere six months that, without that new knowledge, you’ll be fighting modern hackers with out-of-date tools.
If, like a lot of companies, your team is not yet up to speed on the AWS side of things, taking an AWS training course from Global Knowledge can help you get from here to secure faster than just about any other route.
Related courses
Subscribe
Never miss another article. Sign up for our newsletter.
The post Examining the 6 Layers of AWS Security appeared first on Global Knowledge Blog.