Tuesday, January 30, 2007

New Cisco MARS Deployment Guide

Cisco have published a new Deployment Guide for CS-MARS.

This document provides guidance on how to best deploy Cisco® Security Monitoring Analysis and Response System (MARS), an appliance-based, all-inclusive solution that provides unmatched insight and control of your existing security deployment. It discusses, among other topics, how to position the appliance in your network, how to tune it, and how to implement a distributed scenario.



This document is for security engineers, network engineers, engineering managers, and the network and security operations staff that plan, design, and implement security monitoring with MARS.

The document is based on a MARS 4.2.x release.


Monday, January 29, 2007

CS-MARS Case Management

One of the many features of CS-MARS is Case Management.

The Case Management feature can combine and preserve user selected MARS data, in a special report called a CASE.


Why would we want to do this?

Well when we see suspicious behavior alerted to us by MARS, we may want to tie multiple incidents together and keep a textual log, of what action/s the MARS admins have taken regarding these events. This level of information may be needed later for legal/audit/forensic use.

So what information can we add to a Case?

The following data can be added to a case...
  • Text Annotations
  • Incident ID Page
  • Incident Device Information - Source IP/Destination IP Device Info. Reporting Devices
  • Session Information Page
  • Query Results Page
  • Report Results Page
  • Build Reports Page
  • View Case Page (the current case can reference a different case!)

As an example, take the investigation of Peer-to-Peer software on the network.

A case has been created and assigned to a user on the MARS box.


The MARS user logs onto the box, and selects the CASE to work with...

Now reviewing the other incidents that have fired, he/she decides that there a few that they would like to group together for further investigation. This is achived via the "Add This Incident" button.


And maybe they want to add some comments, or re-assign to a different user....


Or maybe add a Device or Source IP/Destination IP Address information into the Case...




And Session information....


And maybe we have run some queries against a particular host, and want to add the results of those queries into the case...



And lastly, maybe we want to reference a different case, that has already been created...


Once done, and we view our case, we will see all the data collated together...



Now if we click on the "View Case Document" button, on the bottom of the CASE, we will see that CASE in full detail, with all the incident and session information expanded, as if we were viewing the individual Incident/Session Pages. This complete display can be emailed, by clicking the email button, and then a MARS user selected.



Any user can create or alter any case, and also add or remove incidents from the case, but this is all tracked in the CASE history.


In order to change or add to a case, we need to select it first, by simply clicking on the case, when found on the dashboard, (or via the Incidents TAB/Cases) or in the To-do List. This particular case is then always highlighted at the top of the dashboard. Once finished we can deselect the case.

Since in many environments multiple users are logging into the MARS box under different usernames, we can also assign cases to different personnel, and only the cases relevant to that particular user will appear under the To-Do List, on the main CS-MARS console.


Another thing to be aware of, is that once a CASE is created, it cannot be deleted. Hell No!, the auditors would just do their nut! It can be closed or resolved. Once in this state it can still be added to, but the status of a closed case cannot be changed.


In the Incident View, we can also narrow down the displayed Incidents, by CASE status, of New,Open, Assigned, Resolved or Closed.


Case information collected together builds up your forensic evidence pertinent to Audits, Policy Change Justifications, MARS False Positive Tuning and examples of allowed and prohibited behaviour.

The information collected by a CASE is preserved. ie, the data that is displayed within a case, is as it was, when the data was actually added to the case, regardless of subsequent changes to the MARS state.

So for example, the CS-MARS data can be purged due to disk partitions being full, (remember earlier articles), the topology can change etc.. but the data reported within a case remains the same as the time it was captured.



Thursday, January 25, 2007

CS-MARS User Group Sign Up

I`ve had great interest in the Cisco MARS User Group, with lots of people signing up.

A few of you though, have had problems, getting an approval email back.

If you have had any problems getting on, please email me direct.

I have also added a signup link to the group opposite.

Tuesday, January 23, 2007

Cisco MARS User Group

For those of you interested, there is a new Cisco MARS User Group that has been created, in google groups, with discussions around MARS features/problems/Useful Resources etc.....

To join go here

Friday, January 19, 2007

Cisco Security Advisory: SSL/TLS Certificate and SSH Public Key Validation Vulnerability

Posted: January 18, 2007

Summary: The Cisco Security Monitoring, Analysis and Response System (CS-MARS) and the Cisco Adaptive Security Device Manager (ASDM) do not validate the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) certificates or Secure Shell (SSH) public keys presented by devices they are configured to connect to. Malicious users may be able to use this lack of certificate or public key validation to impersonate the devices that these affected products connect to, which could then be used to obtain sensitive information or misreport information.

Affected Products
The following products are affected by the vulnerability described in this document:

Cisco Security Monitoring, Analysis and Response System (CS-MARS)

All CS-MARS versions prior to 4.2.3 are affected.

Cisco Adaptive Security Device Manager (ASDM)

All ASDM versions prior to 5.2(2.54) are affected when the ASDM Launcher (the stand-alone version of ASDM) is used.

Cisco has made free software available to address this vulnerability for affected customers.

URL:
http://www.cisco.com/en/US/customer/products/products_security_advisory09186a00807c517f.shtml
(available to registered users)

http://www.cisco.com/en/US/products/products_security_advisory09186a00807c517f.shtml
(available to non-registered users)

Thursday, January 18, 2007

Guest Article - MARS Overview


I have great pleasure in releasing another guest Article (PDF Presentation), to the Cisco MARS Blog.



Edgar Reinke is a senior consultant with Netfarmers, a leading German Consultancy and Training Company, specializing in Enterprise/ISP security, Unified Communications and as he would term Big Clouds (MPLS, QoS, TE, IPv6, BGP-4, OSPF, IS-IS).

This PDF presentation gives an unbiased overview of Cisco MARS, and also provides some insight into the operation and flow of event data. (sample below).

Archiving - Remote Storage Capacity in Days

I blogged a couple of weeks ago, regarding the Remote Storage in Days value, when Archiving.

I had come across an error, where by only a single directory was being created, and no data.

I believed at the time it was due to the Remote Storage Capacity in Days value. I had some comments on this, so i thought i would test this out.

So i set my archiving value to 1 day



And let it run for a couple of days. The correct operation is that, older data will be deleted from the NFS Archive, and from my tests, Yep, that is what happens!





So as can be seen, 1 full days archive is still present on the archive server.

So i have pulled the previous article, as it is complete garbage, but i still havent figured out, what caused it!

Still on the subject of Archiving, i received an email from Nathan, who has had an archiving problem recently, on the new 4.2.3 code. He was archiving to a Windows box running Windows Services for UNIX.

He found that the directories were being created, but no data was actually being stored. Looking into his NFS log file on the windows box, he found..

01-17-2007 11:41:31 CREATE SUCCESS 10.X.X.X \DosDevices\C:\archive\testNfsServer
01-17-2007 11:41:32 DELETE SUCCESS 10.X.X.X \DosDevices\C:\archive\testNfsServer
01-17-2007 11:41:37 CREATE SUCCESS 10.X.X.X \DosDevices\C:\archive\testNfsServer
01-17-2007 11:41:38 DELETE SUCCESS 10.X.X.X \DosDevices\C:\archive\testNfsServer
01-17-2007 11:41:43 CREATE SUCCESS 10.X.X.X \DosDevices\C:\archive\testNfsServer

All seemed fine, except there were no WRITE statements in the logs.

The archive process had hung in some fashion and the solution was restarting the MARS services "pnstop > pnstart" and everything went back to normal.



Tuesday, January 16, 2007

CS-MARS with the Cisco VPN Concentrator

The Cisco ASA Firewall/VPN device maybe at the forefront of most Cisco VPN deals recently, but there are thousands of Cisco VPN Concentrators in use around the world.

And coming back to the Integration Series, MARS will accept Syslog from these devices.

Now MARS knows over 150 different events, that can occur on the VPN Concentrator, with a few shown below.


And looking further into the actual events, we can see there is a varied range, of not just Admin logon or off events, but also VRRP, Webvpn etc.



Now looking at an easy to fire Incident, which in this case would be an authentication failure for an Admin account, we can see the reporting device, the rule which fired, and also the actual user that failed authentication.


With the RAW Event message forwarded by the VPN Concentrator.


Now the benefit of any event management system is the ability to query the data, either historical events or in real time.

Below i have run a real time query, but searching for a particular event type, which is to report the VPN Client application version.


But we can query on any source/destination ip, from any number of devices, and also use keywords in the queries. As this last example shows looking for a particular VPN group..



If this post has been of interest, you may also find these posts useful as well, which i have previously posted.

Cisco MARS Integration with McAfee ePO
Cisco MARS Integration with SNORT
Cisco MARS Integration with the Cisco Security Manager - Policy Lookups

And also remember you will find some live demos and PDF copies of some articles over at the Demolabs website.

Monday, January 15, 2007

CS-MARS 4.2.3 Released

A new version of the MARS OS has just been released, version 4.2.3

The release notes for this are here

Whats new in 4.2.3?

The following changes and enhancements exist in 4.2.3:

SSL Certificate and SSH Fingerprint Validation. MARS detects changes in certificates and fingerprints and provides three options for responding to such changes, including initially accepting them.

Major update to 3rd-party signature sets. This release includes many new vendor signatures, updating 3rd-party signature support.

Bug fixes

New Signature Sets


NOTE: There are special Upgrade Instructions releated to this release, in brief below, but i recommend you read the release notes before proceeding.

The 4.2.3 upgrade package is approximately 1.6 GB due to the large number of signatures updated and due to the inclusion of a patch to the database software, which was added to address CSCsg02873. Downloading the PKG file may take up to 7 times longer than previous packages.


Note: Enable archiving on the MARS Appliance for two to three days before you perform you attempt to upgrade from 4.2.2 to the 4.2.3 release. This precaution is strongly recommended in case reinstallation is required due to any encountered errors.


To upgrade from 4.2.2 to 4.2.3, follow these steps:


Step 1 Verify that your MARS Appliance does not have hard drives that are degraded or rebuilding by performing the following steps:

a. At the CLI, enter the following command:

raidstatus

b. Verify that hard drives are neither in rebuilding nor degraded status. If they are, please wait until all hard drives have finished rebuilding before attempting an upgrade.

Step 2 Verify that the MARS Appliance has at least 3GB of space available on the partition /u01 by performing the following steps:

a. At the CLI, enter the following command:

diskuage

One of the lines should describe the /u01 partition:

Filesystem            Size  Used Avail Use% Mounted on
/dev/md3               16G  4.6G   10G  31% /u01

b. Verify at least 3 GB available is available (the example has 10G available).


A nightly process runs to clean up any files that accumulate on this partition. If you have less than 3 GB, there is an issue with your appliance that you must resolve prior to upgrading.


Step 3 Perform the software upgrade. The CLI method is strongly recommended.


Note While the GUI upgrade works, it does not show progress of the upgrade. Use the CLI instead to ensure the progress of the update is known. Do not reboot the appliance until the upgrade has completed.

Step 4 After the automatic system reboot, verify the upgrade by performing the following steps:

a. At the CLI, enter the following command:

pnstatus

b. Verify that all processes are running.

If some processes are not running, you must troubleshoot that issue before proceeding with the upgrade.

c. Enter the following command:

pnupgrade log

d. Verify that the output looks like the following:

pnadmin]$ pnupgrade log
--------------------------------------
   4.2.2 2303   -->  4.2.3 2403
--------------------------------------
1 Preparing upgrade start
  1.1 Load the step table start
  1.1 Load the step table end
  1.2 Stop pnmonitor start
  1.2 Stop pnmonitor end
  1.3 Stop jboss start
  1.3 Stop jboss end
  1.4 Stop other applications start
  1.4 Stop other applications end
1 Preparing upgrade end
2 Upgrade OS start
  2.1 Patch OS start
  2.1 Patch OS end
  2.2 Patch Oracle start
  2.2 Patch Oracle end
2 Upgrade OS end
3 Upgrade schema start
  3.1 Run upgrade schema script start
  3.1 Run upgrade schema script end
  3.2 Backup schema script start
  3.2 Backup schema script end
3 Upgrade schema end
4 Upgrade MARS applications start
  4.1 Untar MARS executable binary start
  4.2 Untar MARS executable binary end
  4.3 Modify janus.conf start
  4.3 Modify janus.conf end
  4.4 Swap MARS executable binary start
  4.4 Swap MARS executable binary end
  4.5 Run post-unpack-deployment start
  4.5 Run post-unpack-deployment end
4 Upgrade MARS applications end
5 Upgrade data start
  5.1 Start jboss start
  5.1 Start jboss end
  5.2 Importing signature data start
  5.2 Importing signature data end
  5.3 Missing-id fix start
  5.3 Missing-id fix end
5 Upgrade data end
6 reboot ...
Upgrade from 4.2.2 2303 to 4.2.3 2403 finished.


If the log does not include the "Upgrade from 4.2.2 2303 to 4.2.3 2403 finished" line, then a problem occurred during the upgrade regardless of whether the version command reports 4.2.3 (2403).