Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Best Practices for Managing Security Operations in AWS - March 2017 AWS Online Tech Talks

4,404 views

Published on

To help prevent unexpected access to your AWS resources, it is critical to maintain strong identity and access policies. It is equally important to track and alert on changes to your AWS resources. In this tech talk, you will learn how to use AWS Identity and Access Management (IAM) to control access to your AWS resources and integrate your existing authentication system with AWS IAM. We will cover how you can deploy and control your AWS infrastructure using code templates, including change management policies with AWS CloudFormation. In addition, we will explore different options for managing both your AWS access logs and your Amazon Elastic Compute Cloud (EC2) system logs using Amazon CloudWatch Logs. We also will cover how to use these logs to implement an audit and compliance validation process using services such as AWS Config, AWS CloudTrail, and Amazon Inspector.

Learning Objectives:
• Understand the AWS Shared Responsibility Model.
• Understand AWS account and identity management options and configuration.
• Learn the concept of infrastructure as code and change management using AWS CloudFormation.
• Learn how to audit and log your AWS service usage.
• Learn about AWS services to add automatic compliance checks to your AWS infrastructure.

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Best Practices for Managing Security Operations in AWS - March 2017 AWS Online Tech Talks

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Armando Leite, Principal Security Architect 03/29/17 Best Practices for Managing Security Operations in AWS
  2. 2. A practical approach to help achieve SecOps excellence + How to leverage AWS services to implement. + Take home toolkit i.e. try it by yourself. Control Monitor Fix What to expect from the session
  3. 3. In detail 1. Introduction 2. CMF: Control/Monitor/Fix - Control: Creating the guardrails. - IAM, Code*, AWS Config - Monitor: Provide visibility - Cloudtrail, Flowlogs, Syslog, Cloudwatch - Fix: Dealing with Exceptions - Lambda 3. In Practice (aka demo) 4. Your take home kit and actions MSB – Minimum Security Baseline Pro Level – What to aim for.
  4. 4. Cloud Adoption Framework The Security Perspective Directive Preventive Detective Responsive Control Monitor ? Fix Driving the right behavior Maintain and assure over time. Get back to known good.
  5. 5. Our guidelines (‘Directive’) Operating principles: 1. Think pipelines/workflows, not isolated controls. 2. Use the data. 3. The SOP is Code.
  6. 6. Control Monitor FixControl Monitor Fix
  7. 7. Phase 1: Control Goal: • Drive towards secure outcomes i.e. Build guardrails Possible options: • IAM • Cloudformation • Code* Best practice: • MSB: Individual users + Least privilege + use of groups. • Pro level: Centralized deployment of controls across N accounts.
  8. 8. 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 Final decision =“deny” (explicit deny) Ye s Final decision =“allow” Ye s 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.
  9. 9. 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.
  10. 10. 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.
  11. 11. 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
  12. 12. Introducing AWS Organizations Control AWS service use across accounts Policy-based management for multiple AWS accounts. Consolidate billingAutomate AWS account creation
  13. 13. Typical Use Cases Control the use of AWS services to help comply with corporate security and compliance policies. Automate the creation of AWS accounts for different resources. • API response to trigger additional automation. (e.g. deploy CloudFormation template)
  14. 14. What is AWS CloudFormation? • AWS CloudFormation allows you to model, provision, and update the full breadth of AWS resources. • Manage anything from a single Amazon EC2 instance to a multi-tier application. • Integrates with other development and management tools.
  15. 15. Source Code Running Host Continuous Integration / Continuous Deployment Cloudformation Security
  16. 16. Elements of a Continuous Delivery Pipeline Commit Phase: Source Control changes • Static code analysis: Analyze the CFN templates against a set of security rules Acceptance Phase: Dev Environment • Dynamic analysis: Run template in sandbox / acceptance test environment. Capacity/Integration/Staging Phases: Pre-Prod Environment • Load, performance, Penetration and failover testing. Production Phase: Prod Environment • Deploy controls.
  17. 17. Code* for Infrastructure code Create Stack CloudFormation CodePipeline DevOps Code Push Code Pull Static Code Analysis Lambda Dynamic Security checks Lambda Manual Approval Create ChangeSet CloudFormation Approve ChangeSet Delete Stack CloudFormation Execute ChangeSet CloudFormation Commit Phase Acceptance Phase Prod Phase S3
  18. 18. Control Monitor Fix
  19. 19. Phase 2: Monitor Goals: - Ensure effective operation over time. - Detect anomalies/change. Options: • Cloudtrail, Cloudwatch*, VPC Flowlogs, Config… Best Practice: • MSB: Aggregate log data. • Pro level: Analyze and act on log data as it arrives.
  20. 20. What is AWS CloudTrail? A fully managed service that records API calls made on your AWS account. Customers are making API calls... On a growing set of services around the world… CloudTrail is continuously recording API calls… And delivering log files to customers
  21. 21. Alert indexer Triage/Classification rules Cloudtrail Cloudtrail Cloudtrail ... ... Security accountAccount 1 Account 2 Account N Cloudtrail aggregation bucket Automated configuration to enable logging and aggregation destination. Log files deposited in S3 bucket under Security Account. SNS notifies lambda of new events available for processing. Each lambda evaluates a specific compliance item or misuse case. Rules engines help defin action to take based on asset and environment. If dictated by rules engine, event results in notification via email i.e. critical events. Alerts preserved in Dynamodb for reporting and indexing of raw data. All processing in Security Account i.e. no external dependencies to add new logic, log processing, etc.
  22. 22. AWS Config & Config Rules Changing resources AWS Config Config Rules History, Snapshot Notifications API Access Normalized
  23. 23. AWS Config: Inventory and compliance
  24. 24. AWS Config Rules: Evaluate resource Config
  25. 25. Alert… Account DB Cloudtrail Cloudtrail Cloudtrail ... ... Logging aggregation accountAccount 1 Account 2 Account N Cloudtrail aggregation bucket SQS Dashboard CWE Config Config Config Ticketing…
  26. 26. Alert… Account DB ... ... Logging aggregation accountAccount 1 Account 2 Cloudtrail aggregation bucket SQS Dashboard CWE Ticketing… Cloudtrail Account N Config Flowlogs CloudtrailConfig Flowlogs CloudtrailConfig Flowlogs Flowlogs Aggregation bucket
  27. 27. Control Monitor Fix
  28. 28. Goal: • Return to ‘known good’ • ‘Don’t throw the baby out with the bathwater’… Options: • Lambda shines but whole AWS platform plays a role. Best Practices: • MSB: automate alerting and integrate with ticketing systems. • Pro Level: Closed loop. Fix – Correcting anomalies
  29. 29. Signal Noise Gather Remediate Do Nothing Correct Alert Enrich Stop Measure Spectrum of options
  30. 30. Fix using AWS services Trusted Advisor AWS Config Managed Rules AWS Config Custom Rules with remediation CloudWatch Events with Lambda rules Lambda code with various triggers Ease of getting started vs. customization and control
  31. 31. Security Incident Response Simulations Test and benchmark your security response to security events. Experts from the Security, Risk and Compliance (SRC) practice can help you assess your current state of incident response readiness, then prepare and execute an exercise to practice that response. Objectives: • Assess current incident response processes and procedures • Provide recommendations for using AWS services of incident response • Test the cloud incident response process via a simulated exercise Typical effort: 15 Man Days
  32. 32. Control Monitor FixControl Monitor Fix In practice…
  33. 33. Demo – event flow 1 – Standard 2 – Enhanced 3 – Active Auto Scaling group security group security group EC2 instance Web server security group EC2 instance App server Auto Scaling group CloudWatch Syslog Flowlogs CloudTrail In standard operation, we are observant. Control: - Security agent loaded in instance. - Logons tracked. Monitoring: - We gather data covering API activity (cloudtrail), network (Flowlogs) and also in- instance activity (Syslog). Fix: - We are good  Logon ok? Logon is OK! SSH Login! (CWECustom)
  34. 34. Demo – event flow 1 – Standard 2 – Enhanced 3 – Active Auto Scaling group security group security group EC2 instance Web server security group EC2 instance App server Auto Scaling group CloudWatch Syslog Flowlogs CloudTrail SSH Login! (CWECustom) A logon event occurs. We go to Enhanced surveillance mode. Control: - Dynamically add lambda subscriptions to log feeds. Monitor: - In instance activity (privilege escalation) - Initiation of forbidden flows. Fix: - Alert only. Watchful but passive. Enhance OS data analysis Network data analysis Subscribe to Syslog Enable Instance level flowlogs Subscribe to instance flowlogs Flowlogs Logon ok? Logon NOT ok.
  35. 35. Demo – event flow Auto Scaling group security group EC2 instance web app server Elastic Load Balancing security group EC2 instance web app server security group EC2 instance web app server security group App server 1 – Standard 2 – Enhanced 3 – Active OS data analysis Isolate Preserve Deregister Syslog data Root Access CloudWatch
  36. 36. Demo – event flow Auto Scaling group security group EC2 instance web app server Elastic Load Balancing security group EC2 instance web app server security group EC2 instance Anomaly security group App server 1 – Standard 2 – Enhanced 3 – Active OS data analysis Isolate Preserve Deregister Syslog data CloudWatch
  37. 37. Demo – event flow Auto Scaling group security group EC2 instance web app server Elastic Load Balancing security group EC2 instance web app server security group EC2 instance Anomaly security group App server 1 – Standard 2 – Enhanced 3 – Active OS data analysis Isolate Preserve Deregister Syslog data CloudWatch Block all
  38. 38. Demo – event flow Auto Scaling group security group EC2 instance web app server Elastic Load Balancing security group EC2 instance web app server security group EC2 instance Anomaly security group App server 1 – Standard 2 – Enhanced 3 – Active OS data analysis Isolate Deregister Preserve Syslog data CloudWatch Block all Dereg ASG/ELB
  39. 39. Demo – event flow Auto Scaling group security group EC2 instance web app server Elastic Load Balancing security group EC2 instance web app server security group EC2 instance Anomaly security group App server 1 – Standard 2 – Enhanced 3 – Active OS data analysis Isolate Deregister Preserve Syslog data CloudWatch Logs Block all Dereg ASG/ELB Amazon EBS snapshots
  40. 40. Demo – event flow Auto Scaling group security group EC2 instance web app server Elastic Load Balancing security group EC2 instance web app server security group EC2 instance web app server security group App server 1 – Standard 2 – Enhanced 3 – Active security group EC2 instance Anomaly An escalation occurred and we switched to Active i.e. intervene and get it fixed. Control: - SG to isolate anomalous instance. - Preserve instance for both live and offline analysis. - Deregister application from live use. Monitoring: - We continue to monitor all activity as per previous steps. Fix: - The control actions cause ASG to be 1 instance short and will recover to original fleet size from ‘last known good’.
  41. 41. Demo – event flow 1 – Standard 2 – Enhanced 3 – Active Auto Scaling group security group security group EC2 instance Web server security group EC2 instance App server Auto Scaling group CloudWatch Syslog Flowlogs CloudTrail In standard operation, we are observant. Control: - Security agent loaded in instance. - Logons tracked to TT. Monitoring: - We gather data covering API activity (cloudtrail), network (Flowlogs) and also in- instance activity (Syslog). Fix: - We are BACK TO good 
  42. 42. Summary Control: • IAM is the foundation for everything else. • Service catalogue as an option to standardize product distribution. • Code*: Embed security throughout (‘Fail early’). Monitor: • Cloudtrail, Config, Flowlogs,…:To get visibility, you need to see – enable logging. • Data is good. Better if you use it. Great if used to drive automation. Fix: • Reduce ‘Detect-Report-Remediate’ cycles. • Automate to gain speed + free human intellect to more added value tasks.
  43. 43. Take home kit – your turn! #1 Demo code is published • https://github.com/awslabs/automating-governance-sample #2 Implementing DevSecOps using AWS Codepipeline • https://aws.amazon.com/blogs/devops/implementing-devsecops-using-aws-codepipeline #3 “what should I Control/Monitor/Fix next?” • https://aws.amazon.com/whitepapers/aws-security-best-practices/ #4 (Optional) Come Jam with us!
  44. 44. San Francisco Summit 2017 – April 18 (am) and April 19 (pm) Washington DC, Public Sector Summit - June 12 (pm) More to come… Your company? 
  45. 45. Thank you! Armando Leite, Principal Security Architect

×