Top 10 Practices for Securing Cloud Workloads

by Akamai on August 5, 2019

Public cloud is one of the biggest challenges in every IT organization. While driving greater scalability, performance, and access for a competitive edge, it also introduces new security risks. More than just hosted data center infrastructure, public cloud offers the promise of agility, efficiency, and quality, inspiring new approaches to applications altogether―the intent of digital transformation initiatives. But as security vulnerabilities are exposed in breach after breach, this promise becomes more difficult to realize.

Security experts espouse following best practices in cloud architecture design, such as a web application firewall (WAF)―something that sounds fundamental, but is seldom followed consistently. According to the 2018 Magic Quadrant for Web Application Firewalls, Gartner notes that “by 2023, more than 30% of public-facing web applications will be protected by cloud web application and API protection (WAAP) services that combine distributed denial of service (DDoS) protection, bot mitigation, API protection and WAFs. This is an increase from fewer than 10% today.” Though cloud protection is growing, it’s still far from comprehensive.

When it comes to best practices in security, each public cloud provider is unique, but all share similar characteristics. Let’s look at the leading cloud provider, Amazon Web Services (AWS) to examine the security challenges of public cloud deployments and 10 proven practices to mitigate them.

Read the manual. Every cloud provider has a set of recommendations for security infrastructure design and application configuration in the cloud. This overview covers security topics such as identifying, categorizing, and protecting your assets, managing access to resources using accounts, and creating users and groups, as well as suggesting ways to secure your data, operating systems, applications, and overall infrastructure in the cloud. For AWS, you can download AWS Security Best Practices as a primer, manage security checks and alerts at the AWS Security HUB, and follow updates by subscribing to the AWS security blog.
Understand the shared responsibility model. AWS and other cloud providers make it clear that security is a shared responsibility. The cloud provider is responsible for ensuring the platform is always on, available, up-to-date, and so on, however, the customer is responsible for protecting applications and data on the public cloud. In most data breaches, the fault is on the customer―understand your responsibility.
Embrace the chaos. Deviation from your baseline―caused by internal errors, such as a misconfiguration, or external events, such as a DDoS attack―will happen. You need to identify weak points before they manifest to minimize damage. Increase your readiness by creating a security incident response runbook and establishing the governance, risk, and compliance models within which the environment operates. To do this, you must define roles and responsibilities, response mechanisms, and service level agreement (SLA) standards―and make sure partners are accountable for their parts.
Partner with the pros. Evaluate the security options: native public cloud security, DIY security, and point solutions all have their merits and flaws. Understand your internal limitations, and supplement where necessary. With the complexity, integrated systems, and tools required to even understand a diagnostic, every organization should budget professional services for architecture, implementation, configuration, tuning, and testing in the move to the cloud.
Don’t fall into the trap of volume discount or consumer service plans. Consider your needs today and in the future to design a request for proposal (RFP) with support plans that fit your runbook and SLA requirements. Also, get quotes for more advanced options, such as web application data center switchover or full tunneling and the managed security operations center (SOC).
If you are pursuing a hybrid deployment model, understand what can be secured with cloud provider solutions, and what requires a platform-agnostic solution or additional security deployments to ensure consistent controls across your architecture. For example, the shared responsibility model has spawned a growing number of tools to help businesses secure the AWS environment. But even a pristine deployment cannot secure elements of your architecture that are hosted in your own data center or another cloud provider–do you have the resources to support or build these solutions?
When selecting a security partner, consider which responsibilities are best offloaded and look for a vendor with relevant experiences and customers. The right security partner can help you reduce risk and be more agile–and make sure professional services and managed security services, such as a managed SOC, are options for future needs or special projects. To support your evaluation, treat analyst reports as customer reviews.
Be a business enabler. Security should enable the business, not stifle innovation. Public cloud allows DevOps to shift left–enabling teams to spin up infrastructure more quickly, accelerate testing, and leverage new technologies such as containers and microservices―for continuous testing and deployment, essential practices for incorporating security earlier in the development cycle. A secure software development life cycle (SDLC) implementation doesn’t provide full vulnerability coverage. Organizations still struggle to develop a comprehensive application security strategy. Deploying a WAF as a primary web application runtime protection provides a safety net.
Accept temporary is the new permanent. Shortcuts in the development phase don’t always get updated when pushed live. For example, new AWS S3 bucket default settings do not allow public access, but you can modify these settings by using policies and object-level permissions, or take the easy way that provides public access in a few clicks with the excuse that the virtual public cloud (VPC) will protect you―leading later on to new vulnerabilities. Wrong temporary practices will either remain permanent or become the new standard.
Trust no one. Implementing a Zero Trust approach means that all requests should be verified, both internal and external. The goal is to ensure all the security monitoring and services are set up correctly and any violation is reported immediately to the right person. Even after you’ve put the appropriate controls in place, things like server-side request forgery (SSRF) can occur if your processes do not include a way to validate containers or code that your teams download from public repositories. In the case of SSRF, a robust protection method is to whitelist the DNS name or IP address that your application needs to access. If you must rely on a blacklist, be sure to validate user input properly.
When it comes to AWS, carefully examine and monitor the following services:
● CloudTrail and CloudWatch, which covers infrastructure calls as well as user and API call activity into your system.
● Guard Duty, which covers host communications and threat intelligence as well as network communications through VPC Flow log monitoring.
● AWS Inspector, which covers host vulnerabilities and CIS benchmarks.
● AWS Config and Config Rules for asset inventory and configuration compliance.
● AWS Security Hub, or another solution like Splunk, for aggregating third-party monitoring.
Also be aware of shadow IT introducing security holes. It is imperative to know who in your organization is using the public cloud to ensure the environment is configured correctly and monitored completely.
Guard the front door. A highly effective security measure is to control and monitor inbound (ingress) and outbound (egress) traffic in order to distinguish between legitimate and illegitimate requests. If internal servers are compromised, they can pose a threat to a larger network of resources–especially when attempting to steal sensitive data or communicate with command and control systems.
For example, filtering outbound traffic by an expected list of domain names is an efficient way to secure egress traffic from a VPC because the hostnames of these services are typically known at deployment, the list of hosts that need to be accessed by an application is small and does not change often, and hostnames rarely change. Filtering traffic by a list of domain names also enables organizations to centralize the maintenance and deployment of rules.
Once you establish that inbound traffic is coming from expected locations, use a WAF to filter out threats that could damage your site functionality or compromise data, and apply it to all HTTP requests.
A common blind spot is API traffic―organizations simply do not have visibility into what has been exposed, to whom, and what is happening with that data. An API gateway provides a unified entry point for all API consumers and governs traffic via a WAF.
Plan for tomorrow. Find out how to enable developers to do what they need as fast as they need it. Provide a new perspective that demonstrates how security can keep up with the pace of development from day one. Introduce DevSecOps to the security team so it becomes part of the deployment process.
A good example is a multi-cloud strategy. While today your organization may not practice or plan for it, you’ll be more agile using proprietary features from a single infrastructure provider that are also available on other platforms―especially in container management.
Test your security posture. Just installing and integrating a security solution doesn’t mean you’re done. Periodic exercises that test your organization’s security preparedness are necessary. Exercises should check for vulnerabilities in your IT systems and business processes, as well as recommend steps to lower the risk of future attacks. Security assessments are also useful for keeping your systems and policies current to ensure compliance as threats continue to evolve.
You can conduct security assessments internally or partner with a third party, a valuable investment if a preliminary internal assessment reveals security gaps, or if you don’t have a dedicated team of IT professionals with expertise in this area. For more information on how to get started, read Gartner’s Actions for Internal Audit on Cybersecurity, Data Risks or AWS Security Audit Guidelines.

Use public cloud wisely

Sponsorships Available

Security breaches are extremely costly, and installing a security solution alone is not enough to stop them. A clear understanding of public cloud service models and known security issues as well as aligning with a cybersecurity and compliance standard to provide a framework that incorporates well-defined best practices will protect your organization in the public cloud.

There’s a lot of specialized knowledge that comes with operating a public cloud service. Developing a highly trained security team and partnering with the right vendors are essential steps towards creating a strong security posture. Remember, start with security fundamentals to effectively crawl, walk, and then run with a successful cloud deployment.