Computer Science ISSC480 week 6 assignment

Instructions

Incident Response Report

This week's assignment we are going to produce an Incident Response report for a fictional attack against our organization Zenith City Water. Since it is fictional, you will instead use a recent attack against another water company as the stand-in for the organization.

Assignment Guidelines

Step 1: Obviously our first step is to locate a recent incident against another water company.

Step 2: Once you have found a water company that matches-up you will begin the process of filling out the Incident Report called Week6-Form Fillable.docx and you will use the guide called Week6-Assignment Guide.pdf as a companion instruction manual for filling out the report.

Step 3: Once you have completed the Incident Report save it and submit it.

Deliverables

The Word document, Week6-Form Fillable, that has been completed.

You will need to use the “Week6-Assignment Guide.pdf” to assist you in filling out this report.

You will fill out the following form using the incident you chose in Week 1.

Company Background Information

What is your main industry sector? ☐ Defense Industry ☐ Financial Services ☐ Healthcare ☐ Biotech/Pharmaceutical ☐ Food Production/Distribution ☐ Utilities (water, power, etc.) ☐ Transportation/port services ☐ Technology ☐ Energy Production (oil, natural gas, etc.) ☐ R&D/University ☐ Manufacturing ☐ Other ________________________

Does your organization consider itself to be a small, small-medium, medium-sized, or large business? ☐ Small Business (less than 100 employees) ☐ Small-Medium Business (100-999 employees) ☐ Medium-sized Business (1,000-9,999 employees) ☐ Large Business (10,000 employees or more)

How long has your organization been dedicating resources to cybersecurity? ☐ Started within the last year ☐ 1-3 years ☐ 3-5 years ☐ More than 5 years

Does your organization have someone responsible for cybersecurity/information security, such as a CISO (Chief Information Security Officer) or Chief Security Officer (CSO)?

☐ Yes

☐ No

Did your organization have someone responsible for cybersecurity/information security, such as a CISO (Chief Information Security Officer) or Chief Security Officer (CSO), at the time of the incident? ( Yes / No )

☐ Yes

☐ No

1 – Type of Incident

Please identify the major category description that best fits this incident. Check all that apply: ☐ Distributed Denial of Service (DDOS) ☐ Destructive WORM ☐ Ransomware/Extortion ☐ Data Theft ☐ Intellectual Property (IP) ☐ Personally Identifiable Information (PII) ☐ Financial Data ☐ Health Records ☐ Other type of data _______________ ☐ Unknown ☐ Web page defacement ☐ Malware (Variant, if known______________) ☐ Zero-Day Malware Attack ☐ SCADA or Industrial Control System Attack ☐ Accident/Human Error ☐ System Failure ☐ Natural or Man-made (Physical) Disaster ☐ Storage/Back-up Failure ☐ Network Intrusion ☐ Third-Party Event ☐ Phishing ☐ Industrial Espionage ☐ Physical Sabotage ☐ Configuration Error ☐ Insider Attack ☐ Lost Device ☐ Outage ☐ Other ☐ Additional Entry . . .

2 – Severity of Incident (See Assignment Guide Page 10 for charts)

Impact	Financial or Asset Loss	Time-to Market Delay	Product Quality	Environment	Health & Safety	Legal

Fill out the information in the columns above. Then using the charts on Page 10, specify the Impact level.

3 – Company Posture at Time of Incident

Does your organization use a cyber risk management framework, best practice, regulation or standard as part of its cyber risk management activities?

☐ Yes

☐ No

If Yes, please identify: _________________

If you are required to be certified compliant with a technical regulation or standard, how are you assessed?

☐ Self-Assessed ☐ Self-Assessed with Third-Party Validation ☐ Third-Party Assessment and Validation ☐ Post-Market Surveillance ☐ N/A: Not Required

Are your organization’s risk management practices formally approved and expressed as policy?

☐ Yes

☐ No

Are your organization’s cybersecurity practices regularly updated based on the application of risk management processes to changes in business/mission requirements and a changing threat and technology landscape?

☐ Yes

☐ No

Is cybersecurity integrated into your organization’s enterprise risk management?

☐ Yes

☐ No

Does your organization define risk-informed policies, processes, and procedures?

☐ Yes

☐ No

If Yes, are they implemented as intended

☐ Yes

☐ No

Are they reviewed?

☐ Yes

☐ No

Does your organization have methods in place to respond effectively to changes in risk?

☐ Yes

☐ No

Do your organization’s personnel possess the knowledge and skills to perform their appointed roles and responsibilities?

☐ Yes

☐ No

Does your organization understand its dependencies and partners and receive information from partners that enable collaboration and risk-based management decisions within your organization in response to events?

☐ Yes

☐ No

4 – Timeline of Incident

What is the interval between initial cyber intrusion to target or significant system compromise (including data records compromise)? ☐ Less than 4 hours (almost immediate) ☐ 4-24 hours (less than a day) ☐ 2-7 days (less than a week) ☐ 7-30 days (more than a week, but less than a month) ☐ 30-180 days (between 1 and 6 months) ☐ 180 days-365 days ( 6 months to a year) ☐ More than a year ☐ Unknown (initial date of intrusion, and/or system compromise undetermined

What is the interval between compromise and detection of the incident’s effects? ☐ Less than 4 hours (almost immediate) ☐ 4-24 hours (less than a day) ☐ 2-7 days (less than a week) ☐ 7-30 days (more than a week, but less than a month) ☐ 30-180 days (between 1 and 6 months) ☐ 180 days-365 days ( 6 months to a year) ☐ More than a year ☐ Unknown (initial date of intrusion, and/or system compromise undetermined

What is the interval between detection of the incident and containment/mitigation? ☐ Less than 4 hours (almost immediate) ☐ 4-24 hours (less than a day) ☐ 2-7 days (less than a week) ☐ 7-30 days (more than a week, but less than a month) ☐ 30-180 days (between 1 and 6 months) ☐ 180 days-365 days ( 6 months to a year) ☐ More than a year ☐ Unknown (initial date of intrusion, and/or system compromise undetermined

5 – Apparent Goal of Attackers

What was the attacker’s apparent end-state goal? Check all that apply.

☐ Acquisition/Theft – Illicit acquisition of valuable assets for resale or extortion in a way that preserves the assets’ integrity but may incidentally damage other items in the process.

☐ Business Advantage – Increased ability to compete in a market with a given set of products. The goal is to acquire business processes or assets.

☐ Technical Advantage – Illicit improvement of a specific product or production capability. The primary goal is to acquire production processes or assets rather than a business process.

☐ Damage to Property – Injury to the target organization’s physical/electronic assets, or intellectual property.

☐ Bodily Injury/Death – Injury to or death of the target organization’s personnel.

☐ Denial – Prevent the target organization from accessing necessary data or processes.

☐ Disruption of System/Service Availability – Interference with or degradation of the target organization’s legitimate business transactions.

☐ Production Loss – Reduction or halting of the target organization’s ability to create goods and services by damaging or destroying its means of production.

☐ Environmental Harm – Adverse impact to land, air, or water resources.

☐ Degradation of Reputation – Public portrayal of the target organization in an unflattering light, causing it to lose influence, credibility, competitiveness, or stock value.

☐ Unknown – Intent of the attack is not known.

☐ Not Applicable – Attack does not appear to have been an intentional/hostile incident.

☐ Additional Entry . . .

6 – Contributing Causes

Incident Progression	Step 1	Step 2	Step 3	Step 4	Step 5	Step 6
Intentionally caused or conducted by third party vendor	☐	☐	☐	☐	☐	☐
Unintentionally/negligently introduced through third party information sharing partner (e.g., link to an infected site, or poor protection of shared materials)	☐	☐	☐	☐	☐	☐
Third party vendor infrastructure (e.g., remote access connection)	☐	☐	☐	☐	☐	☐
Third party vendor account credentials	☐	☐	☐	☐	☐	☐
Data was under third party control when compromised	☐	☐	☐	☐	☐	☐
Direct access by Insider	☐	☐	☐	☐	☐	☐
Physical access by unauthorized personnel	☐	☐	☐	☐	☐	☐
Spear phishing email attachment	☐	☐	☐	☐	☐	☐
Spear phishing email link	☐	☐	☐	☐	☐	☐
Poor Passwords	☐	☐	☐	☐	☐	☐
Stolen Authorized Credentials	☐	☐	☐	☐	☐	☐
Employee Human Error in authorized procedure (e.g., distracted/multitasking, inadequate training)	☐	☐	☐	☐	☐	☐
Employee Human Error – unauthorized/reckless activity (system or authorization misuse, benign shortcuts, etc.).	☐	☐	☐	☐	☐	☐
Improper sensor tuning	☐	☐	☐	☐	☐	☐
Malicious Insider Activity	☐	☐	☐	☐	☐	☐
Unauthorized Device (e.g., personal laptop)	☐	☐	☐	☐	☐	☐
Misconfigured Device (firewall, router, switch)	☐	☐	☐	☐	☐	☐
Compromised mobile media (e.g. USB)	☐	☐	☐	☐	☐	☐
Compromised firmware	☐	☐	☐	☐	☐	☐
Known vulnerability not patched	☐	☐	☐	☐	☐	☐
Previously unknown vulnerability	☐	☐	☐	☐	☐	☐
Brute Force attack	☐	☐	☐	☐	☐	☐
Virus w/ A/V	☐	☐	☐	☐	☐	☐
Virus – No A/V	☐	☐	☐	☐	☐	☐
Zero-Day	☐	☐	☐	☐	☐	☐
Additional Entry…	☐	☐	☐	☐	☐	☐
Other:

7 – Specific Control Failures

Please identify the category of the involved security control as well as descriptors of the failure. Check all that apply:

Type of Security Control: ☐ Human ☐ Process ☐ Technology ☐ Environmental (e.g., facility power, cooling, natural disaster, etc.) ☐ Third Party

Level of Security Control: ☐ Network ☐ Business/Process Application ☐ System Control (SCADA/ICS) ☐ Data

Descriptor of the Failure: ☐ Poor Internal Security Processes ☐ Approaches/Tool Incompatible with All Platforms ☐ Improperly Tuned Sensor(s) ☐ Inadequate Maintenance/Patching Practices ☐ Working Control Failed to Prevent Incident and/or Attack ☐ Other ________________ ☐ Additional Entry . . .

8 – Assets Compromised or Affected

Please identify all assets that were affected by the compromise. Check all that apply: ☐ SCADA/ Industrial Control Systems (ICS) ☐ Databases ☐ Individual Accounts ☐ Business Application Servers ☐ Third Party Systems ☐ Websites (e.g., defacement) ☐ Structured Data (e.g., application/relational databases) ☐ Unstructured Data (e.g., office/individual’s files, PDFs, blueprints) ☐ Transactional Systems ☐ Decision Support Systems (including data warehouses) ☐ Building Management Systems ☐ Peripheral (e.g., USB, external hard drive) ☐ End-User Device (e.g., stolen iPad, phone, laptops) ☐ Data Center/Office Device (e.g., server, storage array, printer) ☐ Printed Hardcopy ☐ Other ☐ Additional Entry . . .

9 – Type of Impact(s)

Check all that apply:

What is the cybersecurity industry category affected? Check all that apply: ☐ Loss of confidentiality ☐ Loss of integrity ☐ Loss of availability

What is the amount of data compromised? ☐ 0-100,000 records/documents ☐ 100,001-500,000 records/documents ☐ 500,001-1,000,000 records/documents ☐ Over 1,000,000 records/documents ☐ Not Applicable

What is the duration of the experienced business interruption and/or outage? ☐ Less than one hour ☐ 1-3 hours ☐ 3-10 hours ☐ 10-24 hours ☐ 1-3 days ☐ 3-6 days ☐ Greater than one week

What is the sensitivity of the data involved? Check all that apply: ☐ Personally Identifiable Information (PII) ☐ Protected Health Information (PHI) ☐ Intellectual Property (IP) ☐ Credit Card Data ☐ Consumer Financial Data ☐ Employee Data ☐ Business Process Data (e.g., logistics information, trade secrets) ☐ Biometric Data ☐ Corporate Confidential Information ☐ Personal Confidential Information (e.g., an individual’s emails) ☐ Other _______________ ☐ Not Applicable ☐ Additional Entry . .

What was the actual outcome of the attack? Check all that apply: ☐ Acquisition/Theft – Illicit acquisition of valuable assets for resale or extortion. ☐ Business Advantage – Increased ability to compete in a market with a given set of products. ☐ Technical Advantage – Illicit improvement of a specific product or production capability. ☐ Damage to Property – Injury to the target organization’s physical or electronic assets, or intellectual property. ☐ Bodily Injury/Death – Injury to or death of the target organization’s personnel. ☐ Denial – Prevention of the target organization’s access to necessary data or processes. ☐ Disruption of System/Service Availability – Interference with or degradation of the target organization’s legitimate business transactions. ☐ Production Loss – Reduction or halting of the target organization’s ability to create goods and services by damaging or destroying its means of production. ☐ Environmental Harm – Adverse impact to land, air, or water resources. ☐ Degradation of Reputation – Public portrayal of the target organization in an unflattering light, causing it to lose influence, credibility, competitiveness, or stock value. ☐ No Apparent Impact – No impact has been detected or it is confirmed that the attack had no impact. ☐ Additional Entry . . .

10 – Incident Detection Techniques

If the incident was detected externally, how was the organization notified? Check all that apply: ☐ Not Applicable (Detected Internally) ☐ Disclosed by threat agent (e.g., extortion, public bragging) ☐ Compliance Audit ☐ Security/Vulnerability scan ☐ Emergency Response Team (e.g., ICS-CERT) ☐ Found Documents ☐ Fraud Detection (e.g., CPP) ☐ Notified while investigating separate incident ☐ Notified by law enforcement or government agency (what agency? __________________) ☐ Report of suspicious traffic ☐ Notified by partner/provider organization (select below) ☐ Antivirus Company (not AV product) ☐ Monitoring Service ☐ Audit Service ☐ Other _______________________ ☐ Additional Entry . . .

If the incident was detected internally, how was it detected? Check all that apply: ☐ Not applicable (Detected Externally) ☐ Host IDS or file integrity monitoring ☐ Informal IT review ☐ Network IDS or IPS alert ☐ Antivirus alert ☐ Vulnerability scan ☐ Data loss prevention software ☐ Financial audit/reconciliation process ☐ Analytics ☐ Fraud detection mechanism ☐ Discovered while responding to another (separate) incident ☐ Infrastructure monitoring ☐ External Threat Feed ☐ Log review process or SIEM ☐ Reported by employee who saw something odd ☐ Physical security system alarm ☐ Unknown ☐ Additional Entry . . .

11 – Incident Response Playbook

Please identify the tactics, techniques and procedures used to respond to the incident. Check all that apply: ☐ Blocking ☐ Install/update patch ☐ Change passwords ☐ Honeypot ☐ Sinkhole ☐ Isolation/segregation in the DMZ ☐ Disconnection ☐ Employ custom scripts for hunting ☐ Reconfigure network devices ☐ Direct personnel actions ☐ Re-tune Technical Controls ☐ Patch Management ☐ Other ____________________ ☐  Additional Entry . . .

12 – Internal Skill Sufficiency

Were internal skills sufficient?

☐ Yes

☐ No

What internal skills were employed? Check all that apply:

☐ Incident response coordination ☐ Forensics/investigations ☐ Response strategy development ☐ Technical skills ☐ Chain of custody/evidence management ☐ Systems analysis (e.g., correlation, event detection, log analyses) ☐ Enterprise architecture design ☐ Business impact assessment ☐ Malware analysis/reverse engineering ☐ Other __________ ☐ Additional Entry . . .

Does your organization outsource skills?

☐ Yes

☐ No

If yes, did the outsourcing work?

☐ Yes

☐ No

What external skills were employed? Check all that apply: ☐ Expert witness ☐ Incident response coordination ☐ Forensics/investigations ☐ Response strategy development ☐ Technical skills ☐ Chain of custody/evidence management ☐ Systems analysis (e.g., correlation, event detection, log analyses) ☐ Enterprise architecture ☐ Business impact assessment ☐ Malware analysis/reverse engineering ☐ Other __________ ☐ Additional Entry . . .

Does your organization have an incident response (IR) plan?

☐ Yes

☐ No

Does your organization have internal forensic capabilities?

☐ Yes

☐ No

Does your organization have a retainer for external forensic capabilities?

☐ Yes

☐ No

13 – Mitigation/Prevention Measures

Please identify which actions were taken to stop incidents and to prevent similar future occurrences. Check all that apply: ☐ Implemented New Policies/Procedures ☐ Conducted Training ☐ Performed Patch Management ☐ Corrected Configurations ☐ Installed Additional Authentication Measures ☐ Security Communications Program ☐ Revised Security Responsibilities. Check all that apply: ☐ Implemented new policies and procedures ☐ Formalized responsibility for security controls (e.g., documented and assigned) ☐ Added additional security solution to portfolio ☐ Engaged outside provider to support internal skill sets ☐ Other __________________ ☐ Additional Entry . . . ☐ Purchased Cybersecurity Insurance ☐ Engaged with a Third-party Vendor ☐ Deployed New Technology ☐ Captured Lessons Learned ☐ Additional Entry . . .

14 – Costs

COST CATEGORY	COST ($$$)
Direct Losses to Theft (e.g., Diverted Funds)
Liability Claims/ Restitution
Production Equipment Replacement
System Administrator Overtime
Third Party Assistance Costs (e.g., Investigation, Forensics)
Staff Augmentation During Response
Hardware/Equip (Replacement)
Hardware/Equip (New, as in additional sensors/controls)
System/ Software Installation
Production Delays
Backup Restoral
Business Interruption/Lost Transactions
Lost Wages/Lost Profits
Public Relations/Reputation
Victim Notification
Credit Monitoring
Legal Costs
PCI & Regulatory Fines/Assessments
Other _________________________
Additional Entry
Total Costs

15 – Vendor Incident Support

Vendor Type	1 Difficult to Source	2 Hostile / Combative	*3 Not Knowledgeable*	4 Indifferent / Unhelpful	5 Cooperative	6 Reasonably Helpful	7 Actively Helpful
Telco
IaaS Provider
Business Services Partner
Merchandise Supplier
Business App Provider / Host
POS System Provider
Utility (power, HVAC, etc.)
Forensic
Software
Hardware
Insurer
Additional Entry . . .

If you filed an insurance claim, was it accepted or denied?

☐ Accepted

☐ Denied

16 – Related Events

Has your organization experienced any recent events that may be related to the incident? Check all that apply: ☐ New Data Host (IaaS or SaaS Provider) ☐ New Software/Application Provider ☐ Corporate Merger/ Acquisition ☐ Corporate Lay-Offs / Downsizing ☐ Seasonal / Cyclical Event ☐ Geopolitical / Regional Event ☐ Disgruntled Employee(s)/Strike ☐ Industry Sector-Wide Attacks ☐ New Product Release/Pre-Release ☐ Recent Event/Bad Publicity (e.g., Environmental Impact, Scandal) ☐ New Corporate Policy Release (i.e., with Social/Economic Implications) ☐ Natural Disasters ☐ Operation / Campaign ☐ C-Suite Level Public Remarks Additional Entry . . .

Module 9 Incident Response

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Lesson Objectives

List some common types of incidents that may occur in SCADA/ICS systems.

Identify the phases of an Incident Response, as described in NIST SP 800-61.

Define incident containment and describe how it is applied to an incident.

Discuss the IR reaction strategies unique to each category of incident.

Explain the components of an Incident Response Plan.

Identify the 14 response core capabilities covered in the National Response Framework.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

SCADA/ICS Common Incidents

NIST SP 800-82 Guide to Industrial Control Systems (ICS) Security, describes three broad categories of ICS incidents:

Intentional targeted attacks, such as gaining unauthorized access to files, performing a DoS, or spoofing emails (i.e., forging the sender’s identity for an email)

Unintentional consequences or collateral damage from worms, viruses, or control system failures

Unintentional internal security consequences, such as inappropriate testing of operational systems or unauthorized system configuration changes

Of the three, targeted attacks are the least frequent but the most damaging.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

From NIST SP 800-82 Guide to Industrial Control Systems (ICS) Security:

Control systems operation disrupted by delaying or blocking the flow of information through corporate or control networks, thereby denying availability of the networks to control system operators or causing information transfer bottlenecks or denial of service by IT-resident services (such as DNS)

Unauthorized changes made to programmed instructions in PLCs, RTUs, DCS, or SCADA controllers, alarm thresholds changed, or unauthorized commands issued to control equipment, which could potentially result in damage to equipment (if tolerances are exceeded), premature shutdown of processes (such as prematurely shutting down transmission lines), causing an environmental incident, or even disabling control equipment

Control system software or configuration settings modified, producing unpredictable results

Safety systems operation interfered with

Malicious software (e.g., virus, worm, trojan horse) introduced into the system

Example of Intentional Attack

Maroochy Water Services Incident. In the spring of 2000, a former employee of an Australian organization that develops manufacturing software applied for a job with the local government but was rejected. Over a two-month period, the disgruntled rejected employee reportedly used a radio transmitter on as many as 46 occasions to remotely break into the controls of a sewage treatment system. He altered electronic data for particular sewerage pumping stations and caused malfunctions in their operations, ultimately releasing about 264,000 gallons of raw sewage into nearby rivers and parks.

— NIST SP 800-82

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Additional information on the Maroochy Water Services Incident can be found at: http://www.theregister.co.uk/2001/10/31/hacker_jailed_for_revenge_sewage/.

“pipe-dune-sand-water-sea-waste-1721735” by quicksandala CC0 Public Domain via Pixabay. https://pixabay.com/en/pipe-dune-sand-water-sea-waste-1721735/

Example of Unintentional Consequences

Davis-Besse. In August 2003, the Nuclear Regulatory Commission confirmed that in January 2003, the Microsoft SQL Server worm known as Slammer infected a private computer network at the idled Davis-Besse nuclear power plant in Oak Harbor, Ohio, disabling a safety monitoring system for nearly five hours. In addition, the plant’s process computer failed, and it took about six hours for it to become available again. Slammer reportedly also affected communications on the control networks of at least five other utilities by propagating so quickly that control system traffic was blocked.

— NIST SP 800-82

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Slammer spread at a rate 250 times faster than Code Red, scanning approximately 55 million systems per second within 3 minutes of its release, doubling its rate of infection every 8.5 seconds. Within 10 minutes, 90% of vulnerable hosts were infected worldwide.

Additional information on the Davis-Besse incident can found at http://www.securityfocus.com/news/6767.

Example of Unintentional Internal Security Consequences

Penetration testing incident. A natural gas utility hired an IT security consulting organization to conduct penetration testing on its corporate IT network. The consulting organization carelessly ventured into a part of the network that was directly connected to the SCADA system. The penetration test locked up the SCADA system, and the utility was not able to send gas through its pipelines for four hours. The outcome was the loss of service to its customer base for those four hours.

— NIST SP 800-82

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

This is the same incident as was mentioned on Slide 29 of the PowerPoint presentation for Lesson 6, Vulnerabilities.

“Wildflowers And Pipeline” by Ken Kistler via publicdomainpictures.net. http://www.publicdomainpictures.net/view-image.php?image=88047&picture=polne-kwiaty-i-pipeline CC0 1.0 https://creativecommons.org/publicdomain/zero/1.0/

Incident Response Phases

NIST SP 800-61 Computer Security Incident Handling Guide

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Figure 3-1. Incident Response Life Cycle

Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012). Computer Security Incident Handling Guide : Recommendations of the National Institute of Standards and Technology (No. NIST SP 800-61r2). National Institute of Standards and Technology, U.S. Dept. of Commerce. Retrieved from http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.

This figure, from NIST’s SP 800-61 Computer Security Incident Handling Guide, describes the phases involved with incident response. The initial phase involves establishing and training an incident response team, and acquiring the necessary tools and resources. During preparation, the organization also attempts to limit the number of incidents that will occur by selecting and implementing a set of controls based on the results of risk assessments. However, residual risk will inevitably persist after controls are implemented. Detection of security breaches is thus necessary to alert the organization whenever incidents occur. In keeping with the severity of the incident, the organization can mitigate the impact of the incident by containing it 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. After the incident is adequately handled, the organization issues a report that details the cause and cost of the incident and the steps the organization should take to prevent future incidents.

Incident Response Phases — Preparation

Emphasizes both preparation (developing Incident Response Plan) and capabilities (team, etc.) but also prevention.

Preparation includes:

Communication equipment and processes for team members (war room, secure storage facility)

Investigation hardware and software (forensic software, protocol analyzers, assembled “jump kit,” forensic workstation)

Analysis resources (current baselines, authorized ports and protocols, asset inventories, cryptographic hashes of critical files)

Incident mitigation software (approved images and clean OS, and applications for restoration)

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

From the SP 800-61: “Many incident response teams create a jump kit, which is a portable case that contains materials that may be needed during an investigation. The jump kit should be ready to go at all times. Jump kits contain many of the same items listed in the bulleted lists above. For example, each jump kit typically includes a laptop, loaded with appropriate software (e.g., packet sniffers, digital forensics). Other important materials include backup devices, blank media, and basic networking equipment and cables. Because the purpose of having a jump kit is to facilitate faster responses, the team should avoid borrowing items from the jump kit.

Each incident handler should have access to at least two computing devices (e.g., laptops). One, such as the one from the jump kit, should be used to perform packet sniffing, malware analysis, and all other actions that risk contaminating the laptop that performs them. This laptop should be scrubbed and all software reinstalled before it is used for another incident. Note that because this laptop is for a special purpose, it is likely to use software other than the standard enterprise tools and configurations. Whenever possible, the incident handlers should be allowed to specify basic technical requirements for these special-purpose investigative laptops. In addition to an investigative laptop, each incident handler should also have a standard laptop, smart phone, or other computing device for writing reports, reading email, and performing other duties unrelated to the hands-on incident analysis.

Exercises involving simulated incidents can also be very useful for preparing staff for incident handling; see NIST SP 800-84 for more information on exercises and Appendix A for sample exercise scenarios. “

Incident Response Phases — Prevention

Prevention also includes:

Risk assessments – Perform periodic risk assessments of systems and applications, prioritizing risk mitigation activities according to criticality.

Host security – Harden (secure) hosts to standard configuration, using the “principle of least permission.”

Network security – Secure the network perimeter to deny all unauthorized approved connections.

Malware prevention – Deploy antivirus software at severs and hosts (as well as on applications, such as email serves and web proxies).

User awareness and training – Train over policies and procedures.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012). Computer Security Incident Handling Guide : Recommendations of the National Institute of Standards and Technology (No. NIST SP 800-61r2). National Institute of Standards and Technology, U.S. Dept of Commerce. Retrieved from http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

From the SP 800-61:

Risk Assessments. Periodic risk assessments of systems and applications should determine what risks are posed by combinations of threats and vulnerabilities.25 This should include understanding the applicable threats, including organization-specific threats. Each risk should be prioritized, and the risks can be mitigated, transferred, or accepted until a reasonable overall level of risk is reached. Another benefit of conducting risk assessments regularly is that critical resources are identified, allowing staff to emphasize monitoring and response activities for those resources.

Host Security. All hosts should be hardened appropriately using standard configurations. In addition to keeping each host properly patched, hosts should be configured to follow the principle of least privilege—granting users only the privileges necessary for performing their authorized tasks. Hosts should have auditing enabled and should log significant security-related events. The security of hosts and their configurations should be continuously monitored. Many organizations use Security Content Automation Protocol (SCAP) 28 expressed operating system and application configuration checklists to assist in securing hosts consistently and effectively.

Network Security. The network perimeter should be configured to deny all activity that is not expressly permitted. This includes securing all connection points, such as virtual private networks (VPNs) and dedicated connections to other organizations.

Malware Prevention. Software to detect and stop malware should be deployed throughout the organization. Malware protection should be deployed at the host level (e.g., server and workstation operating systems), the application server level (e.g., email server, web proxies), and the application client level (e.g., email clients, instant messaging clients).

User Awareness and Training. Users should be made aware of policies and procedures regarding appropriate use of networks, systems, and applications. Applicable lessons learned from previous incidents should also be shared with users so they can see how their actions could affect the organization. Improving user awareness regarding incidents should reduce the frequency of incidents. IT staff should be trained so that they can maintain their networks, systems, and applications in accordance with the organization’s security standards.

Detection and Analysis Visual Overview

NIST SP 800-61, Computer Security Incident Handling Guide

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Figure 3-2. Incident Response Life Cycle (Detection and Analysis)

Organizations should be prepared to handle any incident; however, they should emphasize training on incidents that use common attack vectors or were identified in the risk assessment as being more likely to occur or have a greater impact if they did occur. Common attack vectors include:

External/Removable Media: An attack executed from removable media or a peripheral device—for example, malicious code spreading onto a system from an infected USB flash drive.

Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services (e.g., a DDoS intended to impair or deny access to a service or application; a brute force attack against an authentication mechanism, such as passwords, CAPTCHAS, or digital signatures).

Web: An attack executed from a website or web-based application—for example, a cross-site scripting attack used to steal credentials or a redirect to a site that exploits a browser vulnerability and installs malware.

Email: An attack executed via an email message or attachment—for example, exploit code disguised as an attached document or a link to a malicious website in the body of an email message.

Impersonation: An attack involving replacement of something benign with something malicious. For example, spoofing, Man-in-the-Middle attacks, rogue wireless access points, and SQL injection attacks all involve impersonation.

Improper Usage: Any incident resulting from violation of an organization’s acceptable usage policies by an authorized user, excluding the above categories; for example, a user installs file sharing software, leading to the loss of sensitive data, or a user performs illegal activities on a system.

Loss or Theft of Equipment: The loss or theft of a computing device or media used by the organization, such as a laptop, smartphone, or authentication token.

Other: An attack that does not fit into any of the other categories.

Incident Response Phases – Detection Challenges

Challenges to accurately detecting that an incident has occurred include:

Large number of detection methods, including network- or host-based IDS/IPSs, antivirus software, firewalls, protocol analyzers, etc., reporting using different formats that may not be easily aggregated.

Signs of potential signs of incidents can be high (IDSs may receive thousands or even millions of intrusion detection sensor alerts per day).

Deep, specialized technical knowledge and extensive experience required for efficient analysis of incident-related data

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61 Computer Security Incident Handling Guide:

Incident Response Phases — Detection Precursors

Signs of an incident fall under two categories: precursors and indicators.

A precursor is a sign that an incident may occur in the future. Examples of precursors include:

Log entries that show usage of vulnerability scanners

Announcements of software vulnerabilities in use

Threats from groups stating they will attack the organization

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Incident Response Phases — Detection Indicators

Signs of an incident fall under two categories: precursors and indicators.

An indicator is a sign that an incident may have occurred or may be occurring now. Examples of indicators include:

IDS sensors alert to buffer overflow or SQL injection attacks against a server

Antivirus software detects malware

Filenames with unusual characters

Missing records in audit logs

Failed login attempts

Bounced emails with suspicious content

Unusual traffic flows

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Incident Response Phases – Detection Alerts

Common Sources of Precursors and Indicators: Alerts

Source	Description
Intrusion Detection and Prevention Systems (IDPSs)	IDPSs identify suspicious events and record date and time of the attack, type of attack, source and destination IP addresses, and username
Security Information and Event Management (SIEM)	Similar to IDPS, but generate alerts on aggregated log data
Antivirus and antispam software	Malware, spam
File and integrity checking software	Detects changes made to files
Third-party monitoring services	Subscription-based and free monitoring services (fraud detection services that notify if an IP address, domain name, etc. is associated with current activity)

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Incident Response Phases – Detection Logs

Common Sources of Precursors and Indicators Logs & Publically Available Information

Source	Description
Operating system, application, service logs	Audit-related data recording what was accessed, accounts used, actions performed
Network device logs	Logs from firewalls, routers that can indicate trends or correlate events
Network flows	Communication session between hosts
Information on new vulnerabilities and exploits	The National Vulnerability Database (NVD) contains information on vulnerabilities.32 Organizations such as US-CERT33 and CERT®/CC periodically provide threat update information through briefings, web postings, and mailing lists.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Incident Response Phases – Detection People

Common Sources of Precursors and Indicators: People

Source	Description
People from within the organization	Users, system administrators, network administrators, security staff, and others from within the organization may report signs of incidents.
People from other organizations	The organization might be contacted by a party claiming a system at the organization is attacking its systems. External users may also report other indicators, such as a defaced web page or an unavailable service. Other incident response teams also may report incidents.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Incident Response Phases – Analysis

The Incident Response Team should work quickly to analyze and validate incidents, following a predefined process and documenting each step taken.

When the team believes that an incident has occurred, the team should rapidly perform an initial analysis to determine the incident’s scope, such as which networks, systems, or applications are affected; who or what originated the incident; and how the incident is occurring (e.g., what tools or attack methods are being used, what vulnerabilities are being exploited).

The initial analysis should provide enough information for the team to prioritize subsequent activities, such as containment of the incident and deeper analysis of the effects of the incident.

Logbooks, laptops, audio recorders, and digital cameras can be used to document the response.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

The issue tracking system should contain information on the following:

The current status of the incident (new, in progress, forwarded for investigation, resolved, etc.)

A summary of the incident

Indicators related to the incident

Other incidents related to this incident

Actions taken by all incident handlers on this incident

Chain of custody, if applicable

Impact assessments related to the incident

Contact information for other involved parties (e.g., system owners, system administrators)

A list of evidence gathered during the incident investigation

Comments from incident handlers

Next steps to be taken (e.g., rebuild the host, upgrade an application)

Incident Response Phases – Analysis (cont.)

Prioritization is the most critical decision point in the process. Decisions are based on

Functional impact of the incident

Information impact of the incident

Recoverability from the incident

Organizations should identify target timeframes for response and establish an escalation process for instances in which the team responds within the designated time.

Incident response times should identify the appropriate individuals who would need to be involved on the team.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Functional impact of the incident. Incidents targeting IT systems typically impact the business functionality that those systems provide, resulting in some type of negative impact to the users of those systems. Incident handlers should consider how the incident will impact the existing functionality of the affected systems. Incident handlers should consider not only the current functional impact of the incident but also the likely future functional impact of the incident if it is not immediately contained.

Information impact of the incident. Incidents may affect the confidentiality, integrity, and availability of the organization’s information. For example, a malicious agent may exfiltrate sensitive information. Incident handlers should consider how this information exfiltration will impact the organization’s overall mission. An incident that results in the exfiltration of sensitive information may also affect other organizations if any of the data pertain to a partner organization.

Recoverability from the incident. The size of the incident and the type of resources it affects will determine the amount of time and resources that must be spent on recovering from that incident. In some instances it is not possible to recover from an incident (e.g., if the confidentiality of sensitive information has been compromised) and it would not make sense to spend limited resources on an elongated incident handling cycle, unless that effort was directed at ensuring that a similar incident did not occur in the future. In other cases, an incident may require far more resources to handle than what an organization has available. Incident handlers should consider the effort necessary to actually recover from an incident and carefully weigh that against the value the recovery effort will create and any requirements related to incident handling.

Incident Response Phases – Containment

NIST SP 800-61, Computer Security Incident Handling Guide

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Figure 3-3. Incident Response Life Cycle (Containment, Eradication, and Recovery)

Containment is important before an incident overwhelms resources or increases damage. Most incidents require containment, so that is an important consideration early in the course of handling each incident. Containment provides time for developing a tailored remediation strategy. An essential part of containment is decision-making (e.g., shut down a system, disconnect it from a network, disable certain functions). Such decisions are much easier to make if there are predetermined strategies and procedures for containing the incident. Organizations should define acceptable risks in dealing with incidents and develop strategies accordingly.

Incident Response Phases — Containment Strategies

Strategies will differ depending on the type of incident and will include consideration of the following criteria:

Potential damage to and theft of resources

Need for evidence preservation

Service availability (e.g. network connectivity, services provided)

Time and resources needed to implement the strategy

Effectiveness of the strategy (partial containment)

Duration of the solution (is it an emergency workaround or permanent solution?)

Be aware that some attacks may cause additional damage when they are contained (e.g., deletion of files).

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Incident Response Phases — Containment Evidence

Evidence Gathering and Handling

Evidence should be gathered as soon as possible after a suspected incident

Maintain a “chain of custody” and logs containing the following:

Identifying information (e.g., the location, serial number, model number, hostname, media access control (MAC) addresses, and IP addresses of a computer)

Name, title, and phone number of each individual who collected or handled the evidence during the investigation

Time and date (including time zone) of each occurrence of evidence handling

Locations where the evidence was stored.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Incident Response Phases — Containment Identification

Identifying Attacking Hosts

Validate the attacker’s IP address

Research the attacking host through search engines

Use incident databases and threat intelligence sources

Monitor possible attacker communication channels

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Validate the attacking host’s IP address. New incident handlers often focus on the attacking host’s IP address. The handler may attempt to validate that the address was not spoofed by verifying connectivity to it; however, this simply indicates that a host at that address does or does not respond to the requests. A failure to respond does not mean the address is not real—for example, a host may be configured to ignore pings and traceroutes. Also, the attacker may have received a dynamic address that has already been reassigned to someone else.

Research the attacking host through search engines. Performing an Internet search using the apparent source IP address of an attack may lead to more information on the attack—for example, a mailing list message regarding a similar attack.

Use incident databases and threat intelligence sources. Several groups collect and consolidate incident data from various organizations into incident databases. This information-sharing may take place in many forms, such as trackers and real-time blacklists. The organization can also check its own knowledge base or issue tracking system for related activity.

Monitor possible attacker communication channels. Incident handlers can monitor communication channels that may be used by an attacking host. For example, many bots use IRC as their primary means of communication. Also, attackers may congregate on certain IRC channels to brag about their compromises and share information. However, incident handlers should treat any such information that they acquire only as a potential lead, not as fact.

Incident Response Phases — Containment Recovery

Eradication and Recovery

Eradication eliminates components of the incident (deleting malware and disabling breached accounts, identifying and mitigating all vulnerabilities that were exploited)

During recovery, systems are restored to normal operation and validated that they are functioning normally

Should be done in a phased approach and could be long-term, ensuring that changes are made to increase overall security and prevent future incidents

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Incident Response Phases – Post-Incident Activity

NIST SP 800-61, Computer Security Incident Handling Guide

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Figure 3-4. Incident Response Life Cycle (Post-Incident Activity)

Incident Response Phases – Post-Incident Activity Lessons Learned

Team should meet to discuss “lessons learned” after the end of the incident, addressing the following:

Exactly what happened, and at what times?

How well did staff and management perform in dealing with the incident? Were the documented procedures followed? Were they adequate?

What information was needed sooner?

Were any steps or actions taken that might have inhibited the recovery?

What would the staff and management do differently the next time a similar incident occurs?

How could information sharing with other organizations have been improved?

What corrective actions can prevent similar incidents in the future?

What precursors or indicators should be watched for in the future to detect similar incidents

What additional tools or resources are needed to detect, analyze, and mitigate future incidents?

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Incident Response Phases – Post-Incident Activity Incident Data & Retention

Using Collected Incident Data

Collected data should be used to trend costs, response time, and other actionable metrics. Possible metrics include:

Number of incidents handled

Time per incident

Objective assessment of each incident

Subjective assessment of each incident

Evidence Retention

Organizations should establish a policy addressing how long evidence should be retained, based on the possibility of prosecution and regulations governing data retention.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

NIST SP 800-61, Computer Security Incident Handling Guide:

Number of incidents handled. Handling more incidents is not necessarily better—for example, the number of incidents handled may decrease because of better network and host security controls, not because of negligence by the incident response team. The number of incidents handled is best taken as a measure of the relative amount of work that the incident response team had to perform, not as a measure of the quality of the team, unless it is considered in the context of other measures that collectively give an indication of work quality. It is more effective to produce separate incident counts for each incident category. Subcategories also can be used to provide more information. For example, a growing number of incidents performed by insiders could prompt stronger policy provisions concerning background investigations for personnel and misuse of computing resources and stronger security controls on internal networks (e.g., deploying intrusion detection software to more internal networks and hosts).

Time per incident. For each incident, time can be measured in several ways:

Total amount of labor spent working on the incident;

Elapsed time from the beginning of the incident to incident discovery, to the initial impact assessment, and to each stage of the incident handling process (e.g., containment, recovery);

How long it took the incident response team to respond to the initial report of the incident

How long it took to report the incident to management and, if necessary, appropriate external entities (e.g., US-CERT).

Objective assessment of each incident. The response to an incident that has been resolved can be analyzed to determine how effective it was. The following are examples of performing an objective assessment of an incident:

– Reviewing logs, forms, reports, and other incident documentation for adherence to established incident response policies and procedures

– Identifying which precursors and indicators of the incident were recorded to determine how effectively the incident was logged and identified

– Determining if the incident caused damage before it was detected

– Determining if the actual cause of the incident was identified, and identifying the vector of attack, the vulnerabilities exploited, and the characteristics of the targeted or victimized systems, networks, and applications

– Determining if the incident is a recurrence of a previous incident

– Calculating the estimated monetary damage from the incident (e.g., information and critical business processes negatively affected by the incident)

– Measuring the difference between the initial impact assessment and the final impact assessment

– Identifying which measures, if any, could have prevented the incident.

Subjective assessment of each incident. Incident response team members may be asked to assess their own performance, as well as that of other team members and of the entire team. Another valuable source of input is the owner of a resource that was attacked, in order to determine if the owner thinks the incident was handled efficiently and if the outcome was satisfactory.

Besides using these metrics to measure the team’s success, organizations may also find it useful to periodically audit their incident response programs. Audits will identify problems and deficiencies that can then be corrected. At a minimum, an incident response audit should evaluate the following items against applicable regulations, policies, and generally accepted practices:

Incident response policies, plans, and procedures

Tools and resources

Team model and structure

Incident handler training and education

Incident documentation and reports

The measures of success discussed earlier in this section.

Incident Response Resources

The National Institute of Standards and Technology (NIST) has developed several guides and publications addressing cybersecurity in general and incident response in particular. Several specific documents on incident handling and response include:

NIST SP 800-40, Creating a Patch and Vulnerability Management Program

NIST SP 800-61, Computer Security Incident Handling Guide

NIST SP 800-83, Guide to Malware Incident Prevention and Handling

NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response

NIST SP 800-92, Guide to Computer Security Log Management

While these documents have a traditional IT orientation, they provide guidance for implementing ICS incident response policies and procedures as well.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

ICS Cyber Incident Response Plan

DHS ICS-CERT is chartered to reduce risks across all critical infrastructure sectors and works with the U.S. Computer Emergency Readiness Team (US-CERT), but with an ICS focus. The organization provides products and services to reduce security risks to ICS asset owners, including best practices, self assessment tools, ICS security documents, and incident response guidance.

The ICS Cyber Incident Response Plan presents recommendations to help those facilities that use control systems better prepare for and respond to cyber incidents, regardless of source. The document also suggests ways to learn from incidents and to strengthen systems against potential attacks. The document includes accepted methods and approaches from tradition information technology, but it is primarily focused on the unique aspects of industrial control systems

The ICS Cyber Incident Response Plan document augments the NIST SP 800-61 document to provide ICS-specific response recommendations, including recommendations for building the Cyber Incident Response Plan.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Department of Homeland Security. Developing an Industrial Control Systems Cybersecurity Incident Response Capability – final. Published October 2009. Retrieved December 7, 2016, from https://ics-cert.us-cert.gov/sites/default/files/recommended_practices/final-RP_ics_cybersecurity_incident_response_100609.pdf/

The Department of Homeland Security ICS-CERT is chartered to reduce control system cybersecurity risks within and across all critical infrastructure sectors. This program works in coordination with the DHS-created United States Computer Emergency Readiness Team (US-CERT) with regard to cybersecurity but with an ICS focus. Supporting the ICS-CERT are expert staff that are familiar with vulnerabilities, intrusion techniques and tools, and methods to prevent or mitigate ICS incidents. They are current on cyber attack methods and preventive techniques. In addition, the Control Systems Security Program (CSSP) provides products and services to reduce security risks to ICS asset owners. Other products and services include recommended practices, self assessment tools, ICS security documents, procurement recommendations, and standards support. CSSP information can be found at

http://www.us-cert.gov/control_systems/index.html.

Creating the ICS Cyber Incident Response Plan

The following sections should be included when creating an Incident Response Plan:

Section	Content
1. Overview, Goals, and Objectives	Provides guidance for the overall business objective in comparison to the response options to the incident
2. Incident Description	Classification of different incident types (Denial-of-Service, unauthorized access, website defacement, etc.)
3. Incident Detection	Addresses the way an ICS incident is identified and reported and will include any automated analysis tools, system behavior patterns, and an awareness of what to look for among operators, supervisors, and other staff.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

With ICS, differentiating between cyber-based incidents and those caused by other sources is critical. For example, the reaction to equipment damaged by a disgruntled employee with a crowbar would be vastly different than damage to the same piece of equipment caused by an unknown attacker who manipulated controls on the equipment. It’s important to identify and define each incident type so that the appropriate response can be followed for that unique situation.

https://ics-cert.us-cert.gov/sites/default/files/recommended_practices/final-RP_ics_cybersecurity_incident_response_100609.pdf

Creating the ICS Cyber Incident Response Plan (cont. 1)

Section	Content
4. Incident Notification	This section should address how an event is prioritized to determine the cause and criticality, and possible immediate escalation. It should include contact information for IR Team members, regulatory authorities, and ICS-CERT/US-CERT.
5. Incident Analysis	Addresses how to evaluate and analyze a reported incident, including its potential to spread to other systems.
6. Response Actions	Defines the procedures that staff will follow for each type of detected incident.
7. Communications	Should include all contacts (media, emergency responders, civil authorities) and a POC who can speak for the organization, as well as a list of alternate physical methods to handle impaired communications.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Information included in the table, is located on pages 10-12, Department of Homeland Security. Developing an Industrial Control Systems Cybersecurity Incident Response Capability – final. Published October 2009. Retrieved December 7, 2016, from https://ics-cert.us-cert.gov/sites/default/files/recommended_practices/final-RP_ics_cybersecurity_incident_response_100609.pdf. Note to instructors: Students can reference the full document and familiarize themselves with the details that would be included in the plan.

Creating the ICS Cyber Incident Response Plan (cont. 2)

Section	Content
8. Forensics	This section should address the process for collecting, examining, and analyzing incident data, as well as protecting incriminating evidence for use in possible legal action. Recommended practices specific to ICS can be found at “Recommended Practice: Creating Cyber Forensics Plans for Control Systems,” August 25, 2008, Control Systems Security Program (CSSP), Department of Homeland Security at the US-CERT website.
9. Additional Sections	The areas mentioned above are essential elements of the incident response plan. The plan may be divided into more detailed topics, if desired, and may include other sections, such as incident tracking and reporting, as necessary.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

https://ics-cert.us-cert.gov/sites/default/files/recommended_practices/final-RP_ics_cybersecurity_incident_response_100609.pdf. Note to instructors: Students can reference the full document and familiarize themselves with the details that would be included in the plan.

Exercising the Incident Response Plan

Incident Response Plans should be exercised on a periodic basis in order to identify weak areas that can be improved and to train staff on response procedures.

Partial testing can be performed prior to a full test; it can serve as a good training exercise for IR Team members without risking the possible disruption of a full test.

Exercises should mimic real-world scenarios and simulate worst-case scenarios. The drill should involve all staff who would be involved in the response.

Drills should be held periodically as staff change, changes in the facility or equipment occur, or new threats are identified.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

https://ics-cert.us-cert.gov/sites/default/files/recommended_practices/final-RP_ics_cybersecurity_incident_response_100609.pdf

National Response Framework

In addition to how a company response to its own incident, consideration should be given to how our nation responds to disasters and emergencies.

DHS’s National Response Framework describes specific authorities and best practices for managing incidents, such as large-scale terrorist attacks or catastrophic national disasters.

The National Response Framework (pdf) is a living document, always in effect, and elements can be implemented at any time.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

National Response Framework: Core Capabilities

14 Response Core Capabilities are identified – 11 that apply to response and 3 that are common to all five mission areas: Prevention, Protection, Mitigation, Response, and Recovery.

Core Capability	Objective Summaries
1. Planning (common to all mission areas)	Engage the community in the development of strategic, operational, community-based response approaches.
2. Public Information and Warning (common to all mission areas)	Deliver coordinated, prompt, reliable, and actionable information to the entire community, relaying information on threats and hazards.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Core capabilities are distinct critical elements necessary to achieve the goal. They provide a common vocabulary describing the significant functions that must be developed and executed across the whole community to ensure national preparedness.

Three response core capabilities—Planning, Public Information and Warning, and Operational Coordination—span all five mission areas. These common core capabilities are essential to the success of the other core capabilities. They help establish unity of effort among all those involved in the Response mission area.

Planning. Planning makes it possible to manage the life cycle of a potential crisis, determine capability requirements, and help stakeholders learn their roles. It includes the collection, analysis, and dissemination of risk assessment data and the development of plans, procedures, mutual aid and assistance agreements, strategies, and other arrangements to perform specific missions and tasks. Governments at all levels have a responsibility to develop all-hazards response plans prior to and during an incident. Including a broad range of partners in the planning process helps ensure that the needs and potential contributions of all elements are integrated into workable plans.

Public Information and Warning. For an effective response, jurisdictions must provide accurate and accessible information to decision-makers and the public. This includes development of accessible message content, such as incident facts, health risk warnings, pre-incident recommendations, evacuation guidance, and other protective measures. It also includes developing strategies for when, where, how, and by whom information will be delivered and ensuring that all levels of government agree on unified messages. Information must be shared with the public and other members of the response community efficiently, effectively, and in an accessible manner. Effective public information and warning is particularly important in dealing with incidents that start small but may evolve to have greater consequences.

Operational Coordination. For incident response, coordination of operations must occur both among those tasked to deliver the various response core capabilities and with those delivering the core capabilities of other mission areas. This coordination occurs through response structures based on clearly established roles, responsibilities, and reporting protocols. Using NIMS principles, structures, and coordinating processes enhances the efficiency and effectiveness of response. Specific actions to achieve this core capability may include coordinating initial actions, managing ESFs, coordinating requests for additional support, and identifying and integrating resources and capabilities.

National Response Framework: Core Capabilities (cont. 1)

Core Capability	Objective Summaries
3. Operational Coordination (common to all mission areas)	Establish and maintain a unified and coordinated operational structure and process.
4. Critical Transportation	Provide transportation for response objectives (including evacuation of people and animals, and delivery of response personnel to affected areas.
5. Environmental Response/Health and Safety	Ensure the availability of guidance and resources to address all hazards.
6. Fatality Management Services	Body recovery and victim identification services, temporary mortuary solutions, sharing information with Mass Care Services for reunifying family members and caregivers with missing persons/remains and providing counseling to the bereaved.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

National Response Framework: Core Capabilities (cont. 2)

Core Capability	Objective Summaries
7. Infrastructure Systems (cross-cutting with Recovery mission area)	Stabilize critical infrastructure functions, minimize health and safety threats, and restore and vitalize systems and services to support a viable, resilient community
8. Mass Care Services	Provide life-sustaining services to the affected population with a focus on hydration, feeding, and sheltering to those with the most need, as well as support for reunifying families
9. Mass Search and Rescue Operations	Deliver search and rescue capabilities, providing personnel, services, animals, and assets – with the goal of saving the greatest number of endangered lives in the shortest time possible
10. On-Scene Security and Protection	Provide law enforcement and related security and protection operations for people and communities in affected areas

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

National Response Framework: Core Capabilities (cont. 3)

Core Capability	Objective Summaries
11. Operational Communications	Ensure the capacity for timely communications.
12. Public and Private Services and Resources	Provide essential public and private services and resources to the affected population, including emergency power to critical facilities, fuel support for emergency responders, and access to community staples (grocery stores, pharmacies, and banks) and fire and other first response services
13. Public Health and Medical Services	Provide lifesaving medical treatment via emergency medical services and related operations.
14. Situational Assessment	Provide all decision-makers with decision-relevant information regarding the nature and extent of the hazard, and any cascading effects, and the status of the response.

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Congratulations, that is it…

Except where otherwise noted, this presentation is licensed under a

CyberWatch West,

Whatcom Community College.

Creative Commons Attribution 4.0 International License.

Computer Science ISSC480 week 6 assignment

Instructions

Incident Response Report

Assignment Guidelines

Deliverables

media1.mp4

image5.png

image6.jpeg

image7.jpg

image8.png

image9.png

image10.png

image11.png

image12.jpeg

image1.png

Place your order now for a similar assignment, and have writers from our team of experts write it for you, guaranteeing you an A+

Order a similar assignment, and have writers from our team of experts write it for you, guaranteeing you an A