What is the broadest category of computer systems protected by the Computer Fraud and Abuse

System compromises can be very difficult to detect. Most often, the data custodian notices something unusual about the data. It could be missing, altered, or moved; the time stamps could be different; or something else is just not right. The more you know about the normal operation of your system, the better prepared you will be to detect abnormal system behavior. Malicious Code When malicious code is mentioned, you probably think of viruses. Although a virus is a com- mon type of malicious code, it is only one type of several. In Chapter 4, “Communications Security and Countermeasures,” we discussed different types of malicious code. Detection of this type of a malicious code incident comes from either an end user reporting behavior caused by the malicious code or an automated alert reporting that scanned code containing a malicious component has been found. The most effective way to protect your system from malicious code is to implement code scanners and keep the signature database up-to-date. In addition, your security policy should address the introduction of outside code. Be specific as to what code you will allow end users to install. Denial of Service The final type of incident is a denial of service DoS. This type of incident is often the easiest to detect. A user or automated tool reports that one or more services or the entire machine is unavailable. Although they’re simple to detect, avoidance is a far better course of action. It is theoretically possible to dynamically alter firewall rules to reject DoS network traffic, but in recent years the sophistication and complexity of DoS attacks make them extremely difficult to defend against. Because there are so many variations of the DoS attack, implementing this strat- egy is a nontrivial task. Response Teams Many organizations now have a dedicated team responsible for investigating any computer security incidents that take place. These teams are commonly known as Computer Incident Response Teams CIRTs or Computer Security Incident Response Teams CSIRTs. When an incident occurs, the response team has four primary responsibilities: Determine the amount and scope of damage caused by the incident Determine whether any confidential information was compromised during the incident Implement any necessary recovery procedures to restore security and recover from inci- dent-related damages Supervise the implementation of any additional security measures necessary to improve security and prevent recurrence of the incident As part of these duties, the team should facilitate a postmortem review of the incident within a week of the occurrence to ensure that key players in the incident share their knowledge and develop best practices to assist in future incident response efforts. The Gibson Research Denial-of-Service Attacks: Fun or Grudge? Steve Gibson is a well-known software developer and personality in the IT industry whose high visibility derives not only from highly regarded products associated with his company, Gibson Research, but also from his many years as a vocal and outspoken columnist for Computer World magazine. In recent years, he has become quite active in the field of computer security, and his site offers free vulnerability scanning services and a variety of patches and fixes for operating system vulnerabilities. He operates a website at http:grc.com that has been the subject of numerous well-documented denial of service attacks. It’s interesting to speculate whether such attacks are motivated by grudges that is, by those who seek to advance their reputations by breaking into an obvious and presumably well-defended point of attack or by fun that is, by those with excess time on their hands who might seek to prove themselves against a worthy adversary without necessarily expecting any gain other than notoriety from their actions. Gibson’s website has in fact been subject to two well-documented denial of service attacks that you can read about in detail on his site: “Distributed Reflection Denial of Service,” February 22, 2002, http:grc.comdosdrdos.htm “The Strange Tale of the Denial of Service Attacks Against GRC.COM,” last updated March 5, 2002, http:grc.comdosgrcdos.htm Although his subsequent anonymous discussions with one of the perpetrators involved seem to indicate that the motive for some of these attacks was fun rather than business damage or acting on a grudge, these reports are fascinating because of the excellent model they provide for incident handling and reporting. These documents contain a brief synopsis of the symptoms and chronology of the attacks that occurred, along with short- and long-term fixes and changes enacted to prevent recurrences. They also stress the critical importance of communication with service providers whose infra- structures may be involved in attacks as they’re underway. What’s extremely telling about Gib- son’s report on the denial of service attacks is that he experienced 17 hours of downtime because he was unable to establish contact with a knowledgeable, competent engineer at his service provider who could help define the right kinds of traffic filters to stymie the floods of traffic that characterize denial of service attacks. Gibson’s analysis also indicates his thoroughness in analyzing the sources of the distributed denial of service attacks and in documenting what he calls “an exact profile of the malicious traffic being generated during these attacks.” This information permitted his ISP to define a set of filters that blocked further such traffic from transiting the final T1 links from Gibson’s Internet service provider to his servers. As his experience proves so conclusively, recognizing, analyz- ing, and characterizing attacks is absolutely essential to defining filters or other countermea- sures that can block or defeat them.