CS-MARS Deployed in the Enterprise: A Case Study
Utilizing CS-MARS in unique and specific deployments
Abstract by: Dale Tesch
CS-MARS has been successfully deployed across large enterprises for well over three years now. The most common Enterprise deployment I have encountered was segmenting CS-MARS to specific areas of the network, such as a DMZ or a Data Center , and using it for its anomaly detection capabilities. Given MARS has a fundamental strength for detecting anomalies in the network, its many other capabilities have been overlooked and; therefore, have not been fully utilized. I once had a Security Operations Group at a large manufacturing facility tell me they loved MARS capabilities, but it is over-whelming to them because it was "schizophrenic." I could not help laughing when I heard this characterization. Not because what they told me was outrageous or inconceivable; rather, they were absolutely correct and I have never heard of it put so creatively.
The truth is MARS has many different personalities, or, better yet, roles it can play in a network. If you try to use all of MARS' capabilities in a large IT infrastructure, you will get overwhelmed and possibly frustrated with the product. Enterprise CS-MARS deployments need to be focused on a specific security purpose. Otherwise, a large generic CS-MARS deployment gives way too much information to handle. As a result, tuning and filtering through it all can be difficult and time consuming. To solve this problem, we had to restructure their CS-MARS installation and redeploy the CS-MARS local controllers to be used for specific purposes, and not for specific areas of the network. The method we used was similar to the method used in Chapter 9 of the Cisco Press book, "Security Threat Mitigation, Understanding Cisco Security MARS." The chapter outlines three phases of a security incident: Detection, Action, and Resolution. In the following example I used the same approach, but used a design as the solution.
CS-MARS is a two-tier solution that has two physical levels of operation: Local and Global. In this example, they had three CS-MARS Local Controllers (LCs) and one CS-MARS Global Controller (GC). They were using the CS-MARS products by themselves and not integrating them with any other security and IT tools at their disposal. Additionally, the three LCs were placed in different areas of the network. They were put in place to monitor critical IT assets and receive logs from all data sources in the network areas.
When speaking with this group, I asked them to explore a different approach in their deployment. Rather than deploying the CS-MARS LCs to monitor areas of their network, why not deploy the sensors into their network for specific purposes and then tie them to their existing trouble ticketing systems and log collection devices? While redesigning the CS-MARS infrastructure, their objectives never changed; just the deployment methodology. The LCs would be deployed in strategic areas to conduct the following analysis:
- LC #1, a MARS 200 for Day Zero attacks and anomaly monitoring w/topology and vectors.
- LC #2, a MARS 100 for AAA monitoring of all network devices and Domain Controller Logs for Domain Security Policy enforcement.
- LC #3, a MARS 100e for Remote Access and WAN ACL (non-firewall).
- GC, for LC management, global rule creation, reporting device configuration, and parser customization.
All data was to be sent to a log aggregator before being relayed to MARS, instead of using the CS-MARS archiving functionality. This gave them more flexibility in controlling archived data and allowed them more access to the raw logs for use in other forensic tools and scripts. Additionally, instead of using the case tool in the CS-MARS GC and LC, they had trouble tickets automatically opened when specific rules were fired by using the XML/E-mail feature in MARS. This methodology allowed the help desk team,monitoring and tracking trouble tickets, to take over some of the workload from the SecOps team.
By changing their deployment methodology, the SecOps team was able to reduce their workload and refocus their attention on Security Incidents. They still devoted approximately thirty minutes to an hour a day looking through the GC's summary of incidents, and spent another two to three hours per week tuning and tweaking the rule sets in the CS-MARS devices. Now they understood when deploying a SIM solution in an Enterprise Network,operating, tuning, and tweaking the rule sets will never go away; it is a part of normal Security operations and should be placed into operational procedures. The final and most difficult hurdle we ran into was to ensure that change control policy made it mandatory to notify the CS-MARS operators of any network changes, so device and rule sets within CS-MARS could be modified to accommodate those changes.
I hope this example provides a different perspective on how to deploy CS-MARS. It is a very unique and creative product that should be deployed creatively in unique situations. To be successful and stand out in a large group, one must concentrate and develop ones strengths. Even though we have many talents, only a few of those talents separate us from everyone else. CS-MARS should be deployed with the same philosophy in mind.