SecOps - Security's a Need-to-Know Event Problem

Wh1t3Rabbit| January 28, 2013

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...

Attachments:

Labels: Enterprise security| SecOps

Labels:

Comments

I totally agree with you Rafal.

In my opinion, sharing "security incidents information or knowledge" (call it what you will) is not only desirable, but necessary, mandatory, for "good security" (100% security being impossible) to be sustained in the long run. Indeed, sharing that information is the only mean you can ever build a more complete picture of your "security posture" (**bleep** do I hate that parlance) and be ultimately able to get a little bit more on top of your things and not only extinguishing fire after fire. The first problem I see with getting "incident info sharing" buy-in is that it was repeated so many times by so many actors of varying credibility that it has lost its significance. People go "yeah right" when you mention it, whichever words you use to try to convey the importance. But it does not mean it was wrong in the first place.

The second reason I see for push-back is exactly what you are writing: security people waving the "need-to-know". I do agree that for some information, they (we :-)) are right. Information that relates people to a case or that reveals your intention to conduct a security audit or reveals how you conduct security audits should not be shared. It could lead you to prosecution in the first case (depending on where you are in the world) and to failing trivially in the second and third. But after putting a reasonable amount of thought on which information is valuable to share and which should not -- a dichotomy that is mostly dependent on the context (laws, business rules, gravity of incidents handled, etc) --, it becomes relatively straightforward to come up with a mean to share it. And I believe the lead on this must be taken by the security team, of course with the approval and support of the higher management, because that team owns the information in the first place.

Moreover, sharing incident information inside one organization is a very good first step but I am also for sharing incident information between organizations of the same business domain, and even across domains when it makes sense. Anonymization of data is then key, of course. You do not want to be able to identify the origin of the information shared. An independent, trusted "information broker" then needs to be put in place for that matter. A good example of such a broker in the banking world (mostly) is NCFTA (http://www.ncfta.net/). Their business model is very well laid out in my opinion and it works. Nothing is perfect but the information they collect and network among their partners enables detection, analysis and mitigation of attacks and even international prosecution of the culprits.

There is certainly more to discuss about but incident information sharing is not something to discuss about but to act about :-).

Cheers,

Fred

@varmapano