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...
  • 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...
  • SANS WhatWorks Summit in Forensics and Incident Response
    I wanted to remind everyone about the SANS WhatWorks Summit in Forensics and Incident Response in DC, 8-9 July 2010. The Agenda looks gre...
  • 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...
  • Sguil 0.7.0 on Ubuntu 9.10
    Today I installed a Sguil client on a fresh installation of Ubuntu 9.10. It was really easy with the exception of one issue I had to troubl...
  • Microsoft Updates MS09-048 to Show XP Vulnerable to 2 of 3 CVEs
    Microsoft published a Major Revision of MS09-048 to show that Windows XP Service Pack 2 and Windows XP Service Pack 3* are now Affected So...
  • Understanding Responsible Disclosure of Threat Intelligence
    Imagine you're hiking in the woods one day. While stopping for a break you happen to find a mysterious package off to the side of the t...
  • Embedded Hardware and Software Pen Tester Positions in GE Smart Grid
    I was asked to help locate two candidates for positions in the GE Smart Grid initiative. We're looking for an Embedded Hardware Penetr...
  • BeyondTrust Report on Removing Administrator: Correct?
    Last week BeyondTrust published a report titled BeyondTrust 2009 Microsoft Vulnerability Analysis . The report offers several interesting ...
  • Human Language as the New Programming Language
    If you've read the blog for a while you know I promote threat-centric security in addition to vulnerability-centric security. I think ...

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