Technical Advances

‚  < ‚  Free Open Study ‚  > ‚  

As technology changes, the field of incident response will change accordingly . Some of the changes will ease the response team's job by automating or simplifying tasks ; others will make it more difficult by placing more sophisticated tools and techniques in the hands of offenders.Automated hacking tools, trojans, and worms are now readily available to attackers .Although most of these are easily detectable and relatively unsophisticated, they are far more widespread than in the past. Programming tools are also available to customize them to escape detection or to provide, for example, encrypted control traffic.

Intrusion Detection

The field of intrusion detection has changed dramatically. Although raw packet logging tools are still available, the sheer volume of traffic makes them difficult to use in most environments. Increasingly, companies are turning to specialized tools that can detect common attacks, log the traffic, and alert the administrator.

Most IDSs currently are signature based. Like antivirus tools, the IDS has a database of common attack patterns. When the software detects a similar pattern, it issues an alert. The disadvantages of this are obvious. First, like antivirus software, it can only detect attacks that are already known. The system must be constantly updated to keep the signature database current. Second, some attacks are indistinguishable from normal traffic. Port scans , for example, can be set up to scan a range of ports randomly and at a very slow rate. If the scan comes below a certain rate, the IDS might not recognize it as a scan.

There is significant research on new methods of intrusion detection based not on signature but on anomalies. These tools detect network traffic that is different from normal patterns. The difficulty with this is defining normal and abnormal traffic. Although this research is promising , anomaly-detection software still is subject to the major disadvantages of signature tools. Both are difficult to configure to avoid either missing attacks or flooding the administrator with false alarms. IDSs, however, are valuable to detect simple attacks by the so-called "script kiddies." As such, they can free up the security staff to concentrate on more significant attacks.

Intrusion detection either can be based on the network, where it listens to network traffic and attempts to detect an attack, or can be installed directly on a critical host. On the host server, it looks for changes to critical files. Arguably, antivirus software is a form of host-based intrusion detection. Microsoft is also now including a feature that tracks changes to library files (dynamic linked libraries, or DLLs) and that can allow the user to revert to a previous version of the file if an application (or attacker) modifies a file. No security is built into this feature; it is primarily to allow users to recover from changes made by installing new applications. A similar feature with appropriate access controls could be the basis for an improved host-based intrusion-detection system.

There are a number of significant limitations to IDS, including both false positives and negatives . A signature-based system can be set to detect certain forms of attack. However, it might not be able to distinguish between a password-guessing attack on a server and a user who has simply forgotten his or her password. Similarly, some denial-of-service attacks can consist of legitimate requests for service but in such large numbers that the server cannot process the requests. The IDS should be able to distinguish between large traffic and actual attacks. One actual example of false alarms is provided in the following sidebar.

False Alarms from Intrusion Detection

A client contacted us about an attempted intrusion. The client had installed IDS software among its critical servers and was detecting what appeared to be attempts to log on to a Windows NT domain. The logon attempts appeared to be coming from within the network but from a remote (international) site. No one from that site had permission to access the domain.

A review of the logs revealed that the logon attempts were actually an attempt to access network resources within the domain. However, the resources did not appear to be available (and, according to the client, did not exist). Further investigation tracked the logon attempts back to a number of workstations. The attempts, however, were occurring at a time when no one was physically at the workstation.

Further analysis revealed that the workstations were attempting to access an antivirus software update server. The client then stated that the same contractor had configured all the workstations. Contact with the contractor confirmed that it had installed antivirus software and automatically updated it prior to shipping the computers. By coincidence , the antivirus server had the same Windows domain name as a critical server at the client site. The contractor had failed to disable automatic updates, so the workstations were periodically polling the client network and attempting to access the antivirus update on this critical server.

There is a specific class of attacks known as stealth scans. In these attacks, the traffic is specifically designed to come at an extremely slow rate. The IDS will not be able to differentiate between the scan traffic and other legitimate traffic occurring simultaneously .

There also might be problems with IDS on switched networks. On standard Ethernet networks, all nodes can monitor all traffic. Deploying an IDS is simply a matter of placing a monitoring station on an unused node. In switched networks, however, traffic might be passed directly from one node, through the switch, to the destination. The IDS station would not be able to monitor the traffic. Most switches have provisions for a port on the switch to monitor traffic, but this might impact the performance of the switch or the IDS engine.

There might also be problems monitoring traffic that is encrypted. Although at some point, the packet headers must be in plain text, this will only serve to catch some attacks. For example, an attack against a web server application might consist of a series of commands for the web server to execute. The commands will be contained in the data section of the packet. If the packets are encrypted when they pass by the IDS monitor, it will be unable to detect the attack.

Finally, capturing traffic is a relatively straightforward practice. Deploying the IDS engine can be fairly simple, and even applying the rule sets might not be especially difficult. However, if the volume of traffic is large, analyzing the output and actually understanding what is occurring on the network is far from a simple task. The specifics of traffic analysis are clearly outside the scope of this book, but interested readers should consult other texts such as those by Marcus Ranum (for example, Web Security Sourcebook , John Wiley & Sons) or Stephen Northcutt ( Network Intrusion Detection ).

Automated Response

There is considerable interest in automating some portion of the response process. For example, the IDS system can isolate attackers into a controlled environment where they can do no harm and can be observed . The attacks can be automatically blocked. However, there is a desire in the discipline to make the process even more automatic.

An automated system can choose from many possible responses:

  • It can shut down the system under attack.

  • It can place the attacker into a "virtual jail" where additional information can be gathered.

  • It can send a message back to the attacker or to his or her ISP.

  • It can shut down the connection and block all further connections from that address for a period of time.

  • It can require additional authentication to allow the session to continue.

  • It can attempt some sort of traceback.

  • It can attempt some sort of counterattack.

Periodically, stories appear in the popular press alleging that corporations are using automated tools to counterattack intruders. For example, one such story read,"In the U.S., firms are increasingly using hacking tools to attack the systems of hackers. Thirty-two percent of Fortune 500 companies have installed counteroffensive software, according to a survey by security consultancy WarRoom Research. Tactics include launching trojan horse attacks to damage and disable a hacker's computer, and automated scripts that can erase an attacker's hard drive or hijack email." [1]

[1] Madeline Bennett, High-Tech Vigilantes Face Legal Threat , www.zdnet.com/zdnn/stories/news/0,4586,2716730,00.html.

It is unlikely , however, that this is actually occurring. Although there have been such reports , none of them have been substantiated. The authors also have no knowledge of any such systems in use by any private corporation, government, or military organization. WarRoom Research stated that this report had its roots in testimony to the U.S. Congress several years ago and is frequently taken out of context.

This is not to say, however, that there is no place for automated tools. Some intrusion-detection software, for example, will automatically block any traffic from an IP address if it detects an attack. Personal IDS is becoming more common as home users are increasingly using high-speed, always-on connections. One example is Black Ice Defender. This tool can be configured to automatically do a DNS lookup on incoming packets. It supports logging of attacks and can automatically block suspicious addresses for 24 hours.The user can then choose to manually block an address indefinitely. Some corporations have developed tools that will extract the data from IDS logs and automatically produce a letter or email to the ISP.

An organization must be extremely careful, however, when deploying any kind of automated system. An increased reliance on automation can lead to increased predictability. This, in turn , might allow the system to be defeated or bypassed more easily. The system itself might be subject to attack, or an attacker could actually use the automated response to create problems for a third party by simulating attacks from that party's network.

That being said, some form of automated response, despite its inherent limitations, is one of the few long- term approaches to incident response that truly offers a unique solution to the problem of managing large numbers of attacks.

Experimental Tracing Methods

Chapter 6,"Tracing Network Attacks," discussed methods of tracing network attacks. Any number of problems and challenges can make this a difficult problem. The intruder can " leapfrog " through multiple hosts in multiple jurisdictions. Tracing such an attack requires cooperation from each organization along the way. Some attacks (including most denial-of-service attacks) support "spoofed" addresses, so the investigator must track a packet from hop-to-hop . To counter some of these issues, there is ongoing research regarding new methods of tracing attacks. None of these is near deployment, and some might require changes in the TCP/IP protocol, so a solution to this problem will not be immediately available. A complete discussion of this research is outside the scope of this book (and would probably be obsolete almost immediately), but some of these methods are described in the following sections.

DOS Tracker

Internet MCI developed this tool. It runs on the routers within a company and automatically traces packets back to their original source (ignoring spoofed addresses). The tool is primarily designed for ISPs because it must be installed on each router.

An early version of this tool was used in 1996 to trace a SYN flood attack against a California company back through a Canadian educational institution and finally to a California university. Although the specific attacker was not found, discovery of the route allowed ISPs to block the flood. The program is available for free download at ftp.mci.net/outgoing/dostrack742812.tar.

Intrusion Detection and Isolation Protocol (IDIP)

The Defense Advanced Research Projects Agency (DARPA) is funding research to combine IDSs with firewalls and routers to develop an automated defense system that can be deployed on an intranet. The components will communicate in real time to detect and respond to attacks. The current project is a cooperative effort between Trusted Information Systems, Boeing, and UC Davis.

IDIP is the common protocol used within this network to communicate between components. This protocol keeps track of packets at each router interface and can track a stream of traffic back to the source. Once more, the limitation is obvious; the protocol only is useful if it is deployed on the router.

Forensics Tools

The field of computer forensics has changed dramatically from its first roots. Investigators are using automated tools to capture and analyze the data. Because mass storage has become extremely cheap, it is no longer feasible to conduct a complete sector-by-sector examination of very large mass-storage devices. It is not unusual for investigations to involve media of over a terabyte. Only automation can reduce this to workable proportions .

It is likely that these tools will continue to evolve . Only time will tell whether a fully automated tool will produce acceptable evidence, but the tools are sure to be challenged in future cases. The probable outcome is that a standard set of tools will emerge, and forensics recovery using these tools will become as acceptable as fingerprinting.

Law enforcement agencies have begun the development of tools to detect pornographic images on large media. These tools are limited in that, at the present time, they can only search for known images. However, promising technologies involving image recognition could make it possible to, for example, identify all images on a drive that have certain characteristics or that contain a given person's face. These tools can also search images or streaming media for corporate logos or proprietary trademarks.

Encryption

In recent years, the U.S. government has moderated its views on the export of strong encryption. At the same time, however, other agencies have warned that the spread of strong encryption technologies could make it more difficult to investigate and prosecute crime. Other governments regulate the use of cryptography, limiting it to certain industries, insisting on a key escrow scheme, or even prohibiting its use entirely. It is unlikely, however, that such regulations will keep strong encryption out of the hands of determined criminals.

As encryption becomes more available, it will be used more often by people involved in computer security incidents. One example of this is the use of encrypted control traffic in denial-of-service attacks. These attacks are covered in more detail later in this chapter. Some of the distributed denial-of-service (DDOS) tools available allow the controller to use encryption to control "zombie" computers. Back Orifice 2000 also uses encrypted control traffic in an effort to evade intrusion-detection software.

Although much has been made recently of advances in breaking encryption algorithms, there is no sign that encryption is becoming more vulnerable. 56-bit DES can be brute-forced using dedicated processors in a reasonable amount of time (depending on the processor, a matter of days or less), but stronger algorithms are readily available. Even using Triple-DES changes the key length from 56 to 112 bits, dramatically increasing the effort required to brute force. At the present time, it is not feasible to brute force attack Triple-DES, and other algorithms are even more robust.

It is likely that encryption will be more widely used in the future. It is equally unlikely that advances in cryptographic techniques will make it easier to break strong encryption. Investigators, therefore, will have to contend with this issue. As discussed in previous chapters, one extremely effective way to deal with this problem is to utilize well-written policies that address the use of both authorized and unauthorized encryption on company computers. Even if the contents of the file cannot be read, the simple fact that encryption was used might be sufficient for the purposes of the investigation.

‚  < ‚  Free Open Study ‚  > ‚  


Incident Response. A Strategic Guide to Handling System and Network Security Breaches
Incident Response: A Strategic Guide to Handling System and Network Security Breaches
ISBN: 1578702569
EAN: 2147483647
Year: 2002
Pages: 103

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net