In this week’s Whiteboard Wednesday, Derek Abdine, Senior Director of Rapid7 Labs, walks us through the proliferation of cloud technology and provides a step-by-step guide to securely adopting cloud technologies and infrastructure within your organization—including how to avoid common pitfalls.
Want to dive deeper into Rapid7 Research? Learn more about Project Sonar and Project Heisenberg, and how you can leverage the ongoing research.
Hi. Welcome to Whiteboard Wednesday. I'm Derek Abdine from Rapid7 Labs, and today we're going to talk about how to securely adopt the cloud. If you look at the last 20 years, since the early 2000s, we've really come from a place where we've moved from static resources, where it took a purchase order to order hardware, and we had to connect that to an ISP, and we need an IT person, and all these things had to beautifully come together to create a new online service that we were producing. To today, where you have all these cloud providers that have really enabled a broad use of technology, and it is so easy to use them that you can drop a credit card in, push a button, and in a minute, you can get a new server, and you can get an IP address facing the internet to serve your new application. It's faster than ever. It allows us to adopt technology at a faster rate, but sometimes that can open us up to additional risk.Show more Show less
And let's take, for example, the case of a fake company called Acme Corp. Acme Corp decides ... Let's say they're a hot Silicon Valley start-up. They decide they want to launch a new application, so they pop in their credit card, they buy new compute resources on a cloud provider, let's say Amazon.com, and two days later they have their application online, it has an IP address, and they have visitors coming in. Let's say a week, a month, whatever later they decide they're going to shut it down, they're going to deprecate it. They had some customers. They're going to deprecate some domain of their website. They shut that server down, but the domain name, the DNS infrastructure, the item that when you as a client or as a customer, you're typing www.acme.com in your browser, that still stays the same and points to the IP address that that host had.
Let's say they forget to remove that part of it. And now, Mallory comes in, and Mallory decides, I'm going to take advantage of this. I see that acme.com's domain name points to an IP address in the Amazon environment that no longer is hosting a server, or it doesn't appear to. So, Mallory decides to go into Amazon environment, or any cloud provider in this case, kick off a new instance, and lo and behold, she gets the IP address of acme.com. Now, Mallory actually controls that www.acme.com domain name and can do anything she wants with that. She can host any type of web page and use that, potentially, for a fraudulent campaign such as phishing that she wants to, so it's important to take a look at these misconfigurations and how they can potentially materialize themselves.
So with that, there's three main things you can do to protect yourself from those types of attacks. The first one is to identify the resources in your entire environment that are subject to dynamic change, so this can be domain names. If you're talking about AWS, you're talking about Route 53, and those domain names connections to compute resources, and in the AWS case, EC2, and this kind of applies to any cloud provider.
The second thing you can do is, start to automate that management. Because deploying these dynamic resources is super-easy to do, we tend to use it a lot, which is great, and it allows us to get value out faster than ever, but because of that value, and because of the scale that we're able to do it, we really need to apply tools that can help us manage that better, so automating that, putting software in place to do that, is key. A lot of these cloud providers, including AWS, allow specific features of these resources to better enable that automated dynamic management, including for Route 53, for example, in the domain name case, you can use something called aliases in the Amazon environment to do that.
The last one is, you always want to monitor, no matter what, for anything, especially on the external-facing infrastructure as you use these cloud service providers. Make sure you're monitoring your specific cloud service area. That would mean really taking a look at the IP addresses that you are using within that account, taking a look at the domain names in your DNS configuration with that cloud provider, and looking at the interaction between both of those components. And it's not limited to those two. There's much more components in those cloud providers, but it's a great start 'cause those are usually the two fundamentals that most people use.
If you ever have any questions around your external service area, Rapid7 has another project called Sonar that does a lot of external scanning, and you can go and check your environment, all your external resources, your IP addresses, domain names, and so on within our Sonar data sets. It's completely free. It's on scans.io.
Lastly, we continuously monitor the trends with respect to cloud environments and the use of dynamic resources with Project Heisenberg. Project Heisenberg is a massive honeypot deployment that spans five providers worldwide and five different continents, and we are continuously monitoring network traffic to see the type of misconfigurations, and then educate by way of some blog posts we put out earlier in the year, and we'll probably put out more in the future, so that you know the types of misconfigurations in the dynamic resources that need to be targeted.
And if you have any questions, as usual, please reach out to us at email@example.com. That wraps up Whiteboard Wednesday. Thank you.