• To create an incident response mechanism within the organisation
• To install a minimum-security baseline in the IT and network infrastructure of the organisation -- to set criteria to help prevent incidents from occurring in the first place.
• The incident response team's level of security experience and subject matter expertise is vital to this effort.

• The most common way to receive notification of a problem is from the users themselves
• Many incident indicators which will need to be reviewed, prioritised, and evaluated each day in a large commercially active organisation
• The right people with the right skills at the right location and time to provide the needed actions in response to each incident

• The team leader's decision-making becomes paramount
  • Allow the right sources applied to the effort
  • Gain management support during the response
  • Secure the data
• Various questions need to be answered,such as:
  • Should we shut the system off?
  • Should we disconnect the network from the machine?
  • Should we disable certain ports, protocols, or services first?

• Considerations for eradication during the response - the type of incident will provide these areas:
  • Potential damage to and theft of resources.
  • Need for evidence preservation.
  • Service availability (e.g., network connectivity, services provided to external parties).
  • Time and resources needed to implement the strategy.
  • Effectiveness of the strategy (e.g., partially/fully contains the incident).
  • Duration of the solution (e.g., emergency workaround to be removed in 4 h, temporary workaround to be removed in 2 weeks, permanent solution).
• Eradication actions could include
  • Deletion of the malicious software or code snippet
  • Disabling certain accounts on the system
  • Closing the applicable firewall ports, etc.
• Full eradication may not be needed and could actually cause further damage, so the method of eradication is also an important consideration during this stage

• The ultimate goal: Recovery back to full business operations
  • Restoring the system affected from full, uninfected backups
  • Rebuilding systems from scratch
  • Hardening systems to prevent further occurrence of incident
  • Adding new or expanded security parameters on boundary devices
  • Changing administrative passwords
  • Increasing the logging of events immediately after the incident to ensure full recovery

• After the event learning action is one of the most important activities
• Each team and team member should review
  • The effort
  • The techniques used
  • The timing of the response
  • The threat realized
  • The support actions taken with the eye on improving the response then next time

Key Steps:

• Secure and Evaluate the Scene
• Document the Scene
• Perform Evidence Collection
• Package, Transport, and Store the Collected Digital Evidence

Incident Handling Tools

• Follow departmental policy for securing crime scenes.
• Immediately secure all electronic devices, including personal or portable devices.
• Ensure that no unauthorized person has access to any electronic devices at the crime scene.
• Refuse offers of help or technical assistance from any unauthorized persons.
• Remove all persons from the crime scene or the immediate area from which evidence is to be collected.
• Ensure that the condition of any electronic device is not altered.
• Leave a computer or electronic device off if it is already turned off.

• The first responder should record
  • The location of the scene;
  • The scene itself;
  • The state, power status, and condition of computers, storage media, wireless network devices, mobile phones, smart phones, PDAs, and other data storage devices;
  • Internet and network access; and
  • Other electronic devices.
• The initial documentation of the scene should include a detailed record using the following to help recreate or convey the details of the scene later
  • Video,
  • Photography, and
  • Notes and sketches.
• All activity and processes on display screens should be fully documented.
• Documentation of the scene should include the entire location, including
  • The type, location, and position of computers,
  • Their components and peripheral equipment, and
  • Other electronic devices.
• First responders should
  • Document all physical connections to and from the computers and other devices.
  • Record any network and wireless access points that may be present and capable of linking computers and other devices to each other and the Internet.
• The existence of network and wireless access points may indicate that additional evidence exists beyond the initial scene.

• The first responder must have proper authority to search for and collect evidence at an electronic crime scene. Such as
  • Plain view observation,
  • Consent, or
  • A court order
• Digital evidence must be handled carefully to preserve the integrity of the physical device as well as the data it contains.
• Data can be damaged or altered by electromagnetic fields such as those generated by static electricity, magnets, radio transmitters, and other devices.
• Communication devices, such as mobile phones, smart phones, PDAs, and pagers should be secured and prevented from receiving or transmitting data once they are identified and collected as evidence.
• Business environments frequently have complicated configurations.

• Digital evidence, and the computers and electronic devices on which it is stored, is fragile and sensitive to:
  • Extreme temperatures,
  • Humidity,
  • Physical shock,
  • Static electricity, and
  • Magnetic fields.
• The first responder should take precautions in the following stages to avoid altering, damaging, or destroying the data.
  • Documenting,
  • Photographing,
  • Packaging,
  • Transporting, and
  • Storing digital evidence

Hacked Government Server

• During a routine antivirus scan, a government system administrator was alerted to suspicious files on a server.
• The files appeared to be part of a well-known rootkit.
• The server did not host any confidential data other than password hashes, but there were several other systems on the local subnet that contained Social Security numbers and financial information of thousands of state residents who had filed for unemployment assistance.
• The administrative account usernames and passwords were the same for all servers on the local subnet.

Was the server in question truly compromised?

• Action: Examining these files
• Artefact 1: The rootkit files were found in the home directory of an old local administrator account that staff had forgotten even existed
• Artefact 2: Investigators found that the local authentication logs had been deleted
• Conclusion: They were, indeed, malicious software

If so, how was the system exploited?

• Action 1: Examining local SSH logs
• Result 1: Found that the local authentication logs had been deleted


• Action 2: Reviewing SSH logs from the central logging server that were associated with the account
• Result 2: The account had been the target of a brute-force password-guessing attack


• Action 3: Conducting password audit
• Result 3: The account’s password was very weak


• Action 4: Tracing the origin of the attack
• Result 4: The brute-force attack was a system located in Brazil (according to network documentation the perimeter firewall was supposed to be configured to block external access to the SSH port of servers on the subnet under investigation)


• Action 5: Reviewing the current, active firewall configuration
• Result 5: It did not match the documented policy. the SSH port was directly accessible from the Internet

Were any other systems on the local network compromised?
Was any confidential information exported?

• Action 1: Conducting a detailed analysis of authentication logs for all systems on the local subnet
• Result 1: Found no other instances of suspicious access to the other servers; no records of logins using the hacked account on any other servers


• Action 2: Extensively analysing the firewall logs
• Result 2: No suspicious data exportation from any servers on the local subnet.

• The server under investigation was compromised
• No other systems on the local subnet had been exploited
• No personal confidential information had been breached

• Correcting the errors in the firewall configuration
• Removing the old administrator account
• Removing the rootkit

• Implementing a policy, in which firewall rules were audited at least twice per year.
• Establishing a policy of auditing all server accounts (including privileges and password strength) on a quarterly basis

• Prepare - Specific forensics training, overarching corporate policies and procedures, as well as practice investigations and examinations will prepare you for an “event.”
• Identify - When approaching an incident scene—review what is occurring on the computer screen. If data is being deleted, pull the power plug from the wall; otherwise perform real-time capture of system “volatile” data first.
• Preserve - Once the system-specific “volatile” data is retrieved, then turn off machine, remove it from scene, and power it up in an isolated environment. Remembering to “hash” the image with the original data for verification purposes.
• Select - Once you have a verified copy of the available data, start investigation of data by selecting potential evidence files, datasets, and locations data could be stored. Isolate event-specific data from normal system data for further examination.
• Examine - Look for potential hidden storage locations of data such as slack space, unallocated space, and in front of File Allocation Table (FAT) space on hard drives.
• Classify - Evaluate data in potential locations for relevance to current investigation.
• Analyse - Review data from relevant locations. Ensure data is readable, legible, and relevant to investigation. Evaluate it for type of evidence: Is it direct evidence of alleged issue or is it related to issue?
• Present - Correlate all data reviewed to investigation papers (warrants, corporate documents, etc.). Prepare data report for presentation—either in a court of law or to corporate officers.