With the exception of physical sabotage, it's rare for a piece of hardware to be so badly damaged from an intrusion that it can't be salvaged and returned to service. (An exception to this rule would be a microprocessor that is the victim of a DoS attack designed to overheat the CPU by performing excessive numerical calculations.) However, it may be more expedient to swap out compromised hardware devices such as hard drives rather than trying to recycle them, especially if the original hard drives are going to be needed by forensics.
In the case of system and application software, rather than trying to figure out exactly which services may have been compromised, it's probably safer to assume the worst and erase and reformat any hard drives (and possibly backup tapes and disks) that may have been accessed by the intruder. This would entail reinstalling the system and application software from a trusted medium such as a nonrewriteable CD. Unfortunately, all too often weak configuration management procedures may have allowed developers or Webmasters to make changes to the production Web site without updating the original source code or test environments, thereby resulting in recent fixes and optimizations being lost as the result of the restoration process. Restoration procedures should therefore be checked to ensure that they are comprehensive and can be implemented in a timely manner.
Data
Although restoring the system and application software that provides a Web site's functionality may be tedious, a much more challenging situation exists when a Web site's nonstatic data needs to be restored. Assuming the damage assessment is able to determine at what point in time an intruder gained unauthorized access to the data, it may be possible to restore the data to a precompromised state. Unfortunately, rolling the data forward from the last backup made before the intrusion may not be possible if transaction logs have not been kept (or cannot be trusted), leaving the organization with an unenviable dilemma of implementing a less-than-ideal recovery process, such as one of the following strategies:
Restore the data back to its last known uncompromised state and then attempt to reenact all the transactions that are believed to have occurred after this point in time. For example, the first step would be to restore last week's version of a database used to support an intranet application that processes all the invoices a company receives. The database could then be brought up-to-date by rekeying all the paper invoices and resubmitting any electronic invoices that the company had received within the last week.
Restore the database back to the last known uncompromised state and then void any transaction that occurred after that point in time. Such a course of action may be chosen because noncorrupted versions of the voided transaction cannot be found (or can't be trusted) or the business cost of reapplying these transactions outweighs the benefit of a full restoration. For example, the administrator for a fantasy football league Web site that did not maintain any transaction logs may decide to simply void all the games that took place after the Web site was defaced. He would do so rather than rely upon the recollections (and honesty) of the individual players to resubmit their game selections. Play would then be resumed for all future games.
Attempt to patch the compromised data files or databases by trying to identify and fix the individual records that have been tampered with, typically using information from an independent trusted source. For example, suppose it appears that the only data that was tampered with was a few employees' salary records. It may be possible to fix these records by reconciling them with records held in a separate uncompromised system, such as the human resource department's paper files, or the payroll run that took place immediately before the intrusion occurred.
Recovering corrupted data becomes increasing more difficult the longer the corruption goes unnoticed. So, an organization wanting to test the capabilities of its data restoration procedures might wish to challenge the team responsible for recovery efforts. It could see how long the recovery team takes to salvage a tampered database that has subsequently had several days' (or weeks') worth of legitimate, nonvoidable transactions applied to it since the corruption occurred.
Once the primary system has been salvaged and restored, one additional step may need to take place before it can reenter service: synchronizing, or reapplying the transactions that have occurred on the temporal system while the primary system was offline. This task should be feasible if the temporal system has been maintaining adequate transaction logs; nevertheless, the synchronizing process should be tested to ensure that it can be
also spell out when these parties should be informed. Possible candidates would include the following:
An organization's legal counsel.
Law enforcement agencies such as the FBI (www.fbi.gov).
Coordination centers such as the Computer Emergency Response Team coordination center (www.cert.org) or the System Administration, Networking, and Security (SANS) institute (www.sans.org).
The unwitting owners of the machines from which the attack was launched.
Business partners who might be affected, such as credit card issuers, banks, customers, and suppliers.
The media and general public. If the news of the attack is likely to make it into the public domain, an organization's public relations department may want to be the source that announces the incident, thereby being given the opportunity to put a more palatable spin on the event.
If the organization has a cybercrime insurance policy, then the organization may need to put the insurance carrier on notice that the organization may be filing a claim. Table 9.2 provides a sample list of insurance carriers that offer cybercrime insurance policies.
Retaliation and Prosecution
One critical decision that should have been made long before any serious attack is detected is whether or not an organization, given the opportunity, would consider trying to prosecute an offender. This decision is critical, as the collection and preservation of evidence for use in a possible prosecution will most likely slow down the recovery effort and potentially increase the recovery cost. Possibly too, an organization may decide to adopt a different policy for internal attacks than for an externally launched attack.
Some organizations may choose to attempt to acquire information on the attacker by trying to trace the attack to the original source. Unfortunately, many sophisticated attackers choose not to launch an attack from their own machine but instead employ a previously compromised (or drone) machine to do their bidding. So, any counterattack launched by the organization that suffered from the original attack may only end up affecting another of the intruder's victims. Although attempting to trace the source of the attack may yield useful information (if only to inform another organization that their system has been commandeered by an intruder), more aggressive action is probably best left to local, nation, or international law enforcement.
In situations when successfully compromising the Web site under attack would be considered a breach of national security, the attack may be considered an act of cyberwar. It could therefore warrant much more aggressive action by the nation's government than actions likely to be taken by national or international law enforcement agencies.
Policy Review
Even when no successful intrusion attempt has been detected, the rapidly changing nature of Web security and the relative inexperience of some of those charged with protecting an organization's Web sites and applications can still make holding a regular policy review extremely beneficial. In addition, it is considered good practice to always review the current security policies and infrastructure after a successful break-in has occurred to make sure that a similar attack would not be successful in the future. Table 8.16 lists the questions to ask when creating an intrusion response policy.