[REPEAT 1] Confidently Execute Your Cloud Audit: Expert Advice (SEC205-R1) - AWS re:Invent 2018
•Descargar como PPTX, PDF•
3 recomendaciones•3,088 vistas
For security-conscious businesses, SOC 2 compliance is a minimum requirement when considering a cloud-based SaaS or PaaS solution. In this session, AWS and Deloitte deliver a joint workshop designed to help customers who are considering or undergoing SOC 2 compliance be successful, from initiation to delivery. The workshop is interactive, with practical activities derived from real-life challenges that occur throughout the audit life cycle, including planning, scoping, control development, and audit execution. Customers walk away with confidence to execute their own SOC audit to validate the security and compliance of their own cloud applications.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a [REPEAT 1] Confidently Execute Your Cloud Audit: Expert Advice (SEC205-R1) - AWS re:Invent 2018
Similar a [REPEAT 1] Confidently Execute Your Cloud Audit: Expert Advice (SEC205-R1) - AWS re:Invent 2018 (20)
Más de Amazon Web Services
Más de Amazon Web Services (20)
[REPEAT 1] Confidently Execute Your Cloud Audit: Expert Advice (SEC205-R1) - AWS re:Invent 2018
- 2. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Confidently ExecuteYourCloud Audit: ExpertAdvice Misty D. Haddox Technical Program Manager AWS/Security Assurance S E C 2 0 5 Kristen Haught Technical Program Manager AWS/Security Assurance Devendra Awasthi Senior Manager Deloitte/Cloud Risk & Compliance
- 3. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Why we are here today … • When asked for a SOC report, I provide my potential customers with AWS’ report. Does that cover us? • How do I reference AWS’ controls in my SOC 2 report? • In a hybrid environment, how do we determine which controls we should consider including in our SOC 2 audit? • What if my MSP doesn’t have a SOC 2 report? • I’m an MSP, how do I get a SOC 2 report? • Can I use AWS services that are not in scope of the AWS SOC 2 report?
- 4. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Control responsibility is important no matter what the business model is. The key is understanding the deployment model and where the responsibility lies, transfers, and/or is shared. Control responsibility is shared
- 5. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. How is access managed?
- 6. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Use case 1:Control ownership and validation AWS is responsible for user management controls for the internal AWS infrastructure. MSP is responsible for user management controls for infrastructure. Customer is responsible for user management controls on application and database. AWS
- 7. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS AWS is responsible for user management controls for the internal AWS infrastructure. MSP is responsible for user management controls for infrastructure. Customer is responsible for user management controls on application and database. SOC 2 CC 5.2 New internal and external users, whose access is administered by the entity, are registered and authorized prior to being issued system credentials, and granted the ability to access the system, to meet the entity’s commitments and system requirements as they relate to security, availability, and confidentiality… Use case 1: Mapping controls toSOC 2 requirement
- 8. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. How is data protected?
- 9. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Use case 2:Control ownership and validation AWS provides the infrastructure controls that enable encryption of data in transit and at rest. Provider supports TLS 1.0, 1.1 and 1.2 to encrypt network traffic. AWS Scheduling SaaS utilizes current encryption mechanisms protect data. Protect patient health information.
- 10. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. SOC 2 CC 5.7 The transmission, movement, and removal of information is restricted to authorized internal and external users and processes and is protected during transmission, movement, or removal enabling the entity to meet its commitments and system requirements as they relate to security, availability, and confidentiality. AWS AWS provides the infrastructure controls that enable encryption of data in transit and at rest. Provider supports TLS 1.0, 1.1 and 1.2 to encrypt network traffic. Scheduler utilizes current encryption mechanisms protect data. Protect patient health information. Use case 2: Mapping controls toSOC 2 requirement
- 11. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Concepts Risk assessment first Concept 2 Control ownership must be understood and validated Concept 3 Mapping controls to requirements (SOC 2) Concept 4 Update processes and controls to fill any gaps Concept 5Concept 1 Control responsibility is shared
- 12. Thank you! © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 13. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Notas del editor
- Speaking notes: Introduce ourselves
- Kristen Speaker Notes: Introduce why we decided to do this Chalk Talk We want to share what we’ve learned with you. Owner: TBD
- MISTY Concept 1 | Control responsibility is shared Speaker Notes: To comprehend this key concept we will discuss deployment scenarios and then walkthrough the control assessment methodology performed to complete the control coverage.
- DEV
- Concept 4 | Translate / Map your security process and controls to SOC 2 Concept 5 | Update your security processes and controls based on your new environment CC 5.2: …For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized. AWSCA-2.1: User access to the internal Amazon network is not provisioned unless an active record is created in the HR System by Human Resources. Access is automatically provisioned with least privilege per job function. First time passwords are set to a unique value and changed immediately after first use. AWSCA-2.3: IT access privileges are reviewed on a quarterly basis by appropriate personnel. AWSCA-2.4: User access to Amazon systems is revoked within 24 hours of the employee record being terminated (deactivated) in the HR System by Human Resources.
- Concept 4 | Translate / Map your security process and controls to SOC 2 Concept 5 | Update your security processes and controls based on your new environment CC 5.2: …For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized. AWSCA-2.1: User access to the internal Amazon network is not provisioned unless an active record is created in the HR System by Human Resources. Access is automatically provisioned with least privilege per job function. First time passwords are set to a unique value and changed immediately after first use. AWSCA-2.3: IT access privileges are reviewed on a quarterly basis by appropriate personnel. AWSCA-2.4: User access to Amazon systems is revoked within 24 hours of the employee record being terminated (deactivated) in the HR System by Human Resources.
- Misty
- Concept 4 | Translate / Map your security process and controls to SOC 2 Concept 5 | Update your security processes and controls based on your new environment CC 5.2: …For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized. AWSCA-2.1: User access to the internal Amazon network is not provisioned unless an active record is created in the HR System by Human Resources. Access is automatically provisioned with least privilege per job function. First time passwords are set to a unique value and changed immediately after first use. AWSCA-2.3: IT access privileges are reviewed on a quarterly basis by appropriate personnel. AWSCA-2.4: User access to Amazon systems is revoked within 24 hours of the employee record being terminated (deactivated) in the HR System by Human Resources.
- Concept 4 | Translate / Map your security process and controls to SOC 2 Concept 5 | Update your security processes and controls based on your new environment AWSCA-1.6: KMS-Specific - Roles and responsibilities for KMS cryptographic custodians are formally documented and agreed to by those individuals when they assume the role or when responsibilities change. AWSCA-4.1: EC2-Specific – Upon initial communication with an AWS-provided Linux AMI, AWS enables secure communication by SSH configuration on the instance, by generating a unique host-key and delivering the key's fingerprint to the user over a trusted channel. AWSCA-4.2: EC2-Specific – Upon initial communication with an AWS-provided Windows AMI, AWS enables secure communication by configuring Windows Terminal Services on the instance by generating a unique self-signed server certificate and delivering the certificate's thumbprint to the user over a trusted channel. AWSCA-4.3: VPC-Specific - Amazon enables secure VPN communication to a VPN Gateway by providing a shared secret key that is used to establish IPSec Associations. AWSCA-4.4: S3-Specific - S3 generates and stores a one-way salted HMAC of the customer encryption key. This salted HMAC value is not logged. AWSCA-4.6: KMS-Specific - AWS Services that integrate with AWS KMS for key management use a 256-bit data key locally to protect customer content. AWSCA-4.7: KMS-Specific - The key provided by KMS to integrated services is a 256-bit key and is encrypted with a 256-bit AES master key unique to the customer’s AWS account. AWSCA-4.9: KMS-Specific - KMS endpoints can only be accessed by customers using TLS with cipher suites that support forward secrecy. AWSCA-4.10: KMS-Specific - Keys used in AWS KMS are only used for a single purpose as defined by the key usage parameter for each key. AWSCA-4.11: KMS-Specific - Customer master keys created by KMS are rotated on a defined frequency if enabled by the customer. AWSCA-5.13: All AWS production media is securely decommissioned and physically destroyed prior to leaving AWS Secure Zones. AWSCA-7.1: S3-Specific – S3 compares user provided checksums to validate the integrity of data in transit. If the customer provided MD5 checksum does not match the MD5 checksum calculated by S3 on the data received, the REST PUT will fail, preventing data that was corrupted on the wire from being written into S3.
- Dev Speaking Notes: If you walk away with one thing from this session; it would be the conceptual process for supporting the achievement of a SOC (Service Organization Controls) attestation. Concept 1 | Control responsibility is shared Concept 2 | Identify the processes and controls needed to secure your scoped environment --look to your controls framework (or if you don’t work w/ your product team to identify the controls in place) Concept 3 | Validate service provider SOC2 report(s) to ensure inherited and shared control coverage Concept 4 | Translate / Map your security process and controls to SOC 2 Concept 5 | Updated your security processes and controls based on your new environment Identified Shared Responsibility Identified What Needs to be done to Securre Do all responsibility owners do those things? Fill in gaps Map