Lowest-Hanging Fruit of Cloud Security

At nearly every conference, we talk about the lowest-hanging fruit of virtualization security, but we often miss the discussion about the lowest-hanging fruit of cloud security. They are not the same. Are we talking about good SSL hygiene? That is a part of it, but there is something even more basic than that. John Dickson, principal of the Denim Group, joined us on The Virtualization Security Podcast to talk about how people are moving to the cloud and the things they miss.

So, if good communication hygiene is part of the answer, what is the rest?

The lowest-hanging fruit of cloud security is actually good planning. Take the time to really think about and plan for those workloads you are placing into the cloud. Do a simple risk assessment to understand all the ins and outs of those applications, who needs access to them, and how those protocols for access are protected. However, even though this is important, it is more an end point. We need to seriously consider mindset before anything else. The lowest-hanging fruit of cloud security starts with:

  1. Convincing upper management that security is necessary and important
  2. Showing developers where their code is weak in a non-confrontational way
  3. Providing threat intelligence and ways of gathering threat intelligence.

Convincing Upper Management

This is the trickiest part of any security discussion, because the attitude of an organization takes its cues from those in charge with respect not only to security but to all other aspects of the business as well. Perhaps this is where you first use threat intelligence, which you can obtain from the following sources:

More importantly, this is where white-hack hacking and penetration tests can come in handy. You need such tests to probe the unknown unknowns, not just the known attacks. For some companies, the convincing threat is the possibility of their name showing up in the newspaper. If a breach is big enough or politically motivated enough, then they will appear within the newspaper (and everywhere else on social media), which will impact the bottom line. This is where we start to talk about financial and reputation impact of bad security choices.

Showing Developers the Breaches

Developers can be prickly, and in many cases, they have their own ideals about how the code should look. After convincing upper management, you need to show the developers the weaknesses in their code, as they are ultimately responsible for any code-related breaches. Mistakes happen, but by the same token, developers seem to be a breed apart and have a different mindset. Showing them where the breach is and how it impacts the business is the first step in convincing developers that their methods need to change. Perhaps this is as easy as a static code analysis or even a code review.

Providing Threat Intelligence

There are many good locations for threat intelligence, yet an organization needs not only to gather intelligence but also to respond to the intelligence they gather. This is where simple risk assessments come in. Seriously consider the threat: does it impact your plans to enter the cloud, does it impact how your code is produced, do you need more resources, tighter controls, or even better communication (SSL) hygiene? This is the repetitive part of the lowest-hanging fruit of cloud security. You iterate after every report. Architects, developers, everyone is involved. We need to break down barriers, not build them up. This is really what DevOps is all about, but we have a way to go.

Concluding Thoughts

This is just the tip of the iceberg when it comes to cloud security, the simplest but perhaps the hardest elements to change within the organization. We need to think more broadly, as a cloud comprises shared resources, which come with their own threats. Will the code or business process be impacted? How can you continue to communicate to partners? These are the types of questions to start asking.

The lowest-hanging fruit of cloud security is to plan, plan again, and plan some more. Ask the tough questions: How are you going to recover in case of an unknown unknown attack? How will you even detect such an attack?

Where do you get your threat intelligence? What is the impact of such intelligence on your organization?