Incident Response Planning Guideline

Looking for the Campus Incident Response Plan? Go to Information Security Documents instead. The below Incident Response Planning Guideline refers to systems and applications that need to adhere to Campus MSSEI policy.

UC Berkeley security policy mandates compliance with Minimum Security Standard for Electronic Information for devices handling covered data.  The recommendations below are provided as optional guidance forincident response requirements.

Requirement

Each system custodian must develop and review at least annually a system-level incident response plan that contains:

• Names and contact information for the local incident response team, including:
  • Security Contact and alternate contact(s) who have system admin credentials, technical knowledge of the system, and knowledge of the location of the incident response plan.
  • A local authority/decision maker for the system who understands business impact of the system and its unavailability.
• System details, or reference to the location of such information, including:
  • Data Flow Diagrams
  • Network Diagrams
  • System hardware inventory (as required by the Annual Registration control)
  • Logging information (as required by the Audit Logging control)
• Procedures for reporting and handling a suspected incident, defined per role: Sys Admin, Bulk Access User, End User, e.g.,
  • Who to contact
  • How NOT to tamper with potential evidence (i.e., not to attempt forensics when not authorized)

Description of Risk

If users and system administrators are not aware of incident response procedures, response will be delayed and evidence can be corrupted or lost, greatly increasing the potential impact of an incident.

Recommendations

To ensure information security events and weaknesses associated with covered core systems are communicated in a manner allowing timely corrective action to be taken, event reporting and escalation procedures should be documented in a formal Incident Response Plan.  Incident response procedures typically fall into the following phases:

• Detection - Initial assessment and triage of security incidents on covered core systems, including escalation to the Information Security Office (ISO) and assigning incident priority level.

• Analysis - Perform detailed impact analysis to properly prioritize additional response activities required for high impact breaches.  Begin evidence preservation and containment activities, as well as initial recovery.   

• Recovery - In keeping with the severity of the incident, mitigate the impact of the incident by finishing containment and eradication activities, and ultimately recovering from it. During this phase, activity often cycles back to detection and analysis—for example, to see if additional hosts are infected by malware while eradicating a malware incident.

• Post-Incident - After the incident is adequately handled, issue a report that details the root cause and total cost of the incident, along with the steps the organization should take to prevent future incidents.

All campus staff, contractors and third party users should be made aware of the procedures for reporting the different types of events that might have an impact on the security of covered devices. They should be required to report any information security incident as quickly as possible to the designated point of contact.

What is a Security Incident?

A security incident in the context of this MSSEI requirement is an event that compromises or has the potential to compromise:

• the operation of covered core systems or
• confidentiality or integrity of covered data assets

A security incident may involve any or all of the following:

• a violation of campus computer security policies and standards
• unauthorized computer or data access
• presence of a malicious application, such as a virus
• presence of unexpected/unusual programs
• a denial of service condition against data, network or computer
• misuse of service, systems or information
• physical or logical damage to systems
• computer theft

Components of an Incident Response Plan for Individual Systems and Services

Resource proprietors and resource custodians should ensure that their Incident Response Plan contains the following components.  We provide this TEMPLATE for incident response plans for individual systems and services.

• Names, contact information and responsibilities of the local incident response team, including:

  • Incident Handler:  Security Contact and alternate contact(s) who have system admin credentials, technical knowledge of the system, and knowledge of the location of the incident response plan.
  • Resource Manager:  A local authority/decision maker for the system who understands the business impact of the system and its unavailability.  The resource proprietor should take on the responsibilities of the resource manager or designate a campus staff member for this role.

• System details, or reference to the location of such information, including:

  • Data Flow Diagrams
  • Network Diagrams
  • System hardware inventory (as required by the Annual Registration control)
  • Logging information (as required by the Audit Logging control)

• Procedures for reporting and handling a suspected incident, including:

  • Complete an incident intake report, which should include the following information:
    • Contact person name and phone number
    • IP address, hostname and physical location of breached system
    • Name of the covered system (as it appears in Socreg)
    • What types of covered data was available on/from the breached host?
      • Full Name
      • Social Security Number
      • Driver's license number or California identification card number
      • Credit or financial account number card number (including PIN or expiration date)
      • Bank account number (including PIN or other access information)
      • Medical information or health insurance information
      • Other
    • For each file containing personal information specify:
      • ​Name of the file
      • Size of the file
      • Location of (full path to) the file
    • ​Was the data encrypted, and if so, how?
    • Describe impact of the incident (e.g. the number of data records are compromised or the number users that are affected by unavailable system)
    • Describe the security incident, including the timeline of activities, how the incident was detected, impact (business and technical) of the incident, details of mitigating controls in place such as what data encryption mechanism was used.  
    • Document action being taken on the breached system (what’s the state of the system now, etc)

• Report security incident to ISO (email urgent@security.berkeley.edu*) and include the intake report. We will assign a Security Analyst to coordinate any follow-up incident response activities.  

  • After a security incident is reported to ISO, do not disconnect or logon to breached system until instructed by the ISO Security Analyst.
  • Service disruption that is not a result of malicious activities should be reported to the appropriate IT support personnel.  Additional information on reporting different types of incidents can be found on the security website.  For example, for most campus wide enterprise applications, service disruption should be reported to Campus Shared Services IT.

• Respond to the security incident in a timely fashion based on the incident prioritization guideline.  

*Note that urgent@security.berkeley.edu email address should be used only to report MSSEI covered security incidents.  Non-MSSEI covered security incidents should be reported to security@berkeley.edu.  

Security Incident Prioritization

To help prioritize the timing and resources needed to deploy corrective action, resource proprietors and resource custodians must assess the impact of a security incident based on the following factors:

• How the incident will impact existing functionality of the affected systems
• Whether the incident breaches the confidentiality or integrity of covered data UC P4 or non-covered data
• How much of the user population is affected by the security incident
• What’s the reputational/financial impact to campus

Using the factors listed above as a starting point, security incidents should be assessed and assigned a high or low priority level by the designated Incident Handler and Resource Manager.  Factors to consider include not only the current impact of the incident but also the likely future impact of the incident if it is not immediately corrected.  Any high priority incidents should be immediately reported to ISO following the incident handling procedures.  Once a security incident is reported to ISO Analyst, the priority rating will be confirmed or revised following additional analysis of the event.

Examples of high priority security incident include an event leading to the loss of critical function to campus-wide or departmental wide user population.  Similarly, breach of covered data confidentiality affecting more than 500 users must also be assigned a high priority rating.  The incident priority level may be revised in later phases of the incident response process after additional evidence analysis provides a more accurate understanding of the incident’s impact.  Any update to priority level should be reviewed by local incident response team members, and an ISO Analyst.

The following table provides additional guidance on time commitment for the incident response team members in the event of a security incident (ISO Analyst, Incident Handler, Resource Manager):

* High priority cases may involve other stakeholders on campus, including IT Policy, Campus Counsel and other campus leadership representatives.

Incident response phase definitions[1]:

• Detection – This specifies the maximum amount of time that should elapse from when the suspicious event is detected to the time the following actions are expected to be completed:

  • Initial assessment and triage
  • Determine initial priority level based on intake report
  • Report Incident to ISO
  • ISO analyst is assigned to work with Incident Handler and Resource Manager
  • Enter incident into the ISO ticketing system
    
    

• Analysis - The period of time in the case lifecycle when active incident response is required in order to ensure the successful resolution of the case.  Typically this includes system or service outages, and/or urgent evidence preservation.  Incident is also verified to be legitimate, prioritization is confirmed and appropriate escalation made based on incident impact.   Typical activities include:

  • Assessment, triage, containment, evidence preservation, initial recovery

• Recovery - The period of time in the case lifecycle when active incident response is not required to successfully resolve the case.  Typical activities include:

  • Evidence collection, analysis and investigation, forensics, remediation, full recovery, post-mortem.

• Post-Incident  - After the incident is adequately handled, the incident response team issues a report that details the cause and cost of the incident and the steps the organization should take to prevent future incidents.

[1] Definitions are derived from http://www.first.org/_assets/resources/guides/csirt_case_classification....

Additional Resources

• NIST Computer Security Incident Handling Guide, http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

• Software Engineering Institute Handbook for Computer Security Incident Response Teams (CSIRTs),http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm

• Incident Response Plan TEMPLATE for individual systems and services 

• Campus Incident Response Plan