Perimeter
1/4/2013
03:40 PM
Wendy Nather
Wendy Nather
Commentary
Connect Directly
RSS
E-Mail
50%
50%

You Keep Using That Word ...

When monitoring doesn't mean what you think it does

I don't like to get all "me too" on a topic, but I really enjoyed the back and forth on Richard Bejtlich's blog as Bejtlich and commenters discussed what "monitoring" means. It's pretty clear that everyone's using the word, but they're differing on the purpose of the monitoring itself.

One of the use cases I see often is "monitoring for risk." Now, risk is a slippery word in and of itself, as the squabbling on risk analysis mailing lists can demonstrate. It should always be accompanied by the word "of" to describe what you mean by it. Is it the risk of not being compliant? Is it the risk of not having your systems configured the way you want them? Or is it the risk of a breach?

When you are "monitoring" something, it needs be a transitive verb that comes with an object as well as a purpose. You are monitoring the network to look for changes in routing configuration. Or you're monitoring your users to look for activities that appear unusual. You are monitoring your security program to make sure you are spending your budget on the right things.

Some other uses (or perhaps misuses) of the word "monitoring" can refer to checking continuously against a set of requirements to make sure they're still being met. This is where "monitoring systems for compliance" comes in. If you are monitoring business processes to make sure they are being completed, or monitoring a vulnerability list to see whether new entries apply to your software, then that's different from monitoring system performance so that you can respond to latency or crashes.

The one thing that really bugs me is the conflation of "monitoring for compliance" with "monitoring for effectiveness." You may be scanning your systems to see whether they are all configured the way you want them to be (or the way you last left them), and you may scan them to see whether they have new vulnerabilities. But that's not the same as measuring the effectiveness of your controls -- as in, whether they are actually preventing or detecting intrusions. You may be 100 percent compliant with your intended controls -- but if their control levels are set to "stupid," then they're not going to stop an attack. And if your controls are set to be as restrictive as possible, but they're still getting bypassed in another way, then they're ineffective.

This, by the way, is also the difference between an audit and a penetration test, which is why compliance does not equal security. One tests the state of controls, and the other tests the results.

So I can certainly see how it can be frustrating to have a purported monitoring program in place that is checking for some things, but not others. Monitoring your program to see whether you are monitoring for intrusions is not only meta enough to make my teeth hurt, it's also saying nothing about how well you're doing it or whether you're already compromised. It's the difference between having syslog running (as required by a checklist), collecting those logs (check), collecting enough of them over the right period of time (check), actually reading them often enough to catch something, and understanding what you're reading. I'd even add "being able to act on that understanding" because monitoring without response capability is pretty useless.

Next time you're tempted to talk about "monitoring risk," try to do so without using either of those words. It may end up taking more sentences to describe what you mean, but it'll probably be clearer in the end. And talk about it in terms of purpose: why you are doing it, and what you are supposed to get out of it. That should differentiate the goals of compliance and effectiveness.

Wendy Nather is Research Director of the Enterprise Security Practice at the independent analyst firm 451 Research. You can find her on Twitter as @451wendy. Wendy Nather is Research Director of the Enterprise Security Practice at independent analyst firm 451 Research. With over 30 years of IT experience, she has worked both in financial services and in the public sector, both in the US and in Europe. Wendy's coverage areas ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-3304
Published: 2014-10-30
Directory traversal vulnerability in Dell EqualLogic PS4000 with firmware 6.0 allows remote attackers to read arbitrary files via a .. (dot dot) in the default URI.

CVE-2013-7409
Published: 2014-10-30
Buffer overflow in ALLPlayer 5.6.2 through 5.8.1 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a long string in a .m3u (playlist) file.

CVE-2014-3446
Published: 2014-10-30
SQL injection vulnerability in wcm/system/pages/admin/getnode.aspx in BSS Continuity CMS 4.2.22640.0 allows remote attackers to execute arbitrary SQL commands via the nodeid parameter.

CVE-2014-3584
Published: 2014-10-30
The SamlHeaderInHandler in Apache CXF before 2.6.11, 2.7.x before 2.7.8, and 3.0.x before 3.0.1 allows remote attackers to cause a denial of service (infinite loop) via a crafted SAML token in the authorization header of a request to a JAX-RS service.

CVE-2014-3623
Published: 2014-10-30
Apache WSS4J before 1.6.17 and 2.x before 2.0.2, as used in Apache CXF 2.7.x before 2.7.13 and 3.0.x before 3.0.2, when using TransportBinding, does properly enforce the SAML SubjectConfirmation method security semantics, which allows remote attackers to conduct spoofing attacks via unspecified vect...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.