SecurityCertified

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

Monday, November 23, 2009

Control "Monitoring" is Not Threat Monitoring

Posted on 4:25 PM by Unknown
As I write this post I'm reminded of General Hayden's advice:

"Cyber" is difficult to understand, so be charitable with those who don't understand it, as well as those who claim "expertise."

It's important to remember that plenty of people are trying to act in a positive manner to defend important assets, so in that spirit I offer the following commentary.

Thanks to John Bambanek's SANS post I read NIST Drafts Cybersecurity Guidance by InformationWeek's J. Nicholas Hoover.

The article discusses the latest draft of SP 800-37 Rev. 1:
DRAFT Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach
.

I suspected this to be problematic given NIST's historical bias towards "controls," which I've criticized in Controls Are Not the Solution to Our Problem and Consensus Audit Guidelines Are Still Controls. The subtext for the article was:

The National Institute for Standards and Technology is urging the government to continuously monitor its own cybersecurity efforts.

As soon as I read that, I knew that NIST's definition of "monitor" and the article's definition of "monitor" did not mean the real sort of monitoring, threat monitoring, that would make a difference against modern adversaries.

The article continues:

Special Publication 800-37 fleshes out six steps federal agencies should take to tackle cybersecurity: categorization, selection of controls, implementation, assessment, authorization, and continuous monitoring...

Finally, and perhaps most significantly, the document advises federal agencies to put continuous monitoring in place. Software, firmware, hardware, operations, and threats change constantly. Within that flux, security needs to be managed in a structured way, Ross says.

"We need to recognize that we work in a very dynamic operational environment," Ross says. "That allows us to have an ongoing and continuing acceptance and understanding of risk, and that ongoing determination may change our thinking on whether current controls are sufficient."

The continuous risk management step might include use of automated configuration scanning tools, vulnerability scanning, and intrusion detection systems, as well as putting in place processes to monitor and update security guidance and assessments of system security requirements.


Note that the preceding text mentions "intrusion detection systems," but the rest of the text has nothing to do with real monitoring, i.e., detecting and responding to intrusions. I'm not just talking about network-centric approaches, by the way -- infrastructure, host, log, and other sources are all real monitoring, but this is not what NIST means by "monitoring."

To understand NIST's view of monitoring, try reading the new draft. I'll insert my comments.

APPENDIX G

CONTINUOUS MONITORING

MANAGING AND TRACKING THE SECURITY STATE OF INFORMATION SYSTEMS

A critical aspect of managing risk from information systems involves the continuous monitoring of the security controls employed within or inherited by the system.65

[65 A continuous monitoring program within an organization involves a different set of activities than Security Incident Monitoring or Security Event Monitoring programs.]


So, it sounds like activities that involve actually watching systems are not within scope for "continuous monitoring."

Conducting a thorough point-in-time assessment of the deployed security controls is a necessary but not sufficient condition to demonstrate security due diligence. An effective organizational information security program also includes a rigorous continuous monitoring program integrated into the system development life cycle. The objective of the continuous monitoring program is to determine if the set of deployed security controls continue to be effective over time in light of the inevitable changes that occur.

That sounds ok so far. I like the idea of evaluations to determine if controls are effective over time. In the next section below we get to the heart of the problem, and why I wrote this post.

An effective organization-wide continuous monitoring program includes:

• Configuration management and control processes for organizational information systems;

• Security impact analyses on actual or proposed changes to organizational information systems and environments of operation;67

• Assessment of selected security controls (including system-specific, hybrid, and common controls) based on the organization-defined continuous monitoring strategy;68

• Security status reporting to appropriate organizational officials;69 and

• Active involvement by authorizing officials in the ongoing management of information system-related security risks.


Ok, where is threat monitoring? I see configuration management, "control processes," reporting status to "officials," "active involvement by authorizing officials," and so on.

The next section tells me what NIST really considers to be "monitoring":

Priority for security control monitoring is given to the controls that have the reatest volatility and the controls that have been identified in the organization’s plan of action and milestones...

[S]ecurity policies and procedures in a particular organization may not be likely to change from one year to the next...

Security controls identified in the plan of action and milestones are also a priority in the continuous monitoring process, due to the fact that these controls have been deemed to be ineffective to some degree.

Organizations also consider specific threat information including known attack vectors (i.e., specific vulnerabilities exploited by threat sources) when selecting the set of security controls to monitor and the frequency of such monitoring...


Have you broken the code yet? Security control monitoring is a compliance activity. Granted, this is an improvement from the typical certification and accreditation debacle, where "security" is assessed via paperwork exercises every three years. Instead, .gov compliance teams will perform so-called "continuous monitoring," meaning more regular checks to see if systems are in compliance.

Is this really an improvement?

I don't think so. NIST is missing the point. Their approach advocates Control-compliant security, not field-assessed security. Their "scoreboard" is the result of a compliance audit, not the number of systems under adversary control or the amount of data exfiltrated or degraded by the adversary.

I don't care how well your defensive "controls" are informed by offense. If you don't have a Computer Incident Response Team performing continuous threat monitoring for detection and response, you don't know if your controls are working. The NIST document has a few hints about the right approach, at best, but the majority of the so-called "monitoring" guidance is another compliance activity.
Email ThisBlogThis!Share to XShare to Facebook
Posted in controls | 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)
      • Real Security Is Threat-Centric
      • Celebrate FreeBSD 8.0 Release with Donation
      • Historical Video on AFCERT circa 2000
      • Tort Law on Negligence
      • Review of Martin Libicki's Cyberdeterrence and Cyb...
      • Shodan: Another Step Towards Intrusion as a Service
      • I'm Surprised That Your Kung Fu Is So Expert
      • Control "Monitoring" is Not Threat Monitoring
      • Audio of Bejtlich Presentation on Network Security...
      • Traffic Talk 8 Posted
      • Extending Security Event Correlation
      • Embedded Hardware and Software Pen Tester Position...
      • Reaction to 60 Minutes Story
      • Notes from Talk by Michael Hayden
      • Bejtlich on Security Justice Podcast
      • DojoCon Videos Online
      • Tentative Speaker List for SANS Incident Detection...
    • ►  October (21)
    • ►  September (13)
    • ►  August (20)
    • ►  July (21)
    • ►  June (21)
Powered by Blogger.

About Me

Unknown
View my complete profile