5 Habits That Will Lead to Security Breaches

In today’s competitive business world, there is pressure to innovate like no other time in history. With the rise of the cloud and its ability to support rapid, iterative experimentation, you are going faster than ever before. With that speed, you are always trying to get new features and improvements into your customers’ hands before your competitors do.

But, there is a problem. You’re lying awake at night because you have dozens or even hundreds of people working on cloud projects, but you’re not sure they are protecting your cloud assets as meticulously as they could. Your team is innovating really fast, but not taking precautions at the same speed.

Here are five of the most common ways teams working on the cloud will leave you open to a security breach.

1. Firewall Sprawl
   Firewalls, which control networking traffic depending on the port of the request and protocol used, are basic security tools. Most developers have at least an entry-level understanding of how they work, and are able to configure firewalls to allow them to do their development and testing work.
   
   If you are using Amazon Web Services (AWS), a too-common practice when creating a virtual machine is leaving Security Group firewalls open to all internet traffic, in an effort to make it easy for the developer to access the instance.
   
   This on its own is not an issue, if the team goes back and modifies or deletes the security group. But in the rush to innovate and ship, over many months, you will have dozens or even hundreds of poorly-named security groups available for use to your team, without an easy way of knowing which ones are in use and are allowing incoming access to the entire public internet. Like a poorly-planned city growing on and on, this is called “firewall sprawl”. Now, you and your team are confused about which instances are exposed and you need to spend significant, deeply focused time to figure it out.
2. Not Enforcing Least Privilege
   Everyone knows that Least Privileged Access is one of the pillars of best security practices. You want to restrict access to data and applications as much as possible without preventing the right people from doing their legitimate jobs.
   
   This is so much easier said than done. In reality, this requires detailed analysis of everyone’s role. Then, someone then needs to write detailed, precise policies that describe least privilege for those types of access. Then, it requires someone to create roles and groups to sort people into.
   
   Once you have these roles and policies defined, you only have a snapshot of your current situation. In today’s fast-moving world, people come and go, roles change, and new data sources and assets come and go all the time. This kind of dynamism will make any effort you make for Least Privilege, out of date almost immediately.
   
   The risk of being able to keep up with enforcing least privilege over time is that sooner or later someone will accidentally have access to the wrong data -- and this is usually an “old” data source whose access rules have become stale.
3. Lazy Tagging Habits
   “Tagging” - or keeping an up-to-date-inventory by attaching metadata like “owner”, “team”, and “environment” to your assets  -- is surprisingly valuable in the cloud, because it is so easy to create and release assets.
   Most companies, when asked for their inventory for an on-premise infrastructure, struggle to produce an accurate list, and that is in a “closed”, finite environment.
   
   When it comes to cloud, which provides basically infinite access to resources, the situation is much worse. How do you know how secure your assets are, if you’re not even sure what you own? At this very moment a “shadow” asset or resource could be compromised and you would never know, because your assets are going untagged.
4. Never Looking at Logs
   Let’s say you have taken care of 1-3 above - you have a disciplined approach to firewalls, you are actively enforcing least privilege, and you have a good habit of tagging every resource. Still, you are missing important information by not reporting all access attempts across your estate.
   
   AWS produces reams of logs which capture every single action in your cloud - who did it, what they did, whether it was successful. Knowing what is in these logs allows you to understand what threats may be coming to your environment externally, and even internally (from disgruntled employees -- we all have them).
   
   Reading these logs, however, takes skill, patience, and focus.
   Thankfully, advances in machine learning have been applied to logs to understand what “normal” operations are. This allows for better understanding of anomaly detection. That being said, it still requires effort and strategy to set up and monitor. If you are not dedicating resources to analyzing logs, you are unaware of what your current threats are.
5. Account Sharing Among Your Own Team
   Ever pass around credentials in the name of speed and simplicity? And, have you ever had an unhappy employee? All it takes is one disgruntled employee with a desire to wreak havoc on the way out. The internet is full of stories of data deletion, customer data being published online, entire environments being deleted.
   
   Generally this happens when an administrator account is known to several people, and there are no protections (like multi-factor delete) against catastrophic data loss. Worst of all, the root account credentials, which has unrestricted access to everything in your AWS account, might be available to the larger team, which makes it harder to keep track of who has access.

What’s challenging about these issues, is that while it is possible to get a handle on things for a day or two, a static solution never works for a dynamic situation. You can take a snapshot of a situation, but by the time you understand it, it has already changed. That is the nature of the cloud.

What if you had a checklist that was used for every single decision in the AWS console? You could sleep easy at night if your team followed a checklist before every single action: is this change safe? Does anyone externally have access? Do the right people still have access? Have I tagged this new resource? But you know it’s completely unrealistic to ask your team to do that. Innovation would slow to a crawl, and you can’t afford that.

What if your security checklist was automatic? What if it ran in the background after every single action your team took?

Wouldn’t it be great to stay compliant at the same speed as innovation? Wouldn’t it be nice to have a system to monitor and fix problems, without having to assign two or three people to manually work on it full time? Wouldn’t it be nice to have a full weekend of peace without any concerns about noncompliant infrastructure?

The problem here is that cloud innovation is great, but it's too easy things to get out of control. You should be able to use the cloud for all it's worth without the risk of a career-ending mistake.

It can be done, and it’s very simple. At Cloud Sheriff, we automate cloud compliance so you can just build.

We understand what it's like to be anxious about your reputation taking a hit from security surprises from the cloud, like security breaches. We've been there ourselves, managing large AWS environments with teams of dozens of people.

With Cloud Sheriff, we’ve deployed thousands of policies that are continually checking and fixing security gaps in our customers’ clouds.

Cloud Sheriff’s Three Steps To Automatic Cloud Safety allows you to rest easy knowing you are safe:

1. We turn your policies and our hundreds of best practices into code (week 1)
2. Use our communication template to prepare your team (week 2)
3. Go live on Cloud Sheriff (week 3)

Once Cloud Sheriff is running, every single action in your console is checked against your rules, automatically. Cloud Sheriff’s response to a violation can be as gentle as an email with some corrections, or as aggressive as automatically reversing the action. Cloud Sheriff will even automatically tag every single existing and new resource in your environment, so you have a crystal-clear picture of who owns what.

Don’t suffer another night worrying about some lurking security breach. Contact us at operations@getcloudsheriff.com to get started.