SecurityCertified

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Wednesday, August 12, 2009

Question on NSM Scaling

Posted on 7:40 AM by Unknown
A long-time TaoSecurity Blog reader sent me the following question:

I have a question about scaling NSM in regards to large, complex enterprises that transmit countless gigabytes of data per day.

Last month I interviewed for a position with a large wireless company and the hiring manager was familiar with your work, so as I attempted to extol the value of NSM and explain how I thought that NSM could benefit this organization, I was told by the hiring manager that he felt that NSM worked with small organizations, but did not scale well with organizations of a certain size.

I am curious if you have ever had to counter this type of argument and how you addressed it.


This is a common question. I'll need to address it concisely and precisely in an updated edition of Tao. A few recent posts come to mind, like Requirements for Defensible Network Architecture: Monitored, NSM vs Encrypted Traffic, Plus Virtualization, and Network Security Monitoring Lives. A few principles come to mind.

  • Concentrate on infrastructure you own, not necessarily infrastructure you support. In other words, I don't advocate full NSM for ISPs watching customer links. That may be the issue mentioned in the question, i.e., a wireless company might think NSM is inappropriate for watching customer traffic. I would probably agree with that.

  • Monitor at trust boundaries. The places where the infrastructure you own touches infrastructure you do not own is likely to be the place where you need additional visibility.

  • Monitor what you can, given your technical, political, and legal constraints. You may not be able to continuously capture full content data on 10 Gbps links with commodity hardware, or even specialized hardware. If that is too expensive, then don't do it. However, deploy the capability to capture at those locations when necessary. Better to be prepared than to struggle with workarounds or emergency deployments in a crisis.

  • Solutions can be engineered for almost any environment. I guarantee organizations larger than those in the question are already doing intense monitoring. If you don't believe me, look at the history of wiretapping during the last administration. Outside of that case, organizations like mine are deploying hundreds of sensors around the world. NSM can scale if you engineer it properly and hire people who know what they are doing!

  • Don't make NSM a hammer and every security problem a nail. NSM is one way to gain visibility and situational awareness. It may be worthless to deploy sensors doing traditional NSM on a link that only sees SSL-encrypted traffic between two point systems, or between the Internet and a SSL-only system. In cases like that, the first option might be to deploy host-centric monitoring and logging on the asset in question.


Thank you for questions like these -- please keep sending them. They make good sections for a new book.
Email ThisBlogThis!Share to XShare to Facebook
Posted in nsm | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • DojoCon Videos Online
    Props to Marcus Carey for live streaming talks from DojoCon . I appeared in my keynote , plus panels on incident response and cloud secur...
  • Practice of Network Security Monitoring Table of Contents
    Since many of you have asked, I wanted to provide an updated Table of Contents for my upcoming book, The Practice of Network Security Monito...
  • Mandiant APT1 Report: 25 Best Commentaries of the Last 12 Days
    Two weeks ago today our team at Mandiant was feverishly preparing the release of our APT1 report . In the twelve days that followed public...
  • Feedback from Network Security Monitoring 101 Classes
    At Black Hat in Las Vegas I taught two Network Security Monitoring 101 (NSM101) classes. This is a new class that I developed this year, a...
  • A Book for the Korean Cyber Armies
    I've got a book for the Korean cyber armies, North and South. That's right, it's my first book , The Tao of Network Security Mo...
  • What is Cloud?
    The slide at left was one of my favorites from Craig Balding's Cloud Security Ghost Story talk from Black Hat EU earlier this year. I ...
  • SQL Injection Challenge and Time-Based Security
    Thanks to this Tweet by @ryancbarnett, I learned of the lessons learned of the Level II component of the ModSecurity SQL Injection Challen...
  • Bejtlich Speaking at TechTarget Emerging Threats Events in Seattle and New York
    I will be speaking at two events organized by TechTarget , for whom I used to write my Snort Report and Traffic Talk articles. The one-da...
  • BeyondTrust Report on Removing Administrator: Correct?
    Last week BeyondTrust published a report titled BeyondTrust 2009 Microsoft Vulnerability Analysis . The report offers several interesting ...
  • President Obama Is Right On US-China Hacking
    I strongly recommend watching the excerpt on the Charlie Rose show titled Obama: Blunt Conversation With China on Hacking . I reproduced the...

Categories

  • afcert
  • Air Force
  • analysis
  • announcement
  • apt
  • attribution
  • bestbook
  • blackhat
  • books
  • breakers
  • bro
  • bruins
  • certification
  • china
  • cisco
  • cissp
  • cloud
  • clowns
  • commodore
  • conferences
  • controls
  • correlation
  • counterintelligence
  • cybercommand
  • cyberwar
  • dfm
  • education
  • engineering
  • feds
  • fisma
  • freebsd
  • GE
  • ge-cirt
  • hakin9
  • history
  • impressions
  • information warfare
  • ipv6
  • law
  • leadership
  • malware
  • mandiant
  • microsoft
  • mssp
  • nsm
  • offense
  • oisf
  • packetstash
  • philosophy
  • pirates
  • powerpoint
  • press
  • psirt
  • reading
  • redteam
  • reviews
  • russia
  • sans
  • sec
  • sguil
  • snorby
  • spying
  • threat model
  • threats
  • Traffic Talk
  • training
  • tufte
  • tv
  • ubuntu
  • usenix
  • verizon
  • vulnerabilities
  • wisdom
  • writing

Blog Archive

  • ►  2013 (16)
    • ►  September (1)
    • ►  August (1)
    • ►  June (2)
    • ►  April (2)
    • ►  March (1)
    • ►  February (3)
    • ►  January (6)
  • ►  2012 (60)
    • ►  December (4)
    • ►  November (5)
    • ►  October (3)
    • ►  September (10)
    • ►  August (2)
    • ►  July (6)
    • ►  June (6)
    • ►  May (4)
    • ►  April (2)
    • ►  March (9)
    • ►  February (6)
    • ►  January (3)
  • ►  2011 (108)
    • ►  December (3)
    • ►  November (7)
    • ►  October (11)
    • ►  September (9)
    • ►  August (18)
    • ►  July (10)
    • ►  June (5)
    • ►  May (4)
    • ►  April (13)
    • ►  March (17)
    • ►  February (2)
    • ►  January (9)
  • ►  2010 (193)
    • ►  December (14)
    • ►  November (11)
    • ►  October (6)
    • ►  September (16)
    • ►  August (15)
    • ►  July (26)
    • ►  June (15)
    • ►  May (15)
    • ►  April (15)
    • ►  March (16)
    • ►  February (19)
    • ►  January (25)
  • ▼  2009 (123)
    • ►  December (10)
    • ►  November (17)
    • ►  October (21)
    • ►  September (13)
    • ▼  August (20)
      • Draft Version of New Keeping FreeBSD Applications ...
      • SANS WhatWorks in Incident Detection Summit 2009 W...
      • Draft Version of New Keeping FreeBSD Up-To-Date
      • Renesys Blog on Routing Vulnerabilities
      • New Must-Read Blog Series from Mike Cloppert
      • Updating FreeBSD Using CVSup through HTTP Proxy
      • Three Free Issues of BSD Magazine in .pdf Format
      • Hakin9 04/2009 Issue
      • Manga Guide to Statistics vs Statistics in a Nutshell
      • GE Is Hiring in Michigan
      • Attack Models in the Physical World
      • Review of The Myths of Security Posted
      • Incident Detection Mindset
      • Build Visibility In
      • Question on NSM Scaling
      • Thoughts on Security Careers
      • 2009 CDX Data Sets Posted
      • SANS Incident Detection Summit in DC in December
      • Review of IPv6 Security Posted
      • Blast from the Past
    • ►  July (21)
    • ►  June (21)
Powered by Blogger.

About Me

Unknown
View my complete profile