U.S. Daylight Savings Time (DST) Changes

New U.S. Daylight Savings Times rules go into effect in March 2007. Consequently, customers whose network components rely on the default CS-MARS U.S. clock settings will be affected by the following problem:

For operating systems that have not been updated with the new U.S. DST policy changes, timestamps will exhibit a one hour time clock offset lasting three weeks beginning at 2 A.M. on the second Sunday in March of 2007. They will also exhibit a one hour time clock offset lasting one week beginning at 2 A.M. on the first Sunday in November.

Solution:

Upgrade to: csmars-4.2.4.2428.pkg. All prior versions will be affected by the change in DST.

New Custom Parser Demo available on demolabs.co.uk

There is a new CS-MARS demo available on the Satisnet Demo Website, Demolabs.co.uk


This demo is the first in a series of Custom Parser Demos

I hope to write a couple of articles on the Custom Parser very soon, but the above demo is about as basic as the custom parser gets.

We can simply fire syslog at MARS and do a keyword search on unknown events. (In fact the demo is a little smarter in that we define a custom device first, and thus we could add more similar devices, and report on them individually)

Security Monitoring With Cisco Security Mars

There is a new MARS book going to hitting the shelves, around April time.

Security Monitoring With Cisco Security Mars, is by Gary Halleen and Greg Kellogg.

I managed to get in contact with one of the authors Greg Kellogg , to find out what this new book will offer Cisco MARS users.

A description of the book, in Greg`s own words "This book is intended to be a medium-to-advanced level reference. Customers will use it to plan a MARS deployment, and then learn the installation tasks and day-to-day tasks an analyst can expect to face. Additionally, Security Monitoring with CS-MARS will teach the analyst how to use the advanced features of the product, such as the custom parser and hierarchical deployment models.

Security Monitoring with CS-MARS will use a series of real-world case studies to lead the reader through all steps of these very important tasks:

• Proper deployment design and sizing.
• Understanding of what information can be gained from monitoring various types of security devices, as well as network session data through netflow.
• Basic installation and troubleshooting of the appliances.
• Forensic analysis of security incidents.
• Tuning of the appliances, as well as how to plan for automated tuning.
• Large-scale deployments using a Global Controller.
• Modification and creation of reports, queries, and rules.
• Updating of MARS software and rulesets.
• Integration of MARS with Cisco’s Security Manager software.
• Using MARS to report on Cisco’s Network Admission Control.
• Integration of third-party vulnerability assessment tools.

Part One of the book introduces the reader to SIM products, and then describes STM and MARS, as well as some of the issues a customer faces in a multi-vendor environment. A summarized description of some of the most common regulatory issues a customer faces will follow.

Part Two of the book will focus on design and deployment issues. It will answer common questions, like “How do I know how many of which appliances I need?” It also explains, at a high level, how to install MARS.

Part Three will focus on operations and security forensics. Day-to-day tasks of the security analyst will take the bulk of this portion of the book. “How do I properly investigate a security incident?”

Part Four will dive into advanced topics. Using real-world examples, the reader will learn how to make best use of the custom parser, customer rules, as well as reports and queries. Additionally, Part Four describes in detail how CS-MARS is used in other technologies, like Network Admission Control and Distributed Threat Mitigation. "

Well i must thank Greg for that, i`m sure we`ll all look forward to reading this book on its release.

For our readers a bit about Greg Kellogg, ex-Cisco/Protego, now works for Calence , a 500 people company spanning 22 Markets, Headquartered in Tempe, Arizona.

Calence is a Cisco Gold Partner, specialized in IP Communications, Security (including MARS), Wireless and Advanced Technology Provider for IP Contact Centers, Rich Media Communications and Optical-Metro.

CS-MARS 4.2.4 Released

Release notes for this release are available here

Cisco Security Monitoring, Analysis, and Response System Implementation Service

Cisco have released details on the implementation service for MARS...

"The Cisco Security MARS Implementation Service, designed for large enterprises, provides the expert network analysis, planning, design, and implementation assistance your organization needs to design and deploy an effective Cisco Security MARS solution.

Availability and Ordering

The Cisco Security MARS Implementation Service is available through Cisco and Cisco partners globally. Details may vary by region."

Now this is not an extensive list, but Cisco Partners with knowledge of MARS i know of are Satisnet (UK) , Netfarmers (Germany), Priveon , Covetrix and Calence (USA).

Cisco MARS 4.3

No wait, it isnt out yet! But there has been some more info released on the Cisco Website about this. verison. (requires CCO login)

I must take my hat of to Cisco though, apart from the title of the document, it mentions very little about what is new in version 4.3

I`m guessing but the 2 items below, sound new to me...

• Automated, verified updates, including device support, new rules, and features

• Support for off-appliance authentication via RADIUS

Anyone got any comments?

Guest Article - MARS Inspection Rule Throttling

Appologies for the lack of posts this week, but i have been working hard on a NAC Appliance Project with Satisnet.

I do have great pleasure though, in providing another Guest Article by Matthew Helman, who works for a fortune 250 financial services company in the US, and has been using the MARS product since it was purchased by Cisco in late 2004.

Inspection Rule Throttling

The inspection rules are truly the heart and soul of the CSMARS system. Each inspection rule represents a particular threat and defines the conditions that, when met, are the realization of that threat. Unfortunately, there doesn’t seem to be detailed technical documentation that describes how the inspection rules work. Conceptually, they’re a relatively easy thing to understand and are described well enough. However, knowing how the various criteria, in particular time range, affect the firing of rules is necessary in order to understand and predict rule behavior. The information below is not complete, but it does at least provide a baseline for validating that CSMARS is working as expected. Specifically, it does not address the complexities of a typical rule, with multiple offsets and using the “special” variables.

Rules can be in one of 3 states as described below:

1. Ready state. The rule is not currently being throttled. It will be checked every 5 seconds. It will fire if new matching events have been received in the last 5 seconds. Once the rule fires, the state automatically advances and throttling starts.
2. 5 minute throttle state. The rule is checked every ~5 minutes. It will fire if new matching events have been received in the last 5 minutes. State advances if rule has fired twice while in this state. State resets to “ready” if no matching events in last "time range from rule".
3. 10 minute throttle state. The rule is checked every ~10 minutes. It will fire if new matching events have been received in the last 10 minutes. State resets to “ready” if no matching events in last "time range from rule".

The following scenario is contrived and simple, but illustrates the behavior described above well enough:

You have an inspection rule that matches a specific IPS alarm. The rule has a single offset that looks for that alarm and has a count of 1. The time range for the rule is 5 minutes. The rule has never fired before and so currently is in the “ready state” and checked every 5 seconds for readiness to fire. At midnight, CSMARS starts receiving that IPS alarm every 3 minutes. A total of 5 alarms are sent and they are exactly the same every time (same tcp 5-tuple).

12:00:00AM. 1st IPS alarm received.
12:00:03AM. Rule checked for readiness to fire. FIRE! Rule state advanced to 5 minute throttle.
12:03:00AM. 2nd IPS alarm received.
12:05:03AM. Rule checked for readiness to fire. FIRE! Rule state still 5 minute throttle.
12:06:00AM. 3rd IPS alarm received.
12:10:03AM. Rule checked for readiness to fire. FIRE! Rule state advanced to 10 minute throttle.
12:09:00AM. 4th IPS alarm received.
12:12:00AM. 5th IPS alarm received.
12:20:03AM. Rule checked for readiness to fire. FIRE! Rule state reset to “Ready”.

Other Important facts:

• Despite a barrage of conflicting information from Cisco, rules appear to work off events and not sessions. This comes directly from Cisco TAC and jives with observed behavior. I can easily create a single session that fires the same rule twice. Each incident will refer to the same session but will have a time range from a subset of the events contained in the session.

• The timing of the readiness checks described above is somewhat vague, but predictable. It is ABOUT 5 seconds, 5 minutes, and 10 minutes.

• Within a 3 second period, if there are multiple events of the same event type (whether or not they are from different devices) belonging to the same session (same flow/five tuple), only the first event will be considered in the rule.

Collaborative Threat Control: Securing the Whole Network

Cisco released a news article yesterday, revealing the updates to many products in the Security Portfolio.

Read about it here.... or summarised on Mikes Mars Blog here, hopefully MARS 4.3 is just around the corner then!

Cisco® today announced significant new capabilities for enhanced collaboration among several products and services in its security portfolio, simplifying the ability for organizations to control and contain information security threats in a more coordinated, flexible fashion across networks while streamlining management and protecting confidential communications to remote users.

The collective enhancements involve Cisco's Intrusion Prevention System (IPS), Cisco Security Agent (CSA), Cisco Security Mitigation Analysis and Response System (CS-MARS), Cisco Security Manager (CSM) and Cisco's Secure Sockets Layer virtual private network (SSL VPN). Together, the enhancements mark the latest evolution of Cisco's Self-Defending Network - a comprehensive framework incorporating various endpoint and network security products into an integrated, collaborative and adaptive security solution for organizations of all sizes.

Cisco's enhanced security portfolio includes Cisco IPS 6.0, CSA 5.2, CS-MARS 4.3, and CSM 3.1 - four products that combine to coordinate visibility, network-wide protection, simplified policy management and dynamic threat mitigation in order to maintain business continuity. These releases strengthen Cisco's approach to coordinated defense by extending beyond the typical standalone nature of these product classes and establishing a vital relationship between the network and its endpoints. This helps ensure that all potential entry points can be protected in a coordinated fashion.

Guest Articles and User Group

I`m always on the lookout for Cisco Partners who have MARS experience, to share information here on the blog.

I`ve already been let down by a couple of US based resellers, but i`m sure there must be some MARS experts out there somewhere!

If you are interested in writing an article, please get in contact.

Also remember, you can post your MARS Questions on the Cisco MARS User Group, join below...

http://groups.google.com/group/cs-mars-ug?hl=en-GB

Connection to Remote NFS Archive Fails

What happens when your NFS Archive Server goes down?

Well i must admit, i was surprised earlier today, when changing some configs in the LAB, that i received an email from my MARS box, telling me the NFS Archive was unreachable.

I`m not sure if this is a new feature, or its always been in there, but it looks like MARS will automatically email the Adminstrator email address, every 2 hours if the NFS is unreachable.

Now i will try to confirm this, but i cannot find a MARS rule for this event. (Unless someone can point me to one?)

So it looks like this is backend stuff.