Saturday, January 27, 2007

What Do I Want

If you've read this blog for a while, or even if you've just been following it the last few months, you might be saying "Fine Bejtlich, we get it. So what do you want?"

The answer is simple: I want NSM-centric techniques and tools to be accepted as best practices for digital security. I don't say this to sell products. I say this because it's the best chance we have of figuring out what's happening in our enterprise.

NSM means deploying sensors to collect statistical, session, full content, and alert data. NSM means having high-fidelity, actionable data available for proactive inspection when possible, and reactive investigation every other time. NSM means not having to wait to hire a network forensics consultant who brings his own gear to the enterprise, hoping for the intruder to make a return appearance while the victim is instrumented. I'd like to see organizations realize they need to keep track of what's happening in their enterprise, in a content-neutral way, similar to the services provided by a cockpit voice recorder and a flight data recorder (CVR, FDR).

This is critical: what does content-neutral mean? The CVR doesn't start recording when it detects the pilot saying "help" or "emergency." The FDR doesn't start recording when the plane's altitude drops below 1000 feet. Rather, both devices are always recording, because those who deploy CVRs and FDRs know they don't know what will happen. This is the opposite of soccer-goal security, where you pick a defensive method and possibly miss everything else.

Network-centric access control, implemented by firewalls and the like, is pretty much a given. (I'm not talking about NAC, which is an acronym for Cisco's Network Admission Control and not Network Access Control, for pity's sake.) Ignoring the firewall-dropping folks at the Jericho Forum and Abe Singer, everyone (especially auditors and regulators) recognizes firewalls are necessary and helpful components of network security. This is undeniably true when one abandons the idea of the firewall as a product and embraces the firewall as a system, as rightly evangelized by Marcus Ranum and described in the Firewall FAQ:

2.1 What is a network firewall?

A firewall is a system or group of systems that enforces an access control policy between two or more networks. The actual means by which this is accomplished varies widely, but in principle, the firewall can be thought of as a pair of mechanisms: one which exists to block traffic, and the other which exists to permit traffic. Some firewalls place a greater emphasis on blocking traffic, while others emphasize permitting traffic. Probably the most important thing to recognize about a firewall is that it implements an access control policy.


Notice this description doesn't mention Pix, or Checkpoint, or Pf, or any other box. Those words apply equally well to router ACLs, layer 3-4 firewalls, "IPS," "deep packet inspection" devices -- whatever. It's about blocking and permitting traffic.

Returning to the main point: we've got to get network visibility and awareness as deeply into the digital security mindset as network-centric access control (via firewalling). How can you possibly consider blocking or permitting traffic if you don't even know what's happening in the enterprise? NSM will answer that question for you. Build yourself a network data recorder today, and learn to interpret what you're seeing. You'll sleep worse in the beginning, but better as you get a grip on your security posture -- managing by fact, not belief.

5 comments:

bjarte said...
This comment has been removed by the author.
bjarte said...

Hi Richard

Just one question. Why is application-logs (NAT-, FW-, WEb-logs and so on) not on your list of collectible data? I find this type of data very useful.

Dr Anton Chuvakin said...

My question exactly: this is waaaaay too network focused for many cases...

Where are the app logs? Where is all the loca, non-network stuff? Desktop logs?

Alex said...

Richard said:

"How can you possibly consider blocking or permitting traffic if you don't even know what's happening in the enterprise?"

Bingo.

A creative analyst will be able to take the techniques that Richard espouses and use them to truly *understand* the network. Thus, NSM traffic analysis will generate more targeted and effective risk mitigations, whether via ACL, IPS, or what have you.

Not to oversell NSM, but the same traffic analysis techniques often come in pretty handy when troubleshooting application and network issues. :)

Richard Bejtlich said...

Regarding logs: I addressed this issue here and I alluded to integrating other sources of data here when I said "I know some of you believe that my Network Security Monitoring (NSM) methodology works and is the best option available for independent, self-reliant, network-centric collection, analysis, and escalation of security events."

At some point I may post my reasons why logs are not the ultimate solution, but that is not part of my argument now. I agree logs can be useful but they are not part of what I call self-reliance.