Intrusion Detection and Prevention Systems (IDS/IPS) Good Practice Guide

Programme NPFIT Document Record ID Key Sub-Prog / Project Infrastructure Security NPFIT-FNT-TO-INFR-0068.01 Prog. Director Mark Ferrar Status Approved Owner James Wood Version 2.0 Author Jason Alexander Version Date 31/09/2009 Intrusion Detection and Prevention Systems (IDS/IPS) Good Practice Guide Crown Copyright 2009

Version Date Amendment History 0.1 First draft for comment 0.2 30/12/2005 Format Updated 0.3 29/06/2006 Section 4 added, information updated to newest standards. 0.4 19/7/2006 Comments from Malcolm McKeating and Phil Benn added 0.5 28/7/2006 Section 1 rewritten inline with existing GPG s 0.6 21/8/2006 Final version for approval 1.1 19/05/2009 Draft update 1.2 09/06/2009 Updated with initial team comments 1.3 29/06/2009 Updated with more team feedback. 2.0 31/09/2009 Completed update Forecast Changes: Anticipated Change Amendment History: When Annual Review May 2010 Reviewers: This document must be reviewed by the following: Name Signature Title / Responsibility Date Version Infrastructure Security Team James Wood Head of IT Security 1.1 Approvals: This document must be approved by the following: Name Signature Title / Responsibility Date Version James Wood Head of IT Security 1.1 Distribution: NHS Connecting for Health Infrastructure Security Team Website http://nww.connectingforhealth.nhs.uk/infrasec/gpg 1.1 Document Status: This is a controlled document. Whilst this document may be printed, the electronic version maintained in FileCM is the controlled copy. Any printed copies of the document are not controlled. Crown Copyright 2009 Page 2 of 30

Related Documents: These documents will provide additional information. Ref no Doc Reference Number Title Version 1 NPFIT-SHR-QMS-PRP-0015 Glossary of Terms Consolidated.doc 13 2 NPFIT-FNT-TO-INFR-SEC-0001 Glossary of Security Terms Latest Glossary of Terms: List any new terms created in this document. Mail the NPO Quality Manager to have these included in the master glossary above [1]. Crown Copyright 2009 Page 3 of 30

Contents 1 About this Document... 6 1.1 Purpose... 6 1.2 Audience... 6 1.3 Content... 6 1.4 Disclaimer... 6 2 Intrusion Detection and Prevention Principles... 8 2.1 Common Detection Methods... 9 3 Components and Architecture... 11 3.1 Typical Components... 11 3.2 Architecture Design... 11 3.3 Securing IDS/IPS components... 12 4 Network Based IDS/IPS... 13 4.1 Architecture and Sensor Locations... 13 4.2 Types of events detected... 15 4.3 Detection Accuracy... 16 4.4 Technology Limitations... 16 5 Wireless IDS/IPS... 17 5.1 Threats against WLANs... 17 5.2 Architecture and Sensor Locations... 17 5.3 Type of Events Detected... 19 5.4 Detection Accuracy... 19 5.5 Technology Limitations... 19 6 Network Behaviour Analysis (NBA) IDS/IPS... 20 6.1 Architecture and Sensor Locations... 20 6.2 Types of events detected... 21 6.3 Detection Accuracy... 22 6.4 Technology Limitations... 22 7 Host Based IDS/IPS... 23 7.1 Architecture and Agent Locations... 23 7.2 Types of events detected... 24 7.3 Detection Accuracy... 25 7.4 Technology Limitations... 26 8 IDS/IPS Technology Comparison Chart... 27 Crown Copyright 2009 Page 4 of 30

9 Configuration and Maintenance of IDS/IPS... 28 9.1 Tuning... 28 9.2 Staffing and Resourcing... 28 9.3 Configuration Management... 29 10 Resources and References... 30 10.1 Further helpful resources... 30 10.2 References... 30 Crown Copyright 2009 Page 5 of 30

1 About this Document 1.1 Purpose This GPG seeks to assist NHS organisations in understanding intrusion detection system (IDS) and intrusion prevention system (IPS) technologies and in designing, implementing, configuring, securing, monitoring, and maintaining intrusion detection and prevention systems. This guide does not deal specifically with any external processes for the management of these solutions as the particulars of implementation specific issues are outside the scope of this document. The purpose of this document is to advise technical personnel of the best practices when implementing IDS/IPS products to provide additional security to networks and systems. 1.2 Audience This document is written for readers with a technical background. A general familiarity with networking concepts and the nature of attacks directed at networks which IDS and IPS solutions attempt to address is assumed. Detailed knowledge of various vendor specific technologies is not required although a familiarity with the basic operation of these technologies will be useful. 1.3 Content Intrusion Detection and Prevention Principles Components and Architecture Network Based IDS/IPS Wireless IDS/IPS Network Behaviour Analysis (NBA) IDS/IPS Host Based IDS/IPS IDS/IPS Technology Comparison Chart Configuration and Maintenance of IDS/IPS Resources and References 1.4 Disclaimer Reference to any specific commercial product, process or service by trade name, trademark manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by NHS Connecting for Health. The views and opinions of authors expressed within this document shall not be used for advertising or product endorsement purposes. Any party relying on or using any information contained in this document and/or relying on or using any system implemented based upon information contained in this document should do so only after performing a risk assessment. It is important to note that a risk assessment is a prerequisite for the design of effective security countermeasures. A correctly completed risk assessment enables an NHS organisation to demonstrate that a methodical process has been undertaken which Crown Copyright 2009 Page 6 of 30

can adequately describe the rationale behind any decisions made. Risk assessments should include the potential impact to live services of implementing changes. This means that changes implemented following this guidance are done so at the implementers risk. Misuse or inappropriate use of this information can only be the responsibility of the implementer. Crown Copyright 2009 Page 7 of 30

2 Intrusion Detection and Prevention Principles Intrusion Detection and Prevention has become a much marketed concept in IT security and has become a standard tool in the protection of the network and computer systems from both external and internal threats. The adoption of IDS/IPS technologies has demonstrated the complexity in implementing a solution which provides increased security within a manageable framework. Many implementations have suffered from lack of resource planning and continued maintenance which has reduced the effectiveness of these solutions and the return on investment. IDS/IPS technologies cannot provide complete accurate detection; they all generate false positives (incorrectly identifying benign activity as malicious) and false negatives (failing to identify malicious activity) Intrusion detection is the process of monitoring the events occurring either in a computer system or network and analysing them for signs of possible security incidents. Intrusion prevention is the process of performing intrusion detection and attempting to stop detected possible security incidents. Intrusion detection and prevention systems (IDS/IPS) are primarily focused on identifying possible security incidents, logging information about them, attempting to stop them, and reporting them to security administrators. Key functions of IDS/IPS technologies include: Logging information related to possible security events Notifying operational administrators of important security events Producing reports i.e. attempted external and internal attacks. Preventing a malicious attack (IPS) The fundamental difference between Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) is that IDS is generally a passive technology. An IDS usually alerts security administrators but does not take any preventative measures to stop the potential malicious activity. IPS on the other hand is a reactive technology. IPS can use multiple response techniques, such as reconfiguring the firewall or changing the attack content which stops the attack itself. Because of the proactive measures that an IPS takes to prevent malicious activity, a risk assessment should be undertaken to ascertain all risks in deploying this technology especially in the context of clinical safety. Considerations such as a fail open policy should also be risk assessed. Crown Copyright 2009 Page 8 of 30

2.1 Common Detection Methods IDS/IPS s operate as network or host based systems. A network based IDS/IPS is focused on detecting security events from monitoring network traffic. Two common subtypes of network based IDS/IPS are wireless and network behaviour analysis (NBA). A host based IDS/IPS usually resides on the actual device and monitors system behaviour as well as network traffic (to and from the host) to detect security events. This GPG will concentrate on the following types: Network-Based: This monitors network traffic and analyses the network and application protocol activity to identify suspicious activity. o Wireless: This monitors wireless network traffic and analyses it to identify suspicious activity. This is usually related to the wireless networking protocols themselves. o Network Behaviour Analysis (NBA): This examines network traffic to identify threats that generate unusual traffic flows, such as DDoS attacks, scanning, and certain forms of malware. Host-Based: This monitors the characteristics of a single host and the events occurring within that host for suspicious activity. Most IDS/IPS technologies use multiple detection methodologies to provide more broad and accurate detection. The primary methods of detection methodologies are as follows: Signature based: This method compares known threat signatures to observed events to identify security incidents. This method is very good for detecting known threats but largely ineffective at detecting unknown threats. As with antivirus, it is most important to ensure that signature updates are applied frequently from the vendor to maintain an effective defence 1. Anomaly based: This method uses profiles that are developed by monitoring the characteristics of typical activity over a period of time. The IDS/IPS then compares the characteristics of current activity to the profile. Anomaly based detection methods can be very effective at detecting previously unknown threats but are notorious for generating false positives. Stateful Protocol Analysis 2 : Unlike anomaly based detection, which uses host or network-specific profiles, stateful protocol analysis relies on vendordeveloped universal profiles that specify how particular protocols should and should not be used. It is capable of understanding and tracking the state of protocols that have a notion of state, which allows it to detect many attacks that other methods cannot. Problems with stateful protocol analysis include that it is often very difficult or impossible to develop completely accurate models of protocols, it is very resource-intensive, and it cannot detect attacks 1 More advanced organisations may have the capability to write their own signatures. 2 Some vendors use the term deep packet inspection to refer to performing some type of stateful protocol analysis, often combined with a firewall capability that can block communications determined to be malicious. Crown Copyright 2009 Page 9 of 30

that do not violate the characteristics of generally acceptable protocol behaviour. Unless the device is capable of running all detection modes without performance degradation a decision will have to be made on what to functionality should be turned on. This should be based on the factors such as the environment, type of detection methods supported and performance capability of the device. The IST would recommend that a minimum baseline requirement is deployed based on the previous factors. If performance is not affected then a staged approach to turning on and tuning of other detection methods should be taken. Crown Copyright 2009 Page 10 of 30

3 Components and Architecture 3.1 Typical Components The typical components of an IDS/IPS solution are as follows: Sensor or Agent: Sensors and agents monitor activity. The term sensor is typically used for IDS/IPS that monitor networks, including network based, wireless, and network behaviour analysis technologies. The term agent is typically used for host based IDS/IPS technologies. Management server: A management server is a centralised device that receives information from the sensors or agents and manages them 3. Some management servers perform analysis on the event information that the sensors or agents provide and can identify events that the individual sensors or agents cannot. Matching event information from multiple sensors or agents, such as finding events triggered by the same IP address, is known as correlation. Management servers are available as both appliance and software-only products. In larger IDS/IPS deployments, there are often multiple management servers. Database server: A database server is a repository for event information recorded by sensors, agents, and/or management servers. Many IDS/IPSs provide support for database servers. Console: A console is a program that provides an interface for the IDS/IPS s users and administrators. Console software is typically installed onto standard desktop or laptop computers. Some consoles are used for IDS/IPS administration only, such as configuring sensors or agents and applying software updates, while other consoles are used strictly for monitoring and analysis. Some IDS/IPS consoles provide both administration and monitoring capabilities. 3.2 Architecture Design A point of note is that network based IDS/IPS generally cannot inspect encrypted communications i.e. SSH, SSL and VPN traffic. This is a major consideration within the design stage and has a bearing on whether host based solutions should be used and the location of sensors. One of the first steps in IDS/IPS implementation is designing the architecture. Architectural considerations include the following: Where the sensors or agents should be placed within your environment. Is redundancy required? Having multiple sensors monitor the same activity in case a sensor fails, or using multiple management servers in case of failure. Which other systems the IDS/IPS needs to communicate with, including the following: 3 Some types of IDS/IPS sensors and agents can be deployed standalone, and managed and monitored directly by administrators without using a management server. Crown Copyright 2009 Page 11 of 30

Systems to which it provides data, such as security information and event management systems (SIEM) centralised logging servers, email servers, and SMS services. In the case of Intrusion Prevention Systems (IPS) which initiates prevention responses e.g. firewall rule changes and router ACL changes 4. How all the components of the IDS/IPS solution will communicate i.e. via a dedicated management network Because a new deployment is likely to generate a large number of false positives until fully tuned, activating many sensors or agents at once might overwhelm the management servers and consoles, making it difficult for security administrators to perform tuning. 3.3 Securing IDS/IPS components Securing IDS/IPS infrastructure is very important because IDS/IPS are often targeted by attackers. If an attacker can compromise an IDS/IPS, it can be rendered useless in detecting and preventing (in the case of IPS) subsequent attacks against other networks and hosts. Also, IDS/IPS often contain sensitive information such as host configurations and known vulnerabilities that could be helpful in planning additional attacks. Comprehensive system hardening procedures should be employed to all components of the IDS/IPS infrastructure. This includes ensuring all components are fully up to date, removing default usernames and passwords and encrypting administrative communication channels 5. 4 This process will need integrating with the organisations current change management process. 5 See NHS Technology Office Infrastructure Security Team (IST) System Hardening Good Practice Guidance (GPG). This can be found at: http://nwww.connectingforhealth.nhs.uk/infrasec/gpg Crown Copyright 2009 Page 12 of 30

4 Network Based IDS/IPS A network based IDS/IPS monitors network traffic and analyses the network and application protocol activity to identify suspicious activity. This section provides more detailed information relating to this type of IDS/IPS 4.1 Architecture and Sensor Locations NHS organisations should consider using dedicated physical management networks for their network based IDS/IPS deployments. If this is not possible then they should consider the use of a VLAN or at the very least ensure all administrative access is encrypted utilising methods such as SSH or SSL 6. In addition to choosing the appropriate network for the components management, IDS/IPS sensor locations need to be decided. Sensors can be deployed in one of two modes: Inline: An inline sensor is deployed so that the network traffic it is monitoring must pass through it. The primary reason for deploying IDS/IPS sensors inline is when utilising IPS functionality to enable them to stop attacks by blocking network traffic. Inline sensors are typically placed where network firewalls and other network security devices would be placed at the logical security borders between networks, such as connections with external networks and borders between different internal networks that should be segregated. Inline sensors are often deployed on the more secure side of a network division so that they have less traffic to process. Figure 1 shows such a deployment. Sensors can also be placed on the less secure side of a network division to provide protection for and reduce the load on the dividing device, such as a firewall although this is usually only done for research purposes as the amount of alerts can be enormous. 6 Please refer to the IST guidance on approved cryptographic standards which can be found here http://nww.connectingforhealth.nhs.uk/infrasec/gpg/acs.pdf Crown Copyright 2009 Page 13 of 30

Figure 1: Inline network Based IDS/IPS Sensor Placement Passive: A passive sensor is deployed so that it monitors a copy of the actual network traffic; no traffic actually passes through the sensor. Passive sensors are typically deployed so that they can monitor key network locations, such as the boundaries between networks, and key network segments, such as activity on a demilitarized zone (DMZ) subnet. Passive sensors can monitor traffic through various methods, including the following: Spanning ports: These are commonly found on enterprise class network equipment such as managed switches. They can be configured in such a way that all other traffic on the switch is mirrored onto this port allowing the IDS/IPS sensor to monitor all traffic the switch deals with. Spanning ports do have some disadvantages, the configuration may be setup incorrectly which may mean missed traffic, in high load situations passing packets are given a higher priority than copying packets to the Spanning port thus some packets may not be copied. Spanning ports are restricted to the device that they are monitoring thus seeing other traffic on the network may require additional devices or a different sensor configuration. Note, SPAN ports are analogous to Roving Analysis Ports and Mirrored Ports Crown Copyright 2009 Page 14 of 30

Network Tap: Network Test Access Ports (TAP) are devices specifically designed to allow monitoring of network traffic passively between two devices. They typically consist of four ports into which the devices are connected and the second two ports are used to monitor the up and down stream traffic individually preserving the fullduplex nature of the traffic. Network Tap devices are generally specialist equipment and can be quite expensive to obtain. The specifics of their installation is beyond this document but should be carefully considered, including their operation upon power/hardware failure, before being integrated into an IDS/IPS solution IDS Load Balancer: Also known as Span expanders are a device that aggregates and directs network traffic to monitoring systems, including IDS/IPS sensors. A load balancer can receive copies of network traffic from one or more spanning ports or network taps and aggregate traffic from different networks. The load balancer then distributes copies of the traffic to one or more listening devices, including IDS/IPS sensors. Figure 2: Passive Network Based IDS/IPS Sensor Architecture Example 4.2 Types of events detected The types of events most commonly detected by network based IDS/IPS sensors include the following: Crown Copyright 2009 Page 15 of 30

Application layer reconnaissance and attacks: e.g. banner grabbing, buffer overflows, format string attacks, password guessing, malware transmission. Transport layer reconnaissance and attacks: e.g. port scanning, unusual packet fragmentation, SYN floods. Network layer reconnaissance and attacks: e.g. spoofed IP addresses, illegal IP header values. Unexpected application services: e.g. tunnelled protocols, backdoors and hosts running unauthorized application services. Policy violations: e.g. use of inappropriate Web sites, use of forbidden application protocols. 4.3 Detection Accuracy Historically, network based IDS/IPS have been associated with high rates of false positives and false negatives. Most of the early technologies relied primarily on signature based detection, which by itself is accurate only for detecting relatively simple well known threats. Newer technologies use a combination of detection methods to increase accuracy and generally the rates of false positives and false negatives have declined. Another common problem with network based IDS/IPS accuracy is that they typically require considerable tuning and customization to take into account the characteristics of the monitored environment. 4.4 Technology Limitations Although network based IDS/IPS offer extensive detection capabilities, they do have some limitations. Three of the most important are analyzing encrypted network traffic, handling high traffic loads, and withstanding attacks against the IDS/IPS themselves. Network based IDS/IPS cannot detect attacks within encrypted network traffic, including Virtual Private Network (VPN) connections, HTTP over SSL (HTTPS) and SSH sessions. It is a recommendation of the Information Security Team (IST) that NHS organisations when deploying network based IDS/IPS place them so that they can analyse traffic either before encryption or after decryption. Network based IDS/IPS solutions may be unable to perform appropriately under high loads. Attackers sometimes take advantage of this. It is essential that network throughput and load analysis is carried out prior to purchasing network based IDS/IPS solutions. IDS solutions may drop packets under high loads resulting in potentially missed security events. IPS solutions dropping packets could result in disruptions to the network. Crown Copyright 2009 Page 16 of 30

5 Wireless IDS/IPS A wireless IDS/IPS monitors wireless network traffic and analyses the wireless networking protocols to identify suspicious activity. This section provides more information relating to this type of IDS/IPS. Please note that the Information Security Team (IST) have produced a comprehensive GPG on Wireless LAN Technologies 7. 5.1 Threats against WLANs Although wireless and wired networks face the same general types of threats, the relative risk of some threats varies significantly. For example, wireless attacks typically require the attacker or a device placed by the attacker to be within close physical proximity to the wireless network. Most WLAN threats involve an attacker with access to the radio link between a wireless endpoint and a wireless access point. Many attacks rely on an attacker s ability to intercept network communications or inject additional messages into them. This highlights the most significant difference between protecting wireless and wired LANs: the relative ease of accessing and altering network communications. In a wired LAN, an attacker would have to gain physical access to the LAN or remotely compromise systems on the LAN; in a wireless LAN, an attacker simply needs to be within range of the WLAN infrastructure. 5.2 Architecture and Sensor Locations Wireless IDS/IPS components are typically connected to each other through a wired network, as shown in Figure 3. As with a network based IDS/IPS, a separate management network is recommended for wireless IDS/IPS component communications. Also, some wireless IDS/IPS sensors (particularly mobile ones) are used standalone and do not need wired network connectivity. It is a recommendation of the Information Security Team (IST) that there should be strictly controlled separation between the wireless and wired networks e.g. utilising firewall technology 7 Wireless LAN Technologies GPG can be found here http://nwww.connectingforhealth.nhs.uk/infrasec/gpg Crown Copyright 2009 Page 17 of 30

Figure 3: Wireless IDS/IPS Architecture Choosing sensor locations for a wireless IDS/IPS deployment is a fundamentally different problem than choosing locations for any other type of IDS/IPS sensors. Organisations may also want to deploy sensors to monitor areas where there should be no WLAN activity, as well as channels and bands that the organisation s WLANs should not use, as a way of detecting rogue access points and ad hoc WLANs. Other considerations for selecting wireless sensor locations include the following: Physical Security: Sensors are often deployed into open locations e.g. corridors, ceilings and meeting rooms. Sensors are also sometimes deployed outdoors as well. Generally, sensors in open interior locations and external locations are more susceptible to physical threats than other sensors. If the physical threats are significant, it would be a recommendation of the IST that NHS organisations select sensors with anti tamper features or deploy sensors where they are less likely to be physically accessed e.g. within view of CCTV. Sensor Range: The actual range of a sensor varies based on the surrounding facilities e.g. walls and doors. Some wireless IDS/IPS vendors offer software that can help in the placement of sensors. Cost: In an ideal world an organisation would deploy sensors throughout its infrastructure to perform full wireless monitoring. However, the number of sensors needed to do so can be quite large, especially in wide open multi building trust sites. A risk assessment should be undertaken at the design stage to ensure a correct balance is achieved in regards sensor coverage, potential threats and the organisations risk appetite. Crown Copyright 2009 Page 18 of 30

5.3 Type of Events Detected The types of events most commonly detected by wireless IDS/IPS sensors include the following: Unauthorised WLANs and WLAN devices: Most wireless IDS/IPS sensors can detect rogue access points and unauthorised end points. Poorly secured WLAN devices: Most wireless IDS/IPS sensors can identify access points and end points that are not using proper security controls. This includes detecting misconfigured devices and the use of weak WLAN protocols. Unusual usage patterns: Some sensors can use anomaly based detection methods to detect unusual WLAN usage patterns. Denial of service (DoS) attacks: DoS attacks include logical attacks such as flooding, and physical attacks such as jamming. Impersonation and man-in-the-middle attacks: Some wireless IDS/IPS sensors can detect when a device is attempting to spoof the identity of another device. 5.4 Detection Accuracy Compared to other forms of IDS/IPS, wireless IDS/IPS is generally more accurate; this is largely due to its limited scope of monitoring wireless networking protocols. Although many alerts may occur based on benign activity, such as another organisation s WLAN being within range of the organisation s WLANs, these alerts are not truly false positives because they are accurately detecting an unknown WLAN within the organisation s facilities. In dense urban areas where wireless networks are prevalent it may prove to be a false economy to implement a Wireless IDS/IPS solution. 5.5 Technology Limitations Although wireless IDS/IPS offers robust detection capabilities, they do have some limitations. Three of the most important are being unable to detect certain wireless protocol attacks, being susceptible to evasion techniques, and being unable to withstand attacks against the IDS/IPSs themselves. Wireless IDS/IPS cannot detect passive attacks against wireless networks. For example an attacker can monitor wireless traffic and if weak security methods are being used e.g. WEP, the attacker can then perform offline processing of that collected traffic to find the encryption key used to provide security for the wireless traffic. The attacker can then passively capture and decrypt all wireless communications, undetected. Crown Copyright 2009 Page 19 of 30

6 Network Behaviour Analysis (NBA) IDS/IPS A network behaviour analysis (NBA) IDS/IPS examines network traffic to identify unusual traffic flows, such as distributed denial of service DDoS attacks, certain forms of malware (worms and Trojans) and policy violations ( client system providing network services to other systems) This section provides more information relating to this type of IDS/IPS. 6.1 Architecture and Sensor Locations Some NBA IDS/IPS sensors are similar to network based IDS/IPS sensors in that they sniff packets to monitor network activity on one or a number of network segments. Other NBA sensors do not monitor the networks directly, but instead rely on network flow information provided by networking devices (flow refers to a communication session occurring between hosts). There are many standards for flow data formats, e.g. NetFlow 8. As with a network based IDS/IPS, a separate management network is recommended for wireless IDS/IPS component communications. If sensors that collect network flow data from other devices are used, the entire NBA solution can be logically separated from the production network. Figure 4 shows an example of an NBA network architecture. 8 NetFlow is a network protocol developed by Cisco Systems to run on Cisco IOS enabled equipment for collecting IP traffic information. It's proprietary but supported by many other platforms and vendors. Crown Copyright 2009 Page 20 of 30

Figure 4: NBA Sensor Architecture Example In addition to choosing the appropriate network for the components, IDS/IPS sensor locations need to be decided. NBA IDS/IPS usually work in passive mode so utilising the same methods as passive network based IDS/IPS mentioned earlier in this document e.g. network taps and spanning ports is appropriate. Passive sensors that are performing direct network monitoring should be placed so that they can monitor key network locations, such as the boundaries between networks, and key network segments, such as a demilitarized zone (DMZ) subnet. 6.2 Types of events detected The types of security events most commonly detected by NBA IDS/IPS include the following: Denial of service (DoS) attacks: Including distributed denial of service DDoS attacks. Crown Copyright 2009 Page 21 of 30

Scanning: Scanning can be detected by typical flow patterns at the application layer (banner grabbing), transport layer (TCP and UDP port scanning), and network layer (ICMP scanning). Worms: Some worms propagate quickly and use large amounts of bandwidth. These are easily detected by NBA IDS/IPS. Unexpected application services: This includes tunnelled protocols, backdoors and use of forbidden application protocols. Since most NBA sensors can reconstruct a series of security events to determine the origin of a threat they are a great asset in the incident response process. 6.3 Detection Accuracy Because NBA IDS/IPS work primarily by detecting significant abnormalities, they are most accurate at detecting attacks that generate large amounts of network activity in a short period of time e.g. DDoS attacks and attacks that have unusual flow patterns e.g. worms. NBA IDS/IPS are less accurate at detecting small scale attacks, particularly if they are conducted slowly and within normal parameters. 6.4 Technology Limitations NBA IDS/IPS offer strong detection capabilities for certain types of threats, but they also have limitations. An important limitation is the delay in detecting attacks. Some delay is expected in anomaly detection methods that are based on deviations from a baseline, such as increased bandwidth usage or additional connection attempts. However, NBA technologies often have additional delay caused by their data sources, especially when they rely on flow data from other network devices. NBA IDS/IPS are normally passive in nature and usually depend on analysis of provided flow data from other devices. This can lead to delays in attack detection. Crown Copyright 2009 Page 22 of 30

7 Host Based IDS/IPS A host based IDS/IPS usually involves the installation of agents on the monitored host. These agents then monitor the host for security events occurring within that host. Examples of the types of characteristics a host based IDS/IPS might monitor are wired and wireless network traffic (only for that host), system logs, running processes, file access and modification, and system and application configuration changes. This section provides information for this type of IDS/IPS. 7.1 Architecture and Agent Locations The network architecture for host based IDS/IPS deployments is usually very simple. As the agents are deployed to existing hosts within the organisation, the components usually communicate over the production network instead of using a separate management network. Most products encrypt their communications, preventing eavesdroppers from accessing sensitive information on the wire. Figure 5 shows an example of a host based IDS/IPS infrastructure. A recommendation of the Information Security Team (IST) is that host based IDS/IPS communications are encrypted. The capability of the system to do this should be investigated prior to purchase. Host based IDS/IPS agents are commonly deployed to critical hosts such as publicly accessible servers and servers containing sensitive information. However, because agents are available for various server and desktop operating systems, organisations could potentially deploy agents to most of their infrastructure e.g. DMZ servers, internal servers and desktop computers. The use of host based IDS/IPS also allows organisations to monitor for security events that can t be detected by other technologies e.g. network based IDS/IPS inability to analyse encrypted traffic. Crown Copyright 2009 Page 23 of 30

Figure 5: A typical host based IDS/IPS infrastructure. 7.2 Types of events detected The types of security events detected by a host based IDS/IPS vary based primarily on the detection method that they use. Some host based IDS/IPS products offer several of these detection methods, while others focus on a few or just one. For example, some products only analyse network traffic, and other products only check the integrity of a hosts critical files. The types of events commonly detected by host based IDS/IPS include the following: Code Analysis: Code behaviour analysis, buffer overflow detection and system call monitoring are all types of code analysis methods. Agents might use one or more of the listed methods to identify malicious activity by analysing attempts to execute code. All of these methods are helpful at stopping malware and can also prevent other attacks, such as some that would permit unauthorised access, code execution, or escalation of privileges. Crown Copyright 2009 Page 24 of 30

Network Traffic Analysis: This is similar to what a network based IDS/IPS does; some products can analyse both wired and wireless network traffic. Host based IDS/IPS agents often include a host based firewall that can restrict incoming and outgoing traffic for each application on the system. File system Monitoring: File system monitoring can be performed using a few different methods, including file integrity checking, file attribute checking and file access attempts. File integrity checking involves periodically generating message digests or other cryptographic checksums for critical files, comparing them to a known value, and identifying differences. File integrity checking can only determine after the fact that a file has already been changed, such as a system binary being replaced by a Trojan or a rootkit. File attribute checking periodically checks the attributes of important files, such as ownership and permissions for changes. Like file integrity checking, it can only determine after the fact that a change has occurred. Scheduling frequent file checks should be balanced against the impact of system performance and the volume of logs which will be generated. Log Analysis: Some agents can monitor and analyse operating system and application logs to identify malicious activity. These logs may contain information on system events such as shutting down the system and starting a service; audit records, which contain security event information such as successful and failed log on attempts and application events, such as application start up and shutdown, application failures, and major application configuration changes. Network Configuration Monitoring: Some agents can monitor a host s current network configuration and detect changes to it. Examples of network configuration changes are network interfaces being placed in promiscuous mode.. Organisations should determine which aspects of a host need to be monitored and select IDS/IPS products that provide adequate monitoring and analysis for them. 7.3 Detection Accuracy Like other IDS/IPS technologies, host based IDS/IPS often cause false positives and false negatives. However, accuracy is more challenging for host based IDS/IPS because many of the possible detection methods, such as log analysis and file system monitoring, do not have knowledge of the context under which detected events occurred. For example, a host may be rebooted, a new application installed, or a system file replaced. These actions could be done by malicious activity, or they could be part of normal operation and maintenance. The events themselves are detected accurately, but their benign or malicious nature cannot always be determined without additional context. Some products, particularly those intended for Crown Copyright 2009 Page 25 of 30

desktops, prompt users to provide context. This in itself can be a problem if users are not educated to determine if the request is benign of malicious. It is a recommendation of the Information Security Team (IST) that host based IDS/IPS that utilises a combination of detection methods are used to achieve a more accurate detection rate. 7.4 Technology Limitations Like all IDS/IPS solutions host based IDS/IPS do have some limitations. The primary issues include centralised reporting delays, host resource usage and potential conflicts with existing security controls. Many host based IDS/IPS are intended to be used with a centralised management server where the agents send their data periodically. This can lead to delays in detecting malicious activity. Where possible and network bandwidth permits it is recommended that this delay is kept to a minimum to provide the best protection.. Crown Copyright 2009 Page 26 of 30

8 IDS/IPS Technology Comparison Chart Technology Type Network Based Types of Malicious Activity Detected Network, transport, and application TCP/IP layer activity Wireless Wireless protocol activity; unauthorised wireless local area networks (WLAN) in use NBA Network, transport, and application TCP/IP layer activity that causes anomalous network flows Host Based Host application and operating system (OS) activity; network, transport, and application TCP/IP layer activity Scope per Sensor or Agent Multiple network subnets and groups of hosts Multiple WLANs and groups of wireless clients Multiple network subnets and groups of hosts Individual host Strengths Able to analyse the widest range of application protocols; only IDS/IPS that can thoroughly analyse many of them Only IDS/IPS that can monitor wireless protocol activity Typically more effective than the others at identifying reconnaissance scanning and DoS attacks, and at reconstructing major malware infections Only IDS/IPS that can analyse activity that was transferred in endto-end encrypted communications The Information Security Team (IST) would recommend a blended approach to IDS/IPS solutions, using multiple types of IDS/IPS technologies to achieve a more comprehensive and accurate detection and prevention of malicious activity, Where possible, IDS/IPS products should provide interoperability through recognised standards to allow centralised management and integration of all aspects of the IDS/IPS solution. This will also enable the organisation to develop the maturity of the IDS/IPS solution in line with the NHS Infrastructure Maturity Model (NIMM) as well as enable changes in architecture as the organisations network and systems change over time. NHS organisations should use risk management techniques to identify the security controls necessary to mitigate risk to an acceptable level. Although it may be tempting to simply choose a product, using a risk management process to choose the most effective blend of controls enhances an organisation s security posture. Note: For further information on Risk Assessment within an NHS organisation refer to the Information Security Teams (IST) GPG Security General Principles http://nwww.connectingforhealth.nhs.uk/infrasec/gpg Crown Copyright 2009 Page 27 of 30

9 Configuration and Maintenance of IDS/IPS 9.1 Tuning IDS/IPS cannot be considered as out of the box security solutions as they require specialised configuration and maintenance to ensure that false positives and false negatives are reduced. Tuning of an IDS is dependent upon the size and complexity of the installed system and the number of sensors used. This type of exercise should normally be carried out by a qualified engineer who can work with the customer to achieve the best protection from the system. In general the following steps are used to tune a system. 1. Determine optimum placement of sensors 2. Determine normal baselines and implement a basic configuration 3. Analyse the logs and alarms whilst normal operations are conducted 4. Filter out false positives through traffic analysis and system use and implement additional filtering as necessary 5. Determine responses to alert types 6. Apply new tuned configuration and return to step 2 as required This process can be used to fine tune the system to a point where the data being generated can be sufficiently analysed to provide the security required. Systems must be tuned to take account of the types of traffic being analysed and the resources available to respond to alerts. The basic process above can be refined and applied to all types of IDS/IPS devices. Typically, the more powerful a product s tuning and customisation capabilities are, the more its detection accuracy can be improved from the default configuration. Security administrators should review tuning and customisations periodically to ensure that they are still accurate. 9.2 Staffing and Resourcing All IDS/IPS require some human intervention at some stage and the levels of resourcing put in place to manage the alerts and incidents detected by the IDS/IPS should be in line with the value of the assets the system is protecting. The use of automated systems to handle the majority of alerts is encouraged and a properly tuned system should not require constant human monitoring for it to be effective. Staff should be put in place to monitor incidents and make the appropriate decisions based upon established policies and procedures. More mature organisations may also be able to integrate the alerting process of the IDS/IPS into the organisations current Incident Management Programme. Crown Copyright 2009 Page 28 of 30

IDS/IPS management and monitoring is a prime candidate for outsourcing especially in large deployments and should be considered. 9.3 Configuration Management Policy and procedure should be put in place to ensure that sensors deployed within the infrastructure can be updated with new configurations in a managed way. The extent of change management is dictated by the number of sensors deployed ranging from a single node with a manual update process to many sensors deployed in different environments which check a central repository for new configurations. Where possible: Group Sensors into as few groups as possible and define appropriate configurations for each group to ease management. Stagger updates to sensors to reduce the impact of mis-configurations leaving the network potentially vulnerable Separate the change management functions from the event monitoring systems to provide resilience Crown Copyright 2009 Page 29 of 30

10 Resources and References 10.1 Further helpful resources Evaluating IDS/IPS solutions: http://www.cioupdate.com/article.php/3563306 Intrusion Detection System Frequently Asked Questions: http://www.sans.org/resources/idfaq/ Wireless Intrusion Detection Systems: http://www.securityfocus.com/infocus/1742 Anomaly Detection in IP Networks: http://users.ece.gatech.edu/~jic/sig03.pdf Host-Based Intrusion Detection Systems: http://staff.science.uva.nl/~delaat/snb-2004-2005/p19/report.pdf 10.2 References Bejtlich, Richard, The Tao of Network Security Monitoring: Beyond Intrusion Detection, Addison- Wesley, 2004. Rash, Michael et al, Intrusion Prevention and Active Response: Deployment Network and Host IPS, Syngress, 2005. NIST, SP 800-83, Guide to Malware Incident Prevention and Handling NIST, SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDS/IPS) Crown Copyright 2009 Page 30 of 30