| Previous | Table of Contents | Next |
A number of network attacks are launched at Web sites almost daily. Many of these attacks can be detected by network sniffers. However, the content of much of the traffic on the Web is application specific. CGI programs, Java applets, and Java servlets are increasingly used to process mission-critical data linking customers and businesses. These scenarios are really custom applications running via the Web. As more companies deploy these solutions, there will be a greater need for application-specific IDSs.
Commonly used applications, such as Web servers, are scanned by some IDSs today. The higher level applications that run on those Web servers are not. Similarly, IDSs specifically designed for databases, Lotus Notes, and other widely used software are still missing. IDS vendors incrementally look to add application-level scan routines or attack signatures for the most popular applications. The rate at which this is occurring could be improved with a flexible attack-pattern development language, such as the language provided by Network Flight Recorder (even though it wasn’t designed for intrusion detection).
The more important point is that in the future, it’s likely that only application-level subjects and objects will have any significance. Already most Web servers have no users and groups in the standard system repositories. This makes the value of the accountability portion of some system-level IDSs less impressive. If all processes on the OS run as root, and the interesting activity occurs between subjects and objects uniquely meaningful only in certain applications, then IDSs must expand detection to include the application space.
Emphasis has been given several times to the importance of the who in a system or network event. Not only is this important for assigning accountability, but it also is necessary for tying together related security events. You cannot recognize a sequence of events as an attack when they are coming from the same user unless you can identify the user.
A big challenge facing IDSs in the future is the changing “who” landscape. In most tools today, it is a login user ID, group ID, or audit ID that uniquely identifies the subject. When more network and system traffic is application specific, finding the who and the what requires knowledge about the applications. IDSs must be able to adapt to this evolving trend in order to continue to show value.
Another important item to watch is the use of X.509 certificates. Identification and authentication in cyberspace already is widely based on X.509 certificates. These certificates are easily thought of as application-specific credentials, even though they are widely used across multiple applications. Because it is likely that an X.509 certificate will travel through cyberspace with all of your transactions, IDSs must consider the impact of this. Attack signatures will need to consider X.509 certificates in the same way that the AUID is used today. As more applications rely on X.509 for authentication, tracking activities across systems actually will get easier. The X.509 certificate will be passed between systems because it is needed for I&A and for resolving access control requests. Assuming that the applications and OSs include the certificate in log records, a convenient way then will be available for consolidating activities of a single user across systems.
Of course, a possibility always exists that a certificate has been compromised, which means that accountability will be no more reliable than it is with UIDs and GIDs today.
Intrusion detection is a subset of systems management. Events are generated by IDSs and reported to central consoles. Sometimes, an IDS requires you to create special users and passwords to protect who can run the tool. Configuring sensors and engines from a central console is often supported as well. These features are admirable, but when a customer has invested in an enterprise systems management product, all of these tasks are extra work. Systems management frameworks, such as Tivoli’s TME or Cross Site, have general-purpose subsystems for event notification, remote configuration, secure communications, and administrative roles.
Today, each IDS also might include its own proprietary communications framework for secure exchanges between engines and sensors (or other distributed components). Administrative tasks to support this framework include defining administrators, configuring shared secrets, and defining relationships between cooperating nodes or software components. The problem is that an IDS introduces its own unique framework, which is just more trouble for your systems administrators. Integration with TME and similar frameworks is needed so that IDSs fit nicely with the rest of the systems management activities at a site.
The dilemma for the IDS vendor is what to do when a customer does not have one of these systems management frameworks. In these installations, you can see why it’s important to have a proprietary IDS framework as a backup choice. As usual, this tradeoff is sticky. Firewall vendors face exactly the same problem and have invented frameworks as well. Unfortunately, no simple development choice is available for the vendors. They simply must support the systems management frameworks most often installed by their customers.
This is a big customer satisfier. Many people ask for easy ways to extend an IDS. Scanners are sometimes easier to augment because they can invoke custom user programs or scripts. Network sniffers and system-level IDSs have not been as lucky. Ongoing research is aimed at finding suitable languages for developing attack signatures.
A benefit of having multiple groups create attack signatures is openness. Any mistakes that an IDS vendor might have made will be quickly critiqued and corrected. Another advantage is the sheer number of signatures. Having more people work on the problems and post their results for others to use is a great way to get additional application-level attack patterns. Everyone is a winner when this is possible.
| Previous | Table of Contents | Next |