Security and Compliance is a shared responsibility between AWS and the customer. This shared model can help relieve customer’s operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.. – AWS Shared Responsibility Model
Follow the Money
Want to know what is really going on? Follow the money. Who has the resources to invest in security R&D and at what scale? Like a previous post on how scale determines public cloud viability, good security is mostly a question of resources. The security community has spent years laying out the people and processes to achieve responsible security. But most enterprises never have the all resources necessary to implement and maintain those practices.
The table below from PricewaterhouseCoopers shows the Top 20 R&D Spenders 2005-2016. Looking over the most recent years, the top three Public Cloud Vendors – Amazon, Microsoft, and Google (Alphabet is now the parent company), dominate the rankings. Last year Amazon, Microsoft and Google collectively spent $31.5 billion building out infrastructure. Amazon alone spent more than $17 billion on research and development over the 12-month period ended in March. Microsoft is investing $1 billion a year in cybersecurity R&D alone and “that spending has to go up”. For comparison, Palo Alto’s R&D expenditures last year were $284 million and VMware’s were $1.1 billion.
Those financial resources fund more than just infrastructure. The top public cloud providers are quite successful at recruiting and retaining talent with innovative projects and competitive salaries. And time spent working at companies with that level of name recognition are great for resumes. Based on personal observation, there is even seems to be a “brain drain” from the traditional hardware and software vendors to public cloud providers and companies that support them.
Amazon Web Services is the market leader and realized early on that security was key to public cloud adoption. The compliance resources that AWS offers are far greater than any enterprise or traditional security vendor is able to provide (see Follow the Money). AWS has been in the game the longest and is the most mature of the public cloud vendors, making them an easy choice to illustrate how security works in the cloud.
The key to understanding security in the cloud is what AWS calls the Shared Responsibility Model (see diagram below). AWS is responsible for the security of the cloud and the customer for the security of what they build in that cloud. Like all public cloud vendors, the level of automation and engineering provides a far greater level of security controls than anything individual enterprises could deploy. Combined with good customer security practices this results in better security than is achievable in the enterprise data center.
That said, all the usual caveats still apply. Verify for yourself that AWS security certifications are current and meet your requirements. Third-party solution providers claiming they are secure because they use AWS says nothing about the security of their application. Compliance requirements and applicable regulations may limit what AWS services you can use. Some Platform as a Service (PaaS) offerings are only accessible via Internet endpoints or lack the options of Infrastructure as a Service (IaaS) to layer on additional controls.
One example of these security practices is how AWS support does not have access to even the hypervisor, let alone the host OS. When access to the hypervisor is needed to troubleshoot customer issues, a temporary, dedicated bastion host is created for the engineer for a brief time and then decommissioned. How many enterprises have multiple administrators with the keys to the kingdom? And then install various controls and security packages trying to mitigate that risk?
Another example of how security in the public cloud can do things not possible within the corporate data center or traditional hosting provider is the Managed DDoS Protection service called AWS Shield. Last year’s DDoS attacks like Mirai leveraged armies of compromised Internet of Things (IoT) to generate record level attacks. For an monthly fee of $3,000 AWS Shield Advanced absorbs the cost of scaling up to handle DDoS attacks with the millions of servers at its disposable.
For more information, check out the AWS Security Blog for announcements of new security features and enhancements:
- Secure Network Connections: An evaluation of the US Trusted Internet Connections program
- Amazon Macie
- AWS Adds 12 More Services to Its PCI DSS Compliance Program
- Updated AWS SOC Reports Include Three New Regions and Three Additional Services
- New Whitepaper: Aligning to the NIST Cybersecurity Framework in the AWS Cloud
- The Four HIPAA Eligible Services Recently Added to the AWS Business Associate Agreement
- AWS EU (London) Region Achieves Public Services Network (PSN) Assurance
Cloud Native Architecture
Traditional data center appliances, be they hardware or software, for networking or security, don’t fit well in the cloud. Fundamental infrastructure constructs like broadcast domains, DNS resolution, or full Layer 2 networking are missing or strangely incomplete. There are good reasons like security, scalability, and multi-tenancy that drive the design decisions to leave out these capabilities. But the legacy methods of clustering, failover, or routing traffic used by these appliances are just not possible.
Cloud native infrastructure and applications are still able to cluster, failover, and route traffic across global infrastructure but use different constructs based on containers management systems (aka Kubernetes and its extensions), Google’s gRPC, or the Gossip protocol. The challenge for the legacy security and infrastructure vendors is to reimagine their product offerings with these new constructs.
Using people to fight cyber attacks is like bringing a knife to a gunfight. Best practice in the cloud is to take DevOps approach to security (aka DevSecOps) and automate all security controls and mitigations using serverless constructs like AWS Lambda. Another common approach is immutable infrastructure that does not require patching in place. Instead new images are created with the software updates are redeployed and old images are discarded a la “Pets vs. Cattle”.
The greatest benefit of these new approaches is security velocity. If applications and operating systems can replaced in real-time without disruption, enterprises can avoid the trap that led to Equifax breach. The two-month old security patch was not applied expeditiously because it required recompiling applications. A continuous integration and delivery (CI/CD) pipeline with techniques like Blue/Green deployment and Canary releases makes it practical to deploy security updates with minimal lag time.