Incident Response

[security_mike]

Hey Guys and Gals,
In response to the recent (ish) site defacement attack against this forum, I would like to present an old article I wrote about basic incident response that might help you if the worst case scenario ever happens.
All the best.
Cheers,
Mike

mike'at'amisecure[.]co[.]uk

Please note: This article originally appeared in the Elsevier Network Security Journal. Copyright Michael Kemp 2005.

The Lens and The Method: Introduction to Incident Response

In a number of Internet and offline sources the detection and prevention of common and stealth attack vectors is discussed in detail. Sadly, many of the methods discussed in numerous sources (and in the marketing materials of many suppliers) may not always prove effective against a skilled and determined attacker and it may well be the case that system administrators find themselves facing the aftermath of a
successful system incursion.

In Price Waterhouse Cooper’s 2004 Information Security Breaches Survey, 64% of respondents reported staff misuse of information systems (of this sizeable percentile it is unclear what percentage of this misuse was aimed at leveraging illicit systems access) and 39% of large businesses reported external attacks.

Statistics are not infallible of course, but this response rate does indicate a significant issue, namely that attacks (be they internal or external) remain a constant threat to many organisations regardless of size.

Many attacks may unfortunately prove to be successful, and this article will examine the basic procedures that can be followed to ensure that any evidence that results following an attack is not lost, and that any external forensic examiners employed by your organisation will be in a better position to accumulate useful evidential material.

This article is not intended for a readership of already practicing forensics professionals, but rather for systems and management professionals who may be called upon to preserve and locate evidential materials as part of their job functions, but have little or no idea where to start.

Although there are a number of excellent resources available to computer forensics examiners, knowledge of this field (and methods of operation) is somewhat restricted amongst systems administrators (and indeed management personnel).

As it will be typically the case that system and network administrators will be amongst the first to discover evidential traces of attacks, it is vital that these groups know what actions to take, and when to take them. From a technical perspective it is essential that systems professionals are conversant in methods to recognise, locate, and most importantly preserve, digital evidence of a computer crime.

By taking relatively simple steps systems professionals can ensure that the evidential trial is preserved for any external forensic specialists, and the integrity of such evidence is preserved in such a state to make it of use to law enforcement.

If a systems intrusion (or act of internal misuse) is serious enough to merit a potential criminal prosecution, the nature of evidence collected will play a vital part in any criminal case. It is important to know what evidence may be collected, how it may be interpreted and what data may be available to trace the source of criminal actions.

Seeing the trees (and logs)

An important element in any discussion of network security is what is commonly referred to as the ‘triple a’ security model, which controls what computer resources may be accessed by users and the tracking of activity in a network environment.

Many system and network professionals will already be familiar with the model, but a firm understanding is vital when considering forensics.

Authentication

– This prong of the triple a model is concerned with the process of identifying a user, process or service and ensuring that they have sufficient credentials to enter or employ systems or resources. This concept relies upon each process, service and use having unique information (account user names and passwords being a good example) that differentiates them.

Authorisation– Is concerned with ensuring that resource requests will be granted or denied according to the permission level of the requester.

Accounting

– This process is concerned with the monitoring and tracking of system activity. From a network security perspective accounting is more usually referred to as auditing. Auditing is the process of logging communications links, networks, systems and related resources to ensure that they may be analysed at a later date. The production of accurate and detailed log files can often play a significant role in the gathering of forensics evidence.

As many system professionals will already know (probably as a result of bitter personal experience!) auditing is a capability that is inbuilt in most operating system environments and network devices. Successful auditing is reliant upon the monitoring and creation of log file data for select processes and resources.

Auditing all the events that occur with a modern network environment is completely impractical; however it is considerably more practical from a forensics perspective than auditing nothing.

A general principle to follow when developing an audit strategy is to focus on the logging of suspicious activity, administrative actions, and access to valuable data.

Specific intrusion signatures and known attack vectors should be routinely monitored on the periphery of the network, and it is advisable to monitor administrative level actions (as many attackers will seek administrative level rights) as well as successful or unsuccessful attempts to access valuable data, or alter system information (e.g. the creation and deletion of accounts and directories).

By applying a consistent and well developed audit policy that is put into effect on a regular basic, network professionals can ensure that the successful groundwork for a forensics examination is laid.

Another aspect of auditing that is commonly discussed but seldom understood in depth is the monitoring of firewalls and other boundary devices. Many technically adept intruders will find ways and means of bypassing external protections, and deleting any logs of their activities, but oftentimes less skilled attackers will ignore these logs, and occasionally even skilled attackers forget.

The logs generated by firewalls and external network devices (e.g. routers, gateways, etc.) can be an important part of the evidential trail but only if logs record relevant data. This article is not intended to be a primer on firewall administration, but from an attack prevention and post-attack perspective it may often be necessary to log the following:

Access to well known ports

– Ports that should be monitored are those associated with Instant Messaging (if this is permitted within your enterprise), as well as those associated with Trojans and other malware (a list of such ports can be attained with relative ease from a number of Internet sources).

Regular scanning behaviours

– Firewalls and external devices should log any systematic or regulated scanning of IP address ranges, TCP and UDP ports and NetBIOS names to name but a few.

ICMP traffic

– Inbound and outbound ICMP traffic should be carefully monitored for excessive pinging, echo requests and other common attack vectors.

From a forensics perspective log files are only as useful as the data they contain, and at the very least they should contain the following information (to a forensics examiner the more information, however the better):

Source address (and source domain address if available)

Protocol

Destination address
Port and socket addresses and message type or class (where applicable)
Timestamp

Provided consistent logs and auditing is in place by organisations (as well as regular and sustained back up procedures) the data collected can be of significant use in locating the source of attacks that may occur.

Many attackers will typically employ previously compromised systems, open proxies or anonymising services in attempts to disguise their origins, however, it is possible to potentially trace their path, providing all involved have defined procedures and a spirit of cooperation.

Absence of evidence is not evidence of absence

Computer forensics is a highly specialised field requiring both a detailed understanding of not only computer systems but the law. Because evidence is of vital importance to securing a prosecution it is strongly recommended that any system administrator charged with collecting digital evidence immediately contact a specialist Computer Incident Response Team.

Such a team will be conversant with the steps and procedures necessary to not only collect evidential materials but ensure that the material collected is admissible within a court of law.

From a legal perspective any evidence collected must be accumulated in such a way as to remain untainted. If a non-specialist (and potentially hostile) system administrator clumsily attempts to gather or preserve evidence they can often significantly reduce the chances of a successful prosecution, and in the worst case cause considerable embarrassment for their employers when it is ruled in court that the evidence gathered is actually inadmissible and in the words of Arthur Conan Doyle “a clever counsel rips it to rags”.

In many cases, the first individual to become aware of a criminal act using IT systems will be a network or systems administrator. In large organisations it is vital that Incident Response specialists (whether internal or external) be contacted to preserve evidential materials and halt any attacks that may be occurring.

Sadly, many enterprises do not possess the necessary budget for the employment of IR specialists and it is often necessary for the network administrator to respond.

Typically, this individual is referred to as the “first responder” and it is essential that they secure the scene of the evidence prior to it being investigated by specialists who may be approached and come into contact with evidential materials at a later date.

The role of a first responder is a clear one. Unless they have received specialist training in computer forensics and forensic methodologies, the individual who is first into contact with computer systems, should wherever practicable, do no harm to any potential evidence.

The principal duty of the first responder is to protect computers from tampering, damage or interference of any kind. Unless specifically trained in forensic procedures, the first responder should never attempt to shut down the computer, or indeed access it in search of forensic information.

Many astute computer attackers will potentially adjust compromised systems to destroy any incriminating evidence if they are tampered with. First responders should endeavour to compile a list of systems that may have been involved in the attack, protect such systems from tampering
and preserve any transient potential evidence.

Transient evidence can take the form of data that could be erased prior to the arrival of any specialist investigative team (e.g. data on screen). Wherever possible, careful records should be taken of all potential evidence and compromised systems, as well as a photographic record (or other method of recording) of any transient data.

Another potential role that may be required in the case of a live attack is to disconnect any compromised systems (that are known about) from a live network environment.

This can greatly reduce the chances of an attacker or any accomplices they may have deliberately erasing or altering any potential evidence, as well as minimising the risks of any other party doing so unintentionally.

As highlighted earlier many large enterprises may have a team of individuals specifically tasked with Incident Response duties...

(As I can't post more than 15,000 chracters the rest of this article is available at http://www.amisecure.co.uk .. sorry for any inconvenience)

[Brian Turner]

Just edited the formating to make it easier to read - also added site link.