10 common cloud security mistakes that put your data at risk

The news is filled regularly with attacks on misconfigured cloud servers and the leaked data that criminals obtain from them. The errors happen because we are all human. We might set up a cloud server with loose (or no) credentials and forget to tighten them when the server is placed into production. Or we fail to keep software up to date when exploits are discovered or get IT involved to audit the finished production app to ensure that it is as secure as possible.

The situation is far too common. Studies by Accurics and Orca Security found a series of basic configuration errors in various cloud practices. As an example, the former study found storage services misconfigurations exist in a stunning 93% of their respondents.

Here are ten of the most common mistakes:

1. Unsecured storage containers

In any given week, security researchers discover data caches on open cloud servers. They can contain all sorts of confidential information about customers. For example, both Avon and Ancestry.com had open containers discovered earlier this summer. Things have gotten so bad that even the security reseller SSL247 had left its files on an open AWS S3 container.

Chris Vickery of UpGuard has made a name for himself with these sorts of discoveries. UpGuard’s blog has a long list of them. Open storage containers happen because developers tend to be sloppy when creating, and they sometimes lose track of them. Because cloud storage is so cheap and easy to create, they have proliferated over the years.

Solutions: Regularly check out your own domain using one of the popular discovery tools such as Shodan.io or BinaryEdge.io. Follow some of CSO’s previously published advice on improving container security, including using the native Docker tools, and using cloud-native solutions from Amazon, such as Inspector, GuardDuty and CloudWatch. Finally, segment your cloud servers with tools such as AWS Virtual Private Clouds or Azure Virtual Networks.

2. Lack of applications protection

Network firewalls don’t help you when it comes to monitoring and protecting your web servers. Attacks on web applications more than doubled according to the 2020 Verizon Data Breach report. The average website runs dozens of software tools, and your applications can be woven out of a complex collection of different products that tap into dozens of servers and services. WordPress is particularly vulnerable, as this one example found close to a million sites at risk.

Solutions: If you run a WordPress blog, purchase one of the tools mentioned here. That post also has techniques for reducing your exposure that can be generalized for other websites. For general application servers, consider using a web application firewall. Also, if you are running Azure or Office 365, consider the public preview of Microsoft’s Defender Application Guard that can help spot threats and prevent malware from spreading across your infrastructure.

3. Trusting SMS MFA to secure an account – or having no MFA at all

Most of us know that using SMS texts as an additional authentication factor is easily compromised. A far more common situation is the lack of any multi-factor authentication (MFA) on most cloud applications. Orca found that a quarter of respondents to its study failed to use MFA to protect their admin accounts. Just a quick scroll through the Two Factor Auth website shows that half or more of the typical apps listed – such as Viber, Yammer, Disqus and Crashplan – have no support for any additional authentication methods.

Solution: While there isn’t much you can do about commercial apps that don’t support better (or any) MFA methods, you can use an authenticator app from Google or Authy to secure as many of your SaaS applications as possible, especially for those administrator accounts that have more rights. Monitor the Azure AD global administrator roles for changes, too.

4. Not knowing your access rights

Speaking of access rights, there are two basic problems with keeping track of which users can access an application. First is that many IT shops still run all their Windows endpoints with administrative rights. While this isn’t exclusively a cloud issue, cloud-based virtual machines and containers also can have too many admins – or share the same administrator password — and should be better locked down. Second is that your security equipment can’t detect common privilege escalation attacks across your infrastructure.

Solutions: Get a privileged identity management tool such as from BeyondTrust, Thycotic or CyberArk. Then regularly audit changes to your account permissions.

5. Leaving ports open

When was the last time you used FTP to reach one of your cloud servers? Exactly. Here is a warning by the FBI about a 2017 breach using FTP.

Solution: Turn those unneeded and ancient ports off now and reduce your attack surface.

6. Not watching for remote access

Most cloud servers have a variety of ways to connect remotely, such as RDP, SSH and web consoles. All can be compromised with the right credentials, or poor passwords, or unprotected ports.

Solution: Monitor these network flows and lock them down appropriately.

7. Not managing your secrets

Where do you store your encryption keys, admin passwords and API keys? If you said in a local Word file or on a Post-It, you need help. You want to better protect these pieces of data and share them with the fewest possible number of authorized developers.

Solutions: Services such as AWS Secrets Manager, AWS Parameter Store, Azure Key Vault and Hashicorp Vault are some examples of robust and scalable secrets management tools.

8. The curse of GitHub – trusting the supply chain

As developers use more open-source tools, they have lengthened their software supply chains, and that means you must understand the trust relationship and protect the complete path that software takes through your entire development process and lifecycle. Earlier this year, GitHub IT staff found 26 different NetBeans open-source projects (a Java development platform) that had backdoors built in and were actively distributing malware. None of the owners of these projects were aware that their code had been compromised. Part of the problem is that it is difficult to differentiate when there is a simple typo in your code and when an actual backdoor has been created.

Solution: Use container security tools mentioned in the first item above and understand the chain of custody in your most-often-used projects.

9. No meaningful logs

When was the last time you reviewed any of your logs? If you can’t recall, this can be an issue, especially for cloud servers, because they can proliferate and not be top of mind. This Dons Blog post shows how attacks happened thanks to poor logging practice.

Solution: AWS CloudTrail will give you better real time visibility of your cloud services. Also, turn on event logging for changes to account configuration, user creation, and authentication failures, just to name a few.

10. Not patching servers

Just because you have cloud-based servers doesn’t mean that they will automatically apply patches or update themselves to the latest versions. (Although some managed service and cloud hosting providers do offer this service.) The Orca study cited above found that half of the respondents are running at least one outdated server. The number of attacks that have happened because of unpatched servers is too long to list here.

Solution: Be more vigilant with your patch management and use providers that will notify you of significant updates in a timely manner.