PDA Logo.gif (6595 bytes)

Intrusion Detection Systems


our services

about Peter Davis+Assoc.


security/audit info

Privacy Test

Security & Audit Tools


Windows NT Server IIS

Windows 95


Java, JavaScript and ActiveX

Intrusion Detection Systems

Security Industry Shakeout

Securing Groupware

Client/Server Audit: One Bite At A Time

Configuring Cisco Denial of Service Security Features - Part 1

Configuring Cisco Denial of Service Security Features - Part 2

Configuring Cisco Lock-and-Key

Configuring Cisco Reflexive Access Lists

Dysfunctional Controls: Useless, Impractical, Inefficient and Poorly-Designed

TCPA: Who Can You Trust?

When Getting the Audit Done Is the Only Thing

Palladium: Friend or Foe?

Commentary: Quis Custodiet Ipsos Custodes?

Data Management: Data Destruction and Preservation

Security & Audit Products
Top Ten Security Links 
Security & Audit Checklists
Computer & Security
Security & Audit Bibliography 
Search Page

legal info

privacy info

Dateline: Toronto, ON, December 1997

Wow. New magazine. New column. Same old problems. Around the world, security experts admit that intrusions occur frequently, but mostly go undetected. I personally have been searching for the intrusion detection Holy Grail for 18 years. When I first started my quest, I was working for a large international bank. Like other researchers, we started analyzing System Management Facility (SMF) data looking for evidence of intrusions. Intuitively, we knew that analyzing ACF2 violation reports would tell us little. A case in point.

I have long told a story about a client so I'm not sure at this juncture whether it is apocryphal or authentic, but I do know it is apocalyptic. I tell of a client where I was asked to do a pre-audit audit. Tell them what their "Big Few" auditors would find before they swarmed my client. Of course I started with security administration. I asked the administrator whether they recorded violations. She pointed to a stack about a yard deep. When I asked whether the listing was year-to-date, I was told no it was from the previous day. When I asked how many people reviewed the log, I was told just her. When I asked whether it was a full-time job, she replied she reviewed the listing before coffee. When I asked what do you look for in your review, I was told-and this is one of my favourites-she looked for "unusual activity." When I asked her to define unusual activity, she responded quite seriously, "activity that is not usual." Any attempts at further defining "unusual activity" got us no closer to an understanding of her review process, so I suggested we look through the voluminous violation reports looking for "unusual activity." After a while, I noticed someone could write to the system kernel. I asked was this unusual, and she replied no that person was the system programmer. We scoured the listing a little further when I saw someone could update the payroll file. "Is this unusual activity," I optimistically asked. No, that person was a human resources clerk. This went on for a while until I closed the listing and bet the system administrator that I could log on to the system with information gleaned from the reports. When challenged, I went over to the nearest workstation, and logged straight in. The date was July 2 and I noticed someone had tried JUNyy to login. Naturally, I used JULyy and presto I was in. And I'm willing to wager that should I try that same person's account right now with a password of DEC97, I'd be right in. So why do people still spend all that effort examining violation reports looking for intruders? Reports such as these tell us of people who didn't get access to a file or directory or people with learning disabilities, "fat fingers," or poor memories. Practically, system managers lack the necessary security tools to identify real intrusions while they occur and have no means to prevent them in real time.

Assessment tools, such as Axent's OmniGuard/Enterprise Security Manager, CA-Examine, Computer Oracle and Password Systems (COPS), Intrusion Detection, Inc.'s Kane Security Analyst and Texas A&M's Tiger Scripts, give only a partial solution by identifying security breaches and, in some cases, identifying evidence of a breach but only long after the event.

Another genre of security software, such as Consul's Consul/Entreprise Audit, Internet Security System's SAFEsuite, Janus Associates's I.C.U...MVS, Qualix Group's NetProbe and Secure Networks Inc.'s Ballista, look for system or protocol-specific vulnerabilities or "wormholes," or look for changes in a cryptographic checksum for evidence of unauthorized changes. But something still is missing.

In the mid 1980s, I naively thought I could learn LISP, PROLOG or some other artificial intelligence language, and work this problem out. On first blush, audit-trail reduction and analysis seemed the simple solution. I could use a rule-based expert system to detect known malicious activity. Simple, right? Ah, but many more learned and capable individuals than I have worked on this same problem since that very time with limited success.

Many intrusion detection systems (IDS) base their operations on analysis of the operating system's audit trail data. This data forms a chronological footprint of system usage and is readily available on most systems. Simplistically, IDS compute metrics about the system's overall state, and decide whether an intrusion is taking place.

SRI's early research led to the development of the Intrusion-Detection Expert System (IDES), and then the Next-Generation Intrusion Detection Expert System (NIDES). Their pioneering intrusion detection work converged on providing a general and flexible approach, with no restrictions on targets, audit data for analysis, and techniques. Their current research is focusing on the next generation: Event Monitoring Enabling Responses to Anomalous Live Disturbances (EMERALD).

From these modest beginnings, we see promising signs. Current products either are based on anomaly detection-the system detects intrusions by looking for activity differing from the user's or system's normal behavior-or misuse detection-the system detects intrusions by looking for activity corresponding to known intrusion techniques or system vulnerabilities.

There are commercial products offering real time intrusion detection and real time reaction, albeit some are limited in platform coverage. We now have Axent's OmniGuard/Intruder Alert (ITA), DEC's POLYCENTER Security Intrusion Detector, Haystack Labs Inc.'s Stalker, InfoStream's Watch Dog, ISS's RealSecure, NETECT Inc.'s NETECTIVE, SAIC's CMDS (Computer Misuse and Detection System), Touch Technologies, Inc.'s INTOUCH NSA (Network Security Agent), and the WheelGroup Corporation's NetRanger.

Regardless of the origin, ensure your intrusion detection system:

  1. Runs in the background without human intervention.

  2. Is fault tolerant and fail-safe.

  3. Resists subversion, and is capable of monitoring itself.

  4. Uses minimal system resources.

  5. Detects deviations from normal behaviour.

  6. Is system-configurable.

  7. Copes with changing system behaviour over time as new applications are added.

  8. Is foolproof.

It may be trite to tell you to use your search engine and look for intrusion detection information, but do it. You also might want to check out the Intrusion Detection mailing list. Find out about IDS, and support these vendors. Stop standing on the sidelines, with your hands in your pockets, and get involved. I don't know whether these products get us any closer to a security Utopia, but I do know that they don't leave us where most of us currently live-Dystopia!

Originally published in "Information Security" magazine.

Tell a friend about this page!
Their Name:
Their Email:
Your Name:
Your Email: