Securing your AWS Cloud Environment from Ransomware

Ransomware is a cyberattack in which a malefactor gains unauthorized access to a system with the goal of locking a victim’s computer and usually encrypting the data on it. In so doing, the cyber criminal holds the computer (and its content) for ‘ransom.’ This can have major disruptive consequences for an organization. Consider, for example, what would happen if a hospital was unable to access patient records on its devices. How could healthcare workers provide potentially life-saving care to patients without knowing their vitals, their history, etc?

As the name suggests, the purpose of a ransomware attack is to demand a ransom - or payout - from the victim for access to its computers and data. Because of the high value of data, many organizations (or their insurers) are willing to pay for it - even if this is generally not advisable, since there is in fact no guarantee that the computers will be restored, and since there is always the possibility of extortion down the line, not to mention that paying ransoms only encourages bad actors to continue to invest in ransomware. Of course, organizations who do not want to pay the ransom still face costs. This is because in a ransomware attack, the victim loses access to its compromised machines, meaning that these will need to be replaced with new computers if the payout is refused.

The threat from ransomware is growing every day. Europol, the EU’s law enforcement agency, recently called ransomware the “most widespread and financially damaging form of cyberattack.” CyberSecurity Ventures estimates that in 2002 a ransomware attack occurs every 11 seconds, imposing total costs of about $20 billion dollars. The threat of ransomware is particularly acute in the healthcare industry, because of the high value of protected health information (PHI).

The point is that organizations need to take the threat of ransomware seriously. While there are general best practices applicable to all kinds of network architectures - most notably, the NIST Cybersecurity Framework (CSF) - more specific actionable steps depend on the particulars of an organization’s network. This blog post focuses on how an organization can secure its resources against ransomware if its network makes use of the AWS cloud environment. AWS has several resources on this topic, including a white paper detailing how to align an AWS cloud environment to the NIST CSF, as well as a presentation on protecting AWS resources against ransomware. More resources on ransomware risk management on AWS can be found here.

The Shared Responsibility Model​

But first a general comment about security on the public cloud.

Organizations that use public cloud infrastructure (e.g., AWS) share the responsibility of securing their resources with their cloud provider. At a high level, AWS is responsible for the security of the cloud, whereas the customer is responsible for securing what it does in the cloud. This is to say, in other words, that AWS is responsible for securing all of the infrastructural components (hardware, software, networking, facilities) that collectively make cloud services possible. Generally speaking, this leaves the customer responsible for securing its data and application workflows, as well as access to it. More on the shared responsibility model can be found here.

But precisely how much responsibility an organization will have to take on depends on the services it uses in AWS. The AWS catalogue ranges from Infrastructure as a Service (IaaS) to Platform as a Service (PaaS) to Software as a Service (SaaS). As we move from IaaS to SaaS, basically, how configurable the service is decreases. This means the customer has less flexibility with what they can do with the service, but also less of a security overhead. So there is something of a tradeoff. When it comes to compute, for example, an organization could choose to use EC2 instances - which it can use for practically any legal purpose, but which require more security management - or it can choose to use Lambda, which has limited use cases, but which is fully managed by AWS.

You can view the security documentation for every AWS service here.

Let’s now turn our attention to securing applications and workloads on AWS. We will look at what kinds of services AWS customers can take advantage of before an attack occurs, during an attack, and after an attack. However, most of our analysis will focus on preventive strategies.

Before an Attack Occurs​

Of course, the main objective of security is to prevent an attack from occurring in the first place! The degree to which this is possible (and in your control) depends on the steps you take to ‘harden’ your network. There is a lot to say here, but let’s take a look at four actions that AWS highlights: network segmentation, managing users, data backup and recovery, and vulnerability management.

Network Segmentation​

All of an organization’s resources are contained within its network. To segment a network is to divide a network into sub-components - that is, sub-networks or subnets - where each subnet is a mini network, with a subset of resources. Dividing a network up like this has a number of benefits, including improving performance to users by easing congestion. But for our purposes, careful network segmentation can significantly improve the security to an organization. The basic idea is that by isolating an organization’s resources by placing them in different subnets, we can prevent bad actors - who may or may not have a legitimate reason for accessing resources in one subnet - from moving laterally in the network, that is, to other subnets (and their resources). For example, an organization could place a web application to handle customer requests in one subnet - that is, a public subnet - and it could place its database in another subnet - a private subnet. In so doing, an organizations ‘walls in’ its valuable data, making it much harder to access than if it was in the same space that the public traverses.

The key question is how to control the movement of traffic within a network?

Let’s first note that subnets cannot exist without being associated with route tables. As the name suggests, a route table consists of routes, and routes control how traffic enters, exits, and moves within the related subnet. For example, if you want resources within a subnet to be able to access resources on the internet (e.g., to check for updates or patches to software), then a route must exist to the internet gateway (the so-called default route). Routing should be carefully architected. In line with the principle of least privilege, users who are allowed into a subnet should only have access to resources they absolutely need.

When it comes to securing traffic in and out of subnets, we use access control lists (ACLs), which are firewalls that operate at the subnet level. An ACL consists of rules specifying what kinds of inbound and outbound traffic to the subnet is allowed or denied.

If it is not obvious how route tables and ACLs work together, an analogy is helpful. Imagine your subnet is a house, with many rooms and family members, not to mention guests of various kinds (relatives, friends, plumber, etc). A routing table specifies how individuals in the house can enter and exit it, and especially how they are allowed to move around in the house. Whereas an ACL specifies which kinds of people are even allowed to enter the house. If a user is denied access based on an ACL, then the user cannot move anywhere within the subnet. Whereas if a user is allowed access based on an ACL, then the user’s options of moving within the subnet are specified by the route table. More information about ACLs can be accessed here.

There is a final access control feature to make use of on AWS. It is security groups. Security groups are essentially firewalls that determine what network traffic can go in and out of a compute instance. To be more precise, security groups consist of in-bound and out-bound rules that control what IP addresses can send traffic to an instance, and what IP addresses an instance can send traffic to. More information about security groups can be found here.

By carefully considering how to configure route tables, ACLs, and security groups in accordance with the principle of least privilege, security architects can segment networks on AWS so as to significantly circumscribe the possibility of privilege escalation by a bad actor.

Managing Users​

The North Star of security architecture is the principle of least privilege. It informs how we segment networks, as discussed above. And it informs what kind of access users in an organization should have to resources. Users - whether they are internal or external users - should only have access to what they absolutely need, when they absolutely need it. In AWS, the way to program access control is by configuring Identity and Access Management (IAM) policies. IAM policies stipulate under what conditions systems and data on AWS are available to individual users, or groups of users. Careful design of IAM policies can significantly harden your network, making it less vulnerable to ransomware attacks. More information about IAM policies can be found here, including recommended best practices.

Let’s spend a moment to clarify something. Someone might ask what is the necessity of segmenting networks and managing users. If we effectively manage routing within a network - by carefully designing routing tables, ACLs, security groups - then why do we also need to specify IAM policies? Isn’t there something redundant about this? The answer is that there is some redundancy here, but that is ok. In fact, it is advisable. We are applying a defense-in-depth strategy. This is the idea that we should design multiple layers of security controls so that if one defensive measure fails for whatever reason, it does not necessarily imply a breach, since other controls may contain the bad actor. But it is also the case that user access is a different kind of attack surface than networking. Consider what might happen if a bad actor somehow learned the login information of an internal user. This might obviate network segmentation since an internal user would have access to private resources. In the absence of strict IAM policies, the malefactor might very well be able to deploy ransomware to the organization.

Data Backup and Recovery​

Recall that the objective of ransomware is to lock users out of their machines, and typically to encrypt data stores. It therefore makes eminently good sense to advise users to back up their data and to be able to spin up new machines at a moments notice. That way if an organization is hit by ransomware, they can limit the impact this has on their operations.

AWS has a number of services that store data. This includes the obvious storage services like S3, EBS, and EFS, but also database services like RDS and DynamoDB, and compute services like EC2. Users can manually architect backup strategies for services like this, or they can take advantage of AWS backup, which is a fully managed service that centralizes and automates data protection across a number of AWS services, the full list of which can be found here. AWS Backup works by configuring a backup policy across your AWS services, where the user specifies backup frequency and backup retention period. Note that while it is advisable to backup your data on AWS, it is also advisable to have multiple copies of backups, some of which should be isolated from your AWS environment, and offline.

Having data backups significantly helps mitigate the harm caused by ransomware. But this is only half the story. It is also critical for business continuity purposes to be able to get machines back online as soon as possible. After all, what is the utility of having backed up data if there are no machines to make use of it?

To this end, AWS users can take advantage of AWS Application Migration Service, which migrates applications from any source infrastructure, on-premise or in the cloud. For example, the service can be used to automatically migrate an EC2 workload across AWS regions or availability zones to strengthen an organization’s resiliency in the face of ransomware attacks.

Vulnerability Management​

It is a fact of life that operating systems and software will have weaknesses, and weaknesses cause systems to be vulnerable to exploitation. For this reason, companies are regularly releasing patches to harden their products. Users are well advised to quickly identify and patch any vulnerable products that they are using. AWS offers a service for the purpose of vulnerability management. With Amazon Inspector, users can scan their workloads for vulnerabilities, as well as unintended network exposure. The service also provides users with a way to prioritize vulnerabilities, so that they can address their most pressing needs first.

More generally, AWS has an end-to-end management solution for workloads, known as AWS Systems Manager, which has the overall goal of improving visibility over operations. For our purposes, one of its key features is patch management.

During an Attack​

Attacks happen. This being said, the goal of an organization should be to detect an attack as soon as possible, so as to more quickly contain, eradicate, and recover from the attack. In addition, organizations should aim to automate their responses as much as possible.

To this end, AWS users can take advantage of Amazon GuardDuty, which is an anomaly-based intrusion detection system. Services like this work by establishing a baseline of normal behavior using machine intelligence, threat intelligence, etc., and then flag deviations from the baseline, or anomalies, as potential threats. In addition, GuardDuty gives users the ability to initiate automated responses to threats.

After an Attack​

After an attack, the main objective is to understand the root cause of an attack, so as to learn how to prevent a similar kind of attack from occurring in the future. With respect to AWS, users can take advantage of Amazon Detective. This service makes it easy to analyze and visualize security data so as to investigate potential security issues.

Conclusion​

The scale and flexibility of public cloud services like AWS make them extremely attractive to organizations. It is important to keep in mind that while AWS assumes some responsibility for security, users also have significant responsibility when it comes to securing their data and workflow on the public cloud. While AWS offers a number of services to make this security burden more manageable for users, it is still a considerable challenge. If you are interested in building a more secure network on the cloud, schedule some time to talk with one of our experts.