SESSION 3 NOTES

21 Jul SESSION 3 NOTES

1. Understand the basics of host-based IDS architecture.

2. Learn what types of threats host intrusion detection systems are intended to detect.

3. Introduce relevant event sources, actions, and other factors to be considered with HIDS.

4. Consider the factors behind choosing host-based IDS placement on systems in an environment.

5. Discover some strengths and weaknesses of host-based IDS.

To Do List

Tasks

· Read the session notes (below), including any embedded URL links.

Readings/OERs

1. Guide to Intrusion Detection and Prevention Systems (IDPS)

http://csrc.nist.gov/publications/drafts/800-94-rev1/draft_sp800-94-rev1.pdf (section 4, pages 57-67 only)

2. Intrusion Response Systems: Survey and Taxonomy

http://paper.ijcsns.org/07_book/201201/20120101.pdf

3. Advances and Challenges in Standalone Host-based Intrusion Detection Systems

http://is.muni.cz/th/172999/fi_r/Advances_and_Challenges_in_Standalone_Host-based_Intrusion_Detection_Systems.pdf

Assignments

· Submit your Analytical Research Project topic to the Paper Topic assignment folder by the end of the session.

Session Notes

Preliminaries

This week we continue our study of approaches and types of tools available to support intrusion detection, with an emphasis on host-based IDS. While we are still covering many of the basic concepts in the course, it is not too early to begin thinking about your term papers for the course. Detailed assignment instructions for the Analytical Research Paper have been posted in the General Information module under Content. Please submit your proposed paper topic by the end of the session.

Host-Based Intrusion Detection Systems

In many contexts, host-based IDS tools are considered somewhat simpler than their network-based counterparts, but this perception is often incorrect. Some of the most common kinds of HIDS products – such as file integrity checkers – do tend to have less complex rulesets and less sophisticated analysis engines. There are many uses for host-based intrusion detection that do involve very complex processing characteristics, so do not be misled by the greater attention often paid in the market to network-based IDS. Also bear in mind that because a host-based IDS can be tailored to the specific type of applications running on the host it monitors, HIDS are well-suited to anomaly-based intrusion detection, and therefore less often dependent on large libraries of attack signatures. None of the popularly available books on IDS and IPS provide any significant coverage of host-based IDS (and NIST Special Publication 800-94 devotes only 10 pages to this class of technology), but it is important to address enough about this class of intrusion detection to be able to compare it with network-based IDS and to understand some of the key threats many environment face against which NIDS tools simply aren’t effective, but where HIDS can offer some protection. The third reading in the list above is intended to compensate for the relatively lack of attention to HIDS in other popular sources.

One way to contrast HIDS with NIDS is to consider of the types of threats that host-based intrusion detection systems (HIDS) are designed to detect, and of the basic architectural characteristics (e.g., detection agents) of host-based sensors. The primary distinction drawn in many HIDS deployment architectures focuses on the use (or absence) of a centralized analysis engine to process the data collected by host-based sensors. There are, as you might expect, some “hybrid” architectures that do not precisely match either the centralized or distributed deployment patterns, but organizations seeking comprehensive HIDS protection are realistically looking a deploying and monitoring a lot of agents. The advantages and disadvantages offered for HIDS deployment architectures center much more on response time and performance trade-offs, rather than the source of the data being monitored as with NIDS. The HIDS market has evolved with solutions in both classes of architecture, but centralized architecture has emerged as a preferred approach due to a variety of factors, not all of which are just about host-based IDS. One of the broad information security tool market trends over the past 5-10 years is a movement towards security devices from different vendors being able to communicate to a single management console or monitoring application. There are of course a few very large security vendors with comprehensive suites of tools that make it possible to deploy many components with the same brand across a security architecture. However, many organizations still prefer the use of “best of breed” tools, including niche products optimized to fill very specific types of security control needs. There are even open-source suites of tools that are designed to work this way. From a security management and operations standpoint, it is essential that the decision to deploy security devices from multiple vendors does not mean that multiple management consoles are required to keep track of security operations. Similarly, the past decade has seen the emergence and rapid growth of the security event correlation market (particularly in support of another infosec discipline often called “security event and incident management” or “SEIM”), in which data from many security devices is aggregated and analyzed together to look for evidence of complex attacks being attempted against an organization. It is these security management-related considerations that lead to the general preference for centralized HIDS deployment, rather than distributed.

Leaving aside for the moment some of the market drivers mentioned above, consider the factors that might lead you to choose one sort of HIDS architecture over the other. One such consideration is the nature of the systems an organization intends to monitor with host-based IDS agents. If the systems on which HIDS will be installed include many instances of similar devices (such as corporate desktop or laptop computers), then it is quite likely that the rules for intrusion detection and the security policies that lead to those rules will be similar across most or all of the computers where agents are installed. A simple example of this sort of deployment in the real world is the growing popularity of USB device monitoring (or blocking). These solutions work by monitoring the event logs from each computer, and reporting to a central administrator any event that corresponds to a restricted USB device having been connected to a monitored computer. A company using such a security tool might want to update the list of approved or forbidden devices; in a centralized HIDS architecture, any change in policy or the rules used to enforce that policy only needs to be applied at the central monitor. Because the analysis is not performed at the agent, each agent can continue to communicate USB connection events as before; the difference after the change is seen in the central analysis engine and the alerts it now generates.

Benefits of HIDS

Drawing primarily on Bukac, Tucek, & Deutsch (2012), we can identify several benefits and drawbacks to HIDS, considered on their own or in contrast to network-based IDS. One of the key benefits of HIDS is that it is able to perform analysis on traffic on data sent across the network with end-to-end encryption, something NIDS tools cannot do without quite specialized configuration. The way HIDS performs this task is not actually about working with encrypted data; because HIDS agents are deployed on computers that send or receive encrypted transmissions, they can inspect the data in unencrypted for before it is sent or after it has been received. The placement of host IDS sensors is an important aspect to leveraging this capability. Typically, HIDS agents are placed on an organization’s important or sensitive computers and devices, including servers, network components, and end-user workstations like desktop and laptop computers.

Another obvious benefit is the wider variety of types and sources of data that host-based IDS tools are designed to inspect. HIDS can look at system and event logs, file systems, and application access and other activity taking place on a host, while NIDS sensors generally monitor network traffic flowing between hosts. Because HIDS tools analyze network traffic specific to the host, they process and interpret network data in much the same way as the applications on the host. This renders many common NIDS evasion techniques (e.g., packet fragmentation, data encryption, exploitation of platform-specific differences in packet interpretation, etc.) ineffective against HIDS.

Like all security tools, HIDS provides discrete benefits but also presents challenges. Bukac, et al. identify four main challenges:  “Real-time and computing resource restraint; networking factor; ground truth problem; [and] deployment issues” (p. 2).  Ideally detected intrusions would be reported in near real-time but in actual practice this is often not the case. Real-time analysis and alerting is difficult for some types of HIDS detection methodologies and processes due to the amount of computational time and resources required to analyze HIDS data sources. The networking factor challenge is essentially a capability limitation of HIDS. According to Bukac et al., modern computing environments are returning to application architectures that resemble client-server patters for applications that are commonly referred to as network-based. Over time, network-based application vulnerabilities have received the most attention from bad actors to gain access to targeted hosts. As a result, network designers migrated to a more central deployment of resources to better defend against this threat vector but most HIDS tools are not always well-suited to defending applications designed in this way.  The ground truth problem has nothing to do with the capabilities of HIDS, but instead stems from HIDS’ reliance on the integrity of data it uses to perform its analysis. Compromises to the integrity of this source data (such as through corruption or alteration by threat agents) can reduce the reliability and usefulness of HIDS monitoring.  Lastly, deployment issues concerns the architecture of the network itself. Most networks tend to have an assortment of hardware platforms with varied capability sets and multiple software deployments including applications and operating systems, presenting a challenge when deploying a single type of IDS technology.

Detection and monitoring of workstations, servers, and network devices also requires attention to the matter of security policy, this time primarily in the context of auditing. Having effective security policies in place and implementing them accurately in the intrusion detection tools that are designed to enforce the policies can be of great help with either centralized or distributed HIDS architectures. Policy in essence is a statement about what the organization cares about. From an IDS perspective (network or host), policy influences both what we detect and, more importantly, what if any response is taken when something is detected. Policies translated into host-based IDS agent configuration helps control the local operation of the agent and govern its communication back to any central monitoring or analysis system. For distributed agents, it is important to find the right balance between the amount of information produced and analyzed by the host-based agent and the performance characteristics of the system on which the agent resides. We will return again to security policy later in the course as another important input to writing IDS rules.

Review Questions

1. What are the two primary host-based IDS architectures? What are the major differences between them?

2. What are some types of threats that host-based IDS can help discover?

3. What are some benefits of host-based IDS?

4. What are some challenges to using host-based IDS?

5. How does the way a host-based IDS works help defend against insider threats?

(These questions are intended to be a self-test of your comprehension of this session’s material; answers to these questions do not need to be turned in.)

Summary

In Session 3 we looked at host-based IDS, and looked at some of the drivers behind HIDS deployment architectures.

Preview of Next Session

In the next session, we will switch our focus from general IDS discussion to a closer examination of the specific IDS product we will use in this course: Snort. We will also complete our first Lab exercise.

Copyright © 2016 UMUC – All rights reserved.