SecOps (a unified Security + IT Operations capability) is something I've been very interested in the last few months. Turns out building the vision into reality has two requirements: 1.) visibility into generic IT operations mechanisms (think database or connectivity monitoring) and 2.) deep insight into security telemetry (think signatures, event correlation, etc). This morning on a call with the team something slapped me like a wet newspaper flying by in a tornado. Unfortunately, enterprises operating at levels 1 and 2 of the CMMI (which is where a vast many organizations are stuck, in my experience) tend to execute security operations in a silo, a "cone of silence" if you will. But "need-to-know" access for the trove of telemetry and data security operations teams is problematic.
Let me explain.
Security Events are Need-to-Know Only
When I first pitched this idea a while back the main push-back I received was from my fellow security professionals, shockingly. They believed that security teams receiving additional operations data was desirable, but pushing security information out to the IT OPS team was a bad idea and would violate security rules - the rules of need-to-know. Makes sense... I think. But how much 'secret' data does the security team actually collect and why does that data get stored? Turns out the risk is not just the specific data bits, but also the knowledge that comes with security monitoring and event handling.
Expanding this point out a bit, it would seem as though security teams are a bit skittish on the types of information they have access to. This is both easily understandable and concerning at the same time. As it turns out the problem isn't that security operations teams have access to usernames and passwords (you can exhale now) but that incident information (and in some cases the mere existence of an incident) is believed to be a security-only property. The knowledge of security events is somehow secretive to the security organization. Maybe it's because we want no one else to know that a security event is happening in the company? Or maybe security is the pent-ultimate guardians of the enterprise. Either way, what starts out as a noble idea quickly turns into a double-edged sword.
Without information and knowledge sharing between security and IT Operations organizations inside the enterprise there may be a lot of double-work where two separate teams are handling the same incident - one from an operations perspective and the other from a security perspective - without knowledge of each other's efforts. This costs the company money; it hurts productivity and even inhibits the ability to solve the problem in the end.
So the key question is do you believe that it's possible to facilitate knowledge-sharing between IT Operations and Security Operations teams efficiently, openly and bi-directionally such that both systems are more effective?
The Case for Knowledge Sharing
Some information bits that security teams have access to should absolutely remain within the security team's purview. Information like:
- who is violating specific policies
- captures of data streams which contain potential evidence
- data that could reveal company-sensitive information or compromise a court case
But there is a difference between sharing information and sharing knowledge. And after a few discussions with products teams the trick is to share knowledge without sharing specific sensitive information - and I think that's where we as an industry stumble.
Rather than focusing on the negatives, ("Oh no, we may accidentally let the OPS team know we're investigating something") let's focus instead on the positives ("Now we'll have better insight into application behaviors to correlate with our security warnings!").
The first step is to identify a few security events that are critical and can elude security telemetry. These would be candidates for cooperative knowledge sharing from OPS teams. As an example, while SQL Injection has many well-known patterns for detection, new attacks are being tossed up all the time, and evading filters has become a game to skilled and unskilled attackers all alike. The added telemetry data, such as increase in rows-returned-per-query, from the OPS team would aide greatly in identifying real-world SQL Injection attacks pilfering a database while failing to trip any signatures. I'm sure there are many other events that fit this profile.
The IT OPS team would effectively become "deputized" (or at least a sub-set of the team would be) so they can have inside knowledge on events that could become security events, and could be trusted not to panic or do silly things with that knowledge. It's not hard to imagine a co-operative knowledge sharing pool like this... it's being done in more CMMI-mature organizations out there and it's just a matter of standardizing and bringing this to the masses with specific steps, tools, and methods.
Sharing is Caring
I've heard "sharing is caring" a million times on different topics. When it comes to enterprise, data being shared across IT OPS teams and security OPS teams, sharing really is caring for the enterprise welfare. If we can simply get past the 'need-to-know' tactics some security organizations use to keep their methods secret, and figure out an effective way to tool the sharing of knowledge without specific information, everyone wins.
Ultimately, we all need to become 'security people' at some level. I believe this would be a tremendous step forward.
Attached to this is the SecOps whitepaper I wrote that more completely illustrates the vision here...