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.

AWS re:Invent 2016: Proactive Security Testing in AWS: From Early Implementation to Deployment Penetration Testing (SEC309)

1,314 views

Published on

Attend this session to learn about security testing your applications in AWS. Effective security testing is challenging, but multiple features and services within AWS make security testing easier. This session covers common approaches to testing, including how we think about testing within AWS, how to apply AWS services to your test setup, remediating findings, and automation.

Published in: Technology

AWS re:Invent 2016: Proactive Security Testing in AWS: From Early Implementation to Deployment Penetration Testing (SEC309)

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Alex Lucas, AWS Security November 29, 2016 SEC309 Proactive Security Testing in AWS From Early Implementation to Deployment Penetration Testing
  2. 2. What to expect from this session • How to think about your AWS assets • Threat modeling and attack surface • Security baseline • Testing for security • Automation • Continuous Security • Close
  3. 3. Threat modeling • Why? • External dependencies and assumptions • System edges and entry points • Assets and information flows • Classes of user and action / trust • Risks and mitigations
  4. 4. Threat modeling  assets • What is an asset? • Amazon EC2 instance • Amazon S3 bucket • Amazon RDS • Access management • Networking • Deployment and development
  5. 5. Threat modeling  actors • Users • Services • Access to shared assets
  6. 6. Threat model  architecture Unknown user Authenticated user Web server Cache RDBMS Web admin DB admin DB users? CMS 1.1 Login 1. 2 Post 2.1 Admin
  7. 7. STRIDE Spoofing Tampering Repudiation Information disclosure Denial of service Elevation of privilege
  8. 8. Table of flows, STRIDE etc Data flow ID Description 1.1 An unauthenticated user can logon onto the CMS system with valid credentials at this point a session identifying the user controls their identity. STRIDE • Spoofing – A user could assume an incorrect identity if not checked properly • Repudiation – Attempts to login and failed login attempts may not be traced • Denial of service (DoS) - If the login flow is too expensive (computationally complex) the login call could potentially be used to deny service to other users • Elevation of Privilege (EoP) – Incorrectly logging in a user would result in this
  9. 9. Feature Id Mitigation Description SESSION-104 To address spoofing concerns an external audit of the code by [X] will take place. All changes to the code post-event will undergo code review. AUDIT-7 For repudiation all login attempts will be logged into the application log and stored to Amazon CloudWatch Logs. AUDIT-7-1 In support of LOGIN-102 the team will investigate the feasibility of using CloudWatch alarms with thresholds for failed logins. LOGIN-11 For DoS prevention we will do extensive profiling of the login flow and ensure that failed and successful logins represent log computational burden. A single web server instance should be able to support O(x) login calls simultaneously.
  10. 10. Management layer Private subnetPublic subnet ws Internet gateway Router Route table Route table Endpoint S3 bucket Instance role IAM ElastiCache Route 53CloudFormation KMSAmazon Inspector CloudTrail Config
  11. 11. Security baseline • Core: • Instances are patched and remain so • Instances are safe to use post-startup as long as security groups only expose the expected services to the Internet • Account AWS infrastructure management is correctly controlled • Application: • The application has been security tested
  12. 12. Demo – patch level • Any outstanding security patches? • Using EC2 Simple Systems Manager (SSM) run command.
  13. 13. Build security testing in • Static analysis on code push to central repository • Adding a trigger to look for security issues • Check staging and pre-deployment • Check your application access controls
  14. 14. Demo – source code • AWS CodeCommit trigger to look for AWS stored secrets
  15. 15. Demo – deployment assessment • Using Amazon Inspector to assess a pre-production environment and move it to production.
  16. 16. Security testing • Penetration test request process: https://aws.amazon.com/security/penetration-testing/ • Focus on baseline • Know your tools • Be selective
  17. 17. Demo – network profile • Enumerate Internet endpoints • Confirm availability
  18. 18. Continuous security • Integrated testing • Point in time questions • Monitor for changes
  19. 19. Thank you!
  20. 20. Remember to complete your evaluations!
  21. 21. Related sessions • SEC301 - Audit Your AWS Account Against Industry Best Practices: The CIS AWS Benchmarks • SEC313 - Automating Security Event Response, from Idea to Code to Execution • SAC401 - 5 Security Automation Improvements You Can Make by Using Amazon CloudWatch Events and AWS Config Rules

×