Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Cloudifying your Security Operations on AWS
Ähnlich wie Cloudifying your Security Operations on AWS (20)
Mehr von CloudHesive
Mehr von CloudHesive (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
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
- 6. Overview of AWS Enterprise, Security and Automation Services • Enterprise Applications – Amazon AppStream – Managed Application Publishing – Amazon WorkSpaces – Managed Desktop Publishing – Amazon WorkDocs – Managed Document Sharing – Amazon WorkMail – Managed Enterprise E-Mail – Amazon SES – Managed SMTP Gateway – AWS Directory Service – Managed Directory Service (Active Directory Compatible) • Security & Identity – AWS CloudHSM – Dedicated HSM Appliances – AWS KMS – Managed Data-At-Rest Encryption – Amazon Inspector – Managed Application Security Scanner – AWS WAF – Managed Web Application Firewall – AWS IAM – User Credential Management • Automation – Auto Scaling – Managed Infrastructure Scaling – AWS Elastic Beanstalk – Managed Application Deployment – AWS CloudFormation – Infrastructure Configuration Management – AWS CodeCommit – Managed Repository – AWS CodeDeploy – Managed Software Deployment – AWS CodePipeline – Managed Continuous Delivery Service – AWS OpsWorks – Infrastructure + Software Configuration Management
- 7. Overview of AWS Managed (Abstracted) Services • Amazon EC2 Container Service – Managed Docker Container Deployment • Amazon API Gateway – Managed API Gateway • AWS Lambda – Managed Application Container • Amazon Cognito – Data Persistence for Mobile Devices • Amazon SNS – Managed Notification Service • Amazon Elastic Transcoder – Managed Transcoding Service • Amazon SQS – Managed Queue Service • Amazon SWF – Managed Workflow Service • Amazon Kinesis – Managed Data Pipeline (Streaming) • AWS Data Pipeline – Managed Data Pipeline (Bulk)
- 8. AWS Shared Responsibility Model
- 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
- 22. Further Learning • AWS Security: https://aws.amazon.com/security • AWS Security Blog: https://blogs.aws.amazon.com/security/ • AWS Documentation – http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc- endpoints.html – http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPN_CloudHu b.html – http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/S ubscriptions.html – http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/S 3Export.html – https://docs.aws.amazon.com/IAM/latest/UserGuide/walkthru_cross- account-with-roles.html – https://aws.amazon.com/articles/2781451301784570 – https://www.dropbox.com/s/hizoeicmgf4iha5/DDoS_White_Paper_June201 5.pdf • IAM Best Practices: https://evidentio.squarespace.com/blog/2015/2/12/top-10- aws-security-best-practices-1-disable-root-account-api-access-key • Realtime Alerting: https://cloudonaut.io/monitor-your-aws-account-to-detect- suspicious-behavior-in-real-time/ • CloudTrail in Kibana: https://github.com/AppliedTrust/traildash
- 23. Florida Meetups • http://www.meetup.com/aws-user-group-miami/ • http://www.meetup.com/Miami-AWS-Users-Group/ • http://www.meetup.com/South-Florida-Amazon- Web-Services-Meetup/ • http://www.meetup.com/awsflorida/ • http://www.meetup.com/AWS-User-Groups-of- Florida-Jacksonville/
- 24. Q&A • Questions?
- 25. Question 1 • What’s the difference between a Security Group and ACL?
- 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
Hinweis der Redaktion
- 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)