Welcome back! This is the third blog post in the series and you might be feeling a bit unmotivated. I get it, every blog post is long and we still have more to go.
Because I was sick of studying as well, I tried taking a practice test and completely failed the security part! So we are back here. It’s tricky to remember what does what, but do not worry — I’ll emphasize the differences between them!
What will we talk about today?
- Compliance in AWS & AWS Artifact
- The Shared Responsibility Model
- AWS WAF & AWS Shield
- AWS Inspector & AWS Trusted Advisor
- AWS CloudTrail & AWS Config
- Penetration Testing in AWS
- AWS KMS and AWS CloudHSM
- AWS Secrets Manager vs AWS System Manager ->Parameter Store
- Amazon GuardDuty vs AWS control tower
- Resolving Compromised IAM Credentials
- Amazon Athena vs Amazon Macie
- AWS Security Hub
Compliance in AWS
The term compliance describes the ability to act according to an order, set of rules, or request. Cloud compliance ensures that cloud computing services meet compliance requirements.
An example of compliance requirement is PCI DSS, which is an acronym for “Payment Card Industry Data Security Standard”. That means that if you want to receive payments in your business, you need to meet the compliance requirements.
Compliance mandates require that you have implemented essential security controls to protect sensitive data in your environment. Auditors will want to see proof that you know:
- Which assets contain sensitive data
- Who can access these data (and that they are authorized)
- How assets are configured and whether there are any known vulnerabilities present
- What threats exist and how to respond to them.
You need to ensure you can handle such sensitive data, like payment cards, in order to store them. AWS supports security standards and compliance certifications.
AWS Artifact
No cost, self-service portal for on-demand access to AWS’ compliance reports. You can access AWS Artifact directly from the AWS Management Console.
The Shared Responsibility Model
Security and Compliance are a shared responsibility between AWS and the customer.
This shared model can help relieve the customer’s operational burden. AWS operates, manages, and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates.
The nature of this shared responsibility also provides the flexibility and customer control that permits the deployment.
As shown in the chart below, this differentiation of responsibility is commonly referred to as Security of the Cloud versus Security in the Cloud.
Do you know what this shared responsibility model reminds me of?
When I used to work at a clothing shop in the mall, it was my responsibility to put the money in the safe and lock the shop doors, while it was the mall’s responsibility to have a security guy 24/7 and prevent entrance to the mall at closing hours.
Here is a trick to remember who is responsible: Can you do this in the AWS console or in EC2 by yourself?
- If yes, you are likely responsible: SGs, IAM users, Patching EC2 operating systems, patching DBs running on EC2, etc.
- If not, AWS is likely responsible for: Management of Data Centers, security cameras, cabling, patching RDS Operating Systems, etc.
- Encryption is a shared responsibility.
You can read more about the shared responsibility model here.
AWS WAF & AWS Shield
AWS WAF is a Web Application Firewall that helps protect your web applications or APIs against common web exploits and bots that may affect availability, compromise security, or consume excessive resources.
AWS Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS.
Here is a nice explanation I found for DDoS attack:
From a high level, a DDoS attack is like an unexpected traffic jam clogging up the highway, preventing regular traffic from arriving at its destination.
— https://www.cloudflare.com/learning/ddos/what-is-a-ddos-attack/
There are two tiers of AWS Shield — Standard and Advanced. The standard shield is turned on by default, but the advanced protection is an additional cost.
So they both protect from attacks, what is the difference?
AWS WAF is a Web Application Firewall, designed to stop hackers.
AWS Shield is a DDOS mitigation service designed to stop DDOS attacks.
AWS Inspector & AWS Trusted Advisor
Some people may confuse AWS Inspector and AWS Trusted Advisor.
AWS Inspector is used for inspecting EC2 instances for vulnerabilities. Remember that it’s inspecting EC2 instances.
AWS Trusted Advisor inspects your AWS account as a whole (not just EC2). It does more than just security checks: Cost optimization, performance, and fault tolerance.
Remember it’s advising you on how to improve your AWS usage.
Trust Advisor has a tiered service based on the AWS support plans. We will talk about it more when we reach the billing & pricing blog post, but for now know that there are four support plans: Basic, developer, business, and enterprise.
AWS Basic Support and AWS Developer Support customers can access core security checks and all checks for service quotas. AWS Business Support and AWS Enterprise Support customers can access all checks.
AWS CloudTrail and AWS Config
AWS CloudTrail
AWS CloudTrail is recording AWS management console actions and API calls. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred.
Remember it’s like a paper trail — it documents everything.
AWS Config
AWS Config provides a detailed view of the configuration of AWS resources in your AWS account. This includes how the resources are related to one another and how they were configured in the past so that you can see how the configurations and relationships change over time. This enables you to simplify compliance auditing, security analysis, change management, and operational troubleshooting.
Some people mix up Amazon CloudWatch and AWS Config. CloudWatch is used for monitoring AWS resources and applications on AWS and on-premises and is not part of the security section. I have a blog post about CloudWatch alarms if you wanna check it out.
Do you see why it’s tricky? CloudWatch is used for monitoring performance and AWS Config is used to monitor configurations of your AWS resources.
Penetration Testing in AWS
A penetration test (pentest) is a simulated cyberattack against your computer system to check for exploitable vulnerabilities.
If we go back to the days I worked in the mall, it’s similar to when your management brings an undercover supervisor as a client, to check your customer service qualities.
Pen-test without prior approval
When I learned about cybersecurity at university, I was curious to ‘test’ random websites on the internet. I just wanted to check what information I could find. Cool idea, but it’s illegal. You can’t decide to try hacking Facebook just for funnies — you can only do it with prior approval.
That’s the same with AWS. You can carry out pentests against your AWS infrastructure without prior approval for eight services only (Some of them you know, and some of them we will meet in a future blog post):
- EC2 instances, NAT Gateways, and ELBs (These are 3 services but all under the EC2 service).
- RDS
- CloudFront
- Aurora
- API Gateway
- Lambda & Lambda Edge functions
- Lightsail resources.
- Elastic beanstalk envs.
AWS KMS and AWS CloudHSM
TLAs…TLAs everywhere… TLAs are Three Letters Acronyms, and here we have a bunch.
KMS = Key Management Service. This service creates and manages cryptographic keys and controls their use across a wide range of AWS services and in your applications.
A few facts about it:
- AWS KMS encrypt and decrypt data, up to 4 kb in size.
- AWS KMS manages customer master keys (CMKs). A customer master key (CMK) is the primary resource in AWS KMS.
- AWS KMS is integrated with most AWS services and is ideal for s3 objects, DB passwords, and API keys stored in the systems manager parameter store.
- AWS KMS is a regional service and is on shared hardware => This is where AWS CloudHSM enters the picture.
AWS CloudHSM
AWS CloudHSM is a cloud-based hardware security module (HSM) that enables you to easily generate and use your own encryption keys on the AWS Cloud.
CloudHSM is a dedicated hardware security module (HSM), single-tenant, multi-AZ cluster, FIPS 140–2 Level 3.
Now, I’ll give you the definition for that FIPS thingy, not because I think it’s necessary, but for those of you who are curious: FIPS 140–2 Level 3 allows for a cryptographic module to be executed on a general-purpose PC as long as its operating system meets the minimum requirements.
You can read more about it here.
AWS Systems Manager Parameter Store vs AWS Secrets Manager
Parameter Store, a capability of AWS Systems Manager, is secure serverless storage for configuration and secrets: passwords and DB connection strings. It is a component of AWS.
Important to mention: Systems Manager was formerly known as “Amazon Simple Systems Manager (SSM)” and the original abbreviated name of the service, “SSM”, is still reflected in various AWS resources. That means You’ll see SSM in the AWS console and it means Secrets Manager.
Values can be stored encrypted (KMS) or in plaintext. In order to store them encrypted, we use the AWS KMS.
This service is free of cost, but there is a limit of 10,000 per account. If you need more — then Secrets manager is your choice.
AWS Secrets Manager is similar to Systems Manager Parameter Store. It automatically rotates secrets, applies the new key/password in RDS for you, and generates random secrets.
For this service, you are charged per secret stored and per 10,000 API calls.
Amazon GuardDuty vs AWS Control Tower
These two services are sitting together because they both manage to secure your AWS environment, so it’s easy to mix between them.
Amazon GuardDuty is a threat detection service that uses machine learning and continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts, workloads, and data stored in Amazon S3. GuardDuty is enabled only to watch over one account.
AWS Control Tower is defined as the easiest way to set up and govern a secure multi-account AWS environment. This service is for large enterprises.
Resolving Compromised IAM Credentials
We’ve talked about IAM in the previous AWS blog post.
To be honest, as a non-native English speaker, I thought the word compromise only describe a situation like deciding from which place to order dinner, but apparently, here in the title, it means “we do the best we can to secure but not preparing for the oopsie is not wise”, which makes sense when we are on the topic of security in AWS.
So, what do you do to resolve compromised IAM credentials?
- Determine what resources those credentials have access to.
- Invalidate the credentials so they can no longer be used to access your account.
- Consider invalidating any temporary security credentials that might have been issued using the credentials.
- Restore appropriate access.
- Review access to your AWS account.
Amazon Athena Vs Amazon Macie
I’ll tell you about the services that sound like first names, and you decide who is Athena and who is Macie!
What is Athena?
An interactive query service that enables you to analyze and query data located in S3 using standard SQL. Athena helps you analyze unstructured, semi-structured, and structured data stored in Amazon S3.
- Serverless, nothing to provision, pay per query/per TB scanned.
- No need to set up complex Extract/Transform/Load (ETL) processes
- Works directly with data stored in S3
What can Athena be used for?
- Can be used to query log files stored in S3, e.g. ELB logs, S3 access logs, etc
- Generate business reports on data stored in S3
- Analyze AWS Cost and Usage reports (we will talk about this service in the future).
- Run queries on click-stream data.
The only connection of Athena to security that I see is integration with IAM. Maybe it’s here because people confuse it with Macie. What do you think?
What is Macie?
First of all, let’s learn about PII (Personally identifiable information). It’s personal data used to establish an individual’s identity, such as home address, email address, or credit card number.
This data could be exploited by criminals, used in identity theft and financial fraud.
What does this have to do with Macie? Amazon Macie is a security service that uses Machine Learning and NLP (Natural language processing) to discover, classify and protect sensitive data stored in S3. It’s great for PCI-DSS and preventing ID theft.
Macie uses AI to recognize if your S3 objects contain sensitive data such as PII, and can also analyze CloudTrail logs.
So, Macie helps recognize objects in S3 that contain sensitive data.
AWS Security Hub
Well, AWS Security Hub does pretty much what you’d expect by the name: Provides a single place that aggregates, organizes, and prioritizes your security alerts and findings from multiple AWS services — such as GuardDuty, Amazon Inspector, Amazon Macie, IAM Access Analyzer and AWS firewall manager — across multiple AWS accounts.
Notice that we have the word “multiple” twice — multiple services and multiple accounts.
That’s it! Wow, we learned a lot today! We learned about concepts such as Compliance in AWS, The Shared Responsibility Model, Penetration Testing in AWS and Resolving Compromised IAM Credentials.
We also got familiar with a bunch of AWS services: AWS Artifact, AWS WAF & AWS Shield, AWS Trusted Advisor, AWS Config, AWS KMS and AWS CloudHSM, AWS Secrets Manager vs Parameter Store, GuardDuty and AWS Control Tower, Amazon Athena Vs Amazon Macie and AWS SecurityHub.
Before we go, I couldn’t help but wonder why some services were called “AWS XXX” and the others “Amazon XXX” and apparently I wasn’t the only one. So according to StackOverflow,
The pattern is that utility services are prefixed with “AWS”, while standalone services are prefixed by “Amazon”.
You are welcome.
If you read this, you’ve reached the end of the blog post, and I would love to hear your thoughts! Was I helpful? Do you also use AWS at work? Here are the ways to contact me:
Facebook: https://www.facebook.com/cupofcode.blog/
Instagram: https://www.instagram.com/cupofcode.blog/
Email: cupofcode.blog@gmail.com
