AWS March 2016 Webinar Series - Best Practices for Managing Security Operations in AWS

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Henrik Johansson, Security Solutions Architect
03/30/16
Best Practices for Managing Security
Operations in AWS

Since migrating to AWS, we
created a secure solution for our
customers that can handle
thousands of daily transactions,
while reducing our costs by 30%
Stefano Harak
Online Senior Product Manager, Vodafone
”
“ Vodafone Italy, based in Milan,
provides mobile services for more
than 30 million customers
Customers can buy additional for SIM
cards using a credit or debit card.
Key requirement was to build a PCI
DSS-compliant solution
Vodafone Italy Migrates to AWS and Creates a Secure Environment
for Customer Transactions While Reducing Capital Costs by 30%

2007 2008 2009 2010 2011 2012 2013 2014
48 61
82
159
280
514
AWS constantly innovating – driven by your needs
Security, compliance, governance, and
audit related launches and updates

Key AWS Certifications and Assurance Programs

 You benefit from an environment built for the most security
sensitive organizations
 AWS manages 1800+ security controls so you don’t have to
 You get to define the right security controls for your workload
sensitivity
 You always have full ownership and control of your data
What This Means

AWS And You Share Responsibility for Security
AWS Foundation Services
Compute Storage Database Networking
AWS Global Infrastructure
Regions
Availability Zones
Edge Locations
AWS takes care
of the security
OF the Cloud
You
Network
Security
Identity &
Access
Control
Customer applications & content
Inventory &
Config
Data
Encryption
You get to define
your controls IN
the Cloud

AWS takes care
of the security
OF the Cloud
You
AWS And You Share Responsibility for Security
AWS Foundation Services
Compute Storage Database Networking
AWS Global Infrastructure
Regions
Availability Zones
Edge Locations
Client-side Data
Encryption
Server-side Data
Encryption
Network Traffic
Protection
Platform, Applications, Identity & Access Management
Operating System, Network, & Firewall Configuration
Customer applications & content
You get to define
your controls IN
the Cloud

You are in control of privacy
Customers retain full ownership and control
of their content
 Choose the AWS Singapore Region and AWS
will not replicate it elsewhere unless you
choose to do so
 Control format, accuracy and encryption any
way that you choose
 Control who can access content
 Control content lifecycle and disposal

Your data stays where you put it
12 Regions
33 Availability Zones

Encrypt your sensitive information
Native encryption across services for free
 S3, EBS, RDS, RedShift
 End to end SSL/TLS
Scalable Key Management
 AWS Key Management Services provides scalable, low cost key
management
 CloudHSM provides hardware-based, high assurance key
generation, storage and management
Third Party Encryption options
 Trend Micro, SafeNet, Vormetric, Hytrust, Sophos etc.

AWS Identity and Access Management (IAM)
 Enables you to control who can do what in your AWS account
 Splits into users, groups, roles, and permissions
 Control
 Centralized
 Fine-grained - APIs, resources, and AWS Management Console
 Security
 Secure (deny) by default

Policy enforcement
Final decision =“deny”
(explicit deny)
Yes
Final decision =“allow”
Yes
No Is there an
Allow?
4
Decision
starts at Deny
1
Evaluate all
applicable
policies
2
Is there an
explicit
deny?
3
No Final decision =“deny”
(default deny)
5
 AWS retrieves all policies
associated with the user and
resource.
 Only policies that match the action
and conditions are evaluated.
 If a policy statement
has a deny, it trumps
all other policy
statements.
 Access is granted
if there is an
explicit allow and
no deny.
• By default, an
implicit (default)
deny is returned.
A deny always wins over allow.

IAM Anatomy
JSON-formatted documents
Statement (permissions) specifies
Principal
Action
Resource
Condition
{
"Statement":[{
"Effect":"effect",
"Principal":"principal",
"Action":"action",
"Resource":"arn",
"Condition":{
"condition":{
"key":"value" }
}
}
]
}

Principal – Examples
 An entity that is allowed or denied access to a resource
 Indicated by an Amazon Resource Name (ARN)
 With IAM policies, the principal element is implicit (i.e., the user, group, or role attached)

"Principal":"AWS":"*.*"

"Principal":{"AWS":"arn:aws:iam::123456789012:root" }
"Principal":{"AWS":"123456789012"}

"Principal":"AWS":"arn:aws:iam::123456789012:user/username"

"Principal":{"Federated":"www.amazon.com"}
"Principal":{"Federated":"graph.facebook.com"}
"Principal":{"Federated":"accounts.google.com"}

"Principal":{"AWS":"arn:aws:iam::123456789012:role/rolename"}

"Principal":{"Service":"ec2.amazonaws.com"}
Replace
with your
account
number

Action – Examples
 Describes the type of access that should be allowed or denied
 You can find these in the docs or use the policy editor to get a drop-down list
 Statements must include either an Action or NotAction element

"Action":"ec2:StartInstances"

"Action":"iam:ChangePassword"

"Action":"s3:GetObject"

"Action":["sqs:SendMessage","sqs:ReceiveMessage"]
<--Use wildcards (* or ?) as part of the action name. This would cover
Create/Delete/List/Update-->
"Action":"iam:*AccessKey*"

Understanding NotAction
 Lets you specify an exception to a list of actions
 Could result in shorter policies than using Action and denying many actions
 Example: Let’s say you want to allow everything but IAM APIs
{
"Version": "2012-10-17",
"Statement": [ {
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
}
]
}

{
"Version": "2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Resource": "*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "iam:*",
"Resource": "*"
}
]
}
or

{
"Version": "2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Resource": "*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "iam:*",
"Resource": "*"
}
]
}
or
This is not a Deny. A user could still have a
separate policy that grants IAM:*
If you want to prevent the user from ever being
able to call IAM APIs, use an explicit deny.

Resource – Examples
 The object or objects that are being requested
 Statements must include either a Resource or a NotResource element
<-- S3 Bucket -->
"Resource":"arn:aws:s3:::my_corporate_bucket/*"
<-- SQS queue-->
"Resource":"arn:aws:sqs:us-west-2:123456789012:queue1"
<-- Multiple DynamoDB tables -->
"Resource":["arn:aws:dynamodb:us-west-
2:123456789012:table/books_table",
"arn:aws:dynamodb:us-west-
2:123456789012:table/magazines_table"]
<-- All EC2 instances for an account in a region -->
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"

Conditions
Optional criteria that must evaluate to true for
the policy to evaluate as true
Ex: restrict to an IP address range
 Can contain multiple conditions
 Condition keys can contain multiple values
 If a single condition includes multiple
values for one key, the condition is
evaluated using logical OR
 Multiple conditions (or multiple keys in a
single condition): the conditions are
evaluated using logical AND
Condition element
Condition 1:
Key1: Value1A
Condition 2:
Key3: Value3A
AND
AND
Key2: Value2A OR Value2B
OR ORKey1: Value1A Value1B Value 1C

Condition example
"Condition" : {
"DateGreaterThan" : {"aws:CurrentTime" : "2015-10-08T12:00:00Z"},
"DateLessThan": {"aws:CurrentTime" : "2015-10-08T15:00:00Z"},
"IpAddress" : {"aws:SourceIp" : ["192.0.2.0/24", "203.0.113.0/24"]}
}
Allows a user to access a resource under the following conditions:
 The time is after 12:00 P.M. on 10/8/2015 AND
 The time is before 3:00 P.M. on 10/8/2015 AND
 The request comes from an IP address in the 192.0.2.0 /24 OR 203.0.113.0 /24
range
All of these conditions must be met in order for the statement to evaluate to TRUE.
AND
OR
What if you wanted to restrict access to a time frame and IP address range?

Policy variables
 Predefined variables based on service request context
• Existing keys (aws:SourceIP, aws:CurrentTime, etc.)
• Principal-specific keys (aws:username, aws:userid, aws:principaltype)
• Provider-specific keys (graph.facebook.com:id, www.amazon.com:user_id)
• SAML keys (saml:aud, saml:iss)
• See documentation for service-specific variables
 Benefits
• Simplifies policy management
• Reduces the need for hard-coded, user-specific policies
 Use cases we’ll look at
• Easily set up user access to “home folder” in S3
• Limit access to specific EC2 resources

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::myBucket"],
"Condition":
{"StringLike":
{"s3:prefix":["home/${aws:username}/*"]}
}
},
{
"Effect":"Allow",
"Action":["s3:*"],
"Resource": ["arn:aws:s3:::myBucket/home/${aws:username}",
"arn:aws:s3:::myBucket/home/${aws:username}/*"]
}
]
}
The anatomy of a policy with variables
Version is required
Variable in conditions
Variable in resource ARNs
Grants a user access to a home directory in S3 that can be accessed programmatically

Basic user and permission management
1. Create individual users. Benefits
 Unique credentials
 Individual credential rotation
 Individual permissions
 Simplifies forensics

1. Create individual users.
2. Grant least privilege.
Benefits
 Less chance of people making
mistakes
 Easier to relax than tighten up
 More granular control

3. Manage permissions with groups.
Benefits
 Easier to assign the same
permissions to multiple users
 Simpler to reassign permissions
based on change in
responsibilities
 Only one change to update
permissions for multiple users

4. Restrict privileged access further with
conditions.
Benefits
 Additional granularity when
defining permissions
 Can be enabled for any AWS
service API
 Minimizes chances of
accidentally performing
privileged actions

4. Restrict privileged access further with
conditions.
5. Enable AWS CloudTrail to get logs of API
calls.
Benefits
 Visibility into your user activity
by recording AWS API calls to
an Amazon S3 bucket

Credential management
6. Configure a strong password policy. Benefits
 Ensures your users and your
data are protected

6. Configure a strong password policy.
7. Rotate security credentials regularly.
Benefits
 Normal best practice

6. Configure a strong password policy.
7. Rotate security credentials regularly.
8. Enable MFA for privileged users.
Benefits
 Supplements user name and
password to require a one-time
code during authentication

Delegation
9. Use IAM roles to share access. Benefits
 No need to share security
credentials
 No need to store long-term
credentials
 Use cases
 Cross-account access
 Intra-account delegation
 Federation

Delegation
9. Use IAM roles to share access.
10. Use IAM roles for Amazon EC2 instances.
Benefits
 Easy to manage access keys
on EC2 instances
 Automatic key rotation
 Assign least privilege to the
application
 AWS SDKs fully integrated
 AWS CLI fully integrated

Delegation
9. Use IAM roles to share access.
10. Use IAM roles for Amazon EC2 instances.
11. Reduce or remove use of root.
Benefits
 Reduce potential for misuse of
credentials

Top 11 IAM best practices
1. Users – Create individual users.
2. Permissions – Grant least privilege.
3. Groups – Manage permissions with groups.
4. Conditions – Restrict privileged access further with conditions.
5. Auditing – Enable AWS CloudTrail to get logs of API calls.
6. Password – Configure a strong password policy.
7. Rotate – Rotate security credentials regularly.
8. MFA – Enable MFA for privileged users.
9. Sharing – Use IAM roles to share access.
10.Roles – Use IAM roles for Amazon EC2 instances.
11.Root – Reduce or remove use of root.

IAM users vs. federated users
Depends on where you want to manage your users
 On-premises → Federated users (IAM roles)
 In your AWS account → IAM users
Other important use cases
 Delegating access to your account → Federated users (IAM roles)
 Mobile application access → Should always be federated access
IMPORTANT: Never share security credentials.

AWS access keys vs. passwords
Depends on how your users will access AWS
 Console → Password
 API, CLI, SDK → Access keys
Make sure to rotate credentials regularly
 Use Credential Report to audit credential rotation.
 Configure password policy.
 Configure policy to allow access key rotation.

Enabling credential rotation for IAM users
(Enable access key rotation sample policy)
Access keys
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:DeleteAccessKey",
"iam:ListAccessKeys",
"iam:UpdateAccessKey"],
"Resource":
"arn:aws:iam::123456789012:
user/${aws:username}"
}]}
1. While the first set of credentials is still
active, create a second set of credentials,
which will also be active by default.
2. Update all applications to use the new
credentials.
3. Change the state of the first set of
credentials to Inactive.
4. Using only the new credentials, confirm
that your applications are working well.
5. Delete the first set of credentials.
Steps to rotate access keys

Inline policies vs. managed policies
Use inline policies when you need to:
 Enforce a strict one-to-one relationship between policy and principal.
 Avoid the wrong policy being attached to a principal.
 Ensure the policy is deleted when deleting the principal.
Use managed policies when you need:
 Reusability.
 Central change management.
 Versioning and rollback.
 Delegation of permissions management.
 Automatic updates for AWS managed policies.
 Larger policy size.

Groups vs. managed policies
Provide similar benefits
 Can be used to assign the same permission to many users.
 Central location to manage permissions.
 Policy updates affect multiple users.
Use groups when you need to
 Logically group and manage users .
Use managed policies when you need to
 Assign the same policy to users, groups, and roles.

Combine the power of groups AND managed
policies
 Use groups to organize your users into logical clusters.
 Attach managed policies to those groups with the permissions those
groups need.
 Pro tip: Create managed policies based on logically separated
permissions such as AWS service or project, and attach managed policies
mix-and-match style to your groups.

One AWS account vs. multiple AWS accounts?
Use a single AWS account when you:
 Want simpler control of who does what in your AWS environment.
 Have no need to isolate projects/products/teams.
 Have no need for breaking up the cost.
Use multiple AWS accounts when you:
 Need full isolation between projects/teams/environments.
 Want to isolate recovery data and/or auditing data (e.g., writing your
CloudTrail logs to a different account).
 Need a single bill, but want to break out the cost and usage.

Segmented AWS Account Structure
Procurement and
Finance
SOC/Auditors
Billing account
Production
accounts
User management
account
Security / Audit
account
Application Owners
Security/auditUtilityFinancial
Consolidated Billing,
Billing Alerts
Read-only access
for all accounts
Dev / Test
accounts
Operational
Logging
account
Backup / DR
account
Key management
account
Shared services
account
Domain Specific Admins
Event and State
Logging
Read-only access
to logging data

Infrastructure as Code is a practice by where
traditional infrastructure management techniques
are supplemented and often replaced by using code
based tools and software development techniques.

Infrastructure as Code workflow
code
version
control
code
review
integrate deploy
Text Editor
Git/SVN/
Perforce
Review
Tools
Syntax
Validation
Tools
AWS
Services

Infrastructure as Code workflow
code
version
control
code
review
integrate deploy
“It’s all software”
Text Editor
Git/SVN/
Perforce
Review
Tools
Syntax
Validation
Tools
AWS
Services

“It’s all software”
AWS Resources
Operating System and Host Configuration
Application Configuration

AWS Resources
Operating System and
Host Configuration
Application
Configuration
Infrastructure Resource Management
Host Configuration Management
Application Deployment

AWS Resources
Host Configuration
Application
Configuration
AWS CloudFormation
AWS OpsWorks
AWS CodeDeploy

AWS Resources
Host Configuration
Application
Configuration
Amazon Virtual Private
Cloud (VPC)
Amazon Elastic Compute
Cloud (EC2)
AWS Identity and Access
Management (IAM)
Amazon Relational
Database Service (RDS)
Amazon Simple Storage
Service (S3)
AWS CodePipeline
…
Windows Registry
Linux Networking
OpenSSH
LDAP
AD Domain Registration
Centralized logging
System Metrics
Deployment agents
Host monitoring
…
Application dependencies
Application configuration
Service registration
Management scripts
Database credentials
…
AWS CloudFormation
AWS OpsWorks
AWS CodeDeploy

Template CloudFormation Stack
JSON formatted file
Parameter definition
Resource creation
Configuration actions
Configured AWS resources
Comprehensive service support
Service event aware
Customizable
Framework
Stack creation
Stack updates
Error detection and rollback
CloudFormation – Components & Technology

Template File
Defining Stack
Git
Perforce
SVN
…
Dev
Test
Prod
The entire infrastructure can be
represented in an AWS
CloudFormation template.
Use the version
control system
of your choice to
store and track
changes to this
template
Build out multiple
environments, such
as for Development,
Test, Production and
even DR using the
same template
Many Stacks & Environments from One Template

What security benefits does this give
Ability to perform “Code Audit” on your infrastructure
 Look for unauthorized network configurations
 Verify Security Groups
 Verify OS
 Use with AWS CodeCommit Trigger or Git Hooks
Split ownership (single file or merge)
 App team owns main section
 Network team owns VPC/Subnets
 Security team owns Security Groups
Automate upon checkin!

Where else can this be applied?
CloudFormation
Template
Task Definition Application
Specification File
(AppSpec file)
…and more.
AWS CloudFormation AWS CodeDeployAmazon EC2 Container Service

Audit and log your AWS
service usage

Why Cloud Logging/Monitoring is Different
 Distributed servers coming and going (e.g. AutoScaling, micro
services)
 More visibility (e.g. CloudTrail)
 In the cloud, we have more log types than in the data center. More
different kinds of data. Many distinct log sources not monitored by
same systems on premises
 Networking (VPC Flow Logs)
 System/application
 Configuration (very difficult on premises)
 Large amount of information(e.g. VPC Flow logs)

Different log categories
AWS Infrastructure logs
 AWS CloudTrail
 VPC Flow Logs
AWS service logs
 Amazon S3
 AWS Elastic Load
Balancing
 Amazon CloudFront
 AWS Lambda
 AWS Elastic
Beanstalk
 …
Host based logs
 Messages
 Security
 NGINX/Apache/IIS
 Windows Event Logs
 Windows Performance
Counters
 …

Different log categories
AWS Infrastructure logs
 AWS CloudTrail
 VPC Flow Logs
AWS service logs
 Amazon S3
 AWS Elastic Load
Balancing
 Amazon CloudFront
 AWS Lambda
 AWS Elastic
Beanstalk
 …
Host based logs
 Messages
 Security
 NGINX/Apache/IIS
 Windows Event Logs
 Windows Performance
Counters
 …
Security related events

Amazon CloudWatch Logs
Monitor Logs from Amazon EC2 Instances in Real-time

Ubiquitous logging and monitoring
CloudWatch Logs lets you grab everything and monitor activity
 Storage is cheap - collect and keep your logs
 Agent based (Linux and Windows)
 Export data
• To S3
• Stream to Amazon ElasticSearch Service or AWS Lambda
 Integration with Metrics and Alarms means you can
continually scan for events you know might be suspicious
 Combine/use 3rd party
IF (detect web attack> 10 in a 1 minute period)
ALARM == INCIDENT IN PROGRESS!

AWS CloudTrail
Records AWS API calls for your account

What can you answer using a CloudTrail event?
 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?
Supported services:
http://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-services.html

What does an event look like?
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser", // Who?
"principalId": "AIDAJDPLRKLG7UEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/Alice", //Who?
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "Alice",
"sessionContext": {
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2014-03-18T14:29:23Z"
}
}
},
"eventTime": "2014-03-18T14:30:07Z", //When?
"eventSource": "cloudtrail.amazonaws.com",
"eventName": "StartLogging", //What?
"awsRegion": "us-west-2",//Where to?
"sourceIPAddress": "72.21.198.64", // Where from?
"userAgent": "AWSConsole, aws-sdk-java/1.4.5 Linux/x.xx.fleetxen Java_HotSpot(TM)_64-Bit_Server_VM/xx",
"requestParameters": {
"name": "Default“ // Which resource?
},
// more event details
}

CloudTrail Best Practices
1. Enable in all regions Benefits
 Also tracks unused regions
 Can be done in single
configuration step

1. Enable in all regions
2. Enable log file validation
Benefits
 Ensure log file integrity
 Validated log files are
invaluable in security and
forensic investigations
 Built using industry standard
algorithms: SHA-256 for
hashing and SHA-256 with
RSA for digital signing
 CloudTrail will start delivering
digest files on an hourly basis
 Digest files contain hash values
of log files delivered and are
signed by CloudTrail

3. Encrypted logs
Benefits
 By default, CloudTrail encrypts
log files using S3 server side
encryption (SSE-S3)
 You can choose to encrypt
using AWS Key Management
Service (SSE-KMS)
 S3 will decrypt on your behalf if
your credentials have decrypt
permissions

3. Encrypted logs
4. Integrate with Amazon CloudWatch
Logs
Benefits
 Simple search
 Configure alerting on events

3. Encrypted logs
4. Integrate with Amazon CloudWatch
Logs
5. Centralize logs from all accounts
Benefits
 Configure all accounts to send
logs to a central security
account
 Reduce risk for log tampering
 Can be combined with S3 CRR
 Include dev/stage accounts!

VPC Flow Logs
Log network traffic for VPC, subnet or single interfaces

VPC Flow Logs
 Stores log in CloudWatch Logs
 Can be enabled on
• VPC, a subnet, or a network interface
• VPC & Subnet enables logging for all interfaces in the VPC/subnet
• Each network interface has a unique log stream
 Flow logs do not capture real-time log streams for your network interfaces
 Can capture on interfaces for other AWS services; for example
• Elastic Load Balancing, Amazon RDS, Amazon ElastiCache, Amazon Redshift, and
Amazon WorkSpaces
 Filter desired result based on need
• All, Reject, Accept
• Troubleshooting or security related with alerting needs?
• Think before enabling All on VPC, will you use it?

Log management and analytics
 ELK (Elastic Search + LogStash + Kibana)
 Amazon Elastic Search + Kibana + AmazonCloudWatch Logs
 3rd Party

AWS Technology Partner solutions integrated with
CloudTrail
New

AWS Consulting Partner solutions integrated
with CloudTrail

Automating your
compliance checks

Multiple levels of automation
Self managed
 AWS CloudTrail -> Amazon CloudWatch Logs -> Amazon CloudWatch Alerts
 AWS CloudTrail -> Amazon SNS -> AWS Lambda
Compliance validation
 AWS Config Rules
Host based Compliance validation
 AWS Inspector
Active Change Remediation
 Amazon CloudWatch Events

AWS Config Rules
Automated compliance validation

Tools - AWS Config Rules
Time based
 When configuration snapshot is delivered
 Choose between 1, 3, 6, 12 or 24h
Configuration Change based
 EC2, IAM, CloudTrail or Tags
AWS Managed or custom checks using Lambda
 Control compliance status using Lambda
 Encrypted volumes, CloudTrail, EIP attached, SSH access, EC2
in VPC, restricted common ports and Require Tags

How do I know what happened
{
”account”: “123456789012”,
”region”: “us-east-1”,
”detail”: {
”eventVersion”: “1.02”,
”eventID”: “c78ce8de-46ee-4fea-bcf4-0e889d419f2f”,
”eventTime”: “2016-01-18T03:32:18Z”,
”requestParameters”: {
”userName”: “trigger”
},
”eventType”: “AwsApiCall”,
”responseElements”: {
”user”: {
”userName”: “trigger”,
”path”: “/”,
”createDate”: “Jan 18, 2016 3:32:18 AM”,
”userId”: “AIDACKCEVSQ6C2EXAMPLE”,
”arn”: “arn:aws:iam::123456789012:user/trigger”
}
},
”awsRegion”: “us-east-1”,
”eventName”: “CreateUser”,
”userIdentity”: {
”userName”: “IAM-API-RW”,
”principalId”: “AIDACKCEVSQ6C2EXAMPLE”,
”accessKeyId”: “AKIAIOSFODNN7EXAMPLE”,
”type”: “IAMUser”,
”arn”: “arn:aws:iam::123456789012:user/IAM-API-RW”,
”accountId”: “123456789012”
},
”eventSource”: “iam.amazonaws.com”,
”requestID”: “13bb5711-bd94-11e5-9abd-af4e7ff9090f”,
”userAgent”: “aws-cli/1.9.20 Python/2.7.10 Darwin/15.2.0
botocore/1.3.20”,
”sourceIPAddress”: “192.0.2.10”
},
”detail-type”: “AWS API Call via CloudTrail”,
”source”: “aws.iam”,
”version”: “0”,
”time”: “2016-01-18T03:32:18Z”,
”id”: “d818DD19-7b16-4e1d-a491-794a26b51657”,

The key to Custom Rules
response = client.put_evaluations(
Evaluations=[
{
'ComplianceResourceType': 'string',
'ComplianceResourceId': 'string',
'ComplianceType': 'COMPLIANT'|'NON_COMPLIANT'|'NOT_APPLICABLE'|'INSUFFICIENT_DATA',
'Annotation': 'string',
'OrderingTimestamp': datetime(2015, 1, 1) },
],
ResultToken='string’
)

The key to Custom Rules
response = client.put_evaluations(
Evaluations=[
{
'ComplianceResourceType': 'string',
'ComplianceResourceId': 'string',
'ComplianceType': 'COMPLIANT'|'NON_COMPLIANT'|'NOT_APPLICABLE'|'INSUFFICIENT_DATA',
'Annotation': 'string',
'OrderingTimestamp': datetime(2015, 1, 1) },
],
ResultToken='string’
)
Use Annotation for pulling rule status using CLI

AWS Config Rules Repository
AWS Community repository of custom Config rules
https://github.com/awslabs/aws-config-rules
Contains Node and Python samples for Custom Rules for AWS Config

AWS CloudWatch Events
The central nervous system for your AWS environment

Tools - Amazon CloudWatch Events
Trigger on event
 EC2 instance state change notification
 AWS API call (very specific)
 AWS console sign-in
 Auto Scaling (no Lifecycle Hooks)
Or Schedule (Used by Lambda)
 Cron is in the cloud!
 No more Unreliable Town Clock
 Min 5min
Single event can have multiple targets

Different sources have different event
”userIdentity”: {
”userName”: “IAM-API-RW”,
”principalId”: “AIDACKCEVSQ6C2EXAMPLE”,
”accessKeyId”: “AKIAIOSFODNN7EXAMPLE”,
”type”: “IAMUser”,
”arn”: “arn:aws:iam::123456789012:user
”accountId”: “123456789012”
"userIdentity": {
"principalId": "AKIAI44QH8DHBEXAMPLE:admin",
"accessKeyId": ”GFSHKUOLZG53JE5DHKRC",
"sessionContext": {
"sessionIssuer": {
"userName": ”AssumeAdministrator",
"type": "Role",
"arn": "arn:aws:iam::123456789012:role/Administrator",
"principalId": "AKIAI44QH8DHBEXAMPLE",
"accountId": "123456789012"
},
"attributes": {
"creationDate": "2016-01-18T16:50:04Z",
"mfaAuthenticated": "false"
}
},
"type": "AssumedRole",
"arn": "arn:aws:sts::123456789012:assumed-
role/Administrator/admin",
"accountId": "123456789012"

How can I get the different events?
import json
def lambda_handler(event, context):
eventdump = json.dumps(event, indent=2)
print("Received event: " + json.dumps(event, indent=2))
return eventdump

Risks with automatic remediation
 You can now automatically mess up your approved changes
 No proper alerting and follow-up on automatic events
 Over/under complicated scripts
 No info on desired state
 Race the hacker…automation wars!

AWS Inspector (Preview)
Automated security assessment service

What is Inspector?
Enables you to analyze the behavior of your AWS resources and helps
identify potential security issues
 Application security assessment
• Agent based
• 15min – 24h
 Selectable built-in rules
• CVE (common vulnerabilities and exposures)
• PCI DSS 3.0 readiness
• …
 Security findings – guidance and management
 Automatable via APIs

Don’t forget built-in reporting

Trusted Advisor checks your account

Rounding up
 Enforce separation of duties and least privilege accounts
 MFA on users; enforce using IAM policies
 Know what is security vs troubleshooting logs
 Storage is cheap, not knowing can be very expensive – Log if possible
 Alerting is good, automating your security response is better
 Use managed services and built-in reporting to offload and automate
 See the Big Picture, what info do you want and what tool can give it to you

AWS March 2016 Webinar Series - Best Practices for Managing Security Operations in AWS

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a AWS March 2016 Webinar Series - Best Practices for Managing Security Operations in AWS

Similar a AWS March 2016 Webinar Series - Best Practices for Managing Security Operations in AWS (20)

Más de Amazon Web Services

Más de Amazon Web Services (20)

Último

Último (20)

AWS March 2016 Webinar Series - Best Practices for Managing Security Operations in AWS