Critical Incident Detection: How to Know What Is Serious and What Is Not

---

The first step in dealing with critical incidents rests with becoming aware that an adverse event has happened. The detection of critical events happens through a variety of avenues:

• Suspected critical incidents may be detected by a review of firewall logs.

• Suspected critical incidents may be detected as suspicious user activity.

• Suspected critical incidents may be detected by intrusion detection systems.

• Suspected critical incidents may be detected by systems administrators.

• Suspected critical incidents may be detected by systems auditors.

• Suspected critical incidents may be reported from contacts outside the organization.

• Suspicious events reported by users.

• Suspicious events reported by help desk operators.

In the course of detecting critical incidents, it is important to have the function point, where these activities can reported. Employees should be regularly familiarized with the procedure directing them to the location where they report suspicious activities. Function-points can be employees or a business unit where potential incidents may be reported 24/7. It is their responsibility to accept the report, elicit as much relevant information as possible, record the details, triage the event, and decide to activate the response plan or not. Using an incident reporting checklist ensures all the pertinent information is recorded so an appropriate determination might be made. When eliciting information, get the facts first, then the complainant's speculation and "good-guesses."

Here are some of the key areas for an incident report checklist:

• Current time and date

• Person accepting information

• Person reporting information

• Nature of the critical incident

• When, how, why, where, and who of the critical incident

• Systems involved (software, hardware, employees, etc.)

• Key contact information for reporting employee, including reporting chain

• Describe any need for out-of-band communications

• Describe estimated priority of critical incident

• Recommendations from the reporting party

If you do not know that an incident has taken place, it is difficult if not summarily impossible to determine if your systems have been compromised. The function-point should get as many of the facts as are available at that time. If information is not collected in a timely fashion, it cannot be determined which sensitive data, systems, or networks have been attacked and the extent of damage that has been done to your operation's confidentiality, integrity, and availability. Detecting critical incidents in a timely fashion is imperative. If you can compare the current systems state with the last time you knew the system was uncorrupted; responders should know what is needed to restore operations.

Critical Incident Symptoms

There are some suspicious activities that might escape the notice of Intrusion Detection Systems, firewalls, and less-than-vigilant systems monitoring. Their discovery sometimes depends on attentive administrators, help desk employees, auditors, and log-entry analyses. Here are a few examples:

• Unusual login accounts. These include failed login attempts - attempts to enter dormant or default accounts. In this category is included the new or unusual account not created by administrators. Often this rogue account is a mysterious root account or a privileged user account.

• Unusual account activity during irregular work hours. It seems that attackers often attempt to gain access during hours when administrators are assumed to be least likely to notice their activities. Attackers assume the system may be unattended or poorly staffed at these times.

• Unfamiliar files or applications. Usually these types of programs are "backdoor" programs facilitating the unauthorized access of an attacker. They often take the form of something innocuous such as /etc/inetd.d/ or ".." (this is read as space-dot-dot).

• Unauthorized changes or escalation of file and directory privileges.

• Use of commands not normally related to an employee's job. This is an event that is often revealed when reviewing log entries. Log entries reveal that a user (not an administrator) is executing commands such as extracting downloaded programs using the tar command and subsequently compiling code.

• Presence of unauthorized utilities. Finding password cracking utilities and other tools used by attackers in the system indicate a potential problem.

• Erasures or gaps in log entries. This is another one of those activities that quickly indicates there is trouble afoot. If there are gaps or erasures in logs, it is likely someone has attempted to cover his tracks.

Response Strategy

The objective of creating a response strategy is to determine the most appropriate method responding to the critical incident. Of course, before heading off into the sunrise with technical guns blazing, there are at least three immediate considerations that must be made:

1. Technical factors

2. Business factors

3. Legal requirements

In formulating your response strategy, much depends on the character of the emergency. You do not want to treat arterial bleeding with a gauze and tape when you should be calling a surgeon. Here are some dependent factors that will significantly impact your decision process:

• Are the affected systems impacting profitable operations?

• If information was stolen, what was its level of sensitivity or classification?

• Which business functions are being impacted and at what level?

• Has the incident been contained or is it continuing?

• What is the origin of the emergency? Is it internal or external to the organization?

• Is the critical incident public knowledge?

• What are the legal reporting requirements? Does the law require this matter to be reported immediately to authorities? Who are those authorities? Should this matter be handled as a human resources matter? Should this matter be handled as a civil suit?

• What, if any, steps should be immediately taken to discover the identity of an outside-agency attacker?

• What is the fault tolerance level of the affected systems?

• As of this moment with the incident contained, what are the financial losses?

Critical incidents will vary greatly from being infected with the latest virus to the loss of extremely sensitive information. Depending on the size of the affected company, the theft of sensitive information as credit card information could result in financial ruin. Even in a larger business, a successful class-action suit resulting from negligently failing to safeguard personally identifiable information can result in significant monetary losses and incalculable damage to business reputation.

Information collected during the initial emergency assessment phase will significantly impact the manner in which a response strategy is formulated. Contained within the response strategy are estimates of your organization's ability to respond to the critical incident, public perceptions, legal and regulatory requirements, as well as an impact assessment on critical assets.

Experience Note 

Remember "haste makes waste." Responders should act deliberately but not dawdle.

Actions taken in response to critical incidents must be made with some degree of alacrity, but attempting to address matters without a firm set of facts is not likely to be productive.

IP Addressing in Brief

By way of review, Internet Protocol, IP, addresses are those numbers assigned to network devices that serve as their identification. It is a decimal notation that divides a 32-bit address into four 8-bit fields. An IP address consists of the following components: Network ID and Host ID. For example, in the IP address 204.9.205.21, the network ID is 204.9.205 and the host ID is 21.

For practical purposes, Internet IP addresses are divided by classes A, B, and C. Network classes are only applicable in Internet environments as closed networks may assign addresses in any form their naming convention policies allow.

• Class A networks begin at address 1.xxx.xxx.xxx through 126.xxx.xxx.xxx

• Class B networks begin at address 128.xxx.xxx.xxx through 191.xxx.xxx.xxx

• Class C networks begin at address 192.xxx.xxx.xxx though 223.255.255.xxx

• Class D networks begin at address 224.0.0.0 through 239.225.225.225

• Class E networks begin at address 240.0.0.0 through 247.225.225.225

Class D networks are reserved for multicasting and Class E networks are reserved as experimental.

There are other reserved IP addresses for example. IP address 225.2.100.1 is a multicast address to be received by a group of hosts on the network. Multicasting is the transmission of information to specific hosts.

Broadcasting is the transmission of information to be received by all hosts on a network. For example, the IP addresses 255.255.255.255, 192.9.205.255, 180.10.255.255, and 10.255.255.255 are broadcast IP addresses.

A unicast IP address uniquely identifies a specific host on a network. The datagram with a unicast IP address is received and processed by one single host. For example, the IP address 204.10.95.214 is a unicast IP address.

IP Addresses

Exhibit 1 should help put things in perspective. Class is for the most part an outdated concept but still used to explain and understand the basic structure of the Internet. The Internet authorities have ceased allocating IP addresses according to class, and all routing through the Internet has implemented Classless Inter-Domain Routing (CIDR). Currently, the preferred means for expressing the size of a network is to use the number of bits in the subnet mask.

Exhibit 1: IP Address Blocks

IP Address	Description
127.xxx.xxx.xxx	Local loopback address. The value of the last 3 bytes is ignored. The datagram with this IP address is never transmitted over the network.
0.0.0.0	Local host
xxx.0.0.0	Local host IP address. The x represents the network ID bits.
xxx.xxx.0.0
xxx.xxx.xxx.0
0.xxx.xxx.	IP address of a host in the local network. The x represents the host ID bits.
0.0.xxx.xxx
0.0.0.xxx
255.255.255.255	Limited broadcast address. Datagram with this address will be received and processed by all the hosts in the local network. This datagram is not forwarded to other networks by routers.
xxx.255.255.255	Directed broadcast address. The datagram with this IP address is received by all the hosts in the specified network. The x represents the network ID bits.
xxx.xxx.255.255
xxx.xxx.xxx.255

CIDR divides IP addresses into host and network portions. Instead of being limited to network identifiers of 8, 16, or 24 bits, CIDR uses prefixes from 13 to 27 bits. In this fashion, blocks of address can be assigned to networks as small as 32 hosts or those with over 500,000 hosts. This allows for address assignments tailored to an organization's specific needs. CIDR addresses include the standard 32-bit IP address and information on how many bits are used for the network prefix. For example, in the CIDR address of 102.13.0.48/8, the "8" indicates the first eight bits are used to identify the unique network leaving the remaining bits to identify the specific host (Exhibit 2).

Exhibit 2: CIDR Addressing Blocks

CIDR Block Prefix	Equivalent Class C (#)	# of Host Addresses
/27	1/8th	32
/26	1/4th	64
/25	1/2	128
/24	1	256
/23	2	512
/22	4	1,024
/21	8	2,048
/20	16	4,096
/19	32	8,192
/18	64	16,384
/17	128	32,768
/16	256	65,536
/15	512	131,072
/14	1,024	262,144
/13	2,048	524,288

Reviewing DNS

Domain name services are structured in a hierarchy with the highest level being the last component of the DNS address. DNS names can be up to 255 characters long and are not case-sensitive. They must start with a letter and may only consist of letters, digits, and hyphens. DNS was originally introduced in the United States and the final component of an address was intended to indicate the type of organization hosting the domain. Some of the three letter final labels such as .edu, .gov, .mil, and .biz are in common usage today. When resolved, these DNS names will indicate the IP address of the host. The purpose of DNS is to register meaningful names with numeric IP addresses, while the process of reducing a DNS name to its IP registration is called "resolution."

In some cases, there are two letter codes indicating the country of origin as part of the domain name as defined in ISO 3166, available at www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/en_listp1.html.

If a DNS name cannot be resolved locally, the DNS server will communicate with other DNS servers reaching higher-level servers attempting to resolve the name. If it is unsuccessful, it will attempt to contact the ultimate authority or root server for the domain, e.g., .gov, .org, etc. This process is called the recursive resolution of addresses.

Resources

Binary mathematics, IP address architecture, CIDR, DNS, TCP/IP, and network subnetting are topics that could fill volumes and are outside the scope of this book, but here are a few resources that will provide valuable information in these areas:

• A review of IP networks and subnetting is available at www.learntcpip.com

• A review of DNS, domain name service, is available at www.ietf.org/rfc/rfc1034.txt?number=1034

• A review of CIDR is available at www.ietf.org/rfc/rfc1517.txt?number=1517

• A review of IP address formatting is available at www.ietf.org/rfc/rfc1166.txt?number=1166

• A review of TCP/IP protocols is available at www.ietf.org/rfc/rfc1180.txt?number=1180

Locating the Origin of Denial-of-Service Attacks

Denail-of-service attacks, DoS, are extremely difficult to trace to a source IP address. For argument sake, DoS attacks include Distributed denial-of-service, DDoS attacks with the distinction being the DoS emanates from a single IP address where the DDoS attack emanates from multiple, even hundreds of IP addresses. Typically, DoS attacks originate from spoofed or compromised accounts making it virtually impossible to trace them to a single source machine.

Investigators have the option of contacting the system administrators of compromised systems and hope they have adequate logging to take the next step backward in the direction of the perpetrator, but eventually it seems there is a system in the tracing chain that does not have enough information to complete the trace. The path toward the attacker will end there.

Experience Note 

Because law enforcement authorities generally have very limited abilities outside their jurisdiction, it may be very helpful for the affected system administrators to contact the system administrators of the previous systems in the chain. Often law enforcement authorities may accept information collected pursuant to the business activities of administrators but may not direct administrators to contact their counterparts, as this would possibly taint the evidence as the officers could only collect the information through a warrant or international treaties.

UNIX Logging

UNIX is a platform that offers much in the way of logging features. Here, as in many systems, it is wise to alter the default-logging configuration.

Experience Note 

Of all the preparatory steps that responders can take before a critical incident, adequate logging is probably the most useful. Logging permits the reconstruction of events and is one of those "save your bacon" policies.

The principle file for logging is UNIX syslog. This file stores logging information in one, or more, configurable locations. Logging is configurable through the syslogd file located at /etc/syslog.conf. Within this file, there are two significant configurations, action and selector. Action controls the location that the logging message is stored, while the selector controls the message's priority and facility. Essentially, this means the selector field controls where the logging message is generated, and the severity of the message.

Logging all security-related events is accomplished in this example:

     var/log/syslog 

Because attackers will attempt to delete or alter system logging, it is strongly recommended that all messages are logged and stored, remotely avoiding the possibility that an attacker could gain root privileges to the same system where the messages are generated and stored. Configuring systems to log their messages to a remote logging server is accomplished by this example:

  auth.* @xxx.xxx.xxx.xxx 

Of course, the xxx.xxx.xxx.xxx is the IP address of the remote logging server.

UNIX is capable of logging the commands that each user executes. This log file is found, depending on the variety of UNIX used, in the/var/adm; /var/log; or/var/adm files. Enabling this level of logging is one that will significantly help emergency responders in their efforts to reconstruct the damaging events on the system.

Experience Note 

There is a major consideration for UNIX process tracking in that it will generate large logging files as essentially every action taken by a user is generating an entry. There must be a compromise reached where meaningful logging is created in the event of an emergency, yet there must be some controls placed on the amount of logging as it will soon consume all available storage.

Windows Logging

Enabling Windows NT server logging, in Microsoft's terms, is called "auditing," and must be manually done by the administrator as it is not done by default at installation. It is accomplished by following this path: Start | Programs | Administrative Tools | User Manager | Audit Policy. The following events are the minimum level of logging:

• User logon and logoff

• Security policy changes

• Shutdown and restart

Windows allows the auditing of file and directory permission changes. In order to accomplish this task, merely right-click on the target file or directory and choose Properties from the displayed menu. In this dialog box, choose the Security selection tab and choose Auditing. From this Directory Auditing dialogue box, you can choose the auditing of events surrounding the selected file or directory such as the success or failure of attempts to change privileges.

Remote logging in Windows is accomplished with third-party software: Kiwi Syslog Daemon, available at www.kiwisyslog.com/products.htm.

Application Logging

There are many applications that allow logging of significant events. Each has its own configuration requirements. However, these are several minimum steps that should be considered when implementing application logging:

• Log messages to a directory or file secured so that only authorized employees can access it.

• If possible, log messages to a secure, remote server.

• Record logs on WORM, Write Once Read Many, media.

• Log as much information as will be necessary to reconstruct system events.

• Ensure that all logging includes the relevant IP addresses of inside and outside the organization.

In the case of Microsoft's Internet Information Server (IIS), there are several layers of meaningful auditing. By accessing the Management Console, administrators may view and change the auditing capabilities. At the time of installation, IIS has logging enabled by default but by viewing the Extended Logging Properties dialogue box, you can see the type of logging available: Date, Time, Client IP Address, User Name, Server IP, Cookie, Server Port, and Bytes Sent, to name a few.

Hardening Servers

In a perfect world, all system components would be impregnable and all applications would not need to be protected from attackers by hiding them behind firewalls. Regrettably, most of us do not live in that world, so a system must be fortified against attacks. By taking a few preincident precautions, you can save yourself a lot of time and resources when the emergency occurs.

Here are a few proactive suggestions:

• Ensure all versions of operating systems, applications, and hardware are the most current available.

• Ensure that all software updates have been installed for all operating systems and applications. Changes must be approved and documented.

• Ensure that all services, not absolutely essential for the server's function are disabled or removed.

• Ensure that all unnecessary hardware is removed or disabled.

• Ensure there is a standard installation procedure for all hardware and software.

• Never accept default software configurations for production environments. Always review configurations and thoroughly test systems before placing them in production.

  Experience Note 

  Attackers are depending on default configurations for their success. Many attacks can be thwarted by correctly configuring software.

• Backup regularly and include critical data, applications, and configurations.

• Ensure all changes are documented, recorded, and approved before implementation.

Backup Frequently

Procedures must demand that regular and frequent backups take place. Backing up data and system configurations will help you discover attacker-related changes and expedite restoration. Backups are only as good as the originals. Test backup copies by attempting to restore operations by using backed-up copies. Many businesses have copies and when critical incidents occur, they discover their backups are insufficient. If the only available backup copies were made after the system was compromised, they are not going to be much help. However, if good backups were made before the incident, they will be invaluable in determining the changes made to the system by the attacker.

User Security Training

Users, whether employees or not, are the most significant threat to system security. Even the most seasoned systems managers are surprised which system flaws can be exploited either intentionally or by accident. It is for this reason that user education is essential in maintaining system security. Users should know what types of emergency actions are acceptable and those that are not. Employees must be trained to know the basic steps regarding critical incident response.

Bare-essential employee training for critical incidents should include the following:

• In normal business operations, they must recognize those events that are indicative of emergencies.

• In the event of a critical incident, they must know and follow applicable policies and procedures.

• They must know that nothing is more important than lives. Data and physical facilities can be replaced.

• Ensure employees do not take any corrective or restorative steps unless advised by senior managers and CIRT members.

• Ensure employees do not take any investigative steps, unless directed by the CIRT.

System Security Architecture

Arguably, there are numerous steps that can be taken ensuring the security of a system. The most secure system denies all access and privilege but is absurd and unworkable. So a compromise is needed, and one that is basically transparent to the users.

Experience Note 

The best system security is transparent to the users.

Network administrators are those who are charged with the responsibility of the system topology, architecture, and secure operation of the network. Administrators are tasked with the day-to-day enforcement of the organization's policies, practices, and standards. Emergency responders are usually dependent on administrators recognizing potential emergencies, standardized configurations, and documentation for their effectiveness. For example, administrators are responsible for the creation and enforcement of policy for packet screens. If they do not have standardized configurations and documentation of access control lists; responders effectiveness will be severely hampered addressing a firewall breach.

Generally, network security is dependent on the following:

• Firewalls consisting of packet screens, inspections, and proxies

• Intrusion detection

• User authentication

• User privileges

• Activity log reviews

• System monitoring

• System audits

• Encryption

Time Stamps

Administrators should make certain that all logs and indeed, all applicable functions are timestamped recording the same time and synchronized for all machines across the network. Using the Network Time Protocol is an efficient way of achieving system-wide temporal parity. Having the same time synchronized with all devices will greatly aid a responder when she is attempting to reconstruct events from log files.

System Monitoring Structure

This seems to be a recurring theme, many businesses have no idea what they have and where it is located. Although having a current hardware and software installation standard particular to each item seems to be obvious. Each time a piece of hardware or software is installed, the authorized person should have a standard installation procedure checklist created specifically for that item governing installation and configuration. From a responder's perspective, fewer things are more frustrating than learning that servers, having the same hardware, software, and function, are configured differently.

Here are some items to have ready when the responder makes contact:

• Ensure all relevant documentation is current and available.

  • Software manuals corresponding to the installed versions

  • Hardware manuals

  • Documentation for software configuration procedures

  • Cabling diagrams

  • Schematics and relevant diagrams

  • Organizational chart, job descriptions, and reporting authority

• Ensure all relevant logs are securely stored and part of the backup procedures.

• Have a current inventory of the locations of hardware and software. The inventory should include items such as:

  • Manufacturer

  • Date of acquisition

  • Serial numbers

  • How the hardware is being used

  • Peripheral equipment attached

  • Names and versions of installed software accompanied by authenticity codes

  • Owner

  • Users

  • Physical location

  • Configuration of hardware

  • Configuration of software

  • Updates installed

• Network topology map. Having a current and accurate topology map is extremely helpful during a critical incident. Under the best of circumstances, the topology map includes relative details as connected hosts, relevant applications, switches, hubs, routers, firewalls, NICs, terminal equipment, location of network storage devices, location and types of cabling or wireless linkage, and open-ended network connections. In order to give responders an accurate picture of the system, this map should also include the physical location and connectivity (including IP addresses and device names) of each device. Many employees will object to performing and updating this document, but it is absolutely necessary in preparing for emergency responses.

Business Issues

In business priorities, often we consider business decisions before any others. For example, when an employee is discovered stealing proprietary information and transmitting it to competitors, the organization goes into self-preservation mode minimizing its risks and preserving its critical assets. Seldom is the offender criminally prosecuted or civilly sued. As a matter of routine course, the offending employee is suspended pending the outcome of an investigation, and, if it is discovered the employee was violating policies, she is dismissed without any future legal action.

The damage an offending employee has done usually spans tangible and the intangible critical assets. Tangible losses are sustained in that valuable information was stolen and passed to competitors. In the avenue of intangible damage, she caused incalculable harm to the business reputation of the company. It is possible the financial losses suffered by the loss of credibility will exceed those from the stolen property.

This is a quandary - should managers legally pursue an offender and risk public scrutiny by airing their seemingly dirty laundry or should they dispose of the matter privately and risk becoming a target for attackers knowing they will not receive serious punishment? Organizations should consider if they fail to legally pursue attackers and criminals with full vigor, they accept current circumstances and fail to deter future attackers. In many cases, the decision is simple to make as laws mandate that suspicious or criminal activities must be reported to law enforcement authorities.

Legal Issues

Adverse legal actions can drive an otherwise well-run business into oblivion. Responders should consult with legal counsel whenever administrative, criminal, or civil proceedings might be the result of employee behavior or an outside originating attack. Considering laws and business positions, it is possible that legal counsel will advise against a particular course of action and suggest alternatives.

Political Issues

Shades of company politics can substantially color the fashion in which an organization handles its crises. Suppose for a moment that it is the atmosphere within an organization to accept all employees at their word, trusting them, it is likely they are provided substantial freedom in their work. In this atmosphere, identifying and handling critical incidents caused by employees would be a matter of little significance. In such environments, few company resources, if any, would be dedicated to addressing critical incidents. However, if the organization has a more realistic culture where it vigorously safeguards critical assets, it will allocate the necessary resources to monitor compliance with its policies and procedures.

Experience Note 

Performing an audit on the organization's Chief Legal Officer's workstation, the auditor discovered pornography. After a careful review, it was determined some of this material was in violation of federal laws as well the company's policies. The auditor advised her supervisor and jointly they briefed the Chief Executive Officer presenting examples of the images. It was well known that the CEO and CLO were close friends. Subsequently, the CLO was dismissed and criminally prosecuted.

Critical Incident Response Tools

Assembling a response toolkit composed of carefully selected and constantly updated hardware and software is an important aspect of critical incident response preparation. Preferred platforms include robust hardware with a full complement of software suitable to address the onsite requirements of the organization's systems.

Suggested hardware tools:

• External hard drives of large capacity

• Network interface cards compatible with LANs in the organization

• CD-RW drive

• Wireless NICs for 802.11a,b and g.

• Floppy drive

• SCSI card and controller

• SCSI hard drive with large capacity

• Surge suppressor power strips

• SCSI cables and terminators

• Several lengths of CAT 5 cables

• Several lengths of telephone cables with RJ-11 connectors

• Ribbon cables with more than three plug connectors

• Coaxial cable and connectors

• CD-Rs (at least 200 or more)

• Labels sufficient for all CD-Rs

• Laptop to EIDE adapter connector for connecting laptop hard drives to the forensic desktop

• Zip and Jazz drives

• Camera and film or removable memory card

• Portable printer and paper

• Sketch pad

• Labeling markers

• Toolkit containing tools to tag and mark hardware fasteners

• Bags into which evidence may be tagged and stored

• Labels and tags for marking evidence

Suggested software tools:

• Disk-write blocking utilities

• Boot disks for DOS and UNIX

• Unerase utilities for DOS, NT, and UNIX

• Unformat utilities

• Bootable CDs for DOS and UNIX

• Disk Editor

• Internet browser

• E-mail clients such as Eudora, Pegasus, or Outlook

• Resident operating systems on the forensic computer, including Windows 98, DOS 6.22, Windows NT, XP, Linux, or UNIX (Some investigators use DOS 6.22 or 7.0 to examine files.)

• Safeback, EnCase, Ghost, or other forensic software used to create bit-by-bit exact images of the target's media

• Word processor and label maker for evidence inventory and tags

• Spreadsheet or database applications for evidence inventories

• Drivers for the hardware in the forensic computer

• Viewers like Quickview Plus or other software allowing the viewing of a wide variety of files

• ThumbsPlus Image finder and publisher

• File organizer like 'Wilbur' (Wilbur is available at redtree.com) suitable to organize the files present on the target media

Critical Incident Response Personnel

The time to formulate a critical incident response team is not the morning after an incident occurs. That's a matter of too little too late. Responding to emergencies requires specially trained and experienced employees.

Experience Note 

One of the most serious transgressions committed by inexperienced responders is attempting techniques outside their area of training and expertise. During a crisis is not the time to experiment or try new techniques. They attempt to perform processes and analyses in which they have little training or experience during a crisis. Such behavior destroys evidence or causes recovered evidence to be useless in legal actions.

Here are desirable characteristics of response-team members:

• Attention to detail

• Knowledgeable in several programming languages, e.g., C, Perl, Assembly, HTML, XML, PHP, COBOL, Java, and JavaScript

• Thorough knowledge of the organization's systems

• Not rushing important tasks

• Attention to detail

• People skills

• Knowing their limitations

• Well-developed communication skills

• Not easily intimidated

Mission Statement

The mission statement of the responders should include at least the following elements:

• Respond to all critical incidents through an organized and deliberate process

• Investigations will be complete and free from bias and prejudice

• Through well-established policies, procedures will seek to immediately assess the scope of damage and take appropriate steps

• Control and contain the emergency

• Thoughtfully collect and document all evidence with consideration given to future legal actions

• Protect employee privacy rights in accordance with laws, regulations, and policy

• Establish liaison with federal and local law enforcement authorities reporting all incidents when appropriate

• Be available for testimony at legal proceedings

• Advise stakeholders of critical incidents and provide them with sound recommendations when requested

• Generate reports accurately reflecting facts, circumstances, events, actions, and recommendations

• Conduct postmortem critique with the goal of improved efficiency and effectiveness

Responding to the Scene

As a baseline, responders will be involved in a six-step methodology when addressing critical incidents:

• Make all necessary preparations for emergencies. Such preparations include personal training and skills updating, network preparations, and equipment/software preparations.

• Detect critical incidents. This includes but is not limited to collecting relevant information from system administrators, Web administrators, security administrators, auditors, human resources administrators, legal unit, firewall administrators, and intrusion detection equipment.

• Investigate incidents effectively and efficiently.

• Create a response strategy and present it to the appropriate senior managers before proceeding with the incident response.

• Respond to the emergency.

• Critique and postmortem. Responders, clients, and stakeholders should conduct a candid and productive analysis of the response with the objective being to improve service.

When those responding to the critical incident are advised of the emergency, there are generally two questions in their minds:

1. What happened?

2. Which is the best action to take?

As with most investigations, conducted by the law enforcement or corporate security officers, the initial stage is essentially obtaining information about the critical incident and making an assessment. Every situation is unique to itself. When collecting information about the incident, you ask what happened from those who are already there and determine if any have direct knowledge.

The first bit of information is usually the notification that something adverse has happened. Investigators should query employees present during the incident about their knowledge. On the completion of these initial interviews, this level of knowledge is usually sufficient to formulate a response strategy and make recommendations. At this particular time, it is important for investigators to ensure that actions and recommendations are measured with the exigencies of the scene.

Critical Incident Checklist

Once investigators learn of a critical incident, they begin by asking questions. Depending on their level of experience and the frequency of such events, they may not ask the right kind of questions or enough questions. At the onset, they should ask questions sufficient to determine the basic facts. Questions will likely involve the location of the affected systems, administrative and management contacts, extent of damage, and if the emergency has been contained or is spreading. They may not receive an answer to every question and in the heat of the event, they might not remember to ask the right questions. Having an emergency response checklist will go a long way to avoiding asking duplicate questions or forgetting to ask questions that should have been asked.

• Identity, location, and title of person calling

• Time and date of call

• Brief description of critical incident:

  • When did it occur?

  • Where did it occur?

  • How was it detected?

  • Who detected it?

  • What is happening at this moment?

• What systems are affected?

  • What is the impact to users now?

• Systems questions:

  • Hardware involved?

  • Software involved?

  • Type of network at the affected systems?

  • Physical location of affected systems?

  • How are the users affected?

  • Is the damage contained?

  • How was the damage contained?

  • What recovery steps have been taken?

• Who is the senior manager for this location? Contact information?

• Who is aware of this problem currently?

• Has the problem been discovered by the public?

• Attacker questions:

  • Is the attack inside or outside the organization?

  • What is the classification and extent of the stolen information?

  • What is the IP address? Has it been resolved to a domain?

  • Has there been any contact with the administrator of that domain?

  • Is the attack a denial of service?

  • What is the level of damage?

  • What steps have been taken to minimize the effects?

• User questions:

  • Have logs been examined and what do they show?

  • Is there remote access to the affected machine?

  • Have there been any changes to firewalls or access control lists?

  • Are there any auditing activities planned or taking place now?

• Contacts:

  • Who can be contacted for more information?

  • Who are the administrators and managers of the affected systems?

System Map

As part of responder preparation, it is strongly suggested that a map showing the topology, architecture, and locations is created and maintained. The location of the affected system may allow a responder to draw certain conclusions about the emergency. For example, if the affected systems are located in a secure area and do not have any connections to open-ended networks, it is obvious an employee is responsible. However, if the affected system is connected to open-ended networks like the Internet, Frame Relay, or X.25, investigators must broaden the universe of likely sources.

From the responder's perspective, there are basically three details that a topology and architecture map will provide, broadcast domains, open-ended network connectivity, and network-attached devices. Broadcast domains are those areas of shared traffic. They show trust-relationships and will generally show that an affected system will likely affect the systems within the broadcast domain. Connectivity with open-ended networks includes any point that is connected to a network that extends outside the protected network.

Reviewing system maps, responders gain an idea of the location of devices such as PBXs, routers, firewalls, intrusion devices, hubs, switches, workstations, and servers. Some documents might be of sufficient detail to display the physical location and MACs of relevant devices. Accompanying systems maps are policies and procedures regarding such items as the filtering rules, access control lists, authentication means, and other applicable policies and configuration procedures.

Experience Note 

Investigators must review all applicable policies and procedures in the creation of their response strategy. One of the questions senior managers will likely ask, when briefed about a critical incident, is the existence of policies and procedures relative to the response strategy.

Investigation at the Crime Scene

After completing an initial assessment, investigators should have a basic understanding of the situation. However, more information is generally needed before being able to decide the next steps. It is necessary to conduct a few interviews and engage in a few hands-on activities before making the first report to senior managers.

Interviews

Interviews are essentially guided conversations. Correctly done, they are extremely useful in gleaning information about the incident. Obviously, any information will have a significant affect on the way a plan of action is formulated and pursued.

Experience Note 

There is a word of caution when conducting interviews - remember that it is possible the person who is being interviewed is the cause of the problem. Document all interviews carefully and thoroughly.

When interviewing employees, a great deal of caution should be used. It is very unwise to use language that would appear to be accusatory. Interviewers must be aware of employees' legal rights, for example, if an employee is threatened with her job in order to obtain a confession of a criminal act. Such action will likely render the statement useless for future criminal prosecution, as statements of this nature must be voluntary and not coerced.

Interviewing Users

Users can provide a great deal of relevant information depending on the circumstances. Often users report unusual happenings to the help unit first. Experienced help unit employees should not dismiss strange happenings quickly. There are times that erratic system indications are a result of attacks.

Experience Note 

The help unit received repeated calls over a period of several days from one of the company's senior employees regarding e-mail that was marked as open, yet the employee insisted she had not opened it. At lunch, the help unit employee was having lunch with her supervisor and described the mysteriously opened e-mail. The supervisor explained she had some experience with "monitoring" software and visited the complaining employee. After a short interview, the help unit supervisor discovered the employee's antivirus program had been disabled. Enabling the anti-virus program and launching it, she discovered a copy of "Back Orifice" had been installed on the workstation. She recognized that Back Orifice was a program that would allow a user to remotely access and operate a workstation. Without delay, the supervisor asked the nature of the mysteriously opened e-mail and found that many dealt with sensitive financial matters. The critical incident response team was immediately notified. They discovered that Back Orifice had been secretly installed on the workstation and through a bit of research, they discovered the employee that had opened and read the e-mail.

Users, help unit employees, auditors, security officers, and senior managers should be encouraged and trained to notice and report events that identify critical incidents. After a user reports her system problems, it is incumbent on the responder to complete the process. A complete interview will answer "who, why, what, where, when, and how" of the alleged incident.

Experience Note 

When is it appropriate to report an incident? This is a difficult question to answer and much depends on the organization. If anyone is in doubt about a suspicious event, they should be encouraged to contact the critical incident response function-point or a senior manager. Through a bit of conversation, the matter can be screened with more action to follow, or the employee can be told there is nothing about which to be concerned.

Interviewing System Administrators

Many suspected critical incidents would either be escalated to a higher level of action or classified as anomalous after a discussion with system administrators. At no other time is this more evident than in the case of firewall or intrusion detection activity. Often the system administrator or firewall administrator can provide information that confirms the suspicious nature of the event or is in a position to indicate that nothing is faulty.

Here are some areas to be asked of administrators:

• What is the nature of any unusual activity?

• Who are the employees with root access to the system?

• What are the logging capabilities of the system in question?

• What do these logs show?

• What security safeguards are implemented on the target system?

Interviewing Managers

It is a good business procedure to contact managers that have responsibility for the compromised systems. The matter is twofold, they are responsible for critical assets and they are responsible to report to their stakeholders about the status of those assets. Frequently, they have information to which administrators and other employees are not entitled. For example, they have information regarding personnel matters such as those employees who have been investigated or disciplined previously.

Here are suggested areas that should be included when the manager is apprised of a suspicious event:

• What is the level of sensitivity surrounding the data and applications on the affected system?

• What, if any, are the personnel issues surrounding the affected systems? Are there personnel issues of which investigators should be aware?

• Is the systems manager aware of any authorized systems auditing or penetration scheduled at the time of the emergency? If so, who authorized this action and who is performing this audit?

Experience Note 

If the responders take any action or direct someone to take action, there must be a determination early in the response to determine if changes, precipitated by the responders, will change anything that could be used as evidence later. This is a critical move; if evidence is altered in any way, it could be rendered useless in future legal proceedings. Consequently, there must be a decision made pursuant to the response strategy recommendations very early in the response action.

If evidence is going to be collected, it must be preserved in such a fashion that it can be introduced at court; otherwise, it does not matter what changes are made. Obviously, there is a balance in getting the affected system back online and carefully collecting evidence.

Determining a Response Strategy

Assembling preliminary information, investigators should be able to formulate a viable response strategy and move to that end. Just because they have made their recommendations to senior managers does not necessarily mean they are locked into that course of action. After getting well into the problem, it is quite likely they will discover it to be different from their initial assessment requiring a change in their original plan. Creating their response strategy is in actuality devising their action plan. This plan answers the question, "Under the circumstances, as I currently know them, what is the best way to proceed considering the organization's goals and applicable legal requirements?"

The response strategy should take everything they know at this point into account as, the type of attack, sensitivity of compromised systems, policies of the organization, legal opinion, and recommendations of senior managers. Armed with an understanding of the initial facts and relevant opinions, they should be in a position to make a determination of whether the system merely needs to be cleanly restored or if a forensic investigation is warranted.

Restoring Service Operations

Restoring business operations has the goal of returning affected systems to normal service. In this action, there is not generally much care taken to collect and preserve evidence, attribute attack responsibility, or remove affected systems from operation. The primary goal is to contain damage, make changes precluding the damage from recurring, and restore the system to its operational state. Usually done at the some time is the examination of how and why the attack was successful. For example, if a virus attack were successful, owing to an outdated antivirus program, updating and change control documentation must take place before the system is restored.

This is probably the most common step dealing with attacks stemming from viruses and worms. Usually this action does not require much of an emergency response, rather it requires administrators to take appropriate action in locating the reason the virus was successful, patching the system, documenting and enabling approved changes, ensuring the system is ready for production, and placing the system back into service. Auditors are notified so they might include antivirus software patching in their next audit program.

An Attack Is Underway

There are many earmarks that identify a system under attack; here are a few:

• Sudden and dramatic increase in overall network traffic

• Traffic occurring at unusual times, usually during slack periods

• Unexplained root or user accounts

• Unexplained installed applications

• Sudden increase in the number of bad or malformed packets

• Large numbers of packets caught by routers or firewalls as egress items

• Unscheduled and unexplained server reboots

• Existence of known attack signatures in log files

Where Is the Attacker?

If investigators are tasked to identify the attacker, the investigation must proceed with great care and great length. Suppose the attacker is located within the organization, the matter may proceed with relative ease with senior managers, legal unit, human resources unit, and law enforcement cooperation. If the matter is deserving of civil or administrative action, immediate steps should be taken to preserve evidence for later proceedings.

In the case of an attacker being located outside the venue of law enforcement, do not despair if she is not identified. It is possible this person resides in a country that does not have a law enforcement assistance treaty with the country where the victim-system resides. In such cases, it is unlikely that criminal prosecution and extradition will be successful.

Do not take this statement as an axiom, as there have been cases where attackers have been lured to countries with extradition treaties and attackers have been extradited for criminal prosecution. There are cases where law officers traveled to the country where the offender resided and assisted law enforcement agencies in building a case against the offender there. Given a sufficient amount of gravity, it is possible for countries to agree to criminally prosecute an individual for analogous crimes in the country of origin. These cases usually happen where the violator cannot be extradited and the host country is interested in deterring this type of criminal behavior.

Prosecutions of a criminal nature are primarily intended to deprive a defendant of her liberty. Criminal prosecutions will not usually provide suitable financial restitution to damaged organizations. However, there is an increasing tendency of judges to order victim-restitution as part of the criminal's sentence.

Civil actions are intended to provide financial restitution for injured plaintiffs (and victims of crimes) for damages and possibly punish the defendant financially. It is a matter of how badly you want to punish the perpetrator and how much money you are willing to spend to be successful. If there have been many attacks launched by the same person and the victims can identify themselves as victims, then it is possible for them to bind together, forming a certified class, and sue the defendant collectively.

Law Enforcement Relations

Handling law enforcement relations is a delicate subject and most businesses are shy to handle it. Nevertheless, reporting allegations of a serious (felony) criminal nature, according to U.S. federal law and many state laws, is not optional. It is mandatory.

Title 18, U.S. Code Section 4, states:

Whoever, having knowledge of the actual commission of a felony cognizable by a court of the United States, conceals and does not as soon as possible make known the same to some judge or other person in civil or military authority under the United States, shall be fined under this title or imprisoned not more than three years, or both.

Another matter worth consideration is the legal requirement of having an internal mechanism to detect criminal acts affecting financial statements in publicly traded companies. Under 15 U.S. Code 87 j-l, the requirements of financial and operational audits include this language:

1. In general, each audit required pursuant to this chapter of the financial statements of an issuer by an independent public accountant shall include, in accordance with generally accepted auditing standards, as may be modified or supplemented from time to time by the Commission

   1. procedures designed to provide reasonable assurance of detecting illegal acts that would have a direct and material effect on the determination of financial statement amounts;

   2. procedures designed to identify related party transactions that are material to the financial statements or otherwise require disclosure therein; and

   3. an evaluation of whether there is substantial doubt about the ability of the issuer to continue as a going concern during the ensuing fiscal year.

2. Required response to audit discoveries

   1. Investigation and report to management If, in the course of conducting an audit pursuant to this chapter to which subsection (a) of this section applies, the independent public accountant detects or otherwise becomes aware of information indicating that an illegal act (whether or not perceived to have a material effect on the financial statements of the issuer) has or may have occurred, the accountant shall, in accordance with generally accepted auditing standards, as may be modified or supplemented from time to time by the Commission

      1. (i) determine whether it is likely that an illegal act has occurred; and (ii) if so, determine and consider the possible effect of the illegal act on the financial statements of the issuer, including any contingent monetary effects, such as fines, penalties, and damages; and

      2. as soon as practicable, inform the appropriate level of the management of the issuer and assure that the audit committee of the issuer, or the board of directors of the issuer in the absence of such a committee, is adequately informed with respect to illegal acts that have been detected or have otherwise come to the attention of such accountant in the course of the audit, unless the illegal act is clearly inconsequential.

   2. Response to failure to take remedial action. If, after determining that the audit committee of the board of directors of the issuer, or the board of directors of the issuer in the absence of an audit committee, is adequately informed with respect to illegal acts that have been detected or have otherwise come to the attention of the accountant in the course of the audit of such accountant, the independent public accountant concludes that

      1. The illegal act has a material effect on the financial statements of the issuer;

      2. The senior management has not taken, and the board of directors has not caused senior management to take, timely and appropriate remedial actions with respect to the illegal act; and

      3. the failure to take remedial action is reasonably expected to warrant departure from a standard report of the auditor, when made, or warrant resignation from the audit engagement; the independent public accountant shall, as soon as practicable, directly report its conclusions to the board of directors.

   3. Notice to Commission; response to failure to notify. An issuer whose board of directors receives a report under paragraph (2) shall inform the Commission by notice not later than 1 business day after the receipt of such report and shall furnish the independent public accountant making such report with a copy of the notice furnished to the Commission. If the independent public accountant fails to receive a copy of the notice before the expiration of the required 1-business-day period, the independent public accountant shall

      1. Resign from the engagement; or

      2. Furnish to the Commission a copy of its report (or the documentation of any oral report given) not later than 1 business day following such failure to receive notice.

   4. Report after resignation. If an independent public accountant resigns from an engagement under paragraph (3)(A), the accountant shall, not later than 1 business day following the failure by the issuer to notify the Commission under paragraph (3), furnish to the Commission a copy of the accountant's report (or the documentation of any oral report given).

3. Auditor liability limitation. No independent public accountant shall be liable in a private action for any finding, conclusion, or statement expressed in a report made pursuant to paragraph (3) or (4) of subsection (b) of this section, including any rule promulgated pursuant thereto.

4. Civil penalties in cease-and-desist proceedings. If the Commission finds, after notice and opportunity for hearing in a proceeding instituted pursuant to section 78u-3 of this title, that an independent public accountant has willfully violated paragraph (3) or (4) of subsection (b) of this section, the Commission may, in addition to entering an order under section 78u-3 of this title, impose a civil penalty against the independent public accountant and any other person that the Commission finds was a cause of such violation. The determination to impose a civil penalty and the amount of the penalty shall be governed by the standards set forth in section 78u-2 of this title.

5. Preservation of existing authority. Except as provided in subsection (d) of this section, nothing in this section shall be held to limit or otherwise affect the authority of the Commission under this chapter.

6. "Illegal act" defined. As used in this section, the term "illegal act" means an act or omission that violates any law, or any rule or regulation having the force of law.

Suspicious Activity Reports

Federally insured financial institutions are required to file Suspicious Activity Reports, SARs, in a timely fashion with copies being sent to at least the following federal authorities:

• Internal Revenue Service

• Federal Bureau of Investigation

• Secret Service

The legal requirement for SAR completion is detailed in 12 CFR Part 21, Subpart B-Reports of Suspicious Activities, Section 21.11 Suspicious Activity Report:

1. Purpose and scope. This section ensures that national banks file a Suspicious Activity Report when they detect a known or suspected violation of Federal law or a suspicious transaction related to a money-laundering activity or a violation of the Bank Secrecy Act. This section applies to all national banks as well as any Federal branches and agencies of foreign banks licensed or chartered by the OCC. (For clarification the "OCC" is the Office of the Comptroller of the Currency.)

SARs must provide basic details surrounding suspicious internal and external events. Suspicious activities include the violation of criminal statutes as well as those that constitute unethical behavior. SAR completion is not optional. It is a regulatory requirement. ^[1]

Law Enforcement Liaison

Dealing with law enforcement authorities means cooperating with them as soon as criminal behavior is suspected. In the most basic terms, it means anyone with knowledge must report crimes to authorities, both civil and military where it applies.

Most law enforcement entities have very strict procedures about evidence collection. Their goal is to collect, analyze, and preserve evidence so it can be used in legal proceedings. In cases where untrained and inexperienced crisis responders go about the process of collecting or analyzing it, they usually render it useless for legal purposes. Officers must be able to testify about the way the evidence was collected and trace its custody from origin, through examination and analysis to testimony.

Incident responders and their legal units should establish liaison with local and federal authorities assigned to computer and white collar crimes. In most regions, law enforcement officers have already formed computer crimes task forces to address technology crimes.

Senior managers and employees are responsible to contact these task force officers and create mutual policies and procedures regarding crime-reporting and evidence collection. In most instances, officers and agents welcome the opportunity to create goodwill with business organizations and are anxious to explain their evidence collection and case-processing requirements.

There are national organizations, with local chapters, having the purpose of facilitating communication between government and private industry sectors. These associations attempt to share knowledge about potential risks and provide an outlet for increased information flow between members.

Experience Note 

Such organizations are Infragard and the NIPC, sponsored by the federal government, with information available at www.infragard.net and www.nipc.gov. Privately sponsored organizations are ISACA (Information Systems Audit and Control Association), www.isaca.org; ISSA (Information Systems Security Association), www.issa.org; and HTCIA (High Technology Crime Investigators Association), htcia.org.

In the case of criminal investigation and subsequent prosecution, it is a lengthy process depending on the local agency's priorities, availability of prosecution resources, and congestion of court dockets. Responders will likely be requested to provide testimony in a wide variety of judicial hearings and trials. Usually law enforcement officers can perform much of the investigation, evidence collection and analysis and preliminary testimony themselves. However, when it comes to testimony before grand juries, evidence hearings, trials, and sentencing hearings, appropriate levels of business resources will be requested to appear.

Experience Note 

It is not unusual for criminal proceedings to take from several months to several years before they are finally adjudicated. Depending on appeals, this period might be extended to several more years.

Many law enforcement authorities are not allowed to provide copies of their investigative reports to interested parties who intend to use them for civil or administrative actions. However, anything said or presented as evidence in open-court is public information. Through public access such as the Freedom of Information and Public Access laws, private entities may obtain information about adjudicated criminal cases. The court reporter's office and the court clerk's office may provide transcripts of hearings and court proceedings that might be used in other legal actions.

Types of Attacks

In determining the correct response strategy, you must identify the type of attack affecting operations. Is the attack unauthorized e-mail access, denial of service, Web site vandalism, theft of sensitive information, or someone exploring the interior network? Knowing and classifying the attack for the response checklist decides response options.

• Computer intrusions. These are attacks against tax critical assets. Unauthorized intrusions can take a variety of forms while attackers attempt to disguise their identity. Attackers freely plant viruses, back doors, Trojans and worms; steal proprietary information; waste system resources; and delete or corrupt data.

• Denial-of service-attacks. DoS attacks can have origins with one source or in the case of a Distributed Denial of Service, DDoS, hundreds of attacking sources. Stopping them depends greatly on the updated configuration of firewall and gateway equipment. They can be nasty - stealing large amounts of bandwidth and crashing systems with outside connections. A devastating DDoS attack was experienced and chronicled by Steve Gibson at http://grc.com/dos/drdos.htm.

• Unauthorized use of resources is not really an attack, but it should be considered in this category. Usually it is an employee violating organization policy by using the workstation and network to do such things as shopping, download software, or distribute prohibited materials. In addressing internal violators, investigators usually focus on the employee's workstation and the media found in the work area.

• Web page vandalism is part of the intrusion category. Here the responder is faced with the circumstances of how the attacker gained access to the Web server and changed the content or the means by which the Web page interacted with the user. A major concern of senior managers is the extent attackers were able to penetrate the victim-network. Web page defacements often appear to be nothing more than acts of cyber-vandalism, but many times they are more insidious. Responders should review the compromised Web page and related systems to determine if intruders accessed sensitive data.

Administrator Facilitated Attacks

There are times when attacks are facilitated by negligent acts on the part of network and systems administrators. Systems administrators are often so busy handling fires; there is not enough time in their day to get done what they are asked to do. Consequently, they install a server platform or application with its default configuration settings.

Experience Note 

Default installations are a recipe for disaster. Attackers are counting default installations for their success. Attacks exploiting default system vulnerabilities must be addressed by policies and procedures, with compliance ensured by unannounced internal audits.

These are a few examples of potentially disastrous acts:

• Administrators perform default installations

• Administrators fail to remove or disable unnecessary services

• Administrators fail to close unnecessary ports

• Administrators fail to remove all unnecessary hardware from networked equipment such as firewalls, servers, and workstations

• Administrators fail to disable 'A' drives from their servers allowing floppy disks to be inserted containing software facilitating system penetration

• Administrators run services, at root, that should be run at account levels

• Administrators fail to review user activity logs for anomalous activities

• Administrators assign poor or no passwords to users

• Administrators fail to enforce user authentication before manually resetting passwords

• Administrators install network services with known security flaws such as telnet, FTP, rhost, etc.

• Administrators fail to adequately protect sensitive files and information

• Administrators install applications that fail to screen, and deny improper user input

Senior Manager's Approval

Completing their initial investigation, investigators should have enough information collected to decide the appropriate response level, methodology, and make recommendations to senior managers. The primary issue at this time is to present the action-plan in an understandable and concise way. As part of the presentation, legal unit representatives should be present during the action plan presentation so they might render an informed legal opinion.

Experience Note 

Actions taken during the response will likely impact the entire enterprise. Investigators and senior managers must proceed with caution and deliberation.

Present all relevant alternatives with their corresponding advantages and disadvantages. Narrow the best choices to one well-justified recommendation. If there is not a clear-cut alternative, investigators must be prepared to declare their best possible recommendations.

Other Relative Issues

In addition to the items mentioned above, there are other matters affecting how and when the responder will react to the critical incident. Often the location of the attacker will affect the response action and willingness to pursue criminal and civil prosecution. If an attacker is located in a country that protects its citizens from extradition or prosecution, then pursuing judicial recourse may not be the wisest course. In some cases, legal efforts might best be directed toward asset forfeiture or civil process focusing on the attacker's financial assets in the region where the attacker's victim resides.

However, if the attacker is located within the same national borders as her victim or in a country with treaties supporting prosecution or within the organization itself, then administrative, civil, and criminal actions should be pursued. Bear in mind, these investigations and prosecutions frequently span months. In some cases, it appears the benefit is relatively small by seeking criminal prosecution; however, if the public is made aware that attacking your business results in legal action with prison, asset forfeiture, and the collection of damages from attackers, it will likely deter other attackers. Basically, civil and criminal prosecutions are effective in the deterrence of unlawful acts only if the public is made aware of them.

Experience Note 

Unlawful acts are not deterred in a news-vacuum.

Business Considerations before Legal Actions

Before pursuing the track of lengthy legal actions, there are technical and business considerations that have to be made.

• Does the organization have the technical expertise, equipment, and time to pursue an investigation, analysis and resolution?

• Are there public or stockholder considerations to be made?

• Do these factors impact legally mandated reporting requirements?

• Does the organization possess sufficient financial resources to initiate and complete a full investigation?

• Will your organization be a repeat target in future attacks if legal action is not taken now?

^[1]More SAR-relevant information is available at www.occ.treas.gov/fr/cfrparts/12CFR21.htm#§%2021.11%20Suspicious%20Activity%20Report and www.occ.treas.gov/sar.htm.

---