Moving to the cloud can feel like an impending zombie apocalypse as you wonder who could gain access to your assets and launch attacks against your company once you migrate. Going into the unknown can be unnerving for many companies considering moving to the cloud. However, with the rapid growth and popularity of the cloud today, organizations are wondering not if they’ll move to the cloud, but when—and when they do, how they can take proactive measures to reduce risk exposure and stay safe.
In a recent webcast, Rapid7’s Head of Labs, Derek Abdine, shared the top cloud configuration mistakes organizations make and four rules to implement so you can migrate securely to the cloud. You can watch the full webcast here and read below for a recap.
Understanding who is gaining access to resources in your cloud environment is a big unknown for many organizations. The best way to prevent this from happening is to use temporary security credentials.
With just a simple search on GitHub, you can usually find zombie credentials or access keys unintentionally embedded within configuration files. This is not a fault of GitHub, but rather application developers who toss access keys into these files and accidentally commit them. This can happen even on content that gets indexed by Google. However, regardless of where they show up, you never want static access keys out in public.
One of the best ways to protect your account is to avoid using statically defined keys (especially for the root user) when you can. Instead, using temporary credentials or IAM roles can help to manage cloud access. Developers can even interact through tools like Rapid7’s open source awsaml, which allows you to integrate with a provider like Okta to get temporary tokens from which to run their tools instead. If you do need to use static keys, putting the right rules and policies in place will be key. Additionally, specifically for git repositories, you can prevent accidental commits of secrets using projects like AWS Labs’ git-secrets project.
The smaller your footprint, the harder you make it for attackers to gain access to your cloud environment. Simply put, don’t expose anything you don’t need to. The first step in doing this is to reduce your attack surface by utilizing private networking of cloud infrastructure (VPCs) instead of using Remote Desktop Protocol (RDP) or Server Message Block (SMB), which allow servers to become publicly exposed.
You can also leverage firewall rules or security groups so that if an administrator needs to access MySQL, for example, they’d have to shell or VPN into the cloud environment to gain access, which significantly limits exposure to malicious actors.
It’s also important to always monitor for exposed assets. Shadow IT is a real issue that often gets overlooked, and because cloud environments are highly dynamic, you need visibility into what you have out there and what is exposed. InsightVM’s Cloud Configuration Assessment can help you see which assets have been made public due to misconfiguration, while Rapid7’s Open Data is a free resource for global public internet exposure data.
Pop quiz: What do the below services all have in common?
Answer: They’re all potential vectors for domain or subdomain takeovers. Case in point: Let’s say a small organization registers a domain and points its IP address to an AWS S3 bucket. A few years later, the company goes out of business, but the business name still exists. If you went to their domain, you’d see this message:
This is an invitation for someone to take advantage of the domain and its contents. All they’d need to do is register the bucket on Amazon using its name and launch the bucket, and any content already on the domain they would instantly own. This is a classic example of subdomain takeover requiring only a stale DNS record that an administrator forgot about.
To avoid this, release, sell, or decommission any names your business no longer uses. For those that are still in use, be sure to monitor them in your DNS and don’t utilize services that are prone to takeover vectors. Cloud infrastructure services like CNAME, A, and AAAA can help handle dynamic records to keep you safe.
One incredibly common source of data breaches is leaving a data bucket open for an adversary to access. These breaches are exceedingly frustrating to witness, not just because of the data that gets exposed, but because they can be so easily avoided.
Cloud providers today can provide you with visibility into which buckets are public and which ones are not, as well as global policy settings for public buckets. These policies alone have significantly reduced the amount of data that can be stolen in a breach.
Plus, the advent of serverless technology to automate which servers are public and providing reports to administrators to identify and close buckets that shouldn’t be public has enabled companies to gain complete visibility and take action before anyone else can.
When you think of dynamism, you may think of things like IP addresses, host names, and other infrastructure that changes often in the cloud. Because attackers are prone to taking advantage of the dynamic nature of the cloud, we need the ability to stay ahead of them. How? By utilizing security orchestration and automation (SOAR).
It can take under 60 seconds for unwanted traffic to come when you bring something online. And, if you let go of an AWS resource, someone can obtain that IP address in under 60 seconds. Information about your app can leak easily if you’re not orchestrating and automating dynamism around IP addresses and names in the cloud with a SOAR solution like InsightConnect.
Derek covered an incredible amount of information in a short amount of time in this webcast, so here are his top takeaways:
Secure Sense is the security provider that cares. We are a team of experts with a passion for IT and protecting your organization is what motivates us daily. If you have questions or want to learn more about how we can improve your organization’s security, our services or just want to chat security please give us a shout. If you’re looking to guest blog, please send an email here.