1.02.02 Security Incident Response Procedure

I. Purpose

This procedure documents Bradley University’s process of responding to confirmed malicious cyber activity for which a major incident has been declared or not yet been reasonably ruled out.

Policy Supported

Supports:

• 1.02 Security Incident Response
• National Institute of Standards and Technology (NIST) Special Publication (SP) 800-61
• National Institute of Standards and Technology (NIST) Special Publication (SP) 800-86
• National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF)
• Executive Order 14028

II. Description

Data Security Incident Response Technical Team:

The Data Security Incident Response Team shall include the following members:

First Level Escalation:

• Chief Information Security Officer
• Cybersecurity Engineer

Second Level Escalation:

• Chief Information Officer
• Director of Infrastructure
• Vice President for Legal Affairs and General Counsel
• Associate Vice President for Public Safety and Chief of Police

Initial Report of the incident:

• Upon being notified of an incident, any team member or other individual who is taking responsibility for reporting the incident shall notify the Chief Information Security Officer and provide all of the information that is currently known about the incident at the present time.

Process:

Detection and Analysis

1. Declare incident.
   1. Perform initial categorization of incident.
   2. Designate incident coordination lead (Chief Information Security Officer).
   3. Notify law enforcement, if applicable.
2. Determine investigation scope.
   1. Identify the type and extent of the incident.
   2. Assess operational or informational impact on organization’s mission.
3. Collect and preserve data.
   1. Collect and preserve the data necessary for incident verification, categorization, prioritization, mitigation, reporting, attribution, and as potential evidence in accordance with NIST 800-61r2.
   2. Log all evidence and note how the evidence was acquired, when it was acquired, and who acquired the evidence.
4. Perform technical analysis.
   1. Develop a technical and contextual understanding of the incident.
   2. Based on analysis thus far and available CTI, form a hypothesis of what the adversary was attempting to access/accomplish.
   3. Update scope as investigation progresses and information evolves. Report most recent findings and incident status to the Chief Information Officer.
   4. Terminating condition: Technical analysis is complete when the incident has been verified, the scope has been determined, the method(s) of persistent access to the network has/have been identified, the impact has been assessed, a hypothesis for the narrative of exploitation has been cultivated (TTPs and IOCs), and all stakeholders are proceeding with a common operating picture.
      Correlate events and document timeline.
   5. Analyze logs to correlate events and adversary activity.
   6. Establish an incident timeline that records events, description of events, datetime group (UTC) of occurrences, impacts, and data sources. Keep updated with all relevant findings.
      Identify anomalous activity.
   7. Assess affected systems and networks for subtleties of adversary behavior which often may look legitimate.
   8. Identify deviations from established baseline activity - particularly important to identify attempts to leverage legitimate credentials and native capabilities and tools (i.e., living off the land techniques).
      Identify root cause and enabling conditions.
   9. Attempt to identify the root cause of the incident and collect threat information that can be used in further searches and inform subsequent response efforts.
   10. Identify and document the conditions that enabled the adversary to access and operate within the environment.
   11. Assess networks and systems for changes that may have been made to either evade defenses or facilitate persistent access.
   12. Identify attack vector. This includes how the adversary accessed the environment (e.g., malware, RDP, VPN).
   13. Assess access (depth and breadth). This includes All compromised systems, users, services, and networks.
       Gather incident indicators.
   14. Review available CTI for precedent of similar activity.
   15. Analyze adversary tools. Assess tools to extract IOCs for short-term containment.
   16. Identify and document indicators that can be used for correlative analysis on the network.
   17. Share extracted threat information (atomic, computed, and behavioral indicators, context, and countermeasures) with internal response teams, REN-ISAC, and CISA.
       Analyze for common adversary TTPs.
   18. Identify initial access [TA0001] techniques (e.g., spearphishing, supply chain compromise).
   19. If access is facilitated by malware, identify associated command and control [TA0011] (e.g., identify port, protocol, profile, domain, IP address).
   20. Identify the techniques used by the adversary to achieve code execution [TA0002].
   21. Assess compromised hosts to identify persistence [TA0003] mechanisms.
   22. Identify lateral movement [TA0008] techniques. Determine the techniques used by the adversary to access remote hosts.
   23. Identify the adversary’s level of credential access [TA0006] and/or privilege escalation.
   24. Identify the method of remote access, credentials used to authenticate, and level of privilege. If access is by legitimate but compromised application (e.g., RDP, VPN), identify the method.
   25. Identify mechanism used for data exfiltration [TA0010].
       Validate and refine investigation scope.
   26. Identify new potentially impacted systems, devices, and associated accounts.
   27. Feed new IOCs and TTPs into detection tools.
   28. Continue to update the scope and communicate updated scope to all stakeholders to ensure a common operating picture.
5. Third-party analysis support (if needed).
   1. Identify if third-party analysis support is needed for incident investigation or response.
   2. Coordinate and facilitate access if incorporating third-party analysis support into response efforts.
   3. Coordinate response activities with agency service providers for systems hosted outside of the agency.
6. Adjust tools.
   1. Tune tools to slow the pace of advance and decrease dwell time by incorporating IOCs to protect/detect specific activity.
   2. Introduce higher-fidelity modifications to tools. Tune tools to focus on tactics that must be used by the adversary to obtain operational objectives (e.g., execution, credential access, and lateral movement).

Containment

7. Contain activity (short-term mitigations)
   1. Determine appropriate containment strategy, including:
      • Requirement to preserve evidence
      • Availability of services (e.g., network connectivity, services continuity)
      • Resource constraints
      • Duration of containment steps
   2. System backup(s) to preserve evidence and continued investigation.
   3. Coordinate with law enforcement to collect and preserve evidence (as required by (Step 3a) prior to eradication, if applicable.
   4. Isolate affected systems and networks including:
      • Perimeter containment
      • Internal network containment
      • Host-based/Endpoint containment
      • Temporarily disconnect public-facing systems from the Internet, etc.
   5. Close specific ports and mail servers. Update firewall filtering.
   6. Change system admin passwords, rotate private keys and service/application account secrets where compromise is suspected, revoke privileged access.
   7. Perform blocking (and logging) of unauthorized accesses, malware sources, and egress traffic to known attacker Internet Protocol (IP) addresses.
   8. Prevent Domain Name Server (DNS) resolution of known attacker domain names.
   9. Prevent compromised system(s) from connecting to other systems on the network.
   10. Advanced SOCs may direct adversary to sandbox to monitor activity, gather additional evidence, and identify TTPs.
   11. Monitor for signs of threat actor response to containment activities.
   12. Report updated timeline and findings (including new atomic and behavioral indicators) to CIO, REN-ISAC, and CISA.
   13. If new signs of compromise are found, return to technical analysis (Step 4) to re-scope the incident.
   14. Terminating condition: Upon successful containment (i.e., no new signs of compromise), preserve evidence for reference and law enforcement investigation (if applicable), adjust detection tools, and move to eradication.

Eradication and Recovery

8. Execute eradication plan.
   1. Develop a well-coordinated eradication plan that considers scenarios for threat actor use of alternative attack vectors and multiple persistence mechanisms.
   2. Provide incident status to CIO, REN-ISAC, and CISA until all eradication activities are complete.
   3. Remove artifacts of the incident from affected systems, networks, etc.
   4. Reimage affected systems from clean backups (i.e., ‘gold’ sources).
   5. Rebuild hardware (if rootkits involved).
   6. Scan for malware to ensure removal of malicious code.
   7. Monitor closely for signs of threat actor response to eradication activities.
   8. Allow adequate time to ensure all systems are clear of threat actor persistence mechanisms (such as backdoors) since adversaries often use more than one mechanism.
   9. Update the timeline to incorporate all pertinent events from this step.
   10. Complete all actions for eradication.
   11. Continue with detection and analysis activities after executing the eradication plan to monitor for any signs of adversary re-entry or use of new access methods.
   12. If new adversary activity is discovered at the completion of the eradication step, contain the new activity and return to Technical Analysis (Step 4) until the true scope of the compromise and infection vectors are identified.
   13. If eradication is successful, move to Recovery.
9. Recover systems and services.
   1. Restore agency systems to operational use: recovering mission/business data.
   2. Revert all changes made during incident.
   3. Reset passwords on compromised accounts.
   4. Install updates and patches.
   5. Tighten perimeter security (e.g., firewall rulesets, boundary router access control lists) and zero trust access rules.
   6. Test systems thoroughly (including security controls assessment) to validate systems are operating normally before bringing back online in production networks.
   7. Consider emulating adversarial TTPs to verify countermeasures are effective.
   8. Review all relevant CTI to ensure situational awareness of the threat actor activity.
   9. Update incident timeline to incorporate all pertinent events from Recovery step.

Post-Incident Activities

10. Post-Incident Activities
    1. Document the incident, inform agency leadership, harden the environment to prevent similar incidents, and apply lessons learned to improve the handling of future incidents.
       Adjust sensors, alerts, and log collection.
    2. Add enterprise-wide detections to mitigate against adversary TTPs that were successfully executed.
    3. Identify and address operational “blind spots” to adequate coverage moving forward.
    4. Continue to monitor the environment for evidence of persistent presence.
       Finalize Reports
    5. Provide post-incident updates as required by law and policy.
    6. Publish post-incident report. Provide a step-by-step review of the entire incident and answer the Who, What, Where, Why, and How questions.
       Perform Hotwash
    7. Conduct lessons learned analysis with all involved parties to assess existing security measures and the incident handling process recently experienced.
    8. Identify if IR processes were followed and if they were sufficient.
    9. Identify any policies and procedures in need of modification to prevent similar incidents from occurring.
    10. Identify how information sharing can be improved during IR.
    11. Identify any gaps in incident responder training.
    12. Identify any unclear or undefined roles, responsibilities, interfaces, and authorities.
    13. Identify precursors or indicators that should be monitored to detect similar incidents.
    14. Identify if infrastructure for defense was sufficient. If not, identify the gaps.
    15. Identify if additional tools or resources are needed to improve detection and analysis and help mitigate future incidents.
    16. Identify any deficiencies in the incident response planning process. If no deficiencies identified, identify how to implement more rigor in IR planning.

III. Scope

This procedure pertains to all devices, physical storage, and cloud storage containing Bradley University data. Incident Response policies and procedures for the financial side are outlined in the document “Credit Card Security Incident Response Plan,” which is documented by Bradley University Financial Services.

IV. Definitions

• CIO – Chief Information Officer
• CISA – Cybersecurity and Infrastructure Security Agency – Collaborates with industry and government partners to help organizations understand and counter critical infrastructure and cybersecurity risks associated with the malicious activities of nation-state and non-state actors.
• CISO – Chief Information Security Officer
• CTI – Cyber Threat Intelligence
• IOC – Indicator of Compromise
• IR – Incident Response
• RDP – Remote Desktop Protocol
• REN-ISAC – Research Education Networking Information Sharing and Analysis Center
• SOC – Security Operations Center
• TTP – Tactics, Techniques, and Procedures
• VPN – Virtual Private Network