O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Modern Security and Compliance Through Automation | AWS Public Sector Summit 2016

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 25 Anúncio

Modern Security and Compliance Through Automation | AWS Public Sector Summit 2016

Baixar para ler offline

Because the entire AWS cloud platform is programmable, it turns out that you can program security and compliance in advance of actually instantiating any actual workloads. In this session, we show how you can design a secure and compliant workload and even have it audited by a third-party auditor before creating it for the first time! Once it's created, other facilities provide mechanisms for detecting and alerting a drift from your baseline, and even automatically remediating the drift. Learn how the comprehensive automation available in AWS provides security and compliance professionals an entire new, more efficient, and more effective way to work.

Because the entire AWS cloud platform is programmable, it turns out that you can program security and compliance in advance of actually instantiating any actual workloads. In this session, we show how you can design a secure and compliant workload and even have it audited by a third-party auditor before creating it for the first time! Once it's created, other facilities provide mechanisms for detecting and alerting a drift from your baseline, and even automatically remediating the drift. Learn how the comprehensive automation available in AWS provides security and compliance professionals an entire new, more efficient, and more effective way to work.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (20)

Anúncio

Semelhante a Modern Security and Compliance Through Automation | AWS Public Sector Summit 2016 (20)

Mais de Amazon Web Services (20)

Anúncio

Mais recentes (20)

Modern Security and Compliance Through Automation | AWS Public Sector Summit 2016

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Modern Security and Compliance Through Automation Brett Miller, Senior Consultant, Amazon Web Services Mike Dixon, Senior Consultant, Amazon Web Services June 21, 2016
  2. 2. Compliance & Accreditation  How do I architect for compliance in AWS?  How can I make architecting for compliance repeatable?  How can I validate that my architecture is compliant before deployment?  How can I ensure continuous compliance in production?  How can I simplify my accreditation process and get to ATO faster?
  3. 3. Compliance Frameworks  NIST SP 800-53  DoD CSM Levels 1-2  DIACAP/FISMA  FedRAMP  PCI DSS  HIPAA  MPAA  CJIS
  4. 4. Shared Responsibility Model Customers are responsible for how they use AWS components in AWS Customer Data Platform, Applications, Identity & Access Management Operating System, Network & Firewall Configuration Client-side Data Encryption & Data Integrity Authentication Server-side Encryption (File System and/or Data) Network Traffic Protection (Encryption/ Integrity/Identity) DatabaseStorageCompute Networking Edge Locations Regions Avail. Zones AWS Global Infrastructure Customer Responsible for security in’the Cloud Responsible for security of the Cloud AWS
  5. 5. Customer Challenges  Meeting compliance requirements (NIST, PCI, HIPAA, CJIS, etc.)  Taking advantage of new services and features when designing for the Cloud  Making many critical decisions to ensure a secure application when using the AWS Shared Responsibility Model  Mapping security controls to numerous AWS services − Example: 400 NIST 800-53 Security Controls to 42 AWS services Common Challenges in Compliance
  6. 6. Shared Responsibility Model Compliance in the Cloud: Examples Framework Control Description Implementation in AWS Architecture (Example) NIST 800-53 AU-9 The information system protects audit information and audit tools from unauthorized access, modification, and deletion AWS CloudTrail and/or log files in S3 buckets which have S3 bucket policies to prevent modification or deletion (write once read many) PCI DSS Requirement 4 Encrypt transmission of cardholder data Elastic load balancers must enforce HTTPS encryption using strong security policies enforcing TLS HIPAA - Tenancy requirement Requirement to use “dedicated” tenancy for EC2 instances storing or processing PHI data CJIS Policy Area 7 Configuration management Enforce use of hardened EC2 instance operating systems and/or pre-approved Amazon Machine Images (AMIs) DoD CSM Levels 4-5 No direct access from VPC to the Internet Amazon VPCs for Impact Levels 4-5 data require VPN connection, no Internet gateway (IGW)
  7. 7. Simplifying Compliance: Key Concepts  Know your compliance framework(s) − Translate compliance controls to technical implementation − Create and manage a pre-approved common security controls mapping (SCTM, CRM, etc.) to use when architecting for security and compliance  Distinguish between inherited controls vs. customer controls − Establish (in advance) which controls are inherited by the global infrastructure  Take advantage of capabilities the Cloud provides − Infrastructure as Code − AWS services (CloudTrail, AWS Config, Amazon Inspector, etc.) − Partner solutions  Automate standard implementations
  8. 8. Automation  Why automate compliance? − Reduced time to ATO − Lower cost − Fewer resources required − Less human error − Consistency − Reproducible
  9. 9. Automating Compliance in AWS  Infrastructure As Code − Managed and controlled like software − Validate pre-deployment − Test-driven development (TDD) for security and compliance  Standardization − Predefined guidelines, mapped to security controls − Consistent, reusable architecture and configuration  Compliance at scale − Enforce policies across accounts, workloads, systems − Shared services for security, logging, monitoring, access control  Transparency − Everything is an API call! − Auditability, logging − Continuous monitoring (CM) for both applications and infrastructure
  10. 10. Demo
  11. 11. Pre-Development Development Testing Production Architect for Compliance Architect for Compliance Provide Baselines Enterprise Accelerator for Compliance IATT ATO Develop Applications Enterprise Accelerator for Compliance AWS Service Catalog Submit SSP Validate Architecture for Compliance Continuous Monitoring Manage Security- Relevant Changes Integration Testing for Compliance Submit for ATO Accelerating the Journey to ATO Vulnerability Scanning AWS Code Pipeline Compliance Control Mapped to Implementation Method Developing with a predefined baseline implementing control Validation & Testing for Requirement Continuous Monitoring for Control Implementation Amazon InspectorAWS Config AWS Config AWS OpsWorks AWS Elastic Beanstalk
  12. 12. Pre-Development  Understand your compliance requirements − Compliance type(s): NIST 800-53, ICD 503, DoD CSM, PCI, HIPAA, etc. − Workload-specific: DoD CSM Levels 1-2, FedRAMP High, etc.  Architect for compliance − Map security controls to technical implementation  Predefine baselines − Examples: VPC configuration, connectivity, AWS Identity and Access Management (IAM) configuration, logging/monitoring − Baselines align with governance model Pre-Development Architect for Compliance Provide Baselines Enterprise Accelerator for Compliance AWS Service Catalog Compliance Control Mapped to Implementation Method
  13. 13. Development  Deploy predefined baseline environment − Service Catalog  Manage all AWS components as code − Version Control (AWS CodeCommit, Git, SVN)  Take advantage of AWS services − AWS CodeDeploy/AWS CodePipeline − Elastic Beanstalk − OpsWorks  Submit for IATT (prepare for ATO) − Simplify the process of security controls mapping Development Architect for Compliance Develop Applications Enterprise Accelerator for Compliance Submit SSP Developing with a predefined baseline implementing control AWS OpsWorks AWS Elastic Beanstalk
  14. 14. Testing  Unit testing − Validate before deployment − Check AWS CloudFormation templates for non-compliant configurations  Integration testing − Deploy infrastructure code into AWS account − Run tests for validation (Config, Inspector, HBSS, partner products, etc.)  Prepare for ATO − Submit predefined security controls mapping for simplified ISSO/ISSM approval Testing Validate Architecture for Compliance Integration Testing for Compliance Submit for ATO Validation & Testing for Requirement
  15. 15. Testing Infrastructure Code  Identify resource configurations in code that violate compliance − Example tools: https://github.com/stelligent/cfn_nag  Common points of compliance validation − Security group rules − Network Access Control List (network ACL) rules − IAM policies − S3 bucket policies − Elastic Load Balancing security policies "sg": { "Type": "AWS::EC2::SecurityGroup", "Properties": { "SecurityGroupIngress": { "CidrIp": “0.0.0.0/0", "FromPort": 22, "ToPort": 22, "IpProtocol": "tcp" }, "VpcId": "vpc-12345678" } } } } Example: AWS CloudFormation template contains security group allowing unrestricted access to SSH
  16. 16. Production  Authority to Operate (ATO) − …but compliance doesn’t end with ATO  Continuous monitoring − Security-relevant changes to configuration  Non-compliance − Continuously monitor for changes that violate compliance − Immediate notifications − Event-driven, automated remediation Production Continuous Monitoring Manage Security- Relevant Changes Vulnerability Scanning Continuous Monitoring for Control Implementation Amazon InspectorAWS Config
  17. 17. Automated Response to Noncompliant Changes with Config
  18. 18. Lifecycle of a Compliance Control: Example Control Pre-Development Development Testing Production SC-7(5) Boundary Protection - DENY BY DEFAULT/ALLOW BY EXCEPTION: The information system at managed interfaces denies network communications traffic by default and allows network communications traffic by exception (that is, deny all, permit by exception). Enterprise Accelerator defines required NIST 800-53 compliance control and maps predefined to implementation in CloudFormation template Enterprise Accelerator as starting point for CloudFormation template development Automated unit testing with cfn-nag tool validates that control is not being violated in a template Integration testing with Config verifies Config rule continuously monitors for violations of this control and takes corrective action if a violation is detected Requirement: Rules with “ALL TRAFFIC” not permitted in security groups Base templates by default deny all ports except those required to be open Starting point in development with templates which Testing for security groups where all ports are open If security group changes, Config rule immediately evaluates and determines if rule changes violate control
  19. 19. Automating Compliance: Tools & Services  AWS Compliance Enterprise Accelerator  Telos Xacta (partner solution)  Config/Config rules  Inspector  AWS Trusted Advisor
  20. 20. AWS Compliance Enterprise Accelerator AWS Compliance Enterprise Accelerator  Address security/compliance requirements and AWS best practices  Knowledge transfer on AWS security model  Standardized for specific use cases  Ready to be pre-approved by customer assessment organizations  Ready to deploy “out of the box”  Customizable AWS Compliance Packages Include: Managed Automation –CloudFormation templates, automation scripts Detailed Documentation – User Guide, setup, customization Security Controls Matrix – Mapping of controls to implementation
  21. 21. AWS Enterprise Accelerator for Compliance Currently Available Quick Starts  NIST High baseline  (Featuring Trend Micro Deep Security)  NIST SP 800-53 (version 2.0)  DoD SRG (GovCloud)  Trusted Internet Connection  800-171  PCI DSS  Secure Commercial Cloud Architecture (SCCA)  Late July preview http://aws.amazon.com/quickstart
  22. 22. Telos Xacta  Xacta IT Governance, Risk, Compliance (GRC) product suite  Automatically map inherited security controls  Generate documentation  Expedite approvals  Automate risk assessment, remediation, and compliance reporting
  23. 23. Simplifying Security Controls with Telos Xacta
  24. 24. Additional Resources  AWS Risk & Compliance Whitepaper https://d0.awsstatic.com/whitepapers/compliance/AWS_Risk_and_Compliance_Whitepaper.pdf  AWS Quick Start Reference Deployments https://aws.amazon.com/quickstart/  AWS Compliance https://aws.amazon.com/compliance/  Telos Corporation Expedites Secure and Compliant Cloud Deployments on AWS Cloud http://bit.ly/1PoQA8O  Continuous Security: Security in the Continuous Delivery Pipeline (Stelligent) http://bit.ly/1sCaQPq

Notas do Editor

  • Title: “Fast track your ATO with Compliance Automation”
    Compliance automation made easy! Who says Compliance and security can’t be cool!  Customers in regulated verticals such as Financial Services (PCI DSS), Public Sector (FedRAMP/NIST) must prove that their IT systems are secure and dependable. However, traditional security and compliance processes are slow, tedious, labor intensive, and not interesting. Come learn about how to employ  “Push Button”  or Alexa powered AWS security/compliance tools that drive down costs, increase your speed to the cloud and make your auditors and developers happy.


    INTRODUCTION
    - Introduce self & session
    *Intro key points:
    Customers in the public sector are taking advantage of all the benefits of moving workloads to AWS including agility, efficiency, cost savings, scalability…
    …but same customers must still adhere to the existing compliance frameworks
    Discuss strategies and tools to help accelerate compliance (more specifically, getting an authorization to operate faster)
    How compliance can be parallel to cloud adoption and not a hurdle to it
    How we can actually implement better compliance in the cloud through automation and taking advantage of available of tools and services
    Also in turn ensuring adherence to compliance well beyond just ATO
  • Common questions from customers…
    How do I architect for compliance?
    In other words, design and develop a compliant configuration in AWS (from VPC networking, to access control, to continuous monitoring requirements, etc)
    How do we take existing compliance controls and turn them into technical implementations
    How can I make architecting repeatable?
    How can we make it so we are not reinventing the wheel every time we want to deploy a new workload
    How can I validate before deployment?
    How can I validate for compliance along the way, avoiding common pitfalls when submitting for my AT
    How can I ensure continuous compliance?
    Compliance doesn’t have to end at ATO obviously, how do I implement solutions including continuous monitoring and automation tools to ensure my deployments are continuously compliance
    How can I simplify the accreditation process…?
    How can I take the same agility and efficiency of the cloud and apply that to my accreditation process
  • Most organizations follow some type of existing industry or government standard compliance framework. These are just a few common frameworks I’m sure most of us have encountered…
  • Brief recap of shared responsibility model.  AWS is responsible for the core infrastructure provided on which our services are built, while the customer is responsible for using the services and features provided by AWS in order to properly meet their security and compliance needs.
     
    In architecting for compliance in AWS, we want to primarily ensure 2 things:
    We know what compliance controls are being met by the AWS global infrastructure (commonly inherited)
    We understand what controls are considered a customer responsibility, and know how to best implement them in our architecture
  • The challenge many organizations encounter with compliance is how to translate compliance requirements into a technical implementation.  In other words, how to configure their systems and design the technical controls of security in a way that properly meets the frameworks the organization must adhere.  This can be a time consuming and error prone process if not done correctly. 

    The cloud offers many options through services and features to better implement security, but within that context we must ensure we are using the correct tools in our toolbox in the correct way to be able to ensure our compliance, whether NIST or PCI or any other requirement, is being met.


    Meeting compliance requirements
    The challenge many organizations encounter with compliance is how to translate compliance requirements into a technical implementation.
    What does it mean to technically implement the controls in NIST 800-53 or in PCI or any other compliance framework?
    Taking advantage of new services
    Now have more than 50 services and we are continuously adding more, how can we use new services to take care of some of the heavy lifting in security and compliance?
    How do we use all the tools in our toolbox the best possible way in terms of our compliance frameworks
    Making critical decisions for security
    May often look at compliance as something we just have to follow, but it plays a valuable purpose in security
    NIST is intended to provide standards to protect federal government information
    PCI is intended to protect payment cardholder data
    HIPAA is meant to ensure protection of personal health information
    Mapping to numerous services
    We can always say we are compliance, but if we want to be authorized by our security organization to operate an application, we typically have to document that (in the form of security controls matrix, system security plan, or other means)

  • To effectively implement compliance controls IN the cloud (in terms of the shared responsibility model) we need to know from a technical perspective how to implement them.
    Some common examples of how typical compliance requirements are implemented are listed here
    While many methods of implementation can often cover requirements across multiple frameworks, as you can see there are differences that must be considered when working with a specific framework.
  • Why automate compliance in AWS?
  • Why automate? Why automate anything?
  • We’ve heard of automation in terms of software deployment and configuration….but what does it mean to automate compliance in AWS?

    *we manage compliance as CODE
    - We manage and control our compliance implementation much like software. Version control, testing, QA, applying corrective action (fixes).
    Optionally we take it to the level of Test Driven Development: concept in which you can first design tests based on requirements before even writing your application (same concept can apply when automating compliance)

    *provide STANDARDIZATION
    Can write something once which can be reused across many deployments many times
    Have consistent and reusability in our architecture

    *deliver COMPLIANCE AT SCALE
    Through standardization and infrastructure as code, we can apply and enforce policies across many workloads
    Shared services for security such as vulnerability scanning and intrusion detection can be scaled to support many workloads across our organization
    Scalability of the cloud also allows us to aggregate and analyze vast amounts of data and logs

    *in automating compliance we have greater TRANSPARENCY
    Remember everything is an API call in terms of monitoring our configuration in AWS
    Continuously monitor both applications and the infrastructure in parallel
  • Demo placeholder
  • My definition of unit testing here….not sure how that fits in with common terminology but wanted to differentiate between just testing code and testing a fully deployed infrastructure
  • My definition of unit testing here….not sure how that fits in with common terminology but wanted to differentiate between just testing code and testing a fully deployed infrastructure
  • Putting this entire workflow together in terms of a DevOps approach, we can have a complete CI/CD pipeline where we start with pre-defined architectures built for compliance, we validate them using automation and continuous integration tools, and finally deliver them for workload owners who can then use these as service catalog products to launch their applications into.

×