The document discusses Amazon Web Services (AWS) security services including AWS CloudTrail, VPC Flow Logs, Amazon CloudWatch, Amazon GuardDuty, AWS Security Hub, and Amazon Detective. It provides overviews and descriptions of the features and capabilities of these services for monitoring, detecting threats, aggregating findings, and investigating security issues on AWS.
Identify
Protect
Detect
Respond
Recover
CloudFormation, OpsWorks, - recovery is not just about the data, but also the ability to recover their entire infrastructure and apps extremely fast.
Integrity validation uses
Who changed what, when, and using what credentials?
How does Integrity Validation work?
CloudTrail creates a digest file, when it delivers new logs into your Amazon S3 Bucket
CloudTrail uses a private key per-region to cryptographically sign the digest file
Customers can use a public key, that correlates to the private key, to validate signatures
SNS notifications when new CloudTrail log files are delivered to Amazon S3 Bucket
Who made the API call?
When was the API call made?
What was the API call?
Which resources were acted up on in the API call?
Where was the API call made from and made to?
Stored durably in S3
Discuss ways to consume CloudTrail logs (Console, CLI, Splunk, SumoLogic, AlertLogic, Loggly, DataDog, etc.)
No Agents! Just Turn it on. No really, Ill wait.
Enable per ENI, per Subnet or per VPC
All network traffic data is logged to CloudWatch logs so you get durable storage but also all the analysis features such as filter queries and metric creation
And then Create Alarms on those metrics
Collected, processed and stored in ~10 minute capture windows into Cloudwatch Logs
Amazon CloudWatch is a monitoring service for AWS cloud resources and the applications you run on AWS and OnPrem. You can use Amazon CloudWatch to collect and track metrics, collect and monitor log files, set alarms, and automatically react to changes in your AWS resources. Amazon CloudWatch can monitor AWS resources such as Amazon EC2 instances, Amazon DynamoDB tables, and Amazon RDS DB instances etc, as well as custom metrics generated by your applications and services, and any log files your applications generate.
You can use Amazon CloudWatch to gain system-wide visibility into resource utilization, application performance, and operational health. You can use these insights to react and keep your application, infrastructure and operations running smoothly.
At a high-level CloudWatch allows to:
Spot Trends
Centralize Monitoring
Troubleshoot
Create Metrics on Logs to evaluate behavior
Take automated action with event and alarms
And have a operational status view through dashboards.
Data Sources
GuardDuty analyzes AWS VPC Flow Logs, DNS and CloudTrail Events. It is optimized to consume large volumes of.
AWS does all of the heavy lifting you are not required to turn on any logging.
Data is NOT stored by GuardDuty – It is pulled from internal sources, analyzed in memory and then discarded.
GuardDuty ONLY stores the results from the findings that are produced.
Thus your data remains your data
Click
With threat intel being applied to data sources Guard Duty can detect known threats and produce instant findings (they are known !). Things like (READ bottom of slide)
Threat Intel comes from:
AWS Security Intel – GuardDuty has access to AWS’ own security intel feed (from ASIS team). This is the only way you can access this feed. This Intel is constantly being updated by AWS Security team.
Commercial/partner Intelligence is currently provided by CrowdStrike and ProofPoint. At no extra cost to the customer.
Customer’s can provide there own Threat Intelligence data and customer provided threat intel does not get shared across customers.
What Else can GD detect…
Discuss Training periods – don’t try to test these
For detecting unknown threats GuardDuty incorporates a heuristic or anomaly based technique that builds profiles of "normal" behavior and then looks for deviations from that normal behavior. This is done using very simplistic state-machines to represent normal behavior, to approximating normal behavior
GuardDuty has an AWS console that consists of a findings dashboard and functionality for customers to review, investigate, search, filter, manage, and respond to GuardDuty security findings
Auto – Archive feature (Examples: SSH for bastion, portscan for vuln tool, anything you don’t want to action on)
In the right hand pane
GuardDuty provides actionable alerts that include detailed information about the threat and AWS resources involved.
GuardDuty can be leveraged vie the CLI/SDK/API using a JSON format which really means all of the information can be used in a machine to machine use case or more generally integrating with various technologies Using…
AWS Security Hub workflow
Get started in a few clicks and a few more for multi-account rollup
No normalization or parsing needed with AWS Security Finding Format
28 partner integrations with simple setup (a few clicks to 15 min of CloudFormation deployment); 3 fully automated AWS integrations
25+ out-of-the-box AWS correlation and stacking rules called “insights” and ability for customers to create their own; plus default ones from partners coming soon.
Automated compliance checks via CIS AWS Foundations Benchmark
Automated response and remediation actions on specific findings via CloudWatch Events rules and targets
You can set up AWS Security Hub in the AWS Management Console by clicking the “Enable Security Hub” button and adding your AWS accounts to the service. The process of ingesting data across the AWS security services begins. Security Hub (CLICK) aggregates findings from AWS security services and partner security tools and correlate them to identify the highest priority findings. As an additional step, (CLICK) Security Hub conducts continuous and automated compliance checks using industry standards and provide the results to you for remediation. Finally, you may review the findings (CLICK) in the console and select the ones for specific actions such as sending finding to ticketing, chat, email, or automated remediation via CloudWatch Events and Lambda.
AWS Security Hub workflow
Get started in a few clicks and a few more for multi-account rollup
No normalization or parsing needed with AWS Security Finding Format
28 partner integrations with simple setup (a few clicks to 15 min of CloudFormation deployment); 3 fully automated AWS integrations
25+ out-of-the-box AWS correlation and stacking rules called “insights” and ability for customers to create their own; plus default ones from partners coming soon.
Automated compliance checks via CIS AWS Foundations Benchmark
Automated response and remediation actions on specific findings via CloudWatch Events rules and targets
You can set up AWS Security Hub in the AWS Management Console by clicking the “Enable Security Hub” button and adding your AWS accounts to the service. The process of ingesting data across the AWS security services begins. Security Hub (CLICK) aggregates findings from AWS security services and partner security tools and correlate them to identify the highest priority findings. As an additional step, (CLICK) Security Hub conducts continuous and automated compliance checks using industry standards and provide the results to you for remediation. Finally, you may review the findings (CLICK) in the console and select the ones for specific actions such as sending finding to ticketing, chat, email, or automated remediation via CloudWatch Events and Lambda.
1.1 Avoid the use of the "root" account
1.2 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password
1.3 Ensure credentials unused for 90 days or greater are disabled
1.4 Ensure access keys are rotated every 90 days or less
1.5 Ensure IAM password policy requires at least one uppercase letter
1.6 Ensure IAM password policy requires at least one lowercase letter
1.7 Ensure IAM password policy requires at least one symbol
1.8 Ensure IAM password policy requires at least one number
1.9 Ensure IAM password policy requires minimum password length of 14 or greater
1.10 Ensure IAM password policy prevents password reuse
1.11 Ensure IAM password policy expires passwords within 90 days or less
1.12 Ensure no root account access key exists
1.13 Ensure MFA is enabled for the "root" account
1.14 Ensure hardware MFA is enabled for the "root" account
1.16 Ensure IAM policies are attached only to groups or roles
1.20
1.22 Ensure IAM policies that allow full "*:*" administrative privileges are not created
2.1 Ensure CloudTrail is enabled in all regions
2.2 Ensure CloudTrail log file validation is enabled
2.3 Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible
2.4 Ensure CloudTrail trails are integrated with CloudWatch Logs
2.5 Ensure AWS Config is enabled in all regions
2.6 Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket
2.7 Ensure CloudTrail logs are encrypted at rest using KMS CMKs
2.8 Ensure rotation for customer created CMKs is enabled
2.9 Ensure VPC flow logging is enabled in all VPCs
3.1 Ensure a log metric filter and alarm exist for unauthorized API calls
3.2 Ensure a log metric filter and alarm exist for Management Console sign-in without MFA
3.3 Ensure a log metric filter and alarm exist for usage of "root" account
3.4 Ensure a log metric filter and alarm exist for IAM policy changes
3.5 Ensure a log metric filter and alarm exist for CloudTrail configuration changes
3.6 Ensure a log metric filter and alarm exist for AWS Management Console authentication failures
3.7 Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs
3.8 Ensure a log metric filter and alarm exist for S3 bucket policy changes
3.9 Ensure a log metric filter and alarm exist for AWS Config configuration changes
3.10 Ensure a log metric filter and alarm exist for security group changes
3.11 Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)
3.12 Ensure a log metric filter and alarm exist for changes to network gateways
3.13 Ensure a log metric filter and alarm exist for route table changes
3.14 Ensure a log metric filter and alarm exist for VPC changes
4.1 Ensure no security groups allow ingress from 0.0.0.0/0 to port 22
4.2 Ensure no security groups allow ingress from 0.0.0.0/0 to port 3389
4.3 Ensure the default security group of every VPC restricts all traffic
1.1 Avoid the use of the "root" account
1.2 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password
1.3 Ensure credentials unused for 90 days or greater are disabled
1.4 Ensure access keys are rotated every 90 days or less
1.5 Ensure IAM password policy requires at least one uppercase letter
1.6 Ensure IAM password policy requires at least one lowercase letter
1.7 Ensure IAM password policy requires at least one symbol
1.8 Ensure IAM password policy requires at least one number
1.9 Ensure IAM password policy requires minimum password length of 14 or greater
1.10 Ensure IAM password policy prevents password reuse
1.11 Ensure IAM password policy expires passwords within 90 days or less
1.12 Ensure no root account access key exists
1.13 Ensure MFA is enabled for the "root" account
1.14 Ensure hardware MFA is enabled for the "root" account
1.16 Ensure IAM policies are attached only to groups or roles
1.20
1.22 Ensure IAM policies that allow full "*:*" administrative privileges are not created
2.1 Ensure CloudTrail is enabled in all regions
2.2 Ensure CloudTrail log file validation is enabled
2.3 Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible
2.4 Ensure CloudTrail trails are integrated with CloudWatch Logs
2.5 Ensure AWS Config is enabled in all regions
2.6 Ensure S3 bucket access logging is enabled on the CloudTrail S3 bucket
2.7 Ensure CloudTrail logs are encrypted at rest using KMS CMKs
2.8 Ensure rotation for customer created CMKs is enabled
2.9 Ensure VPC flow logging is enabled in all VPCs
3.1 Ensure a log metric filter and alarm exist for unauthorized API calls
3.2 Ensure a log metric filter and alarm exist for Management Console sign-in without MFA
3.3 Ensure a log metric filter and alarm exist for usage of "root" account
3.4 Ensure a log metric filter and alarm exist for IAM policy changes
3.5 Ensure a log metric filter and alarm exist for CloudTrail configuration changes
3.6 Ensure a log metric filter and alarm exist for AWS Management Console authentication failures
3.7 Ensure a log metric filter and alarm exist for disabling or scheduled deletion of customer created CMKs
3.8 Ensure a log metric filter and alarm exist for S3 bucket policy changes
3.9 Ensure a log metric filter and alarm exist for AWS Config configuration changes
3.10 Ensure a log metric filter and alarm exist for security group changes
3.11 Ensure a log metric filter and alarm exist for changes to Network Access Control Lists (NACL)
3.12 Ensure a log metric filter and alarm exist for changes to network gateways
3.13 Ensure a log metric filter and alarm exist for route table changes
3.14 Ensure a log metric filter and alarm exist for VPC changes
4.1 Ensure no security groups allow ingress from 0.0.0.0/0 to port 22
4.2 Ensure no security groups allow ingress from 0.0.0.0/0 to port 3389
4.3 Ensure the default security group of every VPC restricts all traffic
Standards is one of the methods used by Security Hub to process findings.
This method uses compliance frameworks that are based on regulatory requirements or AWS best practices.
AWS has defined specific evaluation checks that align to the controls within a certain compliance standard.
CIS, or Center for Internet Security, AWS Foundations Benchmark is the compliance standard currently being used by Security Hub. AWS Security Hub creates a score to inform you how your AWS environment is doing against the CIS Benchmark and displays it on the main dashboard. When you click through to the standard, you will see a summary of the controls that need your attention. Security Hub also shows informational best practices on how to mitigate each compliance issue.
We do all the heavy lifting of provisions processing and storing logs
We take those logs and extract important records and combine them into a federated view
Then present them in an organized time series view that power investigations and reduce mean time to respond
Out of the box we keep this information for a full year so you can historically go back in time
Amazon Detective automatically processes terabytes of event data records about IP traffic, AWS management operations, and malicious or unauthorized activity. It organizes the data into a graph model that summarizes all the security-related relationships in your AWS environment. Amazon Detective then queries this model to create visualizations used in investigations. The graph model is continuously updated as new data becomes available from AWS resources, so you spend less time managing constantly changing data.
Amazon Detective is integrated with AWS security services such as Amazon GuardDuty and AWS Security Hub as well as AWS partner security products to help quickly investigate security findings identified in these services. Using a single-click from these integrated services you can go to Amazon Detective and immediately see events related to the finding, drill down into relevant historical activities and investigate the issue. For example, from an Amazon GuardDuty finding, you can launch Amazon Detective by clicking on “Investigate” that provides instant insight into the relevant activity for the involved resource, giving you the details and context to quickly decide whether the detected finding reflects actual suspicious activity.
Amazon Detective produces visualizations with the information you need to investigate and respond to security findings. It helps you answer questions like ‘is this normal for this role to have so many failed API calls?’ or ‘is this spike in traffic from this instance expected?’ without having to organize any data or develop, configure, or tune your own queries and algorithms. Amazon Detective maintains up to a year of historical event data that shows changes in the type and volume of activity over a selected time window, and links those changes to security findings.
Benefits [“Why”]
Faster and more effective investigationsAmazon Detective presents a unified view of user and resource interactions over time, with all the context and details in one place to help you quickly analyze and get to the root cause of a security finding. For example, an Amazon GuardDuty finding, like an unusual Console Login API call, can be quickly investigated in Amazon Detective with details about the API call trends over time, and user login attempts on a geolocation map. These details enable you to quickly identify if you think it is legitimate or an indication of a compromised AWS resource. Save time and effort with continuous data updates Amazon Detective automatically processes terabytes of event data records about IP traffic, AWS management operations, and malicious or unauthorized activity. It organizes the data into a graph model that summarizes all the security-related relationships in your AWS environment. Amazon Detective then queries this model to create visualizations used in investigations. The graph model is continuously updated as new data becomes available from AWS resources, so you spend less time managing constantly changing data.Easy to use visualizationsAmazon Detective produces visualizations with the information you need to investigate and respond to security findings. It helps you answer questions like ‘is this normal for this role to have so many failed API calls?’ or ‘is this spike in traffic from this instance expected?’ without having to organize any data or develop, configure, or tune your own queries and algorithms. Amazon Detective maintains up to a year of historical event data that shows changes in the type and volume of activity over a selected time window, and links those changes to security findings.
You may be organized with tier one analysts
Or you may have a small team that is responsible for all of it