Security is a stifling fear for organizations considering public clouds, one frequently stoked by IT vendors with vested interests in selling enterprise IT hardware and software using security as a catalyst for overall FUD about cloud services. The fears and misconceptions about cloud security are rooted in unfamiliarity and conjecture. A survey of IT pros with actual cloud experience found the level of security incidents relative to on-premise results quite similar.
Public Cloud Versus On-Premise Security
When asked to compare public cloud versus on-premise security, the difference between those saying the risks are significantly lower versus higher is a mere one percent. Cloud infrastructure is probably more secure than typical enterprise data centers, but cloud users can easily create application vulnerabilities if they don’t understand the available security services and adapt existing processes to the cloud environment.
Whatever the cause, the data shows that cloud security remains an issue with IT executives. For example, a survey of security professionals found that almost half are very concerned about public cloud security, while a 2014 KPMG survey of global business executives found that security and data privacy are the most important capabilities when evaluating a cloud service and that the most significant cloud implementation challenges center on the risks of data loss, privacy intrusions and intellectual property theft.
Unfortunately, such surveys are fraught with problems since they ask for subjective, comparative evaluation of two very different security models, one (on-premise) that IT pros have years of experience implementing, managing and refining, and the other (public cloud) that is relatively new to enterprise IT, particularly as a production platform, and thus often not well implemented. The ‘problem’ with public cloud security isn’t that it’s worse, no, it’s arguably better. Rather, the problem is that cloud security is different. Public cloud services necessarily use an unfamiliar and more granular security design that accommodates multi-tenant services with many users, from various organizations, mixing and matching services tailored to each one’s specific needs.
Protecting and monitoring networks, applications and data is simple if you know and use the right tools
AWS Security Model
AWS designs cloud security using a shared security model that bisects security responsibilities, processes and technical implementation between the service provider, i.e. AWS, and customer, namely enterprise IT. In the cloud, IT relinquishes control over low-level infrastructure like data center networks, compute, storage and database implementation and infrastructure management to the cloud provider. The customer, i.e. enterprise IT, has control over abstracted services provided by AWS along with the operating systems, virtual networks, storage containers (object buckets, block stores), applications, data and transactions built upon those services, along with the user and administrator access to those services.
The first step to cloud security is mentally relinquishing control: internalizing the fact that AWS (or your IaaS of choice) owns low-level infrastructure and is responsible for securing it, and given their scale and resources is most likely doing better than most enterprise IT organizations. Next, AWS users must understand the various security control points they do have. AWS breaks these down into five categories:
- Network security: virtual firewalls, network link encryption and VPNs used to build a virtual private cloud (VPC).
- Inventory and configuration: comprehensive view of AWS resources under use, a catalog of standard configuration templates and machine images (AMIs) and tools for workload deployment and decommissioning.
- Data encryption: security for stored objects and databases and associated encryption key management.
- Access control: user identity management (IAM), groups and policies for service access and authentication options including multifactor using one-time passwords.
- Monitoring and logging: tools like CloudWatch and CloudTrail for tracking service access and use, with ability to aggregate data from all available services into a single pool that feeds comprehensive usage reports, facilitates post-incident forensic analysis and provides real-time application performance alerts (SNS).
Using CloudTrail Activity Logs
Organizations should apply existing IT security policies in each area by focusing first on the objectives, the policy goals and requirements, then mapping these to the available AWS services to create control points in the cloud. For example, comprehensive records of user access and service usage are critical to ensuring policy adherence, identifying security gaps and performing post hoc incident analysis. CloudTrail fills this need acting as something of a stenographer recording all AWS API calls, for every major service, whether accessed programmatically or via the CLI, along with use of the management console. CloudTrail records are written in JSON format to facilitate extraction, filtering and post-processing, including third party log analysis tools like Alert Logic, Loggly and Splunk.
CloudTrail so thoroughly monitors AWS usage that it not only logs changes to other services, but to itself. It records access to logs themselves and can trigger alerts when logs are created or don’t follow established configuration guidelines. For security pros, CloudTrail data is invaluable when used to build reports about abnormal user or application behavior and to detail activity around the time of a particular suspicious event.
The key to AWS security is understanding the division of responsibilities, the cloud control points and available tools. Mastering these can allow cloud-savvy organizations to build security processes that exceed those in many on-site data centers.
-2nd Watch Blog by Kurt Marko
