Protecting Your AWS Environment from Ransomware- AWS Online Tech Talks

Key Takeaways

foreign [Music] folks thanks for joining this webinar today we are excited to announce the release of an updated ebook which is protecting your AWS environment from ransomware in today's session we are going to cover five of the top 10 best practices for rent smart protection and just a little introduction on myself my name is Megan O'Neill I'm a principal security specialist essay for worldwide commercial and I've been with AWS almost five years but I've been in cyber security for gosh over 20 years now so I'm excited to chat with you all today my focus over the past two years at AWS has been um working with customers on ransomware protection so I'm really excited to share this knowledge to a wider audience as opposed to one-on-one and so let's level set first and talk about what is ransomware so ransomware refers to a business model in a wide range of associated technologies that unauthorized users use to extort money from entities and there are several methods used today including taking advantage of unpatched software and successful installation of malware via phishing attacks as well as restricting access to data where the bad actor intends to receive a payment from the victim and this can be accomplished uh through many mechanisms could be accomplished through encryption of data through actor-controlled encryption keys or changing access control and locking the rightful owner from the system as well as revealing data or acts of exfiltration and this can result in large monetary fines from data privacy authorities or litigation from affected parties uh this is still very relevant today even though actually ransomware has been out since the late 80s our first um just little quick history lesson for you is the first uh time we saw ransomware was actually 1989 at the World Health organization's Aid conference where Dr Joseph pop provided a um a disc with ransomware malware and had a little pamphlet wrapped around that disc saying hey if you load this you will need to send 189 dollars to a PO Box in Panama to get your data back and get those encryption keys um and this actually did affect many people and he was later charged um so it's just you know it's funny that Randy Moore has been out since the late 80s and we're still dealing with it today and why is that right um there's there's many reasons um many organizations struggle with privileged access management um over my 20 years in cyber security you know I've seen it too it is a challenge as well as open trust models within large environments which allows malware to spread also security awareness is tough uh fishing fishing type scenarios are growing you know much better than what we initially saw when they first came around it can be really easy to trick folks and uh and that still tends to be a primary Vector right additionally ransomware and uh and other types of security events have been commoditized so they can be much um much easier to um to like weaponize any type of malware for a ransomware type event unfortunately and then of course you know especially in the security subsection of Technology we have a lot of overburdened technical staff and some of that is because we've still got a lot of manual processes within our security technology and and programs all right so what can you do to protect your AWS environment from ransomware well we have the top 10 best practices available for you in the ebook where we go into depth on each subsection of the 10. in this section however since we only have an hour I'm going to cover five um otherwise we'd be here for two hours at least but obviously I could talk about ransomware all day if you'd like so feel free to reach out to me my contact information will be at the end um and so of the five what we're going to touch on today is patch and hardening systems eliminating long-lived credentials implementing centralized blocking and monitoring Implement and testing your backup and restore processes and performing self-assessments so let's get right into it starting with section two which is patch and hardened systems and so what we're going to cover in this section is utilizing Amazon inspector to perform vulnerability management utilizing systems manager patch manager to pass your systems and apply OS and application carding and configuration all right so let's talk about Amazon inspector uh Amazon inspector has actually been around for for a while um but we've actually re-released it uh about two years ago I believe and its new version is actually um you know we got a lot of feedback from customers on what they wanted to see improvements from the inspector platform and we've completely revamped it and there's several features that I want to make sure you are all aware of and that you know it's a newer version um the old version of Inspector is still out there of course but the new version has a lot of benefits and can really help you understand your vulnerability management posture across your ec2 instances so a couple things that are different single click enablement with AWS organizations so you immediately have that integration if you have a large multi-count environment where you're using organizations it is integrated with the systems manager agent so we do not require a separate agent for install um and we cover most common operating systems and we consolidate findings across accounts and resources so you if you have a delegated administrator account for inspector you can see all of those findings across your accounts and resources um now if you have systems manager agent enabled and you've got the um instance profile that allows inspector to communicate and you've enabled inspector um inspector will actually automatically discover resources so as soon as it has those three key uh areas it'll start providing those findings and and tell you if there's vulnerabilities in your environment right away so there's no you know click to scan or anything like that it actually does continual vulnerability and network reachability scanning the other very cool thing about inspector is it provides contextualized risk scores So based on where it is from a network reachability perspective so say the instance is in a public subnet it's going to give a higher score based on if you've got a a higher score vulnerability or based on the score of that vulnerability it'll push up the score and provide that context as far as you know this machine is potentially you know easier to attack based on it being in a public subnet so these vulnerabilities are a higher risk um and those are just a couple things obviously I could spend a full hour just talking about inspector um we the one last thing before we move on is that it also integrates with security cap so um if you're a security Hub user which is our Cloud security posture management tool you can pull in and inspect the findings automatically into security Hub and use security Hub as that single pane of glass to view all of your security findings um all right and so uh let's talk about systems manager as we mentioned before with inspector integrates automatically the systems manager uses that same agent and a lot of customers that are heavy on the ec2 side use systems manager to do various management operations and security functions I refer to it as a Swiss army knife of you know ec2 management um and so for this talk I think we should focus on patch manager which actually allows you to pack it provides patching tools so that you can deploy operating system and software level patches you can do this automatically across a large group of instances you can use um you can set up groups based on tags across your Fleet of ec2 instances um and you can also um communicate and manage the systems over a hybrid connection so you can manage them on-prem if you want to have one tool to do patching um and how patch manager accomplishes this is it uses patched baselines so this includes rules for auto approving patches within days of their release as well as a list of approved and rejected patches so you can install patches on a regular basis by scheduling patching to run in a maintenance window that you specify um or you can install things uh ad hoc individually if if you want um so you have a lot of flexibility within this I played with it quite a bit um and it is an awesome tool I recommend starting with a custom patch Baseline and so you can do things like just Target security patches if you want um if you're you know if you've got a higher risk environment and you don't want to apply all Patches at once you can start with just like critical and high security patches and customize that all through the patch Baseline all right so we we have our vulnerability management we have patching what else do we need to do on our ec2 instances to keep them protected from ransomware well we want to look at endpoint detection and protection products EDR products we want to make sure we've got those enabled and running on our ec2 instances just from a best practices perspective and these tools do things like prevent malware from getting installed on the operating system right and so what I recommend is a lot of cost a lot of large Enterprise customers maybe have some of these tools but haven't looked at the configuration in several years so it's time to re-look at that configuration of your EDR software maybe that's like a crowdstrike falcon a Trend Micro deep security and make sure that it still has that configuration where it's in a prevent versus a detect mode and of course this is all based on you know your environment so you know you might have some files that you don't want scanned for example but you want to go back through and make sure that you're not um you don't have any like old Legacy configurations there anymore and that it's doing it's you know uh most amount of effort to protect your environment the other thing I want to highlight is harming the operating system and software on your ec2 instance so the center for Internet Security or CIS has a pre-hardened Ami available that you can run from the marketplace and it has benchmarks these hardening benchmarks you could actually go to the CIS page and look at their PDF uh all up you know hardening benchmarks and Harden it yourself but this can take a lot of time and a lot of testing so if you if you don't have time or you're working on that as a side project recommend maybe starting with the pre-hardened image available in the marketplace and of course test your systems to make sure that it doesn't cause any any issues but that is available and also if you want to roll your own you can do that as well all right let's get into eliminating long-lived credentials this is actually when we look at the ransomware events that happen across the environment today it's actually not very common for them to be the traditional Ransom events you know when you think about a Windows ec2 instance for example um while that can still occur uh usually from like a hybrid connection if there's not enough Network segmentation there and other you know security program level controls are maybe not as up-to-date as they need to be for example like patching um but if we look at the non-traditional ransomware events where maybe data is being targeted in an S3 bucket that's where it comes back to credentials so let's dig into that and talk about making sure that our developer access is enabled via Federation and that we're actually burning down or eliminating any long-lived IAM static access keys um because that tends to be how these things occur through an accidental exposure of access keys and then let's look at the IAM roles anywhere which is a a new function of um a new feature of IAM that came out at reinforce that I think is one of the most underrated features that the identity team has produced as of late so let's get into that make sure you guys understand what I am roles any words are all right so if we look at uh developer access into the environment what we recommend as a best practice is using Federation and what federation provides you is utilizing your existing identity provider like active directory and federating into using those credentials to access AWS and assuming a role and you can use identity Center and utilize single sign-on into the environment and map to the different AWS accounts that you have using permission sets and what this does is it provides temporary credentials on behalf of the user so you're not having to store static access keys on your developer Workstation and you're not having to manage static access Keys going forward and making sure that they get rotated and that they cannot get exposed right that's the biggest risk is exposure of static access keys so if we are using Federation what we want to make sure of is that we're restricting the creation of those static users and keys so if we're allowing for example developers to create their own IAM roles to manage and um and utilize AWS Services that's great but we want to make sure that they can't do things like create a static user and this is you know probably just a functionality that should be done within the administration group for your maybe your ccoe your Cloud Center of Excellence team um because it should probably be an exception and not the rule right and so I've seen environments where it's allowed and maybe developer or the user of the AWS environment just doesn't know that there's a risk associated with static users so they maybe default to that instead of defaulting to best practices which is creating IAM roles for your AWS resources all right so what do we do if we have static IEM users today well let's audit and track them and then look at re-architecting to eliminate use so what I recommend folks do is actually inventory the static users and keys across all of their accounts um and go back through and do a rotation apply multi-factor authentication if possible if it's a if it's non-interactive then obviously we can't apply MFA but the other thing that we need to do in all cases is actually go through the policies attached to those users and make sure that they are very specific so no wild cards as an action or a resource in those policies and maybe even pulling the capability to do any type of data removal away from that policy so only putting objects in S3 for example all right let's talk about re-architecting so that we can actually eliminate the usage of static access keys all right so I mentioned I am roles anywhere let's dig into this a little bit what is it well especially for our large Enterprise customers this is actually very um you know very possible and a really good idea for implementation and here's why because um in my experience a lot of Enterprises already have a pki environment set up public key infrastructure and so what I enrolls anywhere allows you to do is establish a trust with your pki and configure the roles your IAM roles and actually uh apply a helper to the operating system install like a helper tool that'll interact with IIM um directly and request those temporary credentials and so this is a much better option than creating and trying to manage static access keys and having those static credentials floating around your environment and so the most common use case for this is those hybrid workflows between you know on-premises Data Center and AWS so if you have a workload that runs outside of AWS that needs access to AWS resources and data you need to authenticate that call and authorize that call and so IAM roles anywhere is a really good option for that another use case is backing up on-prem systems to the cloud right you do not you no longer need to use aesthetic I am user for that this is IAM roles anywhere I can do that for you and and using AWS to burst capacity is another common use case for this so we know that static access keys are painful to manage and most non-interactive access can be secured with MFA but that makes you know your static access Keys just sitting there with the risk of accidentally getting leaked or the potential for misuse um so really want to push IAM rules anywhere and make sure that you guys are all aware of it you folks are all aware of it and that you know if you have a lot of static access keys in the environment or even if you it makes sense to eliminate the risk and actually you know start implementing something like IAM roles anywhere all right let's move on number six here is implementing centralized logging and monitoring so we'll talk about some security considerations for logging and monitoring and then we'll talk about some security services that you can utilize to get good visibility across your environment so locally monitoring considerations a couple things that a chat with customers about that may not be obvious um is that you know by default logging data events you might have heard when when speaking to a AWS solution architect the concept of control plane and data plane logging and when we talk about control plane we're talking about basic API interactive interaction and that's usually uh cloudtrail will monitor we'll log all that activity for us however when we look at the data plane we're talking about activity within the service itself so if we're talking about RDS for example we're talking about the records in the database actually getting logged and so as a security person it's really good to understand the difference between those and ensure that you've got a logging strategy and um documentation and best practices within your own environment helping developers understand what needs to be logged and why and maybe providing them things like cloud formation Snippets you know infrastructure as code Snippets so that um you know you just make it easier for them to get the logging right when they're using these AWS services so the the key ones to kind of think about just as we have a five minutes here to discuss is data events for things like S3 buckets so you can enable Bucket Level logging at the bucket or you can enable data events within cloudtrail for S3 buckets and the reason I would recommend looking at the option to configure the studio cloud trail is cloudtrail configuration and logging can be managed at the AWS organizations level and so this can be an easy default to turn on for all buckets however the caveat to that is there is cost Associated and if you have a very nose noisy S3 bucket excuse me um then you know you may want to consider only enabling it at the bucket or account level so it's a consideration because um you know Bucket Level logging is not enabled by default and so if you have any type of security event such as a ransomware event affecting data in an S3 bucket then you know you really need to make sure that those logs have already been enabled so you can understand what data was accessed or removed and things like that and that's never a conversation you want to have as part of your incident response to a security event where you don't know right so making sure that you've got that logging strategy for S3 and other AWS services at the data plane level is super important um other things to consider so post-based Labs right if you're running ac2 um you could put the cloudwatch log agent on the operating system and pull specific logs this is another great opportunity to provide a cloud formation template snippet or a script that configures the logging agent and that way the security team is actually influencing what's actually being pulled from the logs of these hosts because a lot of times this is like new territory for someone like a developer using AWS so if you have a Windows host and you want to pull IES locks you can have a template for that and a repository or a Wiki page explaining how to do that very simply as a base template for your developers um elb access logs if you have any type of security event coming from the internet you've got a load balancer in front of an ec2 instance if you want to get the source IP address of a you know a data flow that a security event occurred you have to have those elb those load balancer access logs enabled as well so just some considerations there initially obviously the ebook goes into more more depth and highly recommend checking out the security reference architecture as well there are a lot of cloudformation templates that you can pull from there all right so let's talk about getting the overall um visibility from a security perspective across our AWS environment so um in the middle of this diagram you'll see security Hub and I mentioned security Hub before it provides you that comprehensive view of the security state within your AWS environment um as well as compliance with security standards and security best practices uh highly recommend the enabling the AWS foundational security best practices this is a curated set of security best practices from the internal AWS security community and it doesn't just cover things like the AWS account it covers more broadly some of the actually many of the AWS services from our best practices security configuration perspective so it's a much much farther goes in much farther depth than the CIS checks for example which are also available with security hub um all right so what else does security Hub do it is actually pulls in um findings from many of the AWS Security Services actually most of them so you'll see um up on the left we've got guard Duty inspector Macy um access analyzer firewall manager um and so you get that single payment glass view of your security findings we also integrate with many third-party security services including crowdstrike Palo Alto qualis checkpoint some open source tools as well uh so we have a huge list of that in the AWS security documentation um that you can pick from and then um we automatically Security app automatically sends findings to um event Bridge or cloudwatch events previously named and you can do things like automatically remediate um based on a security findings so if you have an open security group for example and you want to change it so that it only allows something like RDP or SSH to from an internal IP address instead of the internet for example or if you want to do things like um page someone that's on call if you're using pagerduty or open a jira ticket or a servicenow ticket or slack notify your security team in their in their channel in slack for example the other really cool thing you can do with security Hub is actually investigate using detective so if it's a guard Duty finding for example in that you're looking at in security Hub and you want to dig into that you can use detective to investigate further and what detective does is it provides you with additional information around the time of that security event for example if you had a security event that was associated with static IM credentials detective would pull all the log data like the Telemetry data about that and tell you what other API calls did that credential or did I am user call make and were they success or failures what was the timeline Associated and then you have control over that timeline if you want to go back or forward things like that so it's I think of it as like the incident helper right these are kind of some of the first things you would ask yourself when you're investigating a security event and detective is going to help make that data available to you much faster than if you were to like write custom queries on the Fly all right number seven Implement and test backup and restore processes so we'll talk a little bit about some of the best practices for backup and restore we'll talk about setting up a secure backup strategy and then using managed data and database Services as well as lock features to help protect your environment from ransomware so from Best Practices perspective we always recommend that customers categorize their applications based on criticality it just becomes extremely overwhelming and expensive if we don't categorize and really put our applications in the right amount of backup strategy so if we have RPO um and RTO which is like the ability to you know recovery Point objective recovery time objective so how old is our data and how quickly can we get it back online um if we apply that same strategy or one strategy across all of our all of our applications it can just be extremely expensive right and there are several different tools within AWS that can help whether you're on-prem in Cloud only or um you know a mixture of both and we'll talk about those as well um but really making sure that we've done that categorization and that we have a couple strategies that apply to those categorizations to make it um you know uh financially viable to actually Implement our backup and perform our restore processes um obviously I think one of the things that a lot of a lot of teams Overlook is creating detailed playbooks so that we don't have to have just that one it person that has done this many times right like they're on vacation when we actually have a disaster type event or a security event where we need to do a full restore but we have documented the steps to do that restore process in a Playbook type format and that way it's consistent no matter who runs it and um you know we can test this over time periodically we run through these tests and we make changes to that Playbook over time so that it doesn't get stale that may sound like you know a lot of work but I guarantee you in the event that you actually need to do or restore you know testing and refining that Playbook is actually going to be the most valuable and you know going to provide that seamless experience when it comes down to it um also recommend storing backups and images in an isolated account with minimum minimal access and for those that haven't heard of AWS backup we have a service that actually does this for you it provides the isolated account and a separate Access Control policy that you can apply for who can manage backups and perform restores so highly recommend checking out AWS backup if you don't have a solution existing today that you're happy with um and then having backup servers in the cloud if you have on-prem environment um you know it's you can use things like storage gateway to store your data in something like S3 or even have um you know a mix of the most highly accessed data available in an appliance that's you know closer to your environment and then storing maybe more cold storage and something like an S3 or Glacier and that really kind of removes the data isolates it further from maybe the source of any type of a ransomware event all right so from an architecture perspective what does this look like if you were to build it yourself and not use something like an AWS backup which we have worked with customers and helped them build would be um creating a separate set of AWS accounts and this actually you can do this in the same AWS organization maybe a different organizational unit which is a substructure of AWS organizations um and or creating a completely separate organization potentially where customers already have multi-organizations many times they they actually create a separate organization um whereas if they're just single org today they'll do something like a separate OU the idea here is that you can think of an AWS account like its own isolation mechanism right um and you can dedicate that account to storing backups so we're going to call that account the Vault account and a typical concern I hear when talking to customers is you know I want an air-gapped copy of all my sensitive data and without using physical media for those data copies and actually shipping the media off-site um you can't really have a completely air gapped setup but um you know there is a more practical way of doing this and that is you know pulling backups from your data centers maybe third-party Cloud photos other AWS accounts you know pulling that backup data into a staging account and then creating that automation to pull the data in from a known good location into the Vault account and then applying those security controls on that Vault account something like a S3 object block for example which is going to provide right once read many so to prevent any kind of accidental or malicious deletion of those objects um and doing things like having a separate identity profile for who can access these environments so maybe a subset of your administrators MFA required on login as well as Federation um and you know having a separate policy attached where only certain Services can be used maybe a more lockdown service control policies within organizations so we're only allowing the Automation and S3 usage for example um just to prevent any type of other type of activity that's not expected and things like alerting on any type of access to the account because it should be a set and forget as far as initial automation but if we see folks logging into these accounts a bit of a red flag right because this set it and forget it and then you know to do things like test the restore process rehydrate that data also have a an account for your security folks to pull data so that they can analyze it for how far our back you need to go let's say there is a security event right you can have a vault forensics account and have any type of forensic software installed on ec2 instance for example maybe it's in a shutdown state so you're not paying for it 24x7 but it's there so that you could bring it up on the Fly pull data down and actually do some analysis and then that recovery account is also pre-built so that you can do your test test your restore processes and make sure that those playbooks are defined and well operating so this is definitely a um a do-it-yourself type of architecture AWS backup provides a very similar capability but more in a managed setting and so I wanted to make sure folks were aware of this as well let's go back to AWS backup real quick because I want to make sure folks note that the Vault lock capabilities which I mentioned S3 object lock AWS backup also has fault lock capabilities so that right once read many model is definitely something you can apply to your AWS backup Vault um and it's really going to provide you the ability to protect your backups from inadvertent or malicious actions and it helps just provide more safeguards for your backup data um and what AWS backup does is it provides independent copies of your backups across multiple regions and accounts separate resource access policies as I mentioned and long-term data retention and it's all a managed service so there's really no need to create your own custom automation unless you feel like that's the best solution for you and then you know I already mentioned S3 object lock we also have the capability to do Vault lock features within Glacier as well so Glacier is more of the cold storage version of S3 and I wanted to also point out point in time recovery for dynamodb um and point in time recovery is actually a really cool feature that um it it what it really does is allows you to rewind to any time within the previous 35 days to a given second so if someone accidentally writes or deletes data you can actually rewind and do that point in time recovery uh immediately and it's not going to actually affect your performance of your database of your dynamodb tables um so really cool features at the database data store level are things like point in time recovery there's other features like database cloning in Aurora that allows you to do a full clone of your database so there's things like that that you can do that maybe are a part of your um your you know backup and Recovery strategy as well but don't require like a full disaster for example or a you know a full event to to be kicked off maybe this is a subset that gets you gets your data back much faster than having to go through a full infrastructure level um Dr event all right the last item here is perform self-assessments and this is really important because a lot of times you know as technologists we get wrapped up and like oh we're deploying this new service we got to get it out the door maybe you know we've initially done a security assessment months back and we're time to release and that system has changed quite a bit so how do we make sure that we're putting out you know secure well architected systems before we deliver and what we what I recommend customers do is actually going through and setting up a well architected review before they go to production um and including this in your sdlc process is your secure delivery life cycle processes and the reason that is is well architecture well architected covers um several pillars you know including operational excellence security um and these are things that you know we all we want to make sure any production application is running well and has best practices applied and the well architected um assessment is available in the AWS consoles it's all self-service customers can do this you guys can you folks can do this yourselves and it's a good step to make sure that we're not putting out you know systems and resources that aren't following best practices also I mentioned security Hub AWS foundational security best practices earlier and this is something that you know you can also use it as a self-assessment when you turn on the foundational security best practices check um it'll give you a security score and start scanning your environment immediately for um you know anywhere that you have configuration that's not following best practices based on the approved services that the foundational security best practices is checking for um and this is something that you know we manage the security Hub team manages and keeps it up to date over time so as new best practices come out we update this uh standard so that you're not having to write things like custom config rules we're doing this on your behalf so highly recommend you know getting a baseline security score and then driving that number up and really you know reviewing any of the failed checks making sure that we don't have anomalies and resolving those issues we also have some open source tools that are available there's Prowler and Scout Suite um check those out if you want to go the open source open source route prowler's excellent tool it's it's a it's a great option as well if you want to go the less managed route but definitely you want to have it have uh use something like a security Hub or a tool that you know you're checking that you're following best practices from a security perspective so that you've got that visibility that that you need across your AWS and organization's environment awesome well thank you so much for attending the webinar today I hope you learned something um you can check out more AWS ransomware resources at um the website linked below as well as security resources Hub which provides a lot of information for learning so if there's something you I mentioned that you want to go deeper in there's the security learning site the security resources hub we also have a ransomware risk management that's mapped to the nist CSF which a lot of folks within the US use the CSF cyber security framework so you can check that out as well and we have more information on the well architected framework the security pillar specifically um so the ebook will be on our ransomware resources page please check that out and learn the other five of the top 10 best practices for ransomware protection and thank you so much for attending I hope you guys have a one a great rest of the day [Music]