Technology briefing: log management and SIEM

Feature by Mark Mayne

Log management or SIEM is the key to getting a handle on your network and those trying to breach it. By Mark Mayne

Log management or SIEM is the key to getting a handle on your network and those trying to breach it. By Mark Mayne.

As data breach hysteria rises, “Know where your data is” has become a mantra of the security industry. More important than this is to know who is on your network and what they are doing. There is only one way to discover this – log management.

Log management, or security information event management (SIEM), is a vital part of the network security puzzle, as it ensures that IT security records are stored in relevant detail for an appropriate period. Log analysis can help identify security incidents, fraud, policy violations and operational issues, while correctly archived logs simplify auditing, forensic analysis and supporting internal investigations. The space has become one of the hottest in IT security, as a wide range of drivers is building the market, and a slew of big names races to muscle in. Gartner reports that the SIEM sector saw 30 per cent growth in 2008, and predicts further growth in 2009, in spite of challenging market conditions.

Critically, many international compliance standards require the use of SIEM technology, because effective log management is one of the key steps in securing an IT infrastructure. Not only does the implementation require an organised, process-driven overview of the business, but analysis of the captured data allows stakeholders to optimise processes and mitigate overlooked risks. At its most basic, a log is a record of the events occurring within an organisation's systems and networks. A log comprises a series of entries, each detailing a specific event. IT security logs are produced by many sources, from hardware such as firewalls and IDS systems, through to anti-virus software and operating systems on servers and PCs, as well as applications.

From syslog to SIEM
Log management and security event management have been around for some time, but the growing complexity of IT infrastructure over the past ten years has seen the necessity for them increase dramatically. In 2000, the industry began to produce what we now know as event management tools to combat the rise in false positives from the new firewalls, IDS solutions and perimeter security appliances that were at the cutting edge.

Ross Brewer, vice president and managing director, LogRhythm EMEA, says: “These early tools filtered out the immense amount of network noise, using complex rules that changed hourly. As the regulatory landscape changed post-Enron, it was found that these earlier tools weren't suited to forensics duties, so another generation was born.”

This generation, designed to help businesses deal with an era of legislation and regulation, focused on exceptions rather than normal network activity. However, even focusing on important events still raised the volume of data by 20 times or so, making it necessary to generate reports to clarify what was being recorded and when. There has also been a long-running battle between software and hardware solutions. Appliance-based solutions are more expensive, but offer rapid rollout, while software agent-based technology tends to be cheaper. The final evolution that gave us the SIEM tools we know today was the integration of log and event tools into one, integrated tool that provided alerts to a dashboard setup.

Meteoric rise
The security log management market is seeing a meteoric rise, with household names such as Juniper Networks, Novell, EMC and IBM all battling for space alongside smaller specialist companies. Most of the larger players have grown by acquisition, as in Novell's purchase of eSentry. Several have opted to license SIEM technology, such as HP's appliance that uses SenSage, and Juniper Networks' Security Threat Response Manager that incorporates QRadar. Microsoft also has a range of products in the field.

There is a variety of approaches to the SIEM market – companies such as CA, IBM and Novell have integrated their SIEM offerings with existing identity and access management solutions, while Symantec sells SIEM to clients already running its endpoint security products. Cisco, on the other hand, has positioned similar offerings (such as its Monitoring, Analysis and Response System) as part of its self-defending network; so much of their sales traction comes from hardware acquisitions. Companies traditionally operating in the anti-virus space, such as Check Point and Symantec, have also brought products to market to diversify their portfolios. And there is a broad variety of managed security service providers (MSSPs) offering comparable services on a pay-per-use basis – some charge per alert, for example. The result is an extremely crowded market, due to a range of drivers.

Compliance is a key driver, as many standards explicitly state that logging must be implemented, and that logs must be analysed and stored for specific periods, and under specific conditions. Relevant compliance standards include the Payment Card Industry Data Security Standard (PCI DSS), Government Connect Secure Extranet (GCSx), GCSx Code of Connection (CoCo), Security Policy Framework (SPF), GPG 13, European Data Directive, Federal Information Security Management Act of 2002 (FISMA), the Health Insurance Portability and Accountability Act of 1996 (HIPAA), the Sarbanes-Oxley Act of 2002 (SOX) and the Gramm-Leach-Bliley Act (GLBA) of 1999.

Compliance is not all about government regulation, as Markus Krauss, Novell VP, identity and security management EMEA, says: “I like to use the example of Nigerian financial services companies. Although there is no regulation internally, they wish to do business internationally, so they have internal business rules they must meet. Compliance is a very broad field. Security itself shouldn't be under-estimated as a driver – we had one keen customer which had suffered a serious virus attack, and this was the main factor in its choice to implement SIEM.”

Feel the quality
In spite of the evolution of logging tools, the implementation process is far from straightforward. From the outset, the central problem is one of volume. Even a small system will generate 50 million events per day, and striking a balance between the resources available for storage and analysis and the continuous supply of log data is critical. Krauss says: “In an enterprise architecture, the focus should be actually finding information on the system. It's not just about collecting data. That is easy. It's about the quality of the information you collect, and ensuring that this fulfils the specification.”

Challenges of complexity
Mick Humphries, senior consultant, ITC Global Security, believes businesses are not as well prepared as they could be. “We often find that clients are aware they have a lot of data passing through their network, and that they can add value by monitoring it. Beyond that, there is often a lack of understanding of the potential complexity of an SIEM implementation, and few businesses are totally clear on their use case. It's vital to assess the entire business, and define the key risks it faces. This enables the company to define what problem it is trying to solve, which prevents it getting swamped in detail.”

As with many IT security-led issues, it's vital to ensure there is board-level buy-in from the start, particularly in SIEM implementations. Thoroughly auditing the entire business for relevant processes is key. Humphries adds: “This process is a critical time to ensure that all the stakeholders across the business – human resources department, physical security and so on – are on board. I can't stress enough how important it is to do this before plugging in your solution and getting a mass of data back. If you do that, then you face landing people with another problem, rather than a solution.”

Brewer agrees: “One of the biggest challenges is that organisations have different project teams dealing with different compliance initiatives. Often, teams are not aware of each other and are looking at different solutions to solve the same problem. Ideally, logging should not be looked at from a project standpoint, but as a service that underpins a repeatable business process that will provide the required information regardless of the requirement.”

Other parallel objectives can be reached at the same time, says Humphries: “It's crucial to ensure management processes are up-to-date and operating well. There is little point in setting up a series of alerts on critical applications, then finding that nobody is tasked to receive them. Existing processes may need modifying to accommodate new levels of information.”

Other typical challenges include proprietary formats, and loosely implemented standards. Brewer says: “A good example here is syslog, one of the most abused standards in the industry. Do you get a date stamp or not? Depends which vendor you're talking to... Organisations have been collecting raw log data with syslog servers for years and have struggled to derive meaningful value from it because the data itself is generated by a wide range of technical equipment that does not produce the information in a usable format. The technical language contained in the raw log message for a failed authentication is different on each vendor's platforms, whether it be Windows, Linux, AS/400, Check Point or Cisco networking equipment. What the auditor will ask for is to be shown all failure authentications where the account is a privileged user. The auditor often doesn't know (or care) that it is not that simple and a great deal of analysis needs to be done manually to pull such information together.”

Log files as valuable resource
Humphries agrees: “One of the biggest challenges is that every data source expresses its log in a different format, and not all industry standards have been adhered to. Different vendors have varying ideas about how to represent high and low threat levels, and use different terminologies. So when you start trying to compare different sources, you end up with a mess. This is where building from scratch is a real killer, as you have got to know what each of your vendor's risk indices and expressions is, a mammoth task in itself. After that, you'd need to keep totally up-to-date with any changes in logging format, which happen regularly, as well as any security patches that might break your implementation.”

Finally, it's worth bearing in mind that, once gathered and stored, log files become a valuable resource. Because they contain detailed information about your network security, they must be well protected against compromise. Details such as passwords and content of external emails are likely to be captured, and a breach could have serious consequences for both privacy and security. Accidental destruction or even alteration will undermine forensics efforts, while attackers will seek to manipulate key data in the event of a successful compromise. Many rootkits also attempt to change logs to obfuscate evidence of their activity.

It is worth bearing in mind that not all data is equal. Some sources will be far more useful in a given situation than others, and the knowledge required to prioritise these is key. Many log transport mechanisms are not entirely secure, which raises concerns about tampering. Additionally, in the event of a successful attack on a host, it's definitely wise to assume that the logs may have been altered by the attacker.

Build or buy?
Open source software is a popular choice in many fields, and is particularly common in logging applications. This is partly due to a historic lack of commercial solutions, which forced administrators to devise home-brew-style syslog management tools. As a vendor, Brewer is unsurprisingly vocal about the potential pitfalls: “Commercial organisations have subject-matter experts on the different business drivers and compliance initiatives and are continually receiving feedback from their customer base which is used for product enhancements. Commercial appliance-based solutions are optimised for the task and are easily deployed, managed and supported. Home-grown solutions are typically built and managed by an individual or a small group of individuals, which can represent a serious risk when that individual moves on to another role or leaves the organisation. Using a system that is fully documented, where formal certified training classes are available, ensures smoother adoption throughout the organisation.”

Krauss believes that open source also has its problems. “Open source is very fast, and there are some great tools out there. However, you have to consider how the system will be maintained. Also, open source tools tend to be focused on a very specific problem, which is why many of them are so effective, but this in itself can lead to another problem – how to integrate them into the broader framework that an enterprise demands.”

Whether build or buy makes sense to your organisation, it is pretty clear that only the smallest SME has no need at all for SIEM and the processes that come with it.

Brewer believes that a broad range of enterprises can benefit: “I have seen commercial log management solutions used in organisations from 350 to 350,000 users. It really depends on how critical the business and compliance drivers are and what resources the organisation has available to solve the problem. Generally speaking, the more IT infrastructure there is, the greater the complexity and the higher the need for better management tools. Organisations with more than 100 devices will benefit from such solutions, while organisations with less can simply re-sole their shoes more often!”

SIEM is so much more than an explosively growing section of the security market. Properly researched and implemented, the result will be a wholesale security profile of your business network, minute by minute. This will not only improve security in the short term, but also mitigate future risks and potentially prevent small issues snowballing. Unless you already know exactly what every user on your network is doing, and where your data is, then this level of insight is hard to dismiss.

Case study: Skipton Building Society

Skipton Building Society (SBS) was founded in 1853 and is the UK's fifth largest building society, with 860,000 customers and 90 branches.

A retailer of mortgage and investment products, the group also has interests in estate agency, as well as independent financial and advisory firms and support services to the mutual sector.

Skipton had been performing system monitoring and small-scale log management on an SQL database, but a policy change meant a refresh.

Andrew Whitton, assistant manager of system security at Skipton Building Society, says: “The product wasn't designed for log management, it was a function built into a tool we used for something else. When we started to do Windows auditing, the amount of data rocketed up to 2.5 million messages a day and it couldn't cope.”

However, in July 2008, Skipton began to accept customer payments via debit and credit card. This meant that the business had to comply with PCI DSS, which requires daily event logging.

“PCI was certainly the major driver for us,” says Whitton, “although we are subject to various standards – such as those from the FSA – and are audited externally, most requirements overlap. PCI is very specific in its requirements, though.”

SBS researched a range of solutions before short-listing several alternatives. After arranging demos and inviting sales pitches, it settled on a LogLogic LX1010 appliance to collect events and a LogLogic ST3010 for archive and storage.

Implementation was fast and relatively painless, says Whitton. “Setup took a couple of days, and within a few weeks we had detailed reports coming through. This was the culmination of 12 months' planning. The challenge is in understanding where your sources are coming from, and making sure you are logging the right things. We had to really drill down in a few areas to get what we wanted.”

Beyond PCI compliance, Skipton Building Society has seen other improvements, such as increased system awareness. Additional visibility into system events gives the IT team the ability to see “unusual” Windows event activity easily, not only giving it insights into its own systems, but also the ability to act on these insights. “It is difficult to quantify the time we have saved, other than to say we simply couldn't do what we are doing now without LogLogic – there just aren't enough hours available,” says Whitton.

Having recently done a PCI DSS audit, Skipton plans to focus on setting up and running a variety of alerts for its own systems security. Although it is only running PCI reports, it is looking at expanding reporting to other areas of the business.

“We were keen to get value out of this as well as compliance, and the increased visibility and the ability to set alerts on key trigger events have fulfilled that,” says Whitton. “We've started to take a look at some of the Sarbanes-Oxley log requirements and built a few of those in. It's above and beyond at the moment, but extremely useful.”

Plus and minus of SIEM

Log management is an area with a long history of open-source involvement and a variety of home-brew options. From a simple syslog through to a full event-management system, everything is possible. However, the more complex the systems being monitored and the more detailed the compliance issues in question, the smaller the time-saving returns will be.

The advantages are many, however. There are few or no setup costs, and it's certain that you will get exactly what you want, without compromise or putting up with a best fit from a vendor. You can choose your platform, tools and methods to fit your organisation, your methodologies and your resources. On the downside, maintenance will be a serious expense as time goes on, and there will be no external support available. If you are away or have moved on to other employment when a problem strikes, there will be nobody to pick up the pieces. It's also worth considering whether the tool you choose will scale up.

Of course, nothing in IT security is black and white. The most successful implementations will often use a combination of free, open source products and off-the-shelf vendor tools. This enables custom in-house builds to enhance vendor offerings, although the caveats over time and maintenance still apply.

Tooling up

Here are some products key to a successful open source logging implementation:

Log collection
The syslog-ng open source edition is the direct descendant of the syslog-ng project that started ten years ago. The application can operate in server or agent mode, and – apart from UDP – supports the reliable TCP and the encrypted TLS protocols.

Snare for Windows is a Windows NT, Windows 2000, Windows XP and Windows 2003-compatible service that allows remote, real-time transfer of event log information. Event logs from the Security, Application and System logs, as well as the new DNS, File Replication Service and Active Directory logs are all supported.

Project Lasso is Windows-based open source software designed to collect Windows event logs, including custom application logs, and provide central collection and transport of Windows log data via UDP/TCP syslog.

Secure centralisation
Stunnel allows you to encrypt arbitrary TCP connections inside SSL, on Unix and Windows. It lets you secure non-SSL-aware daemons and protocols (POP, IMAP, LDAP etc), requiring no changes to the daemon's code.

Logpp is a tool for pre-processing event logs and feeding relevant information to other programs for storing or in-depth analysis.

MS Excel and Ossec Ossim are obvious and popular choices here.

Swatch is an active log file-monitoring tool.

Logwatch is a customisable log analysis system, which parses through your system's logs for a given period and creates a report, analysing areas you specify, in as much detail as you require.

Logsentry is a scheduled auditing tool that scans system log files for security violations.


Find this article useful?

Get more great articles like this in your inbox every lunchtime

Upcoming Events