Requirements for Defensible Network Architecture: Monitored

Last year I posted Defensible Network Architecture 2.0, consisting of 8 (originally 7, plus 1 great idea from a comment) characteristics of an enterprise that give it the best chance to resist an intrusion.

In this post I'd like to define some specifics for the first of the 8 characteristics: monitored. At some point in the future it would probably make sense to think of these characteristics in terms of a capability maturity model. Right now I'd like to capture some thoughts for use in later work. I will approach the requirements from a moderate point of view, meaning I will try to stay between what I would expect from a low-capability operation and a high-capability operation.

Like my related posts, this is a work in progress and I appreciate feedback.

A Defensible Network Architecture is an information architecture that is:

1. Monitored. Monitored can be described using the following categories, which collectively can be considered intrusion detection operations. (Add in Response or Resolution, depending on your IRT's mandate, and you have the CAER model for security operations.)




• Collection. The following technical data is collected and available to the security operations team.




• Network Security Monitoring (NSM) data from passive sensors; note the NSM data must depict true source IP and true destination IP (i.e., monitoring traffic between a NAT gateway and a proxy means seeing only the source IP of the NAT gateway and the destination IP of the proxy, radically decreasing the value of the observed traffic)




• Alert data from devices making judgements while inspecting network traffic


• Statistical data summarizing network traffic


• Session data describing conversations in network traffic


• Full content data providing traffic headers and payloads




• Infrastructure Security Monitoring data from routers, firewalls, switches, so-called intrusion prevention systems, and other network infrastructure that actively manipulates network traffic, or provides fundamental network services; by "fundamental services" I mean services that, without which, nothing much else works, e.g., DHCP, DNS, BGP




• Access Control logs that report on allowed and denied traffic


• Infrastructure logs that report DHCP address assignments, DNS queries and responses, BGP routing tables, etc.




• Platform Security Monitoring data from nodes (laptops, desktops, non-infrastructure servers, etc.)




• Operating system security logs, like Windows Event Logs


• Application logs, like Web server logs, Web application logs, etc.


• Platform memory, preferably exposing memory segments as needed (think retrieving a live system registry) or the entire memory (think ManTech DD plus Volatility)






• Analysis.




• A dedicated team analyzes technical data collected in the previous stage.


• The team has access to subject matter experts who can answer questions on the nature of threats, vulnerabilities, and assets in order to better understand the risk posed by monitored activity.


• Analysis is understood and supported by management as a creative task that cannot be "automated away." If automation were possible for detecting intrusions, the same automation could be applied to preventing them. ("If you can detect it, why not prevent it?") Assuming everything detectable is preventable, by definition the analysis team is left to identify activity which is most likely not easily detectable, or at least not easily validated as being malicious.




• Escalation.




• The team has defined categories to identify the nature of intrusions and non-intrusions.


• The team has defined severity levels describing the impact of various types of intrusions.


• The team has an escalation matrix summarizing the stes to be taken given an intrusion of a specific category and severity.

You should monitor at trust boundaries, to the extent you perceive risk and have the technical and legal resources to do so. (For more on trust boundaries with respect to monitoring please see NSM vs Encrypted Traffic, Plus Virtualization and NSM vs Encrypted Traffic Revisited.

I will stop here, but continue with Inventoried when I have time.

---

Richard Bejtlich is teaching new classes in Europe and Las Vegas in 2009. Online Europe registration ends by 1 Apr, and seats are filling. "Super Early" Las Vegas registration ends 15 Mar.