Investigating the efficiency of modern Intrusion Detection Systems (IDS) in detecting current evasion techniques – Part 2

A look at IDSs in more details

As described by Karen Scarfone and Peter Mell (2007, page 15):

“Intrusion detection is the process of monitoring the events occurring in a computer system or network and analysing them for signs of possible incidents, which are violations or imminent threats of violation of computer security policies, acceptable use policies, or standard security practices. Incidents have many causes, such as malware (e.g., worms, spyware), attackers gaining unauthorized access to systems from the Internet, and authorized users of systems who misuse their privileges or attempt to gain additional privileges for which they are not authorized.”

They also mentioned that an IDS is a software that automates the process of intrusion detection and an IPS has the same functionality of an IDS but with an extra option that can stop incidents. An IPS can work as an IDS by deactivating the IPS option, which is why the term IDPS is used to mean both (IDS and IPS).

This post provides solid foundations to setup the seen for the understanding the upcoming posts in this series when we delve into different methods used to defeat these systems.

what are IDPS used for?

An IDS is used to monitor the network activity for any indications of malicious activity. An activity can be classed as malicious if it violates the organisation’s IT policy, which means that in many occasions an activity that is classed as malicious to one organisation might not be classed as so by another organisation. In the event of any violation the IDS would log the event and raise an alert. If the IPS option is activated then it would stop the activity as well. Karen Scarfone and Peter Mell (2007, page 16) mentioned that in addition to detecting incidents and helping in the incident response efforts, organisations have found other uses for IDPSs, including the following:

“Identifying security policy problems – An IDPS can provide some degree of quality control for security policy implementation, such as duplicating firewall rulesets and alerting when it sees network traffic that should have been blocked by the firewall but was not because of a firewall configuration error.

Documenting the existing threat to an organization – IDPSs log information about the threats that they detect. Understanding the frequency and characteristics of attacks against an organization’s computing resources is helpful in identifying the appropriate security measures for protecting the resources. The information can also be used to educate management about the threats that the organization faces.

Deterring individuals from violating security policies – If individuals are aware that their actions are being monitored by IDPS technologies for security policy violations, they may be less likely to commit such violations because of the risk of detection.”

IDPSs have become one of the most important security components of any enterprise network due to the increased reliance of organisations on information systems, which in turn increased the attack parameter that attackers can launch their attack from. Therefore IDPSs have added another layer of security that makes it harder for attackers to succeed.

Intrusion Detection Systems and Intrusion Prevention Systems (IDPSs) come in a lot of different types, these types are categorised according to the events they can detect and the ways they use to detect incidents. Regardless of the different types of IDPSs, they all do the following:

• Record data linked to the detected events.
  
• Notify (alert) security analysts of important events.
  
• Produce reports.
  
• If the IPS option is ON then the system would stop the attack in many ways:
  
  • Terminate the session or connection used for the attack.
    
  • Deny access to the target from the attacking IP or user account.
    
  • Block all access to the targeted host, services, applications or resources.
    
• Change the security environment by modifying security devices such as firewalls or even apply patches.
  
• Change the content of the attack, like for example an IDPS acting as a proxy that normalises requests.
  

All of the mentioned features do not mean that these devices are accurate and reliable as will be demonstrated later in this study. They do have quite a few of limitations such as producing false positives and false negatives.

False positives described by Karen Scarfone and Peter Mell (2007, page 17) as the IDS identifying the event as a threat when it’s really harmless, while False negative is the opposite.

Many organisations choose to lower the rate of false negatives even thus this would increase the rate of false positives. This is due to the difficulty developers found when they tried to solve this issue, they found that a decrease in one would increase the other and vice versa. There are however quite a few of research studies that are still going on with the aim of solving this problem.

Detection Methods

All of the different types of IDPSs that are available fall into one of the following categories:

• Signature-based
  
• Anomaly-based
  
• State-full protocol analysis based
  

signature-based

This type of technology is the simplest method, has very little understanding of network and application protocols and cannot track or understand the state of complex communications. This is not to say that this technology is not popular, many security professionals have realised that most IDPSs use some form of signature-based methodology.

The way this technology works is by comparing the network traffic to a database of signatures of known attacks, if traffic matches any of the signatures contained in the IDS; the IDS considers it as a violation. Signature-based methods are very effective at detecting known attacks with a rate of 100%; however it cannot detect unknown attacks. To explain this further, consider an attack signature that examines the packet payload for a file called “attack.exe” if the attacker changed the name of the file to “attack2.exe” then the attack would bypass detection because the string does not match the string the signature is looking for although it’s the same attack.

Anomaly-based

Anomaly-based technology monitors network activity and detects incidents by comparing the activity to a set of profiles of normal behaviour. An IDS can have a set of different profiles such as profiles for normal services, applications, network bandwidth, users, etc. These profiles are created by the IDS in two ways:

Static profiles are created manually by the administrator and once they’re created they stay as they are and never change unless recreated again. As the network changes this type of profile becomes inaccurate and needs to be recreated.

Dynamic profile is constantly adjusted as changes in the network occur.

These profiles are created in an initial period called the training period and acts as a base-line that the network activity is compared against.

Although anomaly-based methodology can be very effective in detecting unknown attacks, they do suffer from the following problems however:

• Malicious activity could easily sneak into the profile.
  
• The profiles may not describe the true nature of the network especially in complex networks.
  
• A periodic maintenance that was not included into the profile when the profile was created could make the IDS flag it as a violation when it is really a normal activity. Thus this type of detection method tends to create many false positives.
  

State-full protocol analysis

This technology uses universal vendor-developed protocol profiles of how a protocol should and should not be used. This profile is used to compare the activity of the network to it to detect incidents. State-full protocol analysis is able to detect many attacks other detection methodologies can’t because of its ability to understand and track the state of protocols. For example the IDPS could have a profile of unauthenticated FTP sessions and a profile of authenticated FTP sessions, if the user just opens an FTP session the IDS will be able to know that the user is currently in the unauthenticated state and so should only be able to enter few commands such username and password. At this stage the system can track the session to see if the user entered commands that should not be available at that stage.

Once the user authenticates the IDS moves to the authenticated users profile, which allows the user to enter most of the FTP commands. This is very useful and demonstrates the method’s capabilities that other methods don’t have.

However state-full protocol analysis technologies have the following problems:

• They’re very resource-intensive due to the session tracking processes.
  
• It is very difficult to develop an accurate protocol model because of the lack of adherence of vendors to the protocol standards when they implement these protocols into their operating systems or applications.
  
• It cannot sense malicious actions that do not violate the behaviour of a certain protocol, which means attacks such as Denial of Service (DoS) will not be detected.
  

Depending on the kind of actions the IDPSs monitor and the way they’re installed they can be grouped into the following four groups:

• Network Intrusion Detection Systems (NIDS).
  
• Wireless Intrusion Detection Systems (WIDS).
  
• Network Behaviour Analysis (NBA).
  
• Host Intrusion Detection Systems (HIDS).
  

Each one of these IDSs will be presented in the following sections.

IDPS Tecchnologies

components and architecture

As mentioned previously IDPSs monitor the communication for any activities that are classed as a violation of an organisation’s IT security policy. According to what (Mell 2007) mentioned these critical devices are made of several components that make it work:

• Sensors (WIDS, NIDS, NBA) or Agents (HIDS) monitor and analyses the network for any violations.
  
• Management server comes as either an appliance or software; these servers are centralised devices that manage the sensors or agents and gathers information from them.
  
• Database servers store the incident information recorded by the sensors, agents or the management servers.
  
• Consoles are programs that provide the interface for security analysts to monitor the network and administer the sensors or agents.
  

These components are connected to each other and to the rest of the network in two ways:

• Separate management network – all sensors and agents have an additional interface called the management interface that is connected to the management network. The management network contains the management servers, consoles and the database servers, this separates the management network from the rest of the enterprise network, which protects the IDSs from attacks by hiding their presence and identity from attackers and gives IDSs a larger bandwidth of operation then the option described next.
  
• As part of the standard network – this option might have the benefit of lower costs and ease of use (IDSs can be monitored and configured from any computer in the network) but it exposes the IDPS to attackers and attacks. Nevertheless some form of protection and security can be achieved by creating a virtual management network using VLANs. This simulates the physical management network option (above) and improves security but not as much as the separate management network method. Also this method is vulnerable to VLAN misconfiguration, malware incidents and Distributed Denial of Service (DDoS) attacks.
  

IDPS Security Features

Intrusion detection systems offer many security features, these features can be divided into the following four groups:

• Information gathering
  
• Logging
  
• Detection
  
• Prevention (if the IPS option is active)
  

Information gathering

IDSs have the ability of gathering a wide variety of information from the observed network activity such as identifies hosts and operating systems, identifies the type of applications used and identifies the characteristics of the network.

logging

Data related to the events that were detected are logged extensively by IDPSs, analysts use this data to confirm the accuracy of alerts, investigate incidents and links events between IDSs and other logging sources. The logs includes the events timestamps (date and time), event type, rating (impact, severity, confidence, priority) and the actions (Allowed, prevent, alert).

Detection

When it comes to the detection capabilities of IDSs, each type offers certain capabilities other types of IDSs can’t offer. Due to this many modern IDPS products offer a mixture of detection methods in order to provide a bigger detection boundary, more accuracy, and greater flexibility in tuning and customisation. Some of the capabilities most IDPSs offer are as follows:

Threshold – a value that represents the margin between good and bad behaviour, for example 3 failed login attempts in 60 seconds.

Blacklists and White lists – a list containing unacceptable and acceptable TCP/UDP ports, usernames, hosts, IPs, URLs, etc…

Alert settings – customise each alert to:

• Turn it ON/OFF.
  
• Change the importance or severity levels.
  
• What information should be recorded?
  
• The method to use to notify the analyst (email or pager).
  
• What prevention methods to use.
  
• Supress the number of alerts generated for each incident.
  

Code viewing and editing – usually limited to signatures with the exception of some technologies that might allow the administrator to see other codes of other parts of the IDS.

Management

Most of the management features offered by many IDSs are very similar and can be divided into the following two groups:

• Implementation (architecture design)
  
• Operation and maintenance
  

Architecture Design

Before installing the IDS into the network an analyst needs to carefully design its architecture to cover all the areas that needs to be monitored. When designing the architecture the following points needs to be considered:

• Sensor or agent placement.
  
• Solution reliability and what to use to ensure this reliability such as each activity monitored by multiple sensors in case of a failure, multiple management servers, etc.
  
• The number and placement of the components (consoles, database servers, management servers) to cater for usability, redundancy and load balancing.
  
• What other systems the IDS needs to interface with such as:
  
  • Systems it needs to pass data to, like for example security information and management software, logging servers, email servers, paging systems, etc.
    
  • Systems it needs to send responses to (firewalls, routers, switches).
    
  • Systems that deals with the management of the IDS (network management software, patch management software).
    
• How will all of the components be connected together (via a management network or standard network)?
  
• The necessary modifications needed to other security devices to help the IDPS to work effectively (firewall rule set).
  

Component testing and deployment

After the intrusion detection analyst have finished designing the architecture and considered all the important points of a successful design, he/she needs to test and deploy the components according to the requirements of the architecture. This would cause a problem and outage of the production network if great care is not taken. Thus it is very important to do this on a testing environment that simulates the real network but is isolated from the real network. After all the tests, tuning and customisations have been completed, the transition to the production network should be started.

Implementing these tests on a simulation network first rather than the production network will give the analyst extra information of all the problems he/she will face and an approximate time of completion, which will allow for countermeasures and precautions to be taken to reduce the outage time.

component security

Great measures should be taken to secure the IDPSs to prevent them from being attacked. In addition to hardening the devices and making sure they’re always kept updated and patched the analysts should take the following recommendations into account:

• Create separate accounts with least privileges for each user and administrator of the IDS.
  
• Setup the firewalls, routers and packet filters carefully to reduce direct access to the IDS components to only the hosts that needs it.
  
• Ensure the IDS management communication is protected by either a physical management network, a logical management network via VLANs or by the use of encryption. When encryption is used it needs to be FIPS-approved standards.
  
• Use VPNs or other encrypted tunnelling methods for products that do not provide encryption.
  
• For remote access use strong authentication such as two-factor authentication.
  

operation and maintenance

The IDPS architecture is carefully designed and tested, deployed and secured; does this mean the end of it for the security analyst or admin? The answer is no, the admin or analyst needs to carefully monitor and maintain the IDPS at regular periods on a daily basis to ensure the smooth operation of all of the IDPS’s components. This can be achieved by the use of consoles that provide a graphical user interface (GUI) and command line interface (CLI). The CLI allows the analyst to perform the operation and maintenance tasks by means of a script that can be scheduled to run at a time that suites the analysts. Regardless of whether the analyst’s preference is to use the CLI or the GUI, the console enables the analyst to perform their tasks very easily from a single location. Some of the tasks that can be achieved are as follows:

• Configure and update the components (sensors, agents, management servers).
  
• Monitor the components status.
  
• Manage user accounts.
  
• Customise the IDPS and generate reports.
  
• Monitor and analyse the IDPS.
  

Network Intrusion Detection Systems (NIDS)

A network intrusion detection system (NIDS) is a device used to monitor network activity for any malicious behaviour. The protocols that are analysed by NIDSs are:

• Network
  
• Transport
  
• Application
  

In this section the author presents this type of IDS in more details.

Typical components

NIDS are made of the same components as all other IDSs, that have been previously described with one slight difference in the sensor. The sensor of the NIDS monitors and analyses network activity on one or more segments. The network interface card (NIC) of the NIDS can see all of the network traffic no matter where their intended destination is because the NICs are placed into promiscuous mode.

sensor location

As well as choosing the most suitable architecture for the components, an analyst needs to also choose the most suitable location to place the sensors. The following explains the two modes that sensors can be deployed in:

• Inline: in this mode the traffic that is monitored has to pass through the sensor in a similar way to a firewall so the NIDS will be able to stop any malicious activity. This is usually at the more secure side of the network, which is after the firewall. The reason for this is so the NIDS can stop attacks and the amount of traffic that the NIDS have to process is decreased, also this would give another way of testing the effectiveness of the firewall’s operation. To protect the firewall and reduce the traffic it has to process, the NIDS can also be placed in front of the firewall (in the less secure side). The figure below illustrates this mode of deployment.
  

Figure A1: NIDS Inline sensor architecture (Mell 2007)

• Passive: this mode allows the NIDS to passively monitor the network without the ability of stopping any attacks. A copy of the network traffic monitored from key network locations such as DMZs is passed to the IDS so that it can be check for any violations. In this setup the network traffic still makes it to its destination, however a copy of it is captured and analysed by the IDS and if a violation is found an alert is produced. IDSs using passive monitoring can do so by using several methods:
  
  • Spanning port is a port on many switches that can see all of the traffic going through the switch, IDSs can use this port to monitor the network traffic. Analysts might choose such a mode due to its low cost and simplicity; however, it does have some problems. One of these problems is misconfiguration of the switch could lead the spanning port not be able to see all of the traffic. Another problem is that it is resource-intensive and if the switch is under a lot of load the spanning will also not be able to see all of the traffic or worse it might get disabled.
    
  • Network Tap: in this mode the NIDS is provided a copy of the traffic via the network tap, which connects into the physical network media. The problem with this one is that a network down time occurs when the tap is installed, and it can also be expensive.
    
  • Load balancers: receives copies of network traffic from spanning ports or taps and distributes the load amongst other devices. This can reduce the detection accuracy. For example, say we have two sensors, and each see different levels of the attack; the attack might go undetected if each of the levels alone is considered as benign and the two levels in sequence is considered malicious.
    

Figure A2: NIDS Passive sensor architecture (Mell 2007)

Collection Device	Advantages	Disadvantages
Hub	Cheap Simple Usually ready available. See all layers of traffic. Observed packets are not changed.	Half duplex so collisions are a problem. Not designed for monitoring (single power supply). Can inject traffic.
SPAN PORT	Leverages features are available in existing infrastructure. Simplest method for watching internal segments with no natural choke points.	No visibility of layer 2 traffic. Packets that are undersized or oversized or have other problems are ignored. Switch concentrates on passing traffic not coping them to the SPAN port; latency introduced. Multiple SPAN sessions supported only by most expensive switches. Requires choices to monitor SPAN sessions for intra- and interswitch operation, which can cause the sensor to see duplicate packets. Observes packets as copies of traffic, with VLAN tags stripped or otherwise potentially modified. Must dedicate a gigabit port for the sensor to span multiple 100-Mbps ports.
TAP	Full duplex Designed for monitoring (has redundant power source and/or continues to pass traffic if power fails). Can be configured as completely passive devices. Sees all layers. Does not change observed packets in any manner. With regeneration taps, allows multiple sensors to watch a single link.	Expensive (compared with hubs). Requires a sensor to accommodate separate TX stream (for dual output).
Inline device	Offers access control and traffic scrubbing. Easiest to integrate monitoring with other security or network roles, like caching or proxying traffic.	Introduces another point of failure (as do hub and taps but far more complicated than hubs or taps). Latency added to link. Compromise of device possible.

Sensor placement architecture (Mell 2007)

Types of events Detected

Most IDSs detect the same or very similar events because of the multiple detection methodologies they use in a single product; however, the events that are more related to NIDS are as follows:

• Application layer Reconnaissance: Banner grabbing, buffer overflow, DHCP, DNS, finger, HTTP, FTP, peer-to-peer, IRC, etc.
  
• Transport layer Reconnaissance (TCP/UDP): port scanning, packet fragmentation, SYN floods.
  
• Network layer Reconnaissance: spoofed IP, bad IP header values.
  
• Unusual application services: tunnelled protocols, backdoors, and unauthorised applications. This is usually done using state-full protocol analysis or anomaly detection.
  
• Policy violation: forbidden websites or applications.
  

NIDS limitations

There are some important limitations that NIDS suffer. These are outlined as follows:

• NIDS cannot detect attacks that have been encrypted. To overcome this NIDS should be placed either before encryption or after decryption or HIDS can be used to monitor unencrypted activity.
  
• Unable to perform analysis under high load. Sensors that can identify high load should be selected when inline deployment is used, and the sensor should be configured to drop low priority traffic during a high load condition to reduce the load the IDS needs to process.
  
• NIDS are vulnerable to several types of attacks that involve high volumes of traffic such as DDOS and blinding attacks.
  

Wireless IDS (WIDS)

Components

Wireless IDSs have the same components as other IDSs and they work in the same way except for a slight difference in the way the WIDS sensors work. The sensors are more concerned about wireless protocols and operate by sampling the traffic, which means they’re unlike NIDS they can’t see all network traffic (they can only see traffic related to the wireless protocols). WIDS sample traffic using two frequency bands (2.4 GHz and 5 GHz); each of these bands has their own separate channels. The WIDS sensor can only monitor a single channel at a time.

Network Architecture

WIDS components are connected to the enterprise network via the wired network. In this setup a separate management network or the standard network can also be used. An illustration of WIDS architecture is shown in figure A.3.

Figure A3: WIDS architecture (Mell 2007)

Sensor Placement

The location of the WIDS sensors should be in range with the WLAN’s frequencies so that it can monitor the following points of entry to the network:

• Access Point (AP) as well as stations (STAs).
  
• Physical zones where there should be no WLAN activity.
  
• Channels and Bands that shouldn’t be used (this is one of the ways of detecting rouge AP and ad hoc WLANs).
  

The following points are other points that should be considered when placing WIDS sensors:

• Physical Security: so they don’t get stolen or physically damaged.
  
• The range of the sensor: the range of the deployed sensors should overlap (at least 20%).
  
• Wired network: may need extension if the WIDS sensor needs to be placed in an area with no wired connections.
  
• Cost: the risk and impact of attacks should be compared with the cost of:
  
  • Sensors
    
  • Deployment
    
  • Maintenance
    

Events detected

WIDS monitor wireless protocols only (IEEE 802.11a, b, g and i) and cannot examine communications at higher levels (IPs, application payloads). Also, the detection accuracy that WIDS have is greater than other technologies; this is because of WIDS limited monitoring scope.

The types of events WIDS can detect are as follows:

• WLANs and WLAN devices that are not allowed.
  
• Devices with poor security.
  
• Unusual usage.
  
• Wireless scanners.
  
• Denial of Service (DoS) attacks (both logical DoS such as flooding and physical DoS such as jamming).
  
• Impersonation and Man-In-The-Middle attacks.
  

Limitations

WIDS are relatively new and still maturing; it has a robust detection capability and can be very useful when protecting WANs. However, they still suffer some limitations such as the inability of detecting passive monitoring and offline wireless traffic processing. Also, they are vulnerable to evasion attacks. Another problem is that WIDS are unable to monitor a full frequency band, which means that it can only monitor one channel at a time. If the WIDS needs to monitor another channel it has to turn its radio off, switch to the other channel and then turn the radio back on. Thus, the longer the WIDS monitor a channel the more malicious activity on other channels that it will miss.

Network Behaviour Analysis (NBA)

Components

NBA sensors rely on vendor provided protocol profiles that it compares network traffic to; the sensors mostly come as hardware appliances. The components they’re made of are similar to other IDSs, however there are some differences in the way they operate. NBA sensors can detect bad activity in to ways and all depend on the type of NBA sensors used. Some of these sensors monitor the network by sniffing packets of the network while others receive network flow information from routers and other devices that they use to analyse for any violations. According to (Mell 2007) this information typically includes the following:

• Source/destination IPs.
  
• Source/destination TCP/UDP ports or ICMP types and codes
  
• Number of packets and number of bytes transmitted in the session
  
• Timestamps for the start and end of the session.
  

Architecture

The network architecture of NBAs are the same as NIDS network architecture (can be separate management network or standard network); however if the type of sensor used is the one that receives flow information from other network devices such as routers, the NBA can be separated from the network by the use of VLANs. The sensors can be placed in the same way as NIDS (inline or passive).

NBA’s detection techniques require them to have good knowledge and understanding of the network such as the organisation’s hosts characteristics. They can monitor port usage, do fingerprinting and can gather detailed information on hosts as well as the ability to automatically create a list of communicating hosts. The following is a list of some of the information that NBAs can gather for each host:

• IP addresses.
  
• Operating System.
  
• The type of services each host uses as well as the IP protocols and the TCP/UDP ports used.
  
• A list of other hosts it communicates with and the services, IP protocols and TCP/UDP ports.
  

Figure A4: NBA network Architecture (Mell 2007)

Events Detected

Most NBAs cannot offer signature-based detection; they tend to use anomaly and state-full protocol analysis techniques to analyse traffic and have the ability of detecting the following type of activities:

• Denial of Service attacks.
  
• Scanning attacks.
  
• Worms.
  
• Application services that shouldn’t be running.
  
• Policy violations.
  

Most NBAs according to (Mell 2007, p.68) can rebuild a sequence of events to find out where a threat has come from. For example, if a worm is spread throughout the network the sensor can investigate the worm’s flow to pin point which host started the infection.

Limitations

The data that some NBA sensors rely on receiving from other devices cause a delay in detecting attacks because this information comes as a batch every minute or several times an hour and rapid attacks can spread throughout the network before they get detected. The sensor can get flow information from many networks while it can only monitor a few at a time.

Host-based IDS (HIDS)

Components

Host based IDSs monitors wired/wireless network traffic on a single host, system logs, processes that are running, file access, file modification and system and application configuration changes. They’re designed to protect servers, client host and application services. HIDS only monitor the host they’re installed on; the agent monitors the activity on that host, sends the data to the management server, which uses a data base server to store this information and then the console is used by the analyst for management and monitoring.

The agent software is sometimes installed on dedicated appliances instead of being installed on a single host; the appliance monitors the traffic to and from the host.

Architecture

Because the agents are installed on the hosts that are already part of the organisation’s network or on a dedicated appliance its architecture is very simple. A separate management network is not needed because most components communicate over the network via encryption. When appliance based HIDS are used they’re usually placed in front (inline) of the host it is protecting. As it was previously mentioned in this study that one of the limitations of IDSs (except for HIDS) is that they’re unable to detect encrypted malicious activities.

Figure A5: HIDS Sensor placement and architecture (Mell 2007)

For these IDSs to be able to detect these activities they need to monitor traffic either before encryption or after decryption. Therefore HIDS ability to monitor many different types of events that other IDSs can’t monitor and because of its location being installed on the hosts themselves means that they’re able to monitor events after they’ve been decrypted and also before they’ve been encrypted (this is in the case of the event originating from the host being monitored), which gives them the ability of detecting encrypted attacks.

To compensate for the limitations other IDSs have; there’s a need to use HIDS as well but depending on the size of the network this is sometimes not feasible. For this reason, on enterprise networks HIDS are usually installed on critical systems that contain sensitive data and are publicly accessible.

Events Detected

HIDS usually use signature-based and anomaly-based detection to detect unwanted activities. Some HIDS only use one detection technique while others use several techniques to analyse traffic, this depends on the host they’re intended to monitor. The common techniques used by HIDS are as follows:

• Code analysis analyses the attempt to execute code by performing the following analysis techniques:
  
  • Code behaviour analysis executes the code in a virtual environment first and monitors its behaviour.
    
  • Buffer overflow detection (stack and heap buffer overflow)
    
  • System call monitoring like for example detecting the existence of key loggers.
    
  • Application and library list authorised and unauthorised applications and libraries.
    
• Network Traffic Analysis like NIDS.
  
• Network Traffic Filtering a host-based firewall that can allow or block incoming and outgoing traffic to every application on the host.
  
• File System Monitoring (file integrity check, file attribute check, file access)
  
• Log Analysis
  
• Network Configuration Monitoring can detect changes in the host’s network configuration.
  

Not all HIDS monitor all of the mentioned events (some do); however, an organisation needs to choose the product that best suites the job of the system it should monitor. Such choices are usually influenced by the following:

• The cost of the agent and the cost of deploying, maintaining and monitoring.
  
• The operating system and applications supported.
  
• How important the host’s data is?
  
• The current infrastructure’s ability to support the agents and the cost of any modifications to infrastructure that might be needed.
  

Limitations

HIDSs can be very useful and have many features other IDSs don’t have; nevertheless, they do have some limitations that can restrict its usefulness, these are as follows:

• A delay in detecting some event due to some detection techniques being performed in an hourly basis a few times a day.
  
• Delays in responding to some events due to the time it takes to forward alert data to the management servers. These alerts are sent in batches a few times an hour.
  
• They can be resource-intensive because the agents are run on the hosts being monitored. This can be solved by a dedicated appliance.
  
• The agent installation can cause a conflict to the existing security controls on the host, like for example it can modify the firewall rules or turn off the firewall altogether.
  
• An agent configuration or upgrade can cause the host to reboot.
  

Therefore, for the above two points it is important to test these HIDS on a test (can be virtual) host that has the same configuration as the host being monitored.

Summary

In this chapter a detailed look on all the different types of IDSs have been taken; the different types of detection methodologies used, the types of events that can be detected, the security capabilities of each type and the IDSs limitations have been discussed. This gives good background knowledge to start a more detailed look in the upcoming series of posts at the different evasion techniques that can be implemented to evade detection.

Advertisement