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".
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".
