Post PetyaWrap - How to Prevent Ransomware Attacks

Now that most have recovered from the hangover of the PetyaWrap ransomware attacks, it is Monday morning quarterback time. PetyaWrap was not a new ransomware with a zero day vulnerability, but rather a combination of three common vectors of attack that companies do not always take seriously. But securing your assets go beyond just your servers (aka EC2 instances); you also need to ensure your AWS Account is equally as secure.

Local Admin Rights & IAM
Let's be honest, most of us at some point in time have elevated our daily login accounts with the full powers of an Administrator. These powers may have even been extended to certain groups of individuals or departments and while this is easy and low maintenance for the Systems and/or Network Administrators, this type of configuration is wrought with danger. And just as you should never be utilizing an account with elevated account privileges to perform your daily tasks, so too should you never grant your applications the same level of power. In both cases, always grant the least privileges required to get the job done. And never use shared credentials.

When talking about your AWS Account, everyone should have their own unique IAM user account. You can then create an audit trail of who did what with Cloud Trail. You should further utilize IAM Roles which are not associated with a specific user or group. Instead, trusted entities assume roles, such as IAM users, applications, or AWS services such as EC2.

Network Segmentation & VPCs
Network segmentation in computer networking is the act or profession of splitting a computer network into subnetworks, each being a network segment. Advantages of such splitting are primarily for boosting performance and improving security. This, of course, does add complexity to your network and application. However, the time you spend in building out your network correctly now will pay dividends over having to rebuild your network after it has been compromised - not to mention dealing with other fallouts from the compromise.

Again, AWS makes this incredibly easy through the use of VPCs or Virtual Private Clouds. By using unique VPCs for each project, function, or even environments, you create network segmentation to ensure that the blast radius of any issue is minimized. For a more in-depth discussion, take a look at our earlier blog entry titled AWS Best Practices: 3-Tier Infrastructure. Coupled with CloudFormation to automate the creation of these VPCs and you have a quick and repeatable solution. Once you have written your initial configuration template, you can iterate and stack your CloudFormations.

Inadequate Patching & Managed Services
Applying software patches is a necessary evil that all companies must perform. There are many methods to ensure the patching gets done, but wouldn't you like to ensure that not only is patching being performed in a timely manner but also be able to quickly produce documentation for an auditor? Fortunately, AWS has multiple services that now take care of these once tedious tasks. One of those services is EC2 Systems Manager, a management service that helps you automatically collect software inventory, apply OS patches, create system images, and more.

But what happens when you have legacy in-house applications that require a certain version of a software or Operating System distribution, which may no longer be supported? These applications should be carefully reviewed and rewritten as part of the migration into AWS. Why? The AWS cloud is designed in nature to be ephemeral. If an EC2 instance is registering a fault, simply terminate that instance and launch a replacement instance. No longer are we talking about hours of downtime. The previous tasks of troubleshooting, waiting for replacement parts, and data recovery that we all once knew are gone.

With proper solutions architecting and a sound migration strategy, Status10 can help you achieve your AWS cloud goals.

Free Checklist for AWS Migration Safe Data