Earth to MARS

Disclaimer: I'm going to single out a book by Cisco employees that talks about a Cisco product. I have no personal feelings about Cisco. I have friends there. I've done work for Cisco. Since I think Cisco is eventually going to own all network security functions in their switches, I may even work for Cisco one day.

This post is for all product vendors who approach understanding and defending the network in the ways described here. Wherever you read "Cisco" feel free to add products that share the characteristics I outline below.

Once again I found myself hanging in the sky last week. Trips to and from the West Coast gave me the opportunity to read Security Threat Mitigation and Response: Understanding Cisco Security MARS by Dale Tesch and Greg Abelar. This is mainly another Cisco marketing book, like Self-Defending Networks: The Next Generation of Network Security by Duane DeCapite. While I have a few thoughts on the book, I would much rather address the underlying philosophy presented by the authors. I'm fairly sure they're only repeating Cisco market-speak, but I hear the same message from many vendors, consultants, and individuals.

In this post I'd like to take issue with that message. In short, almost nothing about the approach taken by Cisco MARS (and similar products) is new or will "solve" your security problems. Unless you augment tactics and technologies like MARS, you will find yourself wondering why you spent time and effort to end up as frustrated and confused as you were pre-MARS.

I'll refer to this book as STM, short for the Security Threat Mitigation term in the title. STM is supposed to be "beyond Security Information Management" (SIM). According to STM, the five core SIM functions (pp 6-7) are:

• Collect event data


• Store data


• Correlate to show relationships (what the book calls "true power")


• Present data


• Report on, alarm on, and/or notify about data

STM starts to knock the value of SIMs by introducing the idea of "garbage in, garbage out," saying "information or events from several different sources can be 'garbage' unless they are put together in a useful way." I disagree -- garbage in always produces garbage out. The idea that a ton of garbage can be turned into something valuable (like gold from coal) is the fallacy of SIM/SEM technology.

The book tries to position "STM" as "beyond SIM" by granting STM the following attributes:

• Data reduction


• Timely attack mitigation


• End-to-end network awareness


• Integrated vulnerability assessment


• Session correlation

You are probably think what I am thinking; how is that really different from a SIM/SEM? I bet all the SIM/SEM vendors are saying "we do that already."

Things start to get really weird when the authors talk about the "advantages of a proactive security framework" (pp 14-15) compared to what everyone else must be using. STM says:

The key to this framework is the network's capability to behave actively. This does not necessarily mean to take action itself, but to automatically collect data from numerous sources and come to a decision..." (emphasis added)

... so that a person can react like we've always done. It is intellectual dishonesty to claim this product (or any other) is acting "actively" when the end result is still waiting for a person to react. Mind you, I'm not knocking reaction. Too many people seems to think proactivity is king and reactivity is evil, but sometimes there's no other option. It bugs me that Cisco is packaging manual "shunning" in a new wrapping and calling it "self-defending" and "active" when the end result is a person having to make a reactive decision.

The real problem is far more insidious, however. As has always been the case with alert-centric products, there is not enough data available to make a decision. In other words, Cisco MARS, like other products, still cannot tell me if an attack was successful.

More absurdity appears in the section (p 15) on "false-positive reduction," where three methods are given for MARS to "determine the validity of event data." They are, basically:

1. Network topology


2. Vulnerability assessment via limited network scanning


3. User determination

So, we have 1) could the attack reach the target? Guess what -- if it's a TCP connection it probably did. Next we have 2) scan to see if the IIS attack hit an Apache server; limited at best, worthless at other times. Finally -- and this kills me -- 3) let the user decide. How is this better than anything else again?

The section "Enhancing the Self-Defending Network" adds insult to injury by naming three "missing links" in the SDN addressed by STM:

1. Automated log correlation


2. Automated threat response


3. Automated mitigration

We know SIM/SEM does #1. A product that accomplished 2 and 3 would be impressive, but guess again -- MARS does neither automatically:

Automated mitigation is not yet achievable because many security devices still put out false-positive alerts, but CS-MARS makes a recommendation for mitigation and offers security responders a single click to deploy commands on devices that will stop offending traffic after the responder has analyzed the attack data. (emphasis added)

Again, it all comes back to having the data necessary to make a decision, and then letting an analyst make the decision. There's nothing proactive or special here.

STM emphasizes the speed with which one can respond, but how can an analyst even know to start the escalation process? The end of chapter 3 presents a case that aims to show "ROI" for MARS based on shutting down a spreading virus faster than a non-MARS solution. Here's the core of the problem, however:

The virus starts trying to infect other hosts... [MARS sends] an email page... to a security responder 24 hours a day, 7 days a week... The security responder gets the page and logs into CS-MARS.

And that's faster or better how?

STM demonstrates real ignorance of the sorts of data an analyst needs to make decisions regarding security events. On MARS, "forensic analysis" is "visual tools for attack-path analysis and attack propagation" (p 82) or mapping NAT'd IPs to public IPs or IPs to MAC addresses. "Attack validation" (i.e., should I worry?) is knowing "if an attack actually reached the intended destination." Furthermore, p 89 says:

[U]pon detecting an anomalous behavior, CS-MARS starts to dynamically store the full NetFlow records for the anomalous activity. This intelligent collection system provides all the information that a security analyst needs. (emphasis added)

Wrong. What else does MARS offer? Page 127 says "retrieval of raw messages" is available as a download of a zipped text file! I bet that's easy to manipulate when trying to understand alerts. On pp 229-230 we see examples of the sort of "incident ID" data available to analysts -- almost all of which is unactionable and worthless. On MARS, the analysis process consists of looking at a rule MARS used to generate an alert and then guessing at the relationship between the rule and events listed in the "detailed data" section.

I think the real problem with this approach is demonstrated by the case studies in chapter 9, which I guess Cisco sees as a validation of their approach. We read about a Trojan found at a state agency via an IDS alert (no different from non-MARS). We see a .edu respond using MARS because phone calls prompted an investigation of traffic on port 25! We read about a hospital that used a spike in traffic to a Web server as a reason to investigate the Web server (wow). A financial firm investigates high ICMP traffic, and a small business sees odd DNS names in its weekly MARS reports to find another company using its wireless access point. Honestly, is this supposed to make me a believer?

If you want to know how I recommend dealing with this and similar situations, I've already written about it. In brief, analyst must have high-fidelity, original, content-neutral data sources to investigate. That is the key term here. If you do not have such data (as provided by NSM) to investigate, you are doing alert management. And you will lose.

So what is MARS (and similar products) good for? In short, there is value in centralizing and presenting events from disparate security products. There is value in having a single window into that world, with some sort of accountability, escalation, and case management. There is value in being able to contain network-centric exploitation via centralized device control. Just remember that making the decisions to protect the enterprise requires having the proper data. NSM is one way to get that data.