Sorting out SIEM strategy Five step guide to full security information visibility and controlled threat management

Transcription

1 Sorting out SIEM strategy Five step guide to full security information visibility and controlled threat management This guide will show you how a properly implemented and managed SIEM solution can solve the headache of malware threats in a targeted and timely way.

2 STEP ONE Introduction It s your business to know what is happening on your network. Visibility and analysis are paramount not only for security but also for IT service availability and compliance. The industry warnings of ever-increasing and sophisticated security threats have our attention, but the foundation of strong security starts with something simpler. Monitoring, interpreting and mitigating internal and external security threats starts with SIEM (Security Information and Event Management). The millions of logs produced by your IT infrastructure every single day already have all the data you need for SIEM. Despite the volume of log and event data involved across the whole of the network, it s not as daunting as it sounds - the right tools, processes and partners can help to simplify SIEM into real-time actionable information for threat mitigation. Making use of the information you already have, contextualising it against the normal behaviour of your network and finding the best way to manage it in real time are the challenges we look at below in solving SIEM. We find that IT leaders tend to operate in one of three ways when it comes to SIEM: Ignore it, or get away with seat of the pants security (until there is a breach) Acknowledge the need for log management, but do the minimum to meet compliance Understand the value of SIEM and implement a workable solution If you re not using SIEM at all, it s time to reconsider and it s not as difficult as you might think. If you have log management in place, beyond data storage and compliance, look at the other information you could unlock to improve security effectiveness. If you ve ticked the box in implementing SIEM, good work; next, figure out if you have some bases exposed, how to liberate your analytics and how to optimise resources and management. The guidelines in the document are designed to help every security manager apply best practice and ensure they are getting the best out of SIEM for more effective threat management. Centralise logs for correlation but also look beyond the box Log management simply means aggregating all your network data into one addressable dataset. Data logs from firewalls, servers, databases, applications, intrusion detection systems and physical access logs for example, should all flow into a centralised logging system for analysis. Whilst this is a very positive first step, many customers make the mistake of believing that producing and sending logs to the same place takes care of SIEM. Storing logs and running reports is not SIEM. Logs need to be analysed and correlated in real time to identify events and set off alarms for detecting the threat of a possible attack. To handle literally millions of logs on an ongoing basis and turn them into security intelligence, there has to be a degree of automation as it s not practical to rely solely on human resources. This is where specialist correlation tools come in to process the data, connect logs into events and alert the user when any unusual behaviour is detected. Pulling in the broadest possible cross section of logs from across the network has significant influence on the effectiveness of SIEM. Different IT functions often manage their own logs sometimes with different log retention systems and policies. Our recent study in December 2012 found that 42% of IT managers believe that managing multiple systems (network, Windows server, Unix, security) with different teams supporting and controlling the logs for each is a high risk IT security challenge. In preparing a holistic view of the security ecosystem, everything on the network is inter-related and log data from servers, network and applications shouldn t be looked at in isolation. All the logs from the whole of the network should find their way into a single system. Having a single view of the entire system makes correlating the chain of events easier to detect and the root cause much more straightforward to identify. For instance, linking events in the firewall log where a threat was picked up to a server log where a known bad IP address has been accessed tells us there is a correlation and alerts us to a deliberate threat. Collating logs centrally also gives us other typical tell-tale signs of a threat, for instance an increase in log volume, over and above normal usage. The type of log is important if a server suddenly goes from 10 to 1000 logs every minute there is something unusual happening. SecureData 3

3 A business with a particular interest in cyber threat detection and mitigation introduced a SIEM solution. Previously its signature based anti-virus system had fired on multiple hosts and had been cleared, but a residual clock based Trojan still existed. The SIEM system detected this cyber threat based on behaviour and pattern matching rather than just relying on signatures STEP TWO STEP THREE Put more in to get more out think platform With all our logs now in one place, we can now inform you that it s not just about the logs. Log correlation can only offer us part of the bigger picture. When it comes to Advanced Persistent Threats (APT) for instance, the malware could very possibly have been crafted not to alert suspicion, mimicking normal behaviour so that logs are exactly as they should be. This is why in addition to logs from security devices, collating logs for SIEM should take a big data approach. Typical logs are usually focused on what s going on with the device. Of course, this can only alert the system to unusual events the device has picked up. A better approach is to bring in data such as traffic flows, type of traffic, application flow, ambient information from the server (disk space, CPU, temperature, memory etc), as well as information such as which processes are running or indeed not running and which files have been accessed or changed on that server. This is then correlated with information such as the setting up of user accounts, deprovisioning accounts, identity information etc. Simply put, the greater the volume of security logs that can be analysed alongside contextual logs from across the whole of the network, the greater the quality of correlation and intelligence output. True SIEM looks to track the behaviour of what s happening across the whole of the network and this means we should be pulling in contextual data from beyond the security hardware in order to tell the story more precisely and deliver better intelligence. SIEM is really about monitoring the performance of the IT platform as a whole in a security context, not just the status of devices. If you have a light bulb going off with this realisation, you re not alone. You are also not alone in thinking this sounds like an awful lot of data: Our research identified 40% of security professionals have serious concerns about their business s ability to report on internal systems and the time it takes to analyse data and logs. And we get it. We know that SIEM isn t perhaps the most popular of information security requirements and it can feel like a mountain to climb, but, once the platform is set-up in the right way with ongoing expert management, it s foundational to good security practices and for more consistent IT service availability. Contextualise your security intelligence With the right tools and technologies in your SIEM platform, the next step is to make the resulting security information make sense. Log management can help us collate millions of raw logs and correlation and benchmarking enables us to convert them into events. Security intelligence requires a review of the information and deciding what the alert actually means in context of the situation and chain of events. It s the fine line between having information and deciding if we think it s a threat. Somebody has to interpret what the log data is telling us. Correlation tools are a big part of automating this process, but the people reviewing the outputs, the alerts and alarms are critical. There should be expert eyes on the SIEM dashboard 24/7, with the experience and knowledge to make a decision on whether we should be asking the CIO to get out of bed at 3am or not. With security information at our fingertips, interpreting it into security intelligence is an art not a science and real people with security expertise should be making that decision in a timely way. All security monitoring systems, whether it s SIEM or otherwise, have a human interface of some description. The challenge for IT teams is how they can find a balance of how much human resource is optimal to ensure an acceptable level of security intelligence. At one end of the spectrum, outputting a report and having someone read it every Friday is nonsense in security monitoring and threat management terms, but at the opposite end, it s hard to justify the amount of human resource needed for 24/7 monitoring for something that may or may not be of consequence to the business. Further, security intelligence requires an experienced, qualified professional which can be expensive; and finding a qualified security person who would be happy to watch a screen all day would be tricky. If you have your own SOC, this isn t a challenge. For many organisations however, security is a high priority but IT budget is limited and sensible decisions must be taken on stretching it as far as possible on operational requirements. SIEM is important and you should make sure it s done well, but don t spend a fortune on it investigate the options for in and out of house management to find an acceptable balance. SecureData 5

4 A business needed to track and monitor logs within its cardholder data environment. It had 2 weeks before its audit to put in a system. The SIEM solution was up and running within the timeframe and the customer passed their audit STEP FOUR STEP FIVE Take action on SIEM intelligence but take your time The greatest advantage of doing SIEM well is it buys you time in mitigation of threats. By having the early warning system with the right sensitivity, you can pick up emerging and persistent threats as well as the more obvious hacks and DDoS attacks. Taking action to mitigate the threat is simple to prioritise once you have the visibility of security information to understand where the threat is occurring and how important it is to your infrastructure. Clearly if you have malware within your network something should be done about it, but not all malware demands the drop everything approach. There is time for planned changes but only if you have the foresight of course to enable it. Dashboard alerts should be prioritised in order of context, threat level and type. Knowing which threats to prioritise is another essential skill to codify the level of risk. If malware is sending data out of your network, or a firewall is being hacked for example you ll need to find the cause and eliminate the vulnerability or take evasive action as soon as possible. But you need to be proportionate in other cases; if it s a threat on a PC put it on the to-do list for now, and also recognise that some threats can take time to build such as the installation of dormant malware in day zero attacks. When an alert is raised, a high level alarm will be triggered and a decision is required on what actions need to be carried out. When the alarm is shown to be the result of an attack, the need for visibility across the whole of the network becomes instantly apparent. Who will actually be able to determine the symptoms of the threat from known behaviour and apply patches, run a virus scan or power down servers, whatever is required? This often strays across multiple IT teams, but it should be defined and documented in advance so each team understands their responsibility. Resourcing is again a consideration when solving issues, particularly in security where we deal with new threats and an ever-changing external landscape. Many managed Security Operations Centres can monitor and present the history of the event all the way back to the individual logs, what is then needed is contextual interpretation from an internal and external perspective, with recommendation on the course of action and the timeframe required. SIEM is the key to risk management and improving service availability For CIOs and IT leaders, security is all about confidentiality, integrity and availability. With a strong SIEM backbone, availability is much more enhanced for the business through early threat detection and mitigation resulting in less disruptions and user downtime (not to mention improved data security and risk management). The secondary benefit of SIEM is the ability to focus IT resources on other projects if threats can be controlled more consistently and with a greater degree of confidence, the flexibility of available IT skills becomes more available to the business. If you re serious about security, SIEM is a no brainer, but it s not the only option on the table. IT leaders know they have choices they can ignore it, they can review security reports sporadically, they can invest in their own SIEM monitoring team, or they can partner with a specialist service to monitor it for them. Much of IT decision-making is dependent on budget and risk-return modelling. In terms of budget for SIEM, how you choose to do it makes a big difference, but not doing it all is at best short-sighted. Operating with greater visibility and improved security monitoring and mitigation processes avoids the significant expense of on-call overtime and the need to reallocate IT resources into fire-fighting to resolve security incidents. By setting up systems in the right way, security can be managed efficiently, resources can be optimised and availability can be enhanced. SIEM could be considered as a strategic use of budget rather than an operational expense. A business used its SIEM solution to detect 404 error messages on its web pages so it could fix these before causing user dissatisfaction For advice on SIEM, review our latest blogs and solutions or call us on to discuss your needs. SecureData 7

5 SecureData House, Hermitage Court, Hermitage Lane, Maidstone, Kent ME16 9NT T: +44 (0) F: +44 (0) E: Follow us on