Domain 1

Exposed AWS Access Keys

Determine what resources those credentials have access to - If the credentials only allow read access to data you intended to make public, you might choose to create new credentials first, transition to these new credentials, and then disable the old credentials.
Invalidate the credentials so they can no longer be used to access your account - Disabling instead of deleting.
Invalidate any temporary security credentials that might have been issued using the credentials.
Restore appropriate access - If you deleted an IAM user, create a new one with a new access key.
Review access to your AWS account - Review all available S3 bucket logs and CloudTrail logs.

Compromised EC2 Instance

Lock the instance down.
Take the EBS Snapshot.
Take a Memory Dump.
Perform Forensic Analysis.
Terminate the instance.

GuardDuty

A continuous security monitoring service that analyses and processes the following Data sources: VPC Flow Logs, CloudTrail logs, and DNS logs.
Trusted IP lists consist of IP addresses that you have trusted for secure communication with your AWS infrastructure and applications.
If you are using a 3rd party DNS resolver, for example, OpenDNS or GoogleDNS, or if you set up your own DNS resolvers, then GuardDuty cannot access and process data from this data source.
Super important:
- In an Active Directory environment, the DNS Resolver is generally set to that of the AD server. So, if the customer DNS resolver is used, Guard Duty will not be able to see the DNS request.

Penetration Testing

AWS customers are welcome to carry out penetration tests against their AWS infrastructure without prior approval for 8 services (EC2 instances, NAT Gateways, and Elastic Load Balancers, RDS, CloudFront, Aurora, etc.)

Abuse of AWS resources

The AWS Abuse team can assist you if AWS resources are used to engage in an abusive manner, such as: spam, port scanning, DoS attacks, distributing malware, etc.
If you suspect that AWS resources are used for abusive purposes, contact the AWS Abuse team using the Report Amazon AWS abuse form, or by contacting abuse@amazonaws.com.

`authorized_keys`

When you launch an instance, you are prompted for a key pair.
If you plan to connect to the instance using SSH, you must specify a key pair.
You can choose an existing key pair or create a new one.
When your instance boots for the first time, the content of the public key that you specified at launch is placed on your Linux instance in an entry within ~/.ssh/authorized_keys.

CloudTrail

You can troubleshoot operational and security incidents over the past 90 days in the CloudTrail console by viewing Event history.
You can look up events related to creation, modification, or deletion of resources (such as IAM users or EC2 instances) in your AWS account on a per-region basis.
Using Athena with CloudTrail logs is a powerful way to enhance your analysis of AWS service activity. For example, you can use queries to identify trends and further isolate activity by attributes, such as source IP address or user.
Super important:
- CloudTrail console stores logs for only 3 months (90 days) and hence any option requiring to view logs greater than 3 months is not a viable option.
- In cases where older logs need to be retrieved, then we can fetch it from S3 and analyse them.

PreviousAWS Secrets Manager NextDomain 2

Last updated 4 years ago

Was this helpful?

Exposed AWS Access Keys

Determine what resources those credentials have access to - If the credentials only allow read access to data you intended to make public, you might choose to create new credentials first, transition to these new credentials, and then disable the old credentials.

Invalidate the credentials so they can no longer be used to access your account - Disabling instead of deleting.

Invalidate any temporary security credentials that might have been issued using the credentials.

Restore appropriate access - If you deleted an IAM user, create a new one with a new access key.

Review access to your AWS account - Review all available S3 bucket logs and CloudTrail logs.

GuardDuty

A continuous security monitoring service that analyses and processes the following Data sources: VPC Flow Logs, CloudTrail logs, and DNS logs.

Trusted IP lists consist of IP addresses that you have trusted for secure communication with your AWS infrastructure and applications.

If you are using a 3rd party DNS resolver, for example, OpenDNS or GoogleDNS, or if you set up your own DNS resolvers, then GuardDuty cannot access and process data from this data source.

Super important:

In an Active Directory environment, the DNS Resolver is generally set to that of the AD server. So, if the customer DNS resolver is used, Guard Duty will not be able to see the DNS request.

Abuse of AWS resources

The AWS Abuse team can assist you if AWS resources are used to engage in an abusive manner, such as: spam, port scanning, DoS attacks, distributing malware, etc.

If you suspect that AWS resources are used for abusive purposes, contact the AWS Abuse team using the Report Amazon AWS abuse form, or by contacting abuse@amazonaws.com.

authorized_keys

When you launch an instance, you are prompted for a key pair.

If you plan to connect to the instance using SSH, you must specify a key pair.

You can choose an existing key pair or create a new one.

When your instance boots for the first time, the content of the public key that you specified at launch is placed on your Linux instance in an entry within ~/.ssh/authorized_keys.

CloudTrail

You can troubleshoot operational and security incidents over the past 90 days in the CloudTrail console by viewing Event history.

You can look up events related to creation, modification, or deletion of resources (such as IAM users or EC2 instances) in your AWS account on a per-region basis.

Using Athena with CloudTrail logs is a powerful way to enhance your analysis of AWS service activity. For example, you can use queries to identify trends and further isolate activity by attributes, such as source IP address or user.

Super important:

CloudTrail console stores logs for only 3 months (90 days) and hence any option requiring to view logs greater than 3 months is not a viable option.
In cases where older logs need to be retrieved, then we can fetch it from S3 and analyse them.