Security through Data Fusion: Contextual Intrusion Detection
The process of writing these articles has clarified my thinking around the terminology of the framework, relating it more closely to existing concepts. As a result I have arrived at this updated formulation of the full “Security through Data Fusion” framework:
Fig. 1: The full framework. Input objects are down the left margin, output objects across the top.
In due time I’ll discuss most of these fields. So far we’ve been mostly following the main (shaded) path of analysis, so let’s proceed to Contextual Intrusion Detection (Relations → Impacts). “Contextual” just means that we’ve performed some level of Situation Assessment, and we’re using that to reveal the security impacts.
The reality today is that security analysts have a good handle on Signature-Based Intrusion Detection (where a human has performed some extensive analysis to boil the problem down to a feature extraction that directly identifies a security-relevant event). We’re far less effective at more advanced techniques involving modeling entities, let alone a more contextual analysis based on situation assessment models.
“Behavioral Modeling” can include elements of entity modeling or more contextual modeling, depending on the details of the approach. The best models include context about the entities that are interacting with each other, whether internal or external. This means systems that use reputation/threat intel for external networks and hosts (or binaries) or internal hosts (based on vulnerability or previously detected suspicious activity). Some startups have been developing such solutions, sometimes focused on particular entity types (e.g. user behavior).
Another approach that has been helpful is to provide data visualizations to allow analysts to apply their subject-matter expertise to detecting intrusions. Here the contextual approach is just as vital, for example visually representing O/S for hosts, user types for users (user, admin, developer, etc.) as well as some anomaly hints based on security-relevant features (e.g. scaled, perhaps non-linear, variables based on login failures or whether this user has commonly logged into this host before).
You’ll notice that this discussion is a lot more hand-wavy than the previous steps up the main ladder of analysis — that’s for two reasons: first, there are a lot of unsolved problems in how to convert the mental process of intrusion detection at this level of abstraction to useful models. As we climb the ladder, we’re also climbing levels of cognitive difficulty and thus fewer opportunities for automation. Second, I do plan to go into more detail in future articles once I’ve laid some more groundwork. In particular, I think a detailed discussion of entity correlations (which you can see on the framework as “Single-entity correlations” and “Multi-entity correlations”) will be useful, but first I need to motivate the need for better models and integrated systems by discussing incident response, and how disconnected it is today from detection analytics and processes.
Next: Incident Response