1_Introduction + EAM Vocabulary + how to navigate in EAM.pdf
Cloudifying your Security Operations on AWS
1. Cloudifying your Security Operations on AWS
Presented by Patrick Hannah
VP of Engineering, CloudHesive
2. Introduction
• Who am I?
• What’s my background?
• What do I hope to get out of the
presentation?
• How am I using cloud services?
• Why did I pick the cloud services that I am
using?
3. What are we going to talk about?
• Overview
• Shared Responsibility Model
• Getting Started
• Securely Operating in AWS
• Continuous Monitoring
• Conclusion
4. Overview of AWS
• Regional footprints, some with special use cases (GovCloud,
China)
• Access to services via a Web Based Console (customizable via
AWS Service Catalog) or Programmatically (CLI/API/SDK) using
credentials with granular role assignment (Identity & Access
Management)
• Access to E-Mail, Chat and Phone support via AWS Support and
proactive recommendations via Trusted Advisor
• Access to third party products and services via AWS Marketplace
• Access to itemized billing via AWS Billing and Cost Management
• Access to infrastructure monitoring via Amazon CloudWatch
• Access to an audit trail via AWS CloudTrail and configuration
change history via AWS Config
5. Overview of AWS Infrastructure Services
• Networking
– Amazon VPC – Software Defined Network
– AWS Direct Connect – Dedicated WAN Connectivity
– Elastic Load Balancing – Load Balancing
– Amazon Route 53 – DNS
– Amazon CloudFront – Content Delivery Network
• Compute
– Amazon EC2 – Virtualized Servers
• Storage & Content Delivery
– Amazon S3 – Object Storage
– Amazon EBS – Block Storage
– Amazon EFS – NFS Storage
– Amazon Glacier – Long Term Object Storage
– AWS Import/Export/Snowball – Bulk Import/Export of data to disk
• Database
– Amazon RDS – Managed RDBMS
– Amazon DynamoDB – Managed NoSQL
– Amazon ElastiCache – Managed In Memory Cache
– Amazon Redshift – Managed Data Warehouse
– Amazon Elasticsearch Service – Managed ElasticSearch
– Amazon EMR – Managed Big Data platform
– Amazon CloudSearch – Managed Indexer
9. AWS Account
• Setup AWS Accounts
• Balance the number of AWS Accounts with actual need
• Setup General Distribution Lists and Register your AWS Accounts with
them
• Setup more specific distribution lists for Billing, Security and Support on
each account
• These distribution lists shouldn’t be on a domain hosted on AWS
• Keep them generic enough to prevent guessing
• Limit usefulness of Root Account
10. IAM
• Customize the IAM users sign-in link but don’t use something
predictable
• Create Users in Main Account/Leverage roles to manage other
Accounts
• Follow Standard Best Practices
• Manage user policies at group level (where it makes sense)
• Use managed policies as a starting point but evaluate them for fit
• Utilize conditions for more granular control
• Validate Roles and Policies
11. Asset Management
• Enable Billing Alerts
• Enable Billing Reports
• Implement a Tagging Policy
– name: Matches Hostname
– env: Matches Environment
– role: Matches Role
– owner: The name of the resource (typically an instance) that
utilizes other resources (such as EBS Volumes)
– managed: Who manages the asset
• Enable Billing Tags
12. VPC and Subnets
• How many VPCs?
– All Environments or one per Environment
– Shared Services
– Management Services
• How many Subnets?
– Public Subnets for Internet Routable Services
– Private Subnets for Non-Internet Routable Services
– Subnets for Abstracted/Managed Services (ELB, etc.)
– Subnets for consistent IP Addressing
– Ensure you take into account how an instance with multiple ENIs
may behave
13. ACLs and Security Groups
• Follow best practices
– Be Smart
– Controlling outbound traffic is just as important as controlling inbound traffic
– Don’t forget about RDS DB Security Groups
– Watch out for /0
• Use Security Groups and ACLs where they make sense
– ACLs and Security Groups (along with IAM) can help incorporate policies
requiring separation of duties
– Security Groups are stateful, have a default deny and no processing order
– ACLs are stateless, have multiple denies (or no denies at all) and have a
processing order
• Devise a Security Group Scheme
– Environment?
– Role?
– ENIs?
14. VPC Logs, CloudTrail, Config, CloudWatch Logs
• VPC Logs
– Enable VPC logs on critical ENIs or Subnets
• Public Facing
• NAT Instance ENI
– Enable on the entire VPC if needed
• CloudTrail
– Don’t forget to enable in each account and each region
– Use an S3 bucket in the Main account
– Use SSE-KMS to encrypt logs (logs are generally redacted)
• Config
– Don’t forget to enable in each account and each region
– Use an S3 bucket in the Main account
• CloudWatch Logs
– Batch export to S3 bucket in the Main account
– Forward CloudWatch Logs to Kinesis Stream in Main Account
15. Secure storage of Logs on S3
• Ensure Permissions to CloudTrail and Config log buckets are
sufficiently restrictive
• Enable access logging (write it to another bucket)
• Enable notifications unexpected activities
• Enable MFA Delete
• Setup a lifecycle rule to transition to Glacier
• Setup a Vault Lock rule in Glacier to protect access to the data
16. Using Managed/Abstracted Services
• AWS has DoS/DDoS mitigation capabilities but it’s a shared
responsibility
• Follow VPC Recommendations
• Utilize additional AWS services
– Route53 (front end DNS request)
– CloudFront (front end web/application server requests)
– WAF (application layer firewall
– ELB (acts like a reverse proxy/distributes load)
– ASG (scales up as load increases)
• Some of these services allow logging to S3
– Use an S3 bucket in the Main Account
17. Provisioning EC2 Instances
• Launch instance with IAM roles
• Encrypt data at rest using KMS or a third party solution (like ours)
• Encrypt data in flight
• Collect instance logs using CloudWatch logs
• Ensure Active Directory Domain Controllers are using an external NTP
server
• Assume the instance will fail at some point
• Utilize a directory service for authentication – use key pairs once and
throw them away (additional thoughts on administrative access are on
the next slide)
18. Administration of EC2 Instances
• Utilize an SSH Bastion, RDP Proxy or AWS Workspaces for
Administration
– Authenticate an existing directory service (if you have one) or
utilize AWS’
– Don’t forget the security of these hosts – same rules apply
• Use a secure means of sharing data
• Automate instead of administrate
19. AWS Continuous Monitoring Services
• Trusted Advisor – Top Security Recommendations
• Config Rules – Pre-built and custom best practice rules
• Inspector – Application level vulnerability scanning
• AWS
20. Continuous Monitoring Ideas
• Identify users who have not logged in in the last quarter
• Identify users who have disabled accounts
• Identify users who have not rotated passwords in the last quarter
• Identify users who have passwords out of compliance
• Identify credentials that cannot be accounted for
• Identify weak security group entries and ones that cannot be accounted
for
• Identify public AMI, Snapshot and S3 items and ones that cannot be
accounted for
• Identify shared AMI, Snapshot and S3 items and ones that cannot be
accounted for
• Identify expiring certificates on ELB
• Did someone use the root credentials?
• Did someone unexpected access (successfully or otherwise) S3 Logs
or CloudWatch logs?
21. Conclusion and Some Advice
• First place to start is collecting the data
• Once you collect the data you can build a baseline
• Once you build a baseline you can identify anomalies
• There are many tools on the market can help
26. Question 2
• What’s the difference between a Public and Private
Subnet (AWS Definition)?
27. Question 3
• What AWS services you can use for continuous
monitoring?
28. Question 4
• What AWS services can you use to help mitigate a
DoS/DDoS attack?
29. THANK YOU!
Want a copy of this presentation?
sales@cloudhesive.com
http://www.cloudhesive.com
Notas del editor
Who are you?
Patrick Hannah, CloudHesive (where I’m a co-founder and the VP of Engineering)
What’s your background?
Architecture, Security and Operations on AWS for 5 years, prior to that Contact Center Architecture and Operations for over 8 years (SaaS but we didn’t call it that). I’ve drawn on experience in both spaces in this presentation.
What do you hope to get out of the presentation?
I want to help folks get as the same out of AWS as I have.
I’d also like to see how others are using AWS – as with just about any thing in technology there are multiple ways to do something right (or wrong).
How are you using cloud services?
At CloudHesive, we provide consulting services to customers who wish to, or who are, leveraging AWS and we also use a number of AWS services to host our managed services customers (and the back-office systems supporting them).
Why did you pick the cloud services that you are using?
AWS is at the forefront of Cloud; their service catalog can support most traditional on-premise software use cases (infrastructure) but they also offer more abstracted services for software built on the cloud (such as SQS, which is one of my favorite) that negate the need to manage server infrastructure – on premise or on cloud.
What about you?
A lot of this has come from AWS in the form of blog posts, presentations, documentation, trusted advisor, etc. as well as the community
One of the challenges I expect most folks encounter is piecing it all together
I’ll try to do this in this presentation, but probably missed something
This is not a complete list and I’ve categorized certain services to suit my needs.
A key point to note is when I refer to infrastructure I refer to building blocks and when I refer to abstracted I refer to a managed service to solve a specific requirement (like SES, SQS, etc.)
Don’t forget to talk about legal cases
Setup AWS Accounts
Main - Parent/Master Payer
Not Change Controlled - Used for prototyping and other activities in which change control is not required
Change Controlled, Change Controlled 2, etc. - Used for environments in which change control is required
Balance the number of AWS Accounts with actual need
Most use cases for isolation can be done within an account using IAM and VPC
Complexity increases as more accounts are added
Standardization
Moving resources
Setup General Distribution Lists and Register your AWS Accounts with them
Setup more specific distribution lists for Billing, Security and Support on each account
These distribution lists shouldn’t be on a domain hosted on AWS
Keep them generic enough to prevent guessing
Limit usefulness of Root Account
Don’t use a predicable username
Disable Root Access Key/Secret Key
Set a Strong Password
Enable MFA
Some AWS activities still require access to the root credentials so pick a physical device that can be physically secured but is accessible to more than just one person (imagine how you would secure physical media)
Customize the IAM users sign-in link but don’t use something predictable
Create Users in Main Account
Don’t use a predicable username
Set a Strong Password
Enable MFA
Leverage roles to manage other Accounts
Supported in AWS Console
Supported in AWS CLI
Standard Best Practices
Disable Access Key/Secret key when not using
Disable user when not using
Set a password policy congruent with your corporate password policies
Follow the principal of least privilege
Separate user/role for function
Is an application using the AWS API? Use roles
Manage user policies at group level (where it makes sense)
Use managed policies as a starting point but evaluate them for fit
Utilize conditions for more granular control
Validate Roles and Policies
Test for desired result
Test for undesired result
Policy Simulator
Access Advisor
Enable Billing Alerts
Set alarms for cost thresholds congruent with your budget
Enable Billing Reports
Save to S3 (you’ll need them later)
Implement a Tagging Policy
name: Matches Hostname
env: Matches Environment
role: Matches Role
owner: The name of the resource (typically an instance) that utilizes other resources (such as EBS Volumes)
managed: Who manages the asset
Enable Billing Tags
How many VPCs?
All Environments or one per Environment
Shared Services
Management Services
Peer VPCs together and utilize the stateful-ness of Security Groups to secure traffic between VPCs
Your management VPC might need to talk to the rest of your VPCs but not the other way around)
Note that Transitive routing isn’t possible one VPC, even if peered to another VPC cannot utilize that VPC’s VGW
There was a limitation with creating multiple CGWs with the same Public IP Address but this is no longer the case
How many Subnets?
Public Subnets for Internet Routable Services
Route through IGW
Private Subnets for Non-Internet Routable Services
Route through NAT Instance (maybe)
NAT Instance is potential bottleneck
Use Prefix lists to connect to S3
Use an IGW if it makes more sense
NAT Instance can be a SpoF but can be (kind of) mitigated
1 Per Subnet/Route Table
Divide /0 in half
CloudWatch Actions
Auto Scaling Group
Heartbeat Script
Subnets for Abstracted/Managed Services (ELB, etc.)
Subnets for consistent IP Addressing
Ensure you take into account how an instance with multiple ENIs may behave
Route Tables
More specific networks take precident
Route metrics don’t exist
Follow best practices
Internet sourced traffic should use encrypted services
Internet sourced traffic should be limited to specific addresses
Don’t open access to the entire Internet for services prone to security issues (SSH, RDP, SMB, etc.)
/0 Implies the entire Internet
Controlling outbound traffic is just as important as controlling inbound traffic
Watch out for RDS Instances with Public IPs
Use Security Groups and ACLs where they make sense
ACLs and Security Groups (along with IAM) can help incorporate policies requiring separation of duties
Security Groups are stateful, have a default deny and no processing order
ACLs are stateless, have multiple denies (or no denies at all) and have a processing order
Useful for blocking specific IP Addresses/Networks
Security Groups can allow traffic from other Security Groups
Eases administration
Devise a Security Group Scheme
Environment?
Role?
ENI?
Use separate security groups for managed/abstracted services
Ensure you take into account how an instance with multiple ENIs may behave
VPC Logs
Same reason you log internally: Troubleshooting, Monitoring Behavior, Security RCA
Enable VPC logs on critical ENIs or Subnets
Public Facing
NAT Instance ENI
Enable on the entire VPC if needed
CloudTrail
What happened with the API?
Don’t forget to enable in each account and each region
Use an S3 bucket in the Main account
Use SSE-KMS to encrypt logs (logs are generally redacted)
Config
What’s changed?
Don’t forget to enable in each account and each region
Use an S3 bucket in the Main account
CloudWatch Logs
Mostly useful if you have somewhere to dump, analyze and alert on
Batch export to S3 bucket in the Main account
Forward CloudWatch Logs to Kinesis Stream in Main Account
Ensure Permissions to CloudTrail and Config log buckets are sufficiently restrictive
No sense in showing the world what you’re doing
Enable access logging (write it to another bucket)
Quickly identify potential breach
Enable notifications unexpected activities
Quickly identify potential breach
Enable MFA Delete
MFA required to delete
Setup a lifecycle rule to transition to Glacier
Long term storage with an added benefit…
Setup a Vault Lock rule in Glacier to protect access to the data
Immutable policies for immutable data make it more difficult for someone to cover their tracks
While AWS has DoS/DDoS mitigation built into its infrastructure it is designed to protect their customers as a whole rather than a specific customer
The VPC recommendations made on prior slides will help mitigate some types of DoS/DDoS attacks, there are certain AWS services that can further help:
Route53 (front end DNS request)
CloudFront (front end web/application server requests)
WAF (application layer firewall
ELB (acts like a reverse proxy/distributes load)
ASG (scales up as load increases)
Some of these services allow logging to S3
Use an S3 bucket in the Main Account
Launch instance with IAM roles
Numerous benefits but of most interest is EC2 Commands
Encrypt data at rest using KMS or a third party solution (like ours)
Encrypt data in flight
Terminate SSL/TLS at ELB
Terminate SSL/TLS at instance
Create an IPSEC mesh
Create an OpenVPN overlay
Collect instance logs using CloudWatch logs
Ensure Active Directory Domain Controllers are using an external NTP server
Assume the instance will fail at some point
Does a service it is hosting need to be highly available?
Do you have a recovery plan?
Utilize a directory service for authentication – use key pairs once and throw them away (additional thoughts on administrative access are on the next slide)
Utilize an SSH Bastion, RDP Proxy or AWS Workspaces for Administration
Authenticate an existing directory service (if you have one) or utilize AWS’
Don’t forget the security of these hosts – same rules apply
Access (Network, AAA)
Change Logging
Encryption (at rest/in flight)
Host based security
Use a secure means of sharing data
Automate instead of administrate
Services we haven’t talked about
Trusted Advisor – Top Security Recommendations
Config Rules – Pre-built and custom best practice rules
Inspector – Application level vulnerability scanning
Has AWS reached out to you on your Security Distribution List?
First place to start is collecting the data
Once you collect the data you can build a baseline
Don’t forget CloudWatch – Anomolies here could be a good indicator
Once you build a baseline you can identify anomalies
For Example
What’s changed?
Account
Environment
Component
Who’s changed it?
Developer?
When was it changed?
Outside of Business Hours?
Was it expected?
No
Is it counter to what we prescribed in here?
Yes – 0.0.0.0/0 TCP/3389 open
Allows you to both prevent issues and identify issues faster
There are many tools on the market can help
Splunk, Sumo, ELK
Each service has it’s own site and set of documentation
The SlideShare presentations can be an invaluable resource when it comes to diving into the details
The GitHub repositories have excellent examples of applications you can build on AWS
CloudHesive sponsors 5 Meetups in Florida; 4 in the South Florida-Tri-County Area and one in North Florida
We are always looking for ideas on topics, as well as attendees and speakers (especially Jacksonville)