Considerations About a Successful SIEM and Log Management Project

You may spend a lot of effort to build up an infrastructure of SIEM and Log Management composed of source systems, connectors, loggers, rule creation and correlation engines and management systems and then see very little of valuable output….if you do not pay attention to the first thing you actually do in the first place: Define a proper auditing policy.

A recent and very successful approach for building Log Management and SIEM capabilities actually consists of an inverse installation process. Some Security Service Providers come and collaborate with your teams to apply defined risk scenarii on your infrastructure to see if your infrastructure components generate the log messages which should alert you that something unusual and odd is going on. It is at this very step that your SIEM team learns which type of events they should be collecting among a big pile of others, which in many cases constitute most of your log storage without actually providing a value.

Such an approach may create huge differences in outputs and may trigger changes in your infrastructure. I know companies which changed some of their components just because they do not provide essential log information which would allow security alert generation.

A very important thing to keep in mind when deploying SIEM solutions is the involvement of all infrastructure and application teams. No matter how qualified IT Security guys responsible for SIEM deployment, they do not master Operating Systems as much as Windows, Linux and UNIX administrators do, also considering different versions of OSes that can be in place. To my experience, I know that 3 generations of Windows Servers coexist in majority of companies without counting R2 versions. It goes the same way for databases and applications. A SIEM project would probably fail or underperform if all IT teams do not collaborate with SIEM project team and stay isolated in their silos.

Another way of dealing with this issue would be to create a security team composed of security masters in each domain. First difficulty in that approach is to bring together such talents which is very costly and the second challenge is to keep them in the company and provide consistency because such people are highly in demand. This option seems applicable only in very large structures such as multinationals, especially in finance sector where there really are some things to be at stake, money and also reputation.

There are of course lots and lots to say about other aspects of SIEM and Log Management projects. But maybe the most important things to know about them are to set the expectations correctly (Benefits, Aim: “Security?, Compliance?, Both?”, Scope, Schedule and Budget), be patient, provide continuous support and monitor the output closely. The technology in this market is rapidly evolving and it still has much more to offer in years to come.

SIEM Deployment - Collecting Logs from Windows Servers

An important step in SIEM deployments is to collect logs from servers on which your infrastructure, applications and middleware run.

The event collection from servers is to be seen in the 2nd step in a 3 step approach in SIEM deployment, first step being network and network security devices and last step being the applications.

Microsoft proposes a well-designed log collection infrastructure with 2 options left to the administrators. Both methods use WinRM protocol and are safer than collecting logs using RPC.

In the first method, the collector server connects to event sources and pulls the logs with the help of a domain user which is added to the Event Log Readers group. This method is known as “Collector Initiated Event Forwarding” in Microsoft world and can be better remembered as PULL method. This is the easier method but does not scale well in large environments and may be inefficient as the collector server should regularly contact event sources whether they have logs to transmit or not.

In the second method, which I will detail more in this article, event sources push logs to a collector server over http or https. This method is known as “Source Initiated Subscription” and can be better remembered as PUSH method. This method scales much better to larger environments and is definitely more secure when https option is used as transmission protocol. This method requires less configuration when configured through Group Policy. However special attention must be paid for the collector server when logs are sent over https, especially about listener configuration as it is not that well documented on Microsoft’s documentation and needs good system administration skills.

EVENT SOURCE CONFIGURATION

First of all, the winrm service should be activated from the command line with winrm quickconfig command.

In the Local Group Policy Editor, under Computer Configuration -> Administrative Templates ->  Windows Components -> Event Forwarding menu, “Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager” setting should be configured as below:

            

At this point you can prefer to use http or https protocols to transmit your logs to the collector server. The only difference at the event source is the port numbers used for http and https protocols which are 5985 and 5986 respectively as shown below:

Server=http://Servername.Domain:5985/wsman/Subscription Manager/WEC,Refresh=60

Server=https://Servername.Domain:5986/wsman/Subscription Manager/WEC,Refresh=60

Log sending period is chosen as 60 seconds in these examples.

 Once event forwarding configuration is done, the group policy must be updated with  gpupdate /force command.

 In Local Security Policy screen, audit policy settings under Security Setttings -> Local Policies ->  Audit Policy should be configured. It is recommended to enable logging for both successful and failed attempts for all policy items except “Audit object access”, as this setting may generate too many logs if both successful and failed attempts are logged. I recommend configuring this setting only for failed attempts for the beginning and deciding later according to the criticality of the server.

EVENT COLLECTOR CONFIGURATION

First of all, Windows Event Collector service and WinRM service should be enabled from the command line by using wecutil qc and winrm qc commands respectively.

 After this step, Event Viewer is launched and a new Subscription should be created by right clicking on Subscriptions menu item and selecting Create Subscription or selecting from the menu on the right.

Once the Create Subscription window opens, for source initiated subscriptions settings are configured as below.  These settings largely depend on your own needs however there are real life experiences to follow such as collecting logs in “Hardware Events” destination as logs from this folder are correctly parsed at Arcsight and need no further efforts.

Subscription name: Event collection

Destination log: Hardware Events

Subscription type: Source computer initiated

  

Configuration ends after this step and if there are no problems, like firewall rules blocking the traffic, you should be seeing transferred logs in your target log collection folder. The best way to check if there is a problem or not is to use "Runtime Status" option from the menu on the right.

For more details you can read the Technet article below:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb870973(v=vs.85).aspx

Introduction to Security Event and Log Management

Starting from this article, I will share my experiences and insight on Security Event Management and Log Monitoring. I hope you will find some useful information for yourself in them.

To start with: maybe the most important point to know at the start of a SIEM project is to correctly set the expectations from such project. As very important sums of money and effort are put to these projects, the expectations of several units of your company (not only the IT by the way) may be very high.

So, at the kick-off it is important that you know and make sure that others understand:

• that a SIEM solution is not a big box where different parts of IT throw all their logs until the day they will need it. The importance of “Security” word in SIEM must be underlined. Even though by the very nature of SIEM systems, they are considered as Big Data systems but so far they are only “Big Data like” and maybe they should stay so. Peer Teams in IT should take their time to think which category or type of alerts they have to keep, to find out an anomaly in their own systems or which can be meaningful when it comes together with other piece of information.
•  that sizing is one of the critical steps of SIEM project’s success. A strict sizing in such projects is of course impossible but EPS numbers should be guessed with up to 20% accuracy. After that comes the decision of retention period. Most admins would enjoy seeing what website your colleague in the next cubicle visited a year ago but for an effective forensic analysis, a period from 3 to 6 months is advised to be aimed. A failure in not correctly predicting the storage size may cost you having your critical log data overwritten when you most need it. Not to forget, these numbers are also important for the financials, software licenses and appliances sizes and sometimes even the solution architectures change according to the number of logs to be processed.
• that SIEM projects may be huge and should not be tried to be swallowed at once, your company choke while doing so. A wise approach would be to start with Security and  Network Security systems including but not limited to Firewalls, UTMs, IPSs, VPN boxes, Access Control Systems (Radius, Tacacs+), Web Application Firewalls, DOS protection devices, NACs, Load Balancers, Wireless Controllers and Endpoint Security Systems. After these should follow the Infrastructure components, namely OSs and Middlewares of your critical systems. At the last step, you will finally be ready for integrating your applications, which obviously is the most laborious and time-consuming part as several teams will have to come together and discuss.
• that you should document your project very well. SIEM systems are like those puzzles with thousands of pieces and almost every company cooks that soup to its own taste. The way you collect the logs, reduce them and correlate them largely differs. Without proper documentation, you may have serious problems in roll-outs, troubleshooting and handing it over to somebody else or even outsourcing.
• that even to everybody is into it and the technology is very promising, it is still a reactive solution. It will help your company to discover important breaches, learn from important misconfigurations and mistakes and improve your incident response skills and practices but that is all. Everything still depends on your agile, well-documented and respected incident response procedures… Unless you deploy SIEM as a compliance box or to show off your C-level executives.

      After taking into consideration these important facts, you are ready to start choosing your SIEM product. I will mention about SIEM product selection criteria in my next article, before diving into more detail on implementation.