Cloud “shiny rocks” and your SOC

Original post for HPE Security Research Blog 5/4/2015

I love the cloud. What could be better than access to my data from a beach, my phone in Las Vegas, or just between work and home without the need for a massive laptop hard drive? What’s not to love?

Until someone mentions cloud security and reality crashes the party. Working with security operations centers (SOCs ) and SIEM implementations, companies call saying, “we are moving (some mission-critical corporate asset) to the cloud; do you know a good security provider for that?” Yes —  you. Who cares more about your data than you? We know your CISO went to a meeting, and a great cloud-SOC shiny rock distracted him. But you must be strong; you’ve got this.

At RSA last month, Mark Russinovich, the CTO of Microsoft’s Azure cloud offering, gave a presentation on cloud security, citing real examples from internal users of Azure. His first example highlighted the good and the bad possibilities with cloud implementations. In the incident he described, a company VM that was compromised. Once the customer was contacted and they reviewed logs, it was discovered that the A/V  had been disabled from  the VM and the logs were coming into the company butnot fed into their SIEM. This oversight was why they did not notice the A/V disable event.

My focus here is on the logs and your SIEM. Most major cloud providers have mechanisms to return logs to the customer from their services. You do not need a special cloud version of a SOC; these are logs, the same logs you deal with all day, every day. Bring them into your infrastructure and feed them into your SIEM. The difference may be in your asset tagging, as the IPs may have a different destination; the source IPs, however, should be identical to current threat traffic. Once an event is identified as cloud, you may wish to manually change the event prioritization based on the cloud data type or service criticality.

What I have seen too many times is a situation in which  a cloud solution chosen because it is expected to be faster and easier to implement than the on-premises solution. The danger in these deployments points to the earlier example miss. In the breakneck pace at which cloud applications are deployed, someone remembered to involve security and get the logs ported back inside. However, no one followed up with the SIEM team or the SOC to ensure someone was actively monitoring the deployment. A good cloud deployment project plan must include security steps all the way through SOC monitoring to avoid these scenarios.

A good deployment project plan for any service deployment or sensitive data should include security steps through SOC monitoring — but today is about the cloud. With new cloud directives and obvious public threat vectors, it is vital to get log monitoring buy-in. Use Mark’s example in your next cloud deployment meeting and give the SIEM  a chance to right past log gathering and monitoring wrongs. I believe in a SOC/SIEM renaissance with the cloud; this is our time to shine.

Tags: OpSec, SIEM, SOC