Cloud Transformation and the Shared Security Model

Sean Cyriaque, Senior Consultant, Cyber Risk Advisory, Coalfire

For many organizations, the lure of the cloud is very strong. Large enterprises usually have several justifications for adopting cloud-based services including preserving capital, adding scalability to applications, and minimizing IT staffing needs. Small- to medium-sized organizations often look at the cloud as an avenue to achieve all those same goals without the need for improved security skills from their existing IT staff. But as the number and sophistication of attacks in the cloud grow exponentially, there is increasing confusion regarding who is responsible for the security and compliance of applications and data in the cloud.

The “Shared Responsibility Model” defines which party - customer or Cloud Services Provider (CSP) - is responsible for security. As an example, Amazon’s shared responsibility model is “AWS is responsible FOR the cloud, and customers are responsible for what they put IN the cloud.“ This means that AWS is responsible for network segmentation, perimeter services, DDoS spoofing, and scanning prevention. Its customers are responsible for network threat detection, security monitoring, and incident reporting. AWS will secure against attacks to the shared cloud infrastructure and its perimeter, but they will not look for or stop attacks against the instances and applications that customers are using. At the host layer, customers are responsible for access management, patch management configuration hardening, security monitoring, and log analysis. Additionally, the application security components are solely the customer’s responsibility.

While utilizing the cloud offloads some security responsibility to the provider, the customer still has significant cloud security responsibilities for the enterprise. These responsibilities can be segmented into the following areas and should include:

  1. Identity and Access Management (IAM)
    1. IAM solutions that can meet current and anticipated future access control requirements
    2. Role-based access controls based on a principle of least privilege
  2. Data Security
    1. Ensure data is encrypted in transit to the cloud and at rest within the cloud as necessary based on regulatory need
    2. Consider using your own enterprise encryption keys to protect data from disclosure to the CSP
  3. Regulatory
    1. Select a CSP that can support your regulatory and audit requirements
    2. Develop a vendor management program to monitor and measure CSP compliance to contract requirements
  4. Vulnerability Management
    1. Revise vulnerability assessment policies and standards based on risks to cloud infrastructure
    2. Develop security assessments and standards for vendor management
    3. Conduct penetration assessments on cloud-based applications annually
  5. Secure Application Development
    1. Implement secure software development lifecycle policies and standards based on common frameworks
    2. Implement release and change management policies
  6. Resiliency and Availability
    1. Define enterprise policies and standards for data replication and backup
    2. Define and test business continuity and recovery plans with all CSPs

Despite the transformation from an on-premise environment to a cloud-based environment, many of the same basic enterprise security risks remain. By implementing some of these basic controls, organizations can ensure they take command of their shared responsibilities in the cloud.

Sean Cyriaque


Sean Cyriaque — Senior Consultant, Cyber Risk Advisory, Coalfire

Recent Posts

Post Topics



Accounting Agency AICPA Assessment assessments ASV audit AWS AWS Certified Cloud Practitioner AWS Certs AWS Summit bitcoin Black Hat Black Hat 2017 blockchain Blueborne Breach BSides BSidesLV Burp BYOD California Consumer Privacy Act careers CCPA Chertoff CISO cloud CMMC CoalfireOne Compliance Covid-19 credit cards C-Store Culture Cyber cyber attacks Cyber Engineering cyber incident Cyber Risk cyber threats cyberchrime cyberinsurance cybersecurity danger Dangers Data DDoS DevOps DevSecOps DFARS DFARS 7012 diacap diarmf Digital Forensics DoD DRG DSS e-banking Education encryption engineering ePHI Equifax Europe EU-US Privacy Shield federal FedRAMP financial services FISMA Foglight forensics Gartner Report GDPR Google Cloud NEXT '18 government GRC hack hacker hacking Halloween Health Healthcare heartbleed Higher Education HIMSS HIPAA HITECH HITRUST HITRUST CSF Horror Incident Response interview IoT ISO IT JAB JSON keylogging Kubernetes Vulnerability labs LAN law firms leadership legal legislation merchant mobile NESA News NH-ISAC NIST NIST 800-171 NIST SP 800-171 NotPetya NRF NYCCR O365 OCR of P2PE PA DSS PA-DSS password passwords Payments PCI PCI DSS penetration Penetration Testing pentesting Petya/NotPetya PHI Phishing Phising policy POODLE PowerShell Presidential Executive Order Privacy program Ransomware Retail Risk RSA RSA 2019 Safe Harbor Scanning Scans scary security security. SOC SOC 2 social social engineering Spectre Splunk Spooky Spraying Attack SSAE State Stories Story test Testing theft Virtualization Visa vulnerability Vulnerability management web Wifi women XSS