4 Considerations for Improving Cloud Security Hygiene

We think we understand what hygiene is, but what about cloud security hygiene? It’s not like our computers have teeth to brush, but that model is an entry point to a different understanding of security hygiene. If there’s some task you need to do regularly, you need to do it everywhere. It’s not okay to just brush your teeth once a year, or only to brush the front teeth; you also can’t just patch software or check your security configurations once a year, or only for your most visible systems.

Imagine a board member asking a CEO, “Are all your systems patched regularly?” As the CEO goes to find the answer, she may find that instead of the words changing, the meaning of them changes. The board member probably really means “all the company’s systems,” and “patched within industry-standard windows based on criticality,” but that nuance will get lost. The CEO will turn to the CIO to ask the question, which implicitly reduces “all our systems” to “the systems the CIO is responsible for” and “patched regularly” becomes “patched within our internal maintenance windows.” The CIO asks their team, and so on. The metric reported back up ends up being something like “for our supported Windows servers, we apply the Microsoft patches within our planned maintenance windows 87% of the time.”

Those caveats get lost in the messaging back up to the CEO, so the company thinks it’s doing just fine, when, in reality, only a small fraction of software is being tracked well. There’s a disincentive to provide better tracking, because that 87% number will go down when combined with another set of data with a lower score, and no one wants to explain why a metric just got worse. And this management miscommunication only gets worse with the cloud, because executives generally don’t even have a touchstone for how many cloud systems there are. And mixing the security and maintenance practices of cloud environments with your legacy enterprise approaches usually leaves cloud hygiene holding the short end of the stick. Here are four suggestions for getting smarter and more systematic with your cloud security hygiene.

1. Categorize How Complete Your Cloud Coverage Is
In the pre-cloud world, it was easy to understand how many systems you had – after all, you could always walk into the data center and count them. In the cloud, however, even that fallback isn’t readily available, and so you have to give any measurement of security a caveat: How many of your systems are covered by this measurement? “We patched 75 systems for the latest CVE” is only a good statement if you have 75 systems. If you have 1,000, it’s not a very positive outcome.

Keeping an asset inventory may sound like a monumental task, but start by aggregating your systems into clusters, organized by how you manage them. Perhaps your production servers in AWS are one cluster, and your development systems fit into another. Your employee laptops fit into a third cluster, and the corporate IT and networking infrastructure is a fourth (they aren’t “cloud,” but let’s not forget about them). Now, you can start to talk about hygiene practices within each cluster (“We patched 95% of our employee systems within 48 hours”), which gets you closer to understanding business outcomes.

2. Count How Comprehensive Your Controls Are
For any system, it can be easy to implement a security control, and then move on. You’ve patched that Web server in the cloud? Great! But what about all of your other objectives? Have you controlled for all of the relevant types of risk? There are a number of relevant frameworks to look at for risk; in the cloud, the Cloud Controls Matrix from the Cloud Security Alliance is a great place to start.

But 197 controls is a little bit daunting. Those are carefully detailed, and gathered into 17 domains. Start with one domain, and see how each of the controls applies to one cluster of your systems. While some controls might have the same implementation across multiple clusters of systems, your goal is to first understand how comprehensive your security controls are for any given cluster of systems. And then, for each control, see how many of the systems in the cluster actually meet your objectives.

3. Consider the Context Inside Your Cloud
While your controls need to be implemented across all of your systems, some of your systems are more equal than others. Some of your Web servers may only have public-facing information on them, and someone being able to get access to that system would be embarrassing. But some of your Web servers have access to your private data stores, and if those contain personally identifiable information? That’s a much more serious problem. Identifying the systems with direct and indirect access to more sensitive assets is going to be critical to prioritizing your work.

That context may help you create dynamic subclusters in your asset inventory. Your public-cloud cluster may now subdivide into four categories, splitting on the two axes of “Internet-facing” and “has access to personally identifiable information,” with the cluster that has both being your highest priority to implement your controls on.

4. Cancel the Certainty
The hardest part of an approach like this is that you’ll stop providing definitive, certain answers to yourself and others. “Are we patched?” stops being answered with yes. Instead, you’ll start to understand exactly where you are patched, and begin knowing where you don’t even have visibility. But that uncertainty will drive the improvement into your hygiene that almost every enterprise needs.

Read More HERE