SIEM brief explanation

SIEM aka SEIM, SIM, SEM, ESM, etc. means Security Information Even Management. First letter (word) in the abbreviation S (Security) is a first fun and first problem. Ask accountanter what is accounting data and you’ll get clear answer, same for business analyst, medical assistance, even network analyst. Security specialist 15 years ago would give a same kind of clear answer but ask him right now what is NOT security information – would you expect a clear answer? So here is first problem – we have to manage a huge amount of information.

Last common letter M (Management) means among others that we have to manage relations to whole ITIL set of tasks, forensic analysis (here I mean log based forensic analysis), law enforcement connectivity (and legacy forensic data collection, preserving and presentation), support compliance solutions, etc in additional to common system management set of task (including management of data, events, alerts, etc.). It is a huge amount of work but the work is well defined. Even we have to deal with requirements which is in infinite developing loop (like PCI DSS one) we can predict the vector and could be sure the requirements are in quasi static state (at minimum for one year). Another problem is that a lot of regulations require keeping data unchangeable (regulatory requirements for retaining security event data) and that is in addition to possibility to keep enormous amount of data.

Let’s go now to my loving fun named “Information Event”. What is information and what is event? Here is an example. A man knocks to a door – I am Putin and my password is putin1 .. putin2 … putin3. Let’s make better example. Several persons knocked to different entries of s nuclear station – I am Obama and my password is ….

Couple (name=Putin, password=putin1) is a failed login attempt and is a good example of security data. Let’s integrate this security data (here is new term “data integration process”) with other failed login attempts (in first example we have one source integration, in second one – several sources data integration process) and based on this data we create security event “brute force attack”. Or let’s take another example. Network Behavior Analyzer joined (integrated) all ssh, telnet, hhtp, https, nfs, etc. (which are examples of data) between two segments into a QFlow. We know that this QFlow works only during work hours. If this QFlow appeared at night it would create security event and produce security alert which could suggest us some actions (or just run preconfigured action like IPS module, Incident Response Connectivity, Change Management Connectivity, Mail, Page, etc.). Alerts and Actions are part of Management Process (see above). Real Time Data integration (sometimes in opposite to Data Mining Investigations which is under Management part) and Events Creation require some special processing and a Relational Database, filtering, normalization, etc. which is opposite to messages storage requirements formulated above (requirements for retaining of enormous amount of security event data). This conceptual problem became even worse if we would try to include application functionality into a SIEM like financial, accounting, trade, etc. Mother Nature patents to resolve this kind of problem are:

1. Split functionality. Make data integration and event creation in security source or in data concentration centers (for multiply sources) – surely make it in parallel with non-filtering, non-normalized data forwarding. Use isolated Application SIEM communicated with different parts of the ESM (Enterprise Security Management).
2. Use long / short –term memories with different set of storing / processing rules.

1. There is another reason to split functionality: clear needs of Application SIEM (in our case Financial SIEM).
2. Split functionality implementation does not eliminate need of RDB (Relational Data Base) implementing (short-term memory) in a head SIEM coordinating other systems activity.