poniedziałek, 29 kwietnia 2013

SIEM deployment


I would like to start with quick reminder and then share my feelings and comments about SIEM deployment.  Reviewing magazines and  security portals revealed that SIEM subject got so popular,  that everyone is talking about it, constantly exchanging ideas and views. It seems that more often drawbacks and issues as discussed, but on the other hand, the knowledge about security monitoring (NSM) becomes wider and easier accessible. How to understand the potential of security data center, and how to look at SIEM deployment? Let me share my humble opinion.

What is SIEM?

SIEM is responsible for gathering, filtering, normalizing, aggregating , and correlating events coming from multiple data sources, and changing them into valuable information in security data base. Data is stored  as events, flows and records from external feeds and may generate potential security alert – offence. All of these should be performed in real-time, or near real-time.


Logs – this type of information is taken from different operating systems, and network devices. Usually, SYSLOG is used as a standard protocol for pushing logs remotely.  On the other hand, some systems and infrastructure architecture demands installing additional software on remote host, just to allow them to send logs via network. What is more, protocols such OPSEC LEA, SNMP, JDBC/ODBC (pooling) need another way of configuration, and this can be - in some circumstances - a tricky task.

Flows – some SIEM solutions have mechanisms to handle network layer information, and provide details about network flows (session data). These are netflow, JFlow, SFlow. Somehow this capability can be compared to NBAD systems (Network Behavior Anomaly Detection), and we end up with combo SIEM+NBAD.

External feeds – SIEM is building its own static information about each host in the monitored network. We can call it ‘asset’, as it contains data about names, addresses, MAC, timing, usernames, vulnerabilities (vulnerability scanner)  etc. What is more, records from external databases can feed our SIEM and provide additional contextual details to our correlating engine  (blacklisted domains, records for compliance purposes, list of privileged users and so on).

Full package capture technology – several SIEMs have capability to perform deep packet inspection and capture, which provides the ability to identify traffic up to layer 7, and also has content capture capabilities. This means that SIEM can identify applications regardless of port (dynamically allocated ports or tunnels, port-independent applications). What is more, full package is captured – not only headers (session data) but also data.



Why SIEM and who needs it?

I googled the answers, and  I want to quote three of them, as I find them completely  describing the situation, giving interesting reads:

A lot of industries need SIEM for compliance purposes. SIEM is a big part of HIPAA, HITECH, GLBA, and Sarbanes Oxley. The penalties for non-compliance can reach staggering amounts. Beyond the regulatory requirements and penalties, healthcare and financial services organizations face a greater business risk due to volume of sensitive data they store and the associated impact of a damaged reputation related to a breach.
From a business perspective, SIEM is usually a compliance and regulatory  requirement for most certifications. One of the major advantages gleaned  from implementing an SIEM solution is the perspective it brings to the  organization’s security posture, accessibility and the usable metrics it generates. All analysis and dashboards are available on a single console to  aid decision making. Given the security edge an SIEM solution it gives an organization, careful  consideration is due prior to procurement.
The SIEM market is evolving towards integration with business management tools, internal fraud detection, geographical user activity monitoring, content monitoring, and business critical application monitoring. SIEM systems are implemented for compliance reporting, enhanced analytics, forensic discovery, automated risk assessment, and threat mitigation. 
According to RSA survey primary usage of SIEM solution are Security operations, then IT and network operations, ending with compliance and regulatory requirements.

  
SIEM deployment phases

The only phase I want to write about on this stage is the preparation phase. Undoubtedly this is the most crucial part as it contains analyzing needs process,  choosing solution, management software, and others.  According to Gartner and eIQnetworks writings, this stage of planning is very often undervalued and neglected, what leads to delays, expensive mistakes and disappointment. 

The goal is to define what SIEM will be used for. Team and management should focus on choosing the right technology with adequate capabilities that meets their and regulatory requirements.  Are we monitoring infrastructure only for SOX purposes? Do we need to have visibility over all servers in 100 000+ company? Are we responsible for protecting banks, army and other strategic objects? Do we need protection against APT and advanced evasion techniques? What about money and support from support?

Scale estimation is another point. How many log sources will we have? Which machines are generating the biggest traffic? How to deal with logs from FW and other top talkers? Define bottleneck, check network segmentation, and geo-localization. Choosing the right architecture and proper security-infrastructures is essential. How to set collectors and how big disks they have? According to networld magazine, two biggest challenges are: data retention and quick access to data (compression ratio).

Log sources and data quality. Define what information do you want in SIEM. Check and estimate performance on collectors and network. Discuss process of adding log sources with operations teams and support for clarity and understanding.  You may find that crucial log sources cannot be added to your SIEM because some technical issues over network or not sufficient SIEM capabilities.

Processes. Define what processes can be modified, and how to manage them. Prepare list of reports that can be generated by SIEM and check their value. Check your IR process, and see how can it be improved because of SIEM.  Discuss problem of process maturity and additional tools.

Suffering from SIEM Deployments

There is a great work done by several researches and companies, showing problems with SIEM deployment, and what have caused them. Very interesting from management perspective, to see if others have the same issues, and if made the same mistakes.  eIQnetworks conducted a survey, asking for thoughts after deploying standard SIEM in organization. Company published the results and findings:

  • 31 percent of respondents would consider replacing their existing SIEM solution for better cost savings
  • 25 percent of respondents have invested more than a month in professional services since deploying their current SIEM product
  • 52 percent of respondents require 2 or more fulltime employees to manage their current SIEM deployment

RSA came up with the same idea, and ask mid-sized organization a question “If you could change one thing about your current SIEM/log management solution, what would it be?”.

  • Improve alerting to identify only issues that require attention
  • Less expensive
  • Easier to learn and use/ Better user interface

Answers are  very similar to reflections provided by Gartner in “On SIEM Deployment Evolution” article. Gartner concluded with several types or phases of problems. The first one is “stuck in collection” saying, that most companies tend to deploy changes one after another. So when the phase 1 is not completed (adding new log sources) it is not possible to move on to detection and log analysis phase.  “The end result of this is a nice log collection system at 10x the price of a nice log collection system.” Another one “stuck in compliance” describe the situation, when SIEM is bought only to satisfy auditors and regulations: “we have SIEM, we are secure”, nothing more is being done with it. “Stuck in investigations”  type shows the problem with handling incidents, SIEM us used for investigations, not for detection: “organization never matures to security monitoring stage.”

Brightalk webinar on SIEM deployment by Alien Vault

Successful SIEM

I like the statement “it works like a bicycle – you are happy only if you pedal and thus move forward.” According to information found in the net, the best way for a SIEM deployment is constant improvement and development. We are trying to do systematic steps to fully deploy all capabilities of our chosen solution,  having in mind long-term vision. So it is like a combination of operational tasks and strategy.  I suppose, it cannot be called “quick wins process” as SIEM deployment is collection of rather difficult tasks, and demands great engagement, knowledge, budged and skilled personnel.  Checking “The Secret to Successful Global SIEM Deployments” there are high-level steps in planning successful SIEM: The secret to successful global siem deployments
  • Adapt the SIEM to the organizational structure of the business.
  • Create advocates and gain sponsorship within the internal team.
  • Get a complete picture of your networked assets.
Lastly I watched webinar sponsored by Alien Vault (by the way, the best documentation out there!), and great presentation made about SIEM and it's successfull deployment. Not only giving high-level overview, but also describing the situation on the market, constantly evolving threats and methods of 'watching' them. Lecturer has also shown the most important steps in deployment, focusing on uses-cases, incident response and choosing the right solution - marking as the most crucial, and demanding. This talk can be found on brightalk with title "Six Steps to SIEM Success".
Lastly, there was pretty awesome discussion on RSA conference, with statement that there are not many successfully deployed SIEMs , not mentioning these based on Big Data approach. What is more, participants  concluded that, this is not important if we have "big data" or "small data". The most crucial aspect is to focus on incident response processes, processes management, understanding goals and always think about gathered information - how can it be correlated, analysed, what security value is it giving to a bigger picture and investigations. What  I think is, at the end of the day, the only relevant part of any investigation or deployment is human - "human asset".

Brak komentarzy:

Prześlij komentarz