Assignment

Chapter18IntrusionDetectionandPreventionSystems.pptx

Home >Computer Science homework help >Assignment

Chapter 18

Intrusion Detection and Prevention Systems

Introduction

This chapter introduces IDS/IPS concepts, describes the different IDS and IPS types available, identifies features to help you evaluate different solutions, and discusses real-life deployment considerations.

An IDS can be network-based or host-based: a network IDS is referred to as a NIDS, whereas a host-based IDS is referred to as a HIDS.

Additionally, a NIDS and HIDS can detect traffic of interest, or if they are further configured to prevent a specific action from happening, they are referred to as intrusion prevention systems: NIPS and HIPS.

Keep in mind that no matter what the form—NIDS, HIDS, NIPS, or HIPS—they are generically referred to as IDS.

IDS Concepts

Intrusion detection (ID) is the process of monitoring for and identifying specific malicious traffic.

Most network administrators perform ID all the time without realizing it. Security administrators are constantly checking system and security log files for something suspicious.

An antivirus scanner is an ID system when it checks files and disks for known malware.

Administrators use other security audit tools to look for inappropriate rights, elevated privileges, altered permissions, incorrect group memberships, unauthorized registry changes, malicious file manipulation, inactive user accounts, and unauthorized applications.

An IDS is just another tool that can monitor host system changes (host based) or sniff network packets off the wire (network based) looking for signs of malicious intent.

IDS Formats

An IDS can take the form of a software program installed on an operating system, but today’s commercial network-sniffing IDS/IPS typically takes the form of a hardware appliance because of performance requirements.

An IDS uses either a packet-level network interface driver to intercept packet traffic or it “hooks” the operating system to insert inspection subroutines.

An IDS is a sort of virtual food-taster, deployed primarily for early detection, but increasingly used to prevent attacks.

IDS Actions

When the IDS notices a possible malicious threat, called an event, it logs the transaction and takes appropriate action.

The action may simply be to continue to log, send an alert, redirect the attack, or prevent the maliciousness.

If the threat is high risk, the IDS will alert the appropriate people. Alerts can be sent by e-mail, Simple Network Management Protocol (SNMP), pager, SMTP to a mobile device, or console broadcast.

What an IDS Can Detect

An IDS supports the defense-in-depth security principle and can be used to detect a wide range of rogue events, including but not limited to the following:

Impersonation attempts

Password cracking

Protocol attacks

Buffer overflows

Installation of rootkits

Rogue commands

Software vulnerability exploits

Malicious code such as viruses, worms, and Trojans

Illegal data manipulation

Unauthorized file access

Denial-of-service (DoS) attacks

Threat Types

Attacks are unauthorized activity with malicious intent using specially crafted code or techniques.

Attacks include denial-of-service attacks, virus or worm infections, buffer overflows, malformed requests, file corruption, malformed network packets, or unauthorized program execution.

Misuse refers to unauthorized events without specially crafted code.

An offending person can use normally crafted traffic or requests and their implicit level of authorization to do something malicious.

Misuse can also refer to unintended consequences, such as when a hapless new user overwrites a critical document with a blank page.

Another misuse event could be a user mapping a drive to a file server share not intended by the network administrator.

False/True Positives/Negatives

Regardless of how an alert is detected, the administrator groups all alerts into one of four categories:

True positives (correct escalation of important events)

False positives (incorrect escalation of unimportant events)

True negatives (correct ignorance of unimportant events)

False negatives (incorrect ignorance of important events)

Network Protocol Attacks

When information is sent between network hosts, commands and data sent by higher layer application processes (such as FTP clients, web servers, and IM chat programs) are placed as payload content into discrete containers (called datagrams or packets), numbered, and sent from source to destination.

When the packets arrive at the destination, they are reassembled, and the content is handed off to the destination application.

Network protocols define the packet’s formatting and how the datagram is transmitted between source and destination.

Malicious network protocol attacks interfere with the normal operation of this process.

Flag Exploits

Abnormally crafted network packets are typically used for DoS attacks on host machines, to skirt past network perimeter defenses (bypassing access control devices), to impersonate another user’s session (attack on integrity), or to crash a host’s IP stack (DoS). Malicious network traffic works by playing tricks with the legitimate format settings of the IP protocol.

TCP flags can be set in multiple ways, and each generates a response that can either identify the target system, determine whether a stateful packet-inspecting device is in front of the target, or create a no-response condition.

Port scanners often use different types of scans to determine whether the destination port is open or closed, even if firewall-like blocking mechanisms are installed to stop normal port scanners.

Fragmentation and Reassembly Attacks

TCP/IP fragmentation is allowed because all routers have a maximum transmission unit (MTU), which is the maximum number of bytes that they can send in a single packet.

A large packet can be broken down into multiple smaller packets (known as fragments) and sent from source to destination.

A fragment offset value located in each fragment tells the destination IP host how to reassemble the separate packets back into the larger packet.

Attacks can use fragment offset values to cause the packets to maliciously reassemble and intentionally force the reassembly of a malicious packet.

If an IDS or firewall allows fragmentation and does not reassemble the packets before inspection, an exploit may slip by.

Application Attacks

Although network protocol attacks abound, most security threats exploit the host’s application layer.

In these cases, the TCP/IP packets are constructed legitimately, but their data payload contains malicious content.

Application attacks include misappropriated passwords, cross-site scripting, malicious URLs, password-cracking attempts, rootkit software, illegal data manipulation, unauthorized file access, and every other attack that doesn’t rely on malformed network packets to work.

Content Obfuscation

Most IDSs look for known malicious commands or data in a network packet’s data payload. A byte-by-byte comparison is done between the payload and each potential threat signature in the IDS’s database. If something matches, it’s flagged as an event. This is how a “signature-based” IDS works. Someone has to have the knowledge to write the “signature.”

The flexibility of the coding for international languages on the Internet allows ASCII characters to be represented by many different encoding schemes, including hexadecimal (base 16, in which the word “Hello” looks like “48 65 6C 6C 6F”), decimal notation (where “Hello” is “72 101 108 108 111”), octal (base 8, in which “Hello” appears as “110 145 154 154 157”), Unicode (where “Hello” = “0048 0065 006C 006C 006F”), and any combination thereof.

Encoding can be used to obscure text and data used to create malicious commands. Attackers employ all sorts of tricks to fool IDSs, including using tabs instead of spaces, changing values from lowercase to uppercase, splitting data commands into several different packets sent over a long period of time, hiding parameters, prematurely ending requests, using excessively long URLs, and using text delimiters.

Data Normalization

An IDS signature database has to consider all character encoding schemes and tricks that can end up creating the same malicious pattern.

This task is usually accomplished by normalizing the data before inspection.

Normalization reassembles fragments into single whole packets, converts encoded characters into plain ASCII text, fixes syntax mistakes, removes extraneous characters, converts tabs to spaces, removes common hacker tricks, and does its best to convert the data into its final intended form.

Threats an IDS Cannot Detect

IDSs excel at catching known, definitive malicious attacks.

If an outside hacker uses social engineering tricks to get the CEO’s password, not many IDSs will notice.

If the webmaster accidentally posts a confidential document to a public directory available to the world, the IDS won’t notice.

If an attacker uses the default password of an administrative account that should have been changed right after the system was installed, few IDSs will notice.

If a hacker gets inside the network and copies confidential files, an IDS would have trouble noticing it.

The most effective way for an attacker to bypass the visibility of an IDS is to encrypt the traffic at many layers.

First-Generation IDS

First-generation IDSs focused almost exclusively on the benefit of early warning resulting from accurate detection.

IDSs have high false positive rates. A false positive is when the IDS says there is a security threat by “alerting,” but the traffic is not malicious or was never intended to be malicious (benign condition).

Most IDS products err on the side of reporting more events and requiring the user to fine-tune the IDS to ignore frequent false positives.

Second-Generation IDS

Second-generation IDSs simplify the administrator’s life by offering a bountiful array of back-end options.

They offer intuitive end-user interfaces, intrusion prevention, centralized device management, event correlation, and data analysis.

Second-generation IDSs do more than just detect attacks—they sort them, prevent them, and attempt to add as much value as they can beyond mere detection.

IDS Types and Detection Models

Depending on what assets you want to protect, an IDS can protect a host or a network.

All IDSs follow one of two intrusion detection models—anomaly (also called profile, behavior, heuristic, or statistical) detection, OR signature (knowledge-based) detection—although some systems use parts of both when it’s advantageous.

Both anomaly and signature detection work by monitoring a wide population of events and triggering based on predefined behaviors.

Host-Based IDS

A host-based IDS (HIDS) is installed on the host it is intended to monitor.

The host can be a server, workstation, or any networked device (such as a printer, router, or gateway). A HIDS installs as a service or daemon, or it modifies the underlying operating system’s kernel or application to gain first inspection authority.

Although a HIDS may include the ability to sniff network traffic intended for the monitored host, it excels at monitoring and reporting direct interactions at the application layer.

File-Integrity HIDS

A file-integrity HIDS (sometimes called a snapshot or checksum HIDS) takes a cryptographic hash of important files in a known clean state and then checks them again later for comparison.

If any changes are noted, the HIDS alerts the administrator that there may be a change in integrity.

Behavior-Monitoring HIDS

A behavior-monitoring HIDS performs real-time monitoring and intercepts potentially malicious behavior.

For instance, a Windows HIDS reports on attempts to modify the registry, manipulate files, access the system, change passwords, escalate privileges, and otherwise directly modify the host.

On a Unix host, a behavior-monitoring HIDS may monitor attempts to access system binaries, attempts to download password files, and change permissions and scheduled jobs.

A behavior-monitoring HIDS on a web server may monitor incoming requests and report maliciously crafted HTML responses, cross-site scripting attacks, or SQL injection code.

Network-Based IDS (NIDS)

Network-based IDSs (NIDSs) are the most popular IDSs, and they work by capturing and analyzing network packets speeding by on the wire.

Unlike a HIDS, a NIDS is designed to protect more than one host. Captured traffic is compared against protocol specifications and normal traffic trends or the packet’s payload data is examined for malicious content. If a security threat is noted, the event is logged and an alert is generated.

NIDSs must have promiscuous network cards with packet-level drivers, and they must be installed on each monitored network segment.

Network taps, a dedicated appliance used to mirror a port or interface physically, and Switch Port Analysis (SPAN), are the two most common methods for setting up monitoring on a switched network.

Promiscuous Mode

For a NIDS to sniff packets, the packets have to be given to the packet-level driver by the network interface card.

By default, most network cards are not promiscuous, meaning they only read packets off the wire that are intended for them.

This typically includes unicast packets, meant solely for one particular workstation; broadcast packets, meant for every computer that can listen to them; and multicast traffic, meant for two or more previously defined hosts.

Sensors for Network Segments

You should have at least one NIDS inspection device per network segment to monitor a network effectively.

This device can be a fully operational IDS interface, or, more commonly, a router or switch interface to which all network traffic is copied, known as a span port, or a traffic repeater device, known as a sensor or tap.

One port plugs into the middle of a connection on the network segment to be monitored, and the other plugs into a cable leading to the central IDS console.

NIDS Topology

Anomaly-Detection (AD) Model

Anomaly detection (AD) was proposed in 1985 by noted security laureate Dr. Dorothy E. Denning, and it works by establishing accepted baselines and noting exceptional differences.

Baselines can be established for a particular computer host or for a particular network segment.

Some IDS vendors refer to AD systems as behavior-based since they look for deviating behaviors.

If an IDS looks only at network packet headers for differences, it is called protocol anomaly detection.

The goal of AD is to be able to detect a wide range of malicious intrusions, including those for which no previous detection signature exists. By learning known good behaviors during a period of “profiling,” in which an AD system identifies and stores all the normal activities that occur on a system or network, it can alert to everything else that doesn’t fit the normal profile.

Anomaly detection is statistical in nature and works on the concept of measuring the number of events happening in a given time interval for a monitored metric.

Events AD Systems Can Monitor

Unusual user account activity

Excessive file and object access

High CPU utilization

Inappropriate protocol use

Unusual workstation login location

Unusual login frequency

High number of concurrent logins

High number of sessions

Any code manipulation

Unexpected privileged use or escalation attempts

Unusual content

AD Advantages

AD systems are great at detecting a sudden high value for some metric.

For example, when the SQL Slammer worm ate up all available CPU cycles and bandwidth on affected servers and networks within seconds of infection, you can bet AD systems went off. They did not need to wait until an antivirus vendor released an updated signature.

As another example, if your AD system defines a buffer overflow as any traffic with more than 1000 repeating characters, it will catch any buffer overflow, known or unknown, that exceeds that definition.

If your AD system knows your network usually experiences 10 FTP sessions in a day, and suddenly it experiences 1000, it will likely catch the suspicious activity.

AD Disadvantages

Because AD systems base their detection on deviation from what’s normal, they tend to work well in static environments, such as on servers that do the same thing day in and day out, or on networks where traffic patterns are consistent throughout the day.

On more dynamic systems and networks that have a wider range of normal behaviors, false positives can occur when the AD triggers on something that wasn’t captured during the profiling period.

Signature-Detection Model

Signature-detection or misuse IDSs are the most popular type of IDS, and they work by using databases of known bad behaviors and patterns.

This is nearly the exact opposite of AD systems. When you think of a signature-detection IDS, think of it as an antivirus scanner for network traffic. Signature-detection engines can query any portion of a network packet or look for a specific series of data bytes. The defined patterns of code are called signatures, and often they are included as part of a governing rule when used within an IDS.

Signatures are byte sequences that are unique to a particular malady. A byte signature may contain a sample of virus code, a malicious combination of keystrokes used in a buffer overflow, or text that indicates the attacker is looking for the presence of a particular file in a particular directory.

Signatures and rules can be collected together into larger sets called signature databases or rule sets.

Signature-Detection Rules

Rules are the heart of any signature-detection engine. A rule usually contains the following information:

Unique signature byte sequence

Protocol to examine (such as TCP, UDP, ICMP)

IP port requested

IP addresses to inspect (destination and source)

Action to take if a threat is detected (such as allow, deny, alert, log, disconnect)

Advantages of Signature Detection

Signature-detection IDSs are proficient at recognizing known threats.

Once a good signature is created, signature detection IDSs are great at finding patterns, and because they are popular, a signature to catch a new popular attack usually exists within hours of it first being reported.

Another advantage of a signature-detection IDS is that it will specifically identify the threat, whereas an AD engine can only point out a generality.

An AD IDS might alert you that a new TCP port opened on your file server, but a signature-detection IDS will tell you what exploit was used.

Because a signature-detection engine can better identify specific threats, it has a better chance at providing the correct countermeasure for intrusion prevention.

Disadvantages of Signature Detection

Although signature-detection IDS are the most popular type of IDS, they have several disadvantages as compared to an AD IDS.

Cannot Recognize Unknown Attacks: Just like antivirus scanners, signature-detection IDSs are not able to recognize previously unknown attacks.

Performance Suffers as Signatures or Rules Grow: Because each network packet or event is compared against the signature database, or at least a subset of the signature database, performance suffers as rules increase.

What type of IDS should you use?

A HIDS should be used when you want to protect a specific valuable host asset.

A NIDS should be used for general network awareness and as an early warning detector across multiple hosts.

If you have a significant amount of wireless traffic exposed in public areas, consider investing in a wireless IPS.

Should your IDS be based on anomaly or signature detection? When possible, use a product that does both. The best IDSs utilize all techniques, combining the strengths of each type to provide a greater defense strategy.

IDS End-User Interfaces

IDS end-user interfaces let you configure the product and see ongoing detection activities.

You should be able to configure operational parameters, rules, alert events, actions, log files, and update mechanisms.

IDS interfaces come in two flavors:

Syntactically difficult command prompts

Less-functional GUIs

Intrusion-Prevention Systems (IPS)

Intrusion-prevention controls, as they apply to IDSs, involve real-time countermeasures taken against a specific, active threat.

Going far beyond mere monitoring and alerting, second-generation IDSs are being called intrusion-prevention systems (IPSs). They either stop the attack or interact with an external system to put down the threat.

For example, the IDS might notice a ping flood and deny all future traffic originating from the same IP address.

Alternatively, a host-based IDS might stop a malicious program from modifying system files.

IPS Disadvantages

A well-known consequence of IPSs is their ability to exacerbate the effects of a false positive.

With an IDS, a false positive leads to wasted log space and time, as the administrator researches the threat’s legitimacy.

IPSs are proactive, and a false positive means a legitimate service or host is being denied.

Malicious attackers have even used prevention countermeasures as a DoS attack.

IDS Management

Central to the IDS field are the definitions of agent and management console.

An IDS agent (which can be a probe, sensor, or tap) is the software process or device that does the actual data collection and inspection.

If you plan to monitor more than two network segments, you can separately manage multiple sensors by connecting them to a central management console. This allows you to concentrate your IDS expertise at one location.

IDS management consoles usually fulfill two central roles: configuration and reporting.

If you have multiple agents, a central console can configure and update multiple distributed agents at once.

Aggregation

In environments with more than one IDS agent, reporting captured events to a central console is crucial. This is known as event aggregation.

If the central console attempts to organize seemingly distinct multiple events into a smaller subset of related attacks, it is known as event correlation. To aid in this type of correlation analysis, most consoles allow you to sort events by the following:

Destination IP address

Source IP address

Type of attack

Type of protocol

Time of attack

Example of a Distributed IDS Topology

Alerts

Alerts are high-priority events communicated to administrators in real time.

The IDS’s policy determines what security threats are considered high risk, and the priority level is set accordingly.

When an event is considered high risk against a valuable asset, it should be communicated immediately.

Logs

IDS log files record all detected events regardless of priority and, after its detection engine, have the greatest influence on the speed and use of an IDS. IDS logs are used for data analysis and reporting.

At a minimum, a log file should record the event location, timestamp (date and time to the hundredth of a second, which is typically provided by your internal NTP server), description of the action attempted, criticality, and IDS response, if any.

If the event was recorded using network packets, then the following additional information should be noted: source and destination IP addresses, protocol, and port number.

The log should provide a short description of the attack and give links to the vendor or other vulnerability web sites for a more detailed explanation.

UTC / GMT

Reporting event timestamps in Coordinated Universal Time (UTC), also known as Greenwich Mean Time (GMT) or Zulu time, will simplify your task when reporting events to external authorities in different time zones.

UTC is the worldwide standard for time reporting based on the “0” longitude meridian.

All other time zones are based on adding or subtracting from UTC.

IDS Fine-Tuning

Fine-tuning an IDS means doing three things:

increasing inspection speed,

decreasing false positives, and

using efficient logging and alerting.

Increasing Inspection Speed

Most IDS administrators start off monitoring all packets and capturing full packet decodes.

You can narrow down what packets an IDS inspects by telling it to include or ignore packets based on source and destination addresses.

Another strategy is to let other faster perimeter devices do the filtering. Routers and firewalls are usually faster than IDSs, so, when possible, configure the packet filters of your routers and firewalls to deny traffic that should not be on your network in the first place.

Decreasing False Positives

Because IDSs have so many false positives, the number one job of any IDS administrator is to track down and troubleshoot false positives.

Track them all down, rule out maliciousness, and then appropriately modify the source or IDS to prevent them.

If you can’t stop the source of the false positive, modify the IDS so it will not track the event.

The key is that you want your logs to be as accurate as they can be, and they should alert you only to events that need human intervention.

Using Efficient Logging and Alerting

Most vendor products come with their own preset levels of event criticalities, but when setting up the IDS, take the time to customize the criticalities for your environment.

For instance, if you don’t have any Apache web servers, set Apache exploit notices with a low level of prioritization. Better yet, don’t track or log them at all.

IPS Deployment Plan

Here are the steps to a successful IPS deployment:

Decide the physical location of the IPS and sensors.

Configure the IPS sensors and management console to support your security policy.

Plan and configure device management (including the update policy).

Review and customize your detection mechanisms.

Plan and configure any prevention mechanisms.

Plan and configure your logging, alerting, and reporting.

Deploy the sensors and console (do not encrypt communication between sensors and links to lessen troubleshooting).

Test the deployment using IPS testing tools (initially use very broad rules to make sure the sensors are working).

Encrypt communications between the sensors and console.

Test the IPS setup with actual rules.

Analyze the results and troubleshoot any deficiencies.

Fine-tune the sensors, console, logging, alerting, and reporting.

Implement the IPS system in the live environment in monitor-only mode.

Validate alerts generated from the IPS.

One at a time, set blocking rules for known reliable alerts that are important in your environment.

Continue adding blocking rules over time as your confidence in each rule increases.

Security Information and Event Management (SIEM)

Multiple security systems can report to a centralized Security Information and Event Management (SIEM) system, bringing together logs and alerts from several disparate sources.

You may find different combinations of references to the acronym SIEM, owing to the evolution of capabilities and the consequent variety of names attached to SIEM products over the years, such as Security Incident and Event Management or Security Incident and Event Monitoring. These are all the same thing—a technology to collect, analyze, and correlate events and alerts generated by monitoring systems.

SIEM Correlation

SIEM platforms take the log files, find commonalities (such as attack types and threat origination), and summarize the results for a particular time period.

For example, all logs and alerts from all IDSs, perimeter firewalls, personal firewalls, antivirus scanners, and operating systems can be tied together.

Events from all logs are then gathered, analyzed, and reported on from one location.

SIEMs offer the ultimate in event correlation, giving you one place to get a quick snapshot of your system’s security or to get trend information.

SIEMs can also coordinate signature and product updates.

Advantages of SIEM

SIEMs have a huge advantage over individual IDS systems because they have the ability to collect and analyze many different sources of information to determine what’s really happening.

As a result, the SIEM can significantly reduce false positives by verifying information based on other data.

That data comes from many sources, including workstations, servers, computing infrastructure, databases, applications, network devices, and security systems.

Because all those sources generate a vast amount of real-time data, SIEM products need to be fast and effective, with a significant amount of storage and computing power.

Data Aggregation

SIEMs collect information from every available source that is relevant to a security event.

These sources take the form of alerts, real-time data, logs, and supporting data.

Together, these provide the correlation engine of the SIEM with information it can use to make decisions about what to bring to the security administrator’s attention.

Alerts

When is an alert real, and when is it a false positive?

This is the key question associated with an IDS and a source of frustration for security administrators in charge of tuning IDSs.

This is where a SIEM enters the picture. The SIEM’s key function is to validate security alerts using many different sources of data to reduce false positives, so only the most reliable alerts get sent on to the security administrator.

Thus, the alerts from all IDS sources as well as all other security monitoring systems should be given only to the SIEM, so it can decide which ones to pass along.

Real-Time Data

Real-time data such as network flow data gives the SIEM additional information to correlate.

Streaming this data into the SIEM provides important information about normal and abnormal traffic patterns that can be used in conjunction with alerts to determine whether an attack is in progress.

For example, an unusually high amount of SMTP traffic that accompanies several malware alerts may result in a high confidence alert that an e-mail worm is on the loose.

Similarly, an abnormally high amount of inbound Internet traffic, combined with a high number of firewall deny events, can indicate a denial-of-service attack.

Another example is fragmented or truncated network packets, which may indicate a network-based attack.

Each of these real-time data elements gives the SIEM important validation data for IDS alerts.

Logs

Logs can be an important additional data source for a SIEM.

Logs contain valuable information about what’s happening on a system, and they can give the SIEM a deeper view into what’s happening.

For example, login failures that may otherwise go unnoticed by a system administrator because they are buried in a system log might be of great interest to a SIEM, especially if there are many login failures for a single account (indicating a possible focused attempt to break into that account) or, similarly, if there are login failures on many different accounts, which may indicate a broad-based attempt to break into accounts using common passwords.

System errors that are logged and collected by a SIEM are also a valuable source of correlating information.

SIEM Data Sources

End-user computers

Windows and Unix servers

Domain controllers

DNS and DHCP servers

Mail servers

Databases

Web servers

Applications

Switches and routers

VPN concentrators

Firewalls

Web filters and proxies

Antivirus

Push or Pull?

Logs can be sent to the SIEM in a couple of different ways: they can be pushed to the SIEM by the individual devices that collect the logs, or they can be pulled in by the SIEM itself.

The syslog protocol, which is widely used by Unix systems as well as network devices, is an example of a push technique.

When the IP address of the SIEM is configured in the syslog service of a server or device, each log entry that device produces will be sent over the network to the SIEM.

For systems that don’t support syslog, such as Windows, third-party software can be used to collect static log information and send it to the SIEM.

The third-party software agent can be installed directly on the reporting server or on a central server built for log collection, in which case the software periodically connects to the server, grabs the latest log entries, and pushes them to the SIEM.

Normalization and Field Mapping

Whether pushed or pulled, log entries need to be parsed.

Every vendor has a different format for the fields in their syslog data. Even though they all use the same protocol, the information contained within the log is not standardized.

Modern SIEM products come with dozens of parsers that have been preconfigured to convert the syslog fields of different manufacturers into a format the SIEM can use.

In the rare cases where a built-in parser is not available for a particular vendor’s syslog format, the SIEM allows the administrator to define a custom mapping.

Supporting Data

You can enhance the quality of a SIEM’s correlation even more by providing the SIEM with supporting data that has been previously collected. Data can be imported into the SIEM, and it will use that data to make comparative determinations.

For example, asset management data containing names, IP addresses, operating systems, and software versions gives the SIEM valuable information it can use to determine whether an IDS alert makes sense within the context of the software environment. Coupled with risk- weighting data, the SIEM can use this information to prioritize and escalate alerts that pertain to high-risk systems.

You can also use vulnerability scans to give the SIEM information it can use to compare an alert about an exploit with an associated vulnerability to determine whether the exploit is real and whether it was successful.

Moreover, geolocation information can be used to prioritize alerts from high-risk countries, or even local areas such as the datacenter or public hotspots in which mobile devices might be attacked.

Analysis

A SIEM takes all the data given to it and makes decisions, so the security administrator can focus on the most important alerts.

For this reason, event correlation is a SIEM’s most important feature. The correlation engine of every SIEM product is its most distinguishing feature.

In effect, a SIEM is a sort of artificial intelligence system, working much like the human brain in putting together different elements that individually may not be important, but taken together form a picture of a critical security situation.

And a SIEM does this at a much faster rate that any human possibly could, giving the security administrator a time advantage so he or she can react quickly to attacks in progress.

Because it collects so much data from across the enterprise, a SIEM can do more than alert. It can provide system and network administrators with advanced search capabilities they will not find on any other platform.

For this reason, the SIEM represents an excellent shared platform that can make every administrator’s job easier and more efficient.

Thus, the SIEM is not just a security tool; it’s also a valuable IT management tool.

Retention

The SIEM can also perform historical and forensic analysis based on the log information it collects.

Depending on how much storage is allocated to the SIEM, either on-board or over the network, it can retain logs and alerts for a long enough period of time that it can investigate past events.

Security investigators can dig into the logs to find out what happened in a prior situation, and system administrators can look at past events to troubleshoot and evaluate functional issues.

Dashboard

For all the data collected by the SIEM and its resulting alerts to be human-readable, it must present the information in a way that an administrator can understand at a glance. SIEMs do this with a dashboard.

A dashboard is a graphical and organized representation of alerts, event data, and statistical information that allows the administrator to see patterns, understand trends, identify unusual activity, and perceive the current threat landscape quickly at any point in time.

The quality of a SIEM’s dashboard is a key differentiator among the various SIEM products on the market.

Alerting

Alerting is the other way the SIEM interacts with humans.

Whereas the dashboard performs a pull type of data transfer to the administrator (because the administrator must go to the SIEM, log in, and intentionally look for the information), alerts represent a push technique that doesn’t require human diligence to notice something important is happening.

When a SIEM scores a series of events and the associated correlation of supporting information to be high enough, it sends an alert.

The threshold for alerts should be set properly to ensure that only events that require action get the attention of the administrator, without excessive false positives.

This is another reason a SIEM complements an IDS–the SIEM is more sophisticated than the IDS at creating appropriate alerts.

Additional SIEM Features

SIEMs provide additional value beyond collecting data and sending alerts.

Because they collect and store so much data, SIEMs provide a natural advantage for offline log storage and retention, root cause analysis, advanced searching, and compliance reporting.

Summary

An intrusion detection system should be a part of every network security administrator’s protection plan. An IDS provides the “detection” aspect of the three Ds of security mentioned in Chapter 1, by providing visibility into activities, incidents, and intrusions. Along with other ID tools and methods, an IDS can monitor a host for system changes or sniff network packets off the wire, looking for malicious intent. An NIDS uses the same technology to make decisions about blocking network traffic. An IDS can be installed purely as a monitoring and detection device that sends alerts to administrators, who would then evaluate the situation and potentially take some action.

An IDS in blocking mode is known as IPS. Security administrators should consider using a combination of HIPS and NIPS, with both signature-detection and anomaly-based engines. An IPS’s biggest weaknesses are the high number of false positives and the significant maintenance effort needed to keep it up to date and finely tuned so it doesn’t block legitimate activities on systems and networks.

A HIPS would be appropriate on strategically valuable hosts, an IDS across the network for general early-warning detection, and an IPS for critical networks that need active protection. Central management consoles are helpful when multiple distributed agents are involved.

SIEM systems greatly enhance the accuracy, effectiveness, and completeness of IDS alerts. By themselves, individual IDS sensors can only see constrained segments of a network. Used in conjunction with a SIEM, multiple IDS sensors can provide much greater visibility. Reliability is also improved when a SIEM is used to collect and correlate alerts from IDSs and other sources, along with supporting data that has either been preconfigured into the SIEM or fed to it in real time. SIEMs also provide advanced capabilities that enhance the effectiveness of system, network, and security administrators.