5 Cloud Security Mistakes to Avoid

This is a guest article from Doug Heestand, President/Founder for hootsecurity.com.

Are there any people left, excluding a few flat-earthers on AM radio, who still doubt that moving services to the cloud generally improves security? Cloud environments are secure by default, they have extremely limited attack surfaces, and they are monitored by highly specialized security teams. Most organizations don’t have the resources to manage their own security half so well as the leading cloud providers. Yet moving to the cloud isn’t guaranteed to improve security. Here are 5 cloud security mistakes we see all too often:

1. Keeping Your Cloud in Hybrid Mode Indefinitely
   Most cloud migrations start out as a hybrid network where the cloud environment has a direct connection to the corporate network to make the initial transition easier. Fine. It’s often unavoidable. But don’t leave
   it like that. Hybrid networks provide attackers a backdoor into your cloud environment. If you fail to isolate your vulnerable corporate endpoints from the cloud network, that backdoor essentially becomes a ramshackle screen door. Cloud security shouldn’t hinge on whether Tim in HR recognizes a phishing attempt when he sees one. (He never does,
   poor guy!). Bottom line: you have to aggressively push your IT team to cut the umbilical cord as quickly as possible postmigration. Rearchitect your cloud services/applications so they are segregated from the corporate network.
2. Replicating your Firewall Rules to the Cloud
   Cloud environments control access using “security groups” which are applied per instance like tags. For example, a rule might allow servers in the “database” security group to communicate with servers from the “web server” group over port 3306. These rules are much different than traditional firewall ACLs which are applied at the boundary between subnets. Security groups offer the benefit of segregating hosts on the same subnet which dramatically limits an attacker’s ability to move laterally. Don’t just lazily replicate your existing firewall rules
   using the traditional subnet ACL approach! You will not only squander the benefit of host segregation, but you will also limit your ability to scale your security rules as your environment grows into multiple virtual networks and availability zones. Bottom line: translate your rules to the new security group paradigm, don’t replicate them.
3. Lumping Everything into 1 Account and 1 Network
   One of the main security benefits of the cloud is the ability to create separate, isolated infrastructures for each
   application and each environment (dev, test, and production). Each isolated infrastructure can be locked down to only those IPs, ports, and people that absolutely need access. It is so tempting to lump everything into 1 account and 1 virtual network. Sure, it might save you some work up front, but then it forces you to open up access to
   the superset of all IPs, ports, and people for all of your applications and environments. Bottom line: invest time in building templates and scripts to automate the creation of separate infrastructures so you can take advantage of network and account segregation.
4. Managing Security Using Your Old Tools
   The speed and grace with which you managed your traditional security tools (IPS, SIEM, etc.) were the stuff of legend! You are so comfortable with these old-school tools you decide to use the VM versions in your new cloud environment. Unfortunately, cloud concepts like autoscaling, immutable servers, and availability zones fundamentally break your old favorites. Bottom line: time to learn a new set of security tools made specifically for cloud environments. Back to the lab again, yo!
5. Forgetting to Patch
   For some reason, we see a lot of cloud infrastructures with no automated patching process whatsoever–way more than we encounter this finding for on-prem infrastructures. Maybe administrators think that because their instances get
   security updates automatically on bootup they don’t have to worry about keeping them updated afterwards. The problem is cloud instance uptimes can stretch out for months or even years! Bottom line: implement a regular process of updating your master images and replacing running instances with new, fully patched instances.

What other cloud security mistakes have you learned to avoid? Share your wisdom below!