The great migration to the cloud is underway. As part of it, Amazon Web Services (AWS) has become an incredibly popular destination for organizations making the move to cloud computing. As new workloads are deployed on AWS and IT organizations are freed from having to purchase, deploy, operate, and maintain hardware, network, and other infrastructure components it is time to think about another critical aspect of cloud deployments — security.

With cloud providers now owning so much of the infrastructure, it is inevitable for IT organizations to get confused about who is responsible for securing what, and how to go after security in a methodical, organized fashion. AWS has been forthcoming in explaining its shared responsibility model for security and provides security services to help customers. However, organizations must be willing to put effort into acquiring new skills in order to deploy these services, and validate that their configuration of AWS resources and services follows security best practices. In addition, customers are clearly responsible for the security of what they deploy on AWS.

Many organizations struggle on how to best handle security for AWS. Some customers operate with the assumption that AWS is responsible for securing the entirety of its deployments. Others are proactively taking ownership of the security of the full stack and deploying security solutions that overlap with AWS services. There is tremendous opportunity for the education, clarification, and sharing of best practices.

There are a few principles that are common to many organizations that have been born in the cloud and run their services entirely on AWS, they are frequently referred to as cloud-native companies. This can make it more difficult for these companies to know which security responsibilities are outsourced to AWS.

As stated by AWS, customers are responsible for the security of what they deploy in the cloud — both data and workloads, whether these are deployed as virtual machines (VMs) or containers.

It’s also the customer’s responsibility to configure the various resources and services provided by AWS correctly so that security best practices and required regulations are met. This includes:

• Checking the configuration of your cloud for security best practices. A great place to start is by selecting an AWS-certified benchmark program that provides you with a comprehensive set of controls and configuration guidelines.
• Creating control who has access to what. You need to define and maintain security groups to accurately control who has access the various resources including access to S3 buckets.
• Protection of the workloads. From micro-services to applications deployed in the AWS cloud, customers are responsible for the deployment of adequate protection for the applications and data they operate in the cloud.

With these responsibilities in mind, this brings us to the three commandments of cloud security:

You can’t secure what you can’t see, and you need adequate visibility into your cloud deployment to secure it. Most conventional security tools have become blind in the cloud, and because everything in the cloud is part of a microservices architecture, logging that data is key. To regain the necessary visibility, make sure to log and analyze all API calls using a tool like AWS CloudTrail to log, monitor, and retain account activity across your AWS infrastructure. With AWS increasing access to core functions within their API ecosystem, it’s important to activate these types of services within your account to improve authentication and access visibility.

Embrace automation where continuous check is a must — including cloud compliance and the validation of your configuration for security. In highly dynamic clouds, workloads are transient, resources are reallocated dynamically, and configuration is expected to change accordingly and quite frequently. The scale of the cloud and the speed of change are such that it is no longer viable to manually validate every aspect of your configuration. Automation is a must.

Protect your workloads. The ultimate threat is if an unauthorized user gets privileged access to your portion of the shared cloud infrastructure. Your hosts must be secured, so using incident detection at the host layer (also called “host-based IDS”) will improve your security posture.

In any computing infrastructure, incidents happen all the time. They can range from genuine user mistakes, overlooked settings, misunderstandings between teams about who needs access to what, development environments evolving to staging and production with the same settings that developers need to be productive, to malicious incidents initiated by insiders or cybercriminals. In the cloud, investigating these incidents is as vital as in a traditional data center. Being disciplined about finding and fixing misconfigurations will make for a stronger security posture over time and make it a lot harder for attacks to succeed.