Incident Response - For Sysadmins

Scope

The policy and procedure in this document applies to all individuals authorized to use SDSC's IT resources. The prescribed actions and processes described in this document apply to situations involving any SDSC Host (as defined in the SDSC Security Policy) as well as any of the IT resources provided by SDSC.

Note that this document does not authorize all affected individuals to act upon the procedures described here. The policy in this document authorizes actions for only specific roles. For those not included in those roles, this document is purely informational.

Background

After identification, incident response focuses upon two general activities: containment and eradication. Containment attempts to restrict the influence of an attacker while trying to learn the attacker's goals and methods. Eradication attempts to remove the attacker's influence. Both activities require the oversight of security personnel as well as cooperation between security personnel, service administrators, and host administrators.

Incident response involves both activities: containment, then eradication, in that order. Depending on the nature of the incident and attack, one may have priority over the other. We must strive to understand an attack to reduce the chance of future attacks, but must also balance that effort against the security needs (confidentiality, integrity, availability) of the affected system. This policy outlines the criteria for striking that balance, but leaves the final judgement in the hands of security personnel.

Goals (of this policy)

• Establish roles, timelines, and key procedures for post-detection incident response efforts.
• Explain the reasoning behind the stipulations of this policy.

Goals (of the procedures in this policy)

• Acquire and preserve information that may help understand an attack.
• Determine the scope of an attack.
• Address the security needs of the affected service or host.
• Remove the influence of the attacker.
• Restore the affected service or host to a secure state.

Roles and Definitions

(Move these to their own page and replace with hyperlinks... some day.)

Security Personnel

These are members of SDSC's security group (sometimes known as "Security Technologies"), or individuals designated by SDSC's CISO as members of the incident response team. Incident response team members may oversee a response effort until relieved by a member of SDSC's security group.

Preferred Responder

A member of SDSC's security group designated by the CISO as the preferred person to respond to security incidents.

Service Administrators

Service administrators are personnel responsible for the maintenance, configuration and administration of a service or group of services running on a host operating system. In some cases, a service administrator may also serve as a system administrator for the same host; though in most cases, service administrators have restricted administrative privileges and do not maintain the underlying host operating system.

System Administrators

System administrators are personnel responsible for the maintenance, configuration, and administration of a host operating system and its core services (e.g. ssh). System administrators have full administrative privileges on the host they manage, and bear ultimate responsibility for the proper operation of their hosts.

Threat

A possible violation of security, which may result in impacted confidentiality, integrity, or availability of data or resources.

Attack

An action that violates security and may result in impacted confidentiality, integrity, or availability of data or resources. (An instance of a threat.)

Attacker

An entity that executes an attack.

Incident

An investigative event arising from an attack, set of related attacks, evidence of an attack, or discovery of a new threat. (When we get stuck at work late and don't get enough sleep.)

Procedures

This process begins when someone reports an incident according to Incident_Response_-_For_Users, or when a service administrator or system administrator notifies security personnel of an incident. Note that the recipient of an incident report, as discussed here, must have the role of security personnel.

Identification

1. Upon receipt of an incident report, the recipient must attempt to contact the preferred responder through all reasonable and persistent means to hand off the report.
2. If the recipient can not confirm hand-off to the preferred responder within 30 minutes of receipt of the report, the recipient may:
   1. Investigate the claims if working within their expertise and with the assistance of qualified individuals.
   2. Contact and hand off the report to other security personnel more qualified to perform the investigation.
3. Whoever performs the investigation becomes the responder.
   1. The preferred responder or other member of the security group may request the responder to hand off the incident at any time, at which point after confirmation of the hand off, the person making the request becomes the new responder.
4. The responder shall send an email to security@sdsc.edu with their findings. The sender must encrypt the email using GPG and the predetermined shared secret.

Containment

1. If the responder can not account for the claims in the incident report as false positives, we must assume an attack is, or has taken place.
2. The responder shall create an incident page on incidenterator with the initial information.
3. The responder shall, in a timely and non-intrusive manner as possible, collect details of the running state of the affected system and place these details, when practical, into the incidenterator page. (Pasting in chunks of logs is okay. Pasting in a binary file is not.) Small, frequent updates with remarks are easier to follow than long updates with no remarks.
4. The responder shall attempt to discover the extent of the attacker's influence, goals and methods using any passive methods available to the responder. The responder must document their findings and attempt in the incidenterator page. The responder must not perform destructive analysis at this time.