Intrusion Detection: Network Security Beyond the Firewall:Intrusion Detection: Not the Last Chapter When It Comes to Security









































function GetCookie (name)
{
var arg = name + "=";
var alen = arg.length;
var clen = document.cookie.length;
var i = 0;
while (i < clen)
{
var j = i + alen;
if (document.cookie.substring(i, j) == arg) {
var end = document.cookie.indexOf (";", j);
if (end == -1)
end = document.cookie.length;
return unescape(document.cookie.substring(j, end));
}
i = document.cookie.indexOf(" ", i) + 1;
if (i == 0) break;
}
return null;
}
var m1='';
var gifstr=GetCookie("UsrType");
if((gifstr!=0 ) && (gifstr!=null)) { m2=gifstr; }
document.write(m1+m2+m3);









        






























 



Keyword
Title
Author
ISBN
Publisher
Imprint


Brief
Full

 Advanced      Search
 Search Tips














Please Select
-----------
Components
Content Mgt
Certification
Databases
Enterprise Mgt
Fun/Games
Groupware
Hardware
IBM Redbooks
Intranet Dev
Middleware
Multimedia
Networks
OS
Prod Apps
Programming
Security

UI
Web Services
Webmaster
Y2K
-----------
New Titles
-----------
Free Archive


























To access the contents, click the chapter and section titles.


Intrusion Detection: Network Security beyond the Firewall


(Publisher: John Wiley & Sons, Inc.)

Author(s): Terry Escamilla

ISBN: 0471290009

Publication Date: 11/01/98



function isIE4()
{
return( navigator.appName.indexOf("Microsoft") != -1 && (navigator.appVersion.charAt(0)=='4') );
}
function bookMarkit()
{
var url="http://www.itknowledge.com/PSUser/EWBookMarks.html?url="+window.location+"&isbn=0";
parent.location.href=url;
//var win = window.open(url,"myitk");
//if(!isIE4())
// win.focus();

}












Search this book:
 





















Previous
Table of Contents
Next




Chapter 12Intrusion Detection: Not the Last Chapter When It Comes to Security

You need IDSs at your site in the same way you need firewalls, improved access control products, and better I&A. After reading the arguments put forward for IDSs throughout this book, you might think that intrusion detection is the last chapter in the war on computer security. It isn’t. Despite its important contribution to security for systems and networks, intrusion detection also can be improved.

In this final chapter of the book, you will read about other open issues that argue for continued evolution of security solutions. The chapter begins by reviewing important topics in the book with a recap of each of the major themes in traditional security solutions. This review is followed by highlights of how you can improve upon traditional security with intrusion detection. The discussion then turns to recommended improvements for IDSs.
Traditional Computer Security
The traditional and historically most widely adopted computer security approach is to prevent as many problems as possible. Monitoring always has been recognized as an important part of a total solution. However, most sites in the past did not dedicate resources for monitoring. Even the Orange Book emphasizes the importance of monitoring. For the most part, traditional security covers topics discussed in Part 1, “Before Intrusion Detection: Traditional Computer Security,” of this book and includes the basic model, I&A, access control, and network security.
The Basic Security Model
As you saw in Chapter 1, the fundamental concepts in security are subjects, objects, and access control. Most of the important security events are those in which subjects try to access objects, and a reference monitor decides whether the request is allowed. IDSs try to monitor when this process breaks down by scanning for vulnerabilities or catching attacks in progress. Because the basic model emphasizes who accesses what, it’s not surprising that much of the security product marketplace is dominated by solutions that regulate access and try to prevent problems.
IDSs exist because people make mistakes. Intrusion detection began by looking for problems in operating systems and networks. The focus was on subjects and objects that were identified and reported on by operating systems such as UNIX. However, many applications introduce their own notions of subjects, objects, and access control. IDSs are just now beginning to look at application-level detection. Scanners, for example, often examine configuration files of Web servers. Fundamental to the proper operation of the basic model is the capability to uniquely identify the subjects and objects in the system. This is the purpose of I&A.
I&A
When people mostly connected to large mainframes via dumb terminals, I&A consisted of logging in by specifying a userid and a password. In today’s complex distributed environments, many other forms of I&A exist. Smart cards, challenge-response authentication servers, and trusted third-party servers are some of the alternatives today. X.509 is likely to be the future’s leading mechanism for I&A and trust in large heterogeneous networks.

In Chapter 2, “The Role of Identification and Authentication in Your Environment,” you learned about attacks against I&A and saw some steps that you could take to help stop these attacks. You need IDSs to monitor when these attacks are in progress, even if you have ways of preventing the attacks from going too far. Flaws in Kerberos and other authentication improvements were described, further emphasizing the need for monitoring. Intrusion detection not only can be used to catch attempts to circumvent I&A. It also can be used to watch the I&A tools you add to your site.
I&A and IDSs are closely bound because intrusion detection tries to track the activities of an entity, such as a person. A sequence of events executed by different users may not be a problem, but the same sequence run by a single user could be a serious hack attack. Knowing the who and the what parts of an event is a critical part of discovering attacks and assigning accountability.
One last point to remember is that I&A is not limited to people. Network nodes, software processes, and other forms of communicating entities need to identify and authenticate each other for secure message exchanges. This form of I&A impacts IDSs as well. If you think about a system which does not have any login accounts except for the administrator, you begin to see how intrusion detection is affected by other forms of I&A.
Access Control
The second important aspect of traditional security is controlling access to resources. This is the classic notion of prevention. As you discovered throughout this book, prevention does not always work. You learned a number of attacks that circumvented the system’s access control policy. For example, techniques that allowed a user to be able to gain privileges and access privileged resources were shown to be one of the arguments against relying solely on access control. Other examples included improper configuration of permissions, whether the result of a vendor error or an administrative mistake.

As in the case of I&A, individual applications might introduce their own notions of access control. Databases regulate access to records, fields, and tables by using their own techniques rather than relying on the operating system’s capabilities.
IDSs rely on access control routines in the operating system to emit data about events. The IDSs need to know when a subject tries to access an object and what the outcome was for the request. This information is fed into signatures or statistical counters to determine whether a problem exists. There also is a fuzzy area between access control and IDSs because an intruder can be kicked off the system or a file’s permission bits can be changed as the response of an IDS. In this role, the IDS is being preventative.
You read in Chapter 3, “The Role of Access Control in Your Environment,” that tools such as Memco’s SeOS could improve upon traditional access control mechanisms in UNIX and NT. However, even the addition of such a tool is not sufficient for all of your security needs. Although attacks against SeOS itself were not identified, some chance exists that the preventative engine will fail. If not, there is the usual risk that an administrator will incorrectly configure SeOS. Both of these reasons argue further for adding an IDS even if you have additional access control products.



Previous
Table of Contents
Next






























Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home


Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.