Tag Archives: SIEM

Cisco Smart Business Architecture (SBA) guides for SIEM solutions integration

Cisco provide some useful Smart Business Architecture (SBA) guides for SIEM solutions integration how will helps you to design and deploy best practices that include Cisco switching, routing, security and wireless technologies.

Actually the SBA guides are covering the following solutions :

  • SBA guide how provides a general overview of SIEM technology, as well as best practices, use cases, and deployment considerations for using a SIEM with Cisco infrastructure (click here to read). Cisco products logging retrieval methods,
  • SBA guide for ArcSight SIEM plateform (ESM, Logger, Express, SmartConnectors and Content Pack) integration (click here to read).
  • SBA guide for Loglogic MX Series SIEM product integration (click here to read).
  • SBA guide for netForensics nFX Cinxi One SIEM product integration (click here to read).
  • SBA guide for RSA enVision SIEM product integration (click here to read).
  • SBA guide for Splunk security management solution (click here to read).

Why And Howto Calculate Your Events Log Size

If you are projecting to start a Log or Event Management project, you will surely need to know your Normal Event log size (NE). These Normal Event log size (NE) value, combinated with the your Normal Events per second (NE) value and with your storage retention policy will help you to design in order to estimate your storage requirements.

Never forget that Log Management storage requirements are not the same for Event Management. Most of time Log Management storage requirements are higher than for Event Management. For example for Log Management, PCI-DSS v2.0 Req. 10.7 require 1 year retention :

10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).

But in order to compensate PCI-DSS v2.0 Req. 10.6, you will maybe do Event Management with a SIEM (like ArcSight ESM, RSA enVision, QRadar SIEM, etc.).

10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for
example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6

You don’t need a SIEM to do Log Management, but you also don’t need to store 1 year of your logs on your SIEM solution. Long term retention, long term reporting, “raw” events forensics are mostly done on a Log Management infrastructure (like ArcSight Logger, QRadar Log Manager, Novell Sentinel Log Manager, etc.). Storage retention for your Event Management infrastructure will depend mostly on your correlation rules, your acknowledge time on a correlated event, the number of security analysts present in your SOC, etc.

Don’t imagine that a magic formula exist to define your events log size, some tools could help you, but you need to analyze your logs in order to have your Normal Event log size.  First of all you have to define your Log and/or Event Management scope, this scope could first be driven by regulations or compliances, but don’t forget that regulations or compliances are not Security. Also each technologies have different log sizes, an Apache HTTPD log will not have the same size than a SSHD log, and an Apache HTTPD log from server A will surely not have the same size than an Apache HTTPD log from server B.

xxx.xxx.xxx.xxx - - [25/Aug/2011:04:23:47 +0200] "GET /feed/ HTTP/1.1" 304 - "-" "Apple-PubSub/65.28"

This log from Apache HTTPD server A has a size of 102 bytes.

xxx.xxx.xxx.xxx - - [25/Aug/2011:04:15:08 +0200] "GET /wp-content/themes/mystique/css/style-green.css?ver=3.0.7 HTTP/1.1" 200 1326 "http://eromang.zataz.com/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.20) Gecko/20110803 Firefox/3.6.20 ( .NET CLR 3.5.30729)"

This log from Apache HTTPD server B has a size of 274 bytes.

Also, depending the Log or Event Management infrastructure product, you need to consider event generated by intrinsically mechanism. For example, in order to search in your events most of products are creating indexes, these indexes are representing an average of twice the time of the size of the event. Also another intrinsically mechanism is that these products are also monitoring themselves, regularly executing tasks, do some statistics for dashboards or reports.

I have develop a bash script how will permit you to analyze all your archived logs and gather the following informations:

  • For each archived files, the total number of events, the total uncompressed size of the events, the Normal Event log size.
  • The total events for all archived files.
  • The total uncompressed size of all events in all archived files.
  • The grant total Normal Event log size.
  • The average event number per archived files.
  • The average bytes per archived file.

You can download this script by clicking on this link. A reminder, the provided Normal Events per second value, is not your real EPS rate, just check my previous blogpost regarding on “Why and howto calculate your Events Per Second“.

Why and howto calculate your Events Per Second

Each time I ask a CISO, or a technological expert, on their number of events per second (EPS), I receive each time the same “No idea.“, “A lot of events“, “EPS WTF ?” answers. Most of actors are not sensibilized and/or don’t understand the key design factor of EPS metrics during the enumeration and scope design phase of a Log or Event Management (SIEM) project. Why are EPS metrics so important ?

EPS metrics usages

These EPS metrics will help you to determine and provide you responses to :

  • Acquire an appropriate Log or Event Management solution

Most of Log & Event Management vendors arguing that their products are supporting thousands of events per second. And surely their products are designed to support this number of EPS, and surely the vendor will ask questions about your EPS metrics. Most of time, if it is not an appliance, Log & Event Management solutions are supported by others tiers hardware and software’s. You will surely have a dedicated servers (with a limited amount of CPU, RAM & NIC), a SAN storage connexion (with a limited amount of size, I/O, speed, etc.), an attached external database (with all their own critical metrics), a backup solution, network bandwidth, etc. The EPS metrics will help you to design a part of your architecture and determine a part of your costs (CAPEX / OPEX). More EPS you will have more you will need an scalable and available architecture. If you acquire a Log or Event Management appliance solution, you will be limited de-facto by the vendor solution.

To not determine the EPS metrics during a Log or Event Management solution acquisition process, will surely make you acquire a solution how is oversized or undersized in front of your real initial scope needs. But never forget, EPS rate is only one factor to make the final selection of your Log or Event Management solution.

  • Respond appropriately to compliance’s and/or regulations

If you have compliance’s and/or regulations, how require Log & Event Management retention policies, the EPS metrics will help you to determine your online and offline storage requirements. Your retention policies period are indicated by compliance’s and/or regulations, but your storage requirements not. How many Giga or Tera bytes will you need to respond to your retention policies period ?

  • Improve your Capacity Management

During you day to day operation of your Log & Event Management solution, your storage requirements have to be monitored to ensure that the capacity meets current and future business requirements in a cost-effective manner. EPS metrics, based on a baseline, will help you to improve your application sizing, your performance management and to create a Capacity Planning.

Depending  on your EPS metrics, you will maybe have to redesign your technical infrastructure by adding clustering concept to your SIEM solution, creating an out-of-band network to deal with bandwidth limitations, etc.

  • Improve your Incident Management

Once you have an EPS baseline per device and/or per infrastructure, if you see an abnormal variation in your event rate flow, it will maybe indicate your that an unauthorized change has be done, or that a device has a misconfiguration, or that you are maybe under attack.

  • Improve your Service Level Management

As MSSP (Managed Security Service Provider), if you determine with your customer, during the scope definition, an EPS metrics baseline, it will be more easy for you to include EPS guaranties and/or limitations in the SLA. EPS metrics could be integrated in a SLA, same as for network bandwidth, and include concepts such as “burstable EPS“, “Peak EPS” and “EPS – 95th percentile“…

  • Provide some useful KPI’s

Once you have an EPS baseline, you will be able to gather some interesting KPI’s, for examples, total audited events during a period of time, EPS versus correlated events, etc.

And they are surely other good reasons to determine your events per second 🙂

EPS metrics definitions and methodology

The best definition of EPS metrics, I have read, are available in the SANS Whitepaper “Benchmarking Security Information Event Management (SIEM)” published in February 2009. I will do a recap of the metrics definitions and the methodologies on how to to create your EPS baseline.

They are two EPS metrics definitions :

  • Normal Events per second (NE) :The NE metric will represent the normal number of events usage time for a device, or for your Log or Event Management scope.
  • Peak Events per second (PE) :The PE metric will represent the peak number of events usage time for a device, or for your Log or Event Management scope. The PE represent abnormal activities on devices you create temporary peaks of EPS, for example DoS, ports scanning, mass SQL injections attempts, etc. PE metric is the more important cause it will determine your real EPS requirements.

Depending of the activities and your SIEM infrastructure, you will have these metrics for both activities, NE and PE for Log Management, and NE and PE for Event Management. A Log Management solution will have his own EPS limitations how are not the same as the Event Management solution limitations. This case is depending on your futur Log & Event Management infrastructure, if you will have a Log management solution in front of the Event Management solution, you will be able to filter out unnecessary events from the Log Management solution to the Event Management solution. I really recommend you to split the activities by dedicated solutions.

Also, to have valuable EPS metrics we recommend you to do analyse a period of 90 days of logs. The analyzed logs should represent all your normal and peak activities. If you analyse only a short period of time, your EPS metrics will surely not represent the truth.

Methodology :

  • Define your scope !

To define your initial scope, please ask you simple questions. What are your compliance or regulation requirements how need to be in the Log Management scope  ? What are the initial “Use Cases“, or policies, you will monitor through the Event Management solution, etc. The scope definition could be a dedicated blog post, so I will not explain further on how to determine this scope.

  • Scope devices inventory

Identify and do an inventory of all devices how should be integrated into your Log or Event Management scope. By your scope definition you will identify a certain number of required devices, some of these devices are running the same technology (for example : 4 Check Point firewalls, 2 Apache Web servers, etc). These identical devices don’t have the same roles and activities, so they will surely have a different EPS metrics.

  • Identify logs location and required events

For each device, identify the logs location, the logs retention period and in these logs file identify the required events to respond to the “Use Cases” or policies monitoring. In case of Log Management, please log everything. For Event Management, if you will have a Log Management solution in front of the Event Management solution, you will only need certain logs patterns. Identify these logs patterns and extract them into dedicated log files. Event Management is not to log everything, don’t consider your SIEM solution as a long term storage solution, the long term storage role is for Log Management.

You will then probably have 1 original log file for the Log Management scope, and one deviated log file for the Event Management scope.

  • Identify NE and PE metrics for devices and get the PE grand total

Here come the logfu and mathematics things. You will need some shell skills to extract all necessary information’s, and simple use Excel to analyse them.

Identify all your devices PE rates and sum all PE numbers to come up with a grand total for your environment. It is unlikely that all devices in your scope will ever simultaneously produce events at maximum rate.

Example of PE rate analysis

In this example (Google Docs), I have an IDS exposed to Internet, and I will do some statistical analysis. We will analyse 1 month logs to determine the PE metrics for this device. First gather the number of events per day and calculate you average and median EPS per day (Number of events per day / 86400 seconds). In this example I have an average EPS rate of 0.03 and a median EPS rate also equal to 0.03. But as you can see I have 12 days how have an average EPS rate above 0.03, and I have also one average EPS peak rate of 0.08.

We will zoom on the 2011-04-10 how as an average EPS peak rate of 0.08, to determine the exact average EPS peak rate for this day. The representation will be all events by minutes. We can see that the PE is located between 09:42 PM and 09:59 PM. We can also find that our PE rate, with a minute interval on the entire day, is now 6.27 (number of events per minutes / 60) and no more 0.08!

We will zoom in this time interval to identify more precisely our exact PE and we will represent all events per seconds. We can see that the real PE rate is equal to 12 and not 6.27 !

As described by this example, if you don’t analyse precisely logs, you will not able to determine your exact NE and PE rate. The PE grand total rate is clearly not representing a real PE rate, but will help you to not have a Log or Event Management solution how is undersized in term of EPS limitations.