Cloudops (cloud operations) and secops (security operations) are quickly evolving practices. While I’m seeing some errors, what’s more common is that ops teams are leaving important things out. If these missing aspects are not addressed, secops will become problematic quickly.
Here are two secops omissions that you can deal with today, even though your public cloud provider won’t tell you about, won’t be on any certification, and is typically widely misunderstood.
Link secops monitoring to govops monitoring
Both secops and govops (governance operations) need to be proactive, meaning that they need to adjust based on changing threats in the case of secops, and changing policies in the case of govops.
The reality is that secops and govops are not effective without each other because govops needs to understand what secops is doing for it to actively adjust policies around security threats, and voice versa.
Let’s say that many failed login attempts are noticed on a group of provisioned virtual servers in production running on a public cloud provider. The secops approach would be to lock out that offending IP address automatically, and that’s that.
However, govops needs to be alerted of the risk as well to automatically create new policies around all IPs coming from that area, such as the amount of resources they can provision at any one time, the need to force re-logins every few hours for the next 30 days, and the ability to spot malicious behavior by turning on extra fined-grained logging.
Both secops and govops must work together to deal with risk using hard and soft approaches.
Link costops with secops
Ever wonder where the $100,000 monthly cloud bills come from? From not having good proactive visibility into what you’re using; that is, what you’re spending. Usage-based accounting (aka costops, or cost operations) should be able to place some cost governance by not allowing cloud users to exceed a predetermined threshold.
But you’re leaving money on the table by also not using cost governance as an indicator to find attacks. Indeed, while hackers using a cloud services may be able to stay under the radar of secops if they don’t consume too many resources, the cost patterns indeed change in some manner, providing a new clue about a possible attack.
You should use the analytics automation feature of most costops tools to spot attack vectors that are not as obvious. In fact, I’ve had two companies find out that their public cloud server had been used for malicious reasons for more than six months. The secops folks failed to find the breach, but the costops audit of the cloud-usage logs did reveal it. If those companies had had some automated costops policies in place, the hacks could have been detected in the first few days.
