What Fortnite Taught Me About Cloud Security
Keep moving. Disorient your attackers. Be aggressive. Sometimes winning a battle royale and securing your cloud can feel similar.
Cloud security requires a strategy of constant movement. Long gone are the days of fixed perimeters and static security reviews. What does this idea have to do with Fortnite? Despite it being a popular online video game since 2017, spending an hour (ok, maybe a bit more) having my teenage son and his friends beat on me, I learned some valuable lessons that have correlations in the cloud.
Move constantly
Cloud native infrastructure and applications are always moving. Your security should do the same. In practice, this means making sure your cloud security strategy is taking a threat-based approach -- do you know how adversaries might be targeting your cloud infrastructure?
In a recent Unit 42 Cloud Threat Report, researchers found that cryptojacking affects 23% of organizations globally. This number is up almost 300% from levels witnessed in 2018. This is one example showing how security playbooks you put in place last year may no longer be effective.
If your team isn’t re-evaluating threats and countermeasures on a quarterly basis, you are likely not moving fast enough. As the famed U.S. General George S. Patton said, “Fixed fortifications are a monument to the stupidity of man.” When applied to cloud security (and Fortnite) it rings true. Your security cannot be fixed, it must be constantly evolving based upon the latest threats.
Disorient attackers
The Oxford dictionary defines disorient as: cause (someone) to lose their sense of direction; make (someone) feel confused. If you want to keep your cloud environment secure, disorienting attackers needs to be a strategic focus.
The challenge is that, when it comes to security, unlike Fortnite, we have traditionally tried to keep things as static as possible. This is wonderful for attackers and suboptimal for security. Here’s why: dwell time, meaning the amount of time an attacker is in your system.
If you are still manually building your cloud environments, you are playing with a disadvantage. In an ideal scenario, you should constantly tear down and rebuild your cloud estate from infrastructure as code (IaC) templates e.g.., Terraform, AWS CloudFormation and/or Azure Resource Manager (ARM) templates.
Image: Pixabay
If your applications are cloud native, this is not difficult. On the other hand, if you did a "lift and shift", you will be quite challenged. Cloud-native applications have this distinct advantage over those that were merely migrated. Instead of patching a running application or host, the original container and IaC template are updated and then pushed to production. Not only is the security vulnerability closed with the patch, but if an attacker was mapping your environment they now have to start over. Following this approach, dwell time is considerably reduced.
A key to winning in the cloud (and Fortnite) is to constantly disorient attackers. Cloud-native applications coupled with cloud native security allow you to do exactly this.
Be aggressive
This is about moving beyond thinking in terms of passive defense and instead using active "antipatterns". In the cloud this means looking for certain conditions, and then when you see them, doing something immediately to address them.
Years ago, this was called self-healing. I never liked that term much because it left the impression that there was some machine learning involved (that wasn’t the case, especially back then). Today we call it auto-remediation: If X condition is true, then carry out Y action automatically. E.g., if a cloud storage bucket with sensitive data is publicly accessible, don’t send an alert and wait a week for a SOC analyst to triage it. Immediately set the bucket to private and then file a ticket to find out how and why it happened. This is playing aggressively.
The correlation to Fornite is how the player that gets a "Victory Royale" is often the one that plays the most aggressively. They know the map (they have visibility), know where the loot is (sensitive data or IP) and understand the most likely plays an adversary might run (threat-based planning). Security in the cloud should be no different. Here is a simple list of five antipatterns to be on the lookout for in your cloud environments:
Cloud storage buckets should not be set to public unless it's marketing material
Security groups should not allow internet (0.0.0.0/0) traffic by default
Security groups should not permit internet (0.0.0.0/0) traffic for SSH or RDP
Flow logs should not be set to off
Cloud databases should not be publicly accessible
If any of these conditions are observed, then automated (non-human) processes should correct them immediately. There are two ways this can be done. First, make sure to check IaC templates for misconfigurations to prevent many of these issues in the first place. Second, even though your IaC templates might be good to go, you also need to ensure your cloud infrastructure is not drifting from the templates. This can be done by building custom scripting or by leveraging a cloud-native security platform like Prisma Cloud.
Cloud security victory royale
Just when you thought playing Fornite might be a waste of time, it turns out it’s not always the case. Getting a victory royale requires a combination of aggressiveness and strategy. Cloud security is no different. If you’ve never played Fornite before, I want to encourage you to spend a few hours and you’ll see what I mean. Not only is a great way to bond with your kids/grandkids/nephews/nieces, you might also walk away with a refreshed view into what it takes to stay ahead of attackers in the cloud.
Matt Chiodi has nearly two decades of security leadership experience and is currently the Chief Security Officer of Public Cloud at Palo Alto Networks. He is a frequent blogger and speaker at industry events such as RSA. He currently leads the Unit 42 Cloud Threat team, which is an elite group of security researchers exclusively focused on public cloud concerns. He is also on faculty at IANS Research.
About the Author
You May Also Like