Incident Response Plan

This document describes the procedures CodeHS will follow in response to the report of a data breach or security incident.

Discovery and Response to Incident

1. If the person discovering the incident is a member of the IT department or affected department, they will proceed to step 5.
2. If the person discovering the incident is not a member of the IT department or affected department, they will call the CodeHS Headquarters at 415-889-3376.
3. The headquarters office manager will refer to the IT emergency contact list or affected department contact list and call the designated numbers in order on the list. The grounds security office will log:
1. The name of the caller
2. Time of the call
3. Contact information about the caller
4. The nature of the incident
5. Equipment or persons involved
6. Location of equipment or persons involved
7. How the incident was detected
8. When the event was first noticed that supported the idea that the incident occurred.
4. The IT staff member or affected department staff member who receives the call (or discovered the incident) will refer to their contact list for both management personnel to be contacted and incident response members to be contacted. The staff member will call those designated on the list. The staff member will contact the incident response manager using both email and phone messages while being sure other appropriate and backup personnel and designated managers are contacted. The staff member will log the information received in the same format as the grounds security office in the previous step. The staff member could possibly add the following:
1. Is the equipment affected business-critical?
2. What is the severity of the potential impact?
3. Name of system being targeted, along with operating system (if applicable), IP address, and location.
4. IP address and any information about the origin of the attack.
5. Contacted members of the response team will meet or discuss the situation over the telephone and determine a response strategy.
1. Is the incident real or perceived?
2. Is the incident still in progress?
3. What data or property is threatened and how critical is it?
4. What is the impact on the business should the attack succeed? Minimal, serious, or critical?
5. What system or systems are targeted, where are they located physically and on the network?
6. Is the incident inside the trusted network?
7. Is the response urgent?
8. Can the incident be quickly contained?
9. Will the response alert the attacker and do we care?
10. What type of incident is this? Example: virus, worm, intrusion, abuse, damage.
6. An incident ticket will be created. The incident will be categorized into the highest applicable level of one of the following categories:
1. Category one - A threat to sensitive data
2. Category two - A threat to computer systems
3. Category three - A disruption of services
7. Team members will establish and follow one of the following procedures basing their response on the incident assessment:
1. Worm response procedure
2. Virus response procedure
3. System failure procedure
4. Active intrusion response procedure - Is critical data at risk?
5. Inactive Intrusion response procedure
6. System abuse procedure
7. Property theft response procedure
8. Website denial of service response procedure
9. Database or file denial of service response procedure
10. Spyware response procedure.

The team may create additional procedures which are not foreseen in this document. If there is no applicable procedure in place, the team must document what was done and later establish a procedure for the incident.

8. Team members will use forensic techniques, including reviewing system logs, looking for gaps in logs, reviewing intrusion detection logs, and interviewing witnesses and the incident victim to determine how the incident was caused.
9. Team members will recommend changes to prevent the occurrence from happening again or infecting other systems.
10. Upon management approval, the changes will be implemented.
11. Team members will restore the affected system(s) to the uninfected state. They may do any or more of the following:
1. Re-install the affected system(s) from scratch and restore data from backups if necessary. Preserve evidence before doing this.
2. Make users change passwords if passwords may have been sniffed.
3. Be sure the system has been hardened by turning off or uninstalling unused services.
4. Be sure the system is fully patched.
5. Be sure real-time virus protection and intrusion detection are running.
6. Be sure the system is logging the correct events and to the proper level.
12. Documentation—the following shall be documented:
1. How the incident was discovered
2. The category of the incident
3. How the incident occurred, whether through email, firewall, etc.
4. Where the attack came from, such as IP addresses and other related information about the attacker
5. What the response plan was
6. What was done in response?
7. Whether the response was effective
13. Evidence Preservation—make copies of logs, email, and other communication. Keep lists of witnesses. Keep evidence as long as necessary to complete prosecution and beyond in case of an appeal.
14. Notify proper external agencies—team members will notify the police and other appropriate agencies if prosecution of the intruder is possible.
15. Review response and update policies—team members will plan and take preventative steps so the intrusion can't happen again. The following factors will be considered:
1. Whether an additional policy could have prevented the intrusion
2. Whether a procedure or policy was not followed which allowed the intrusion, and then consider what could be changed to ensure that the procedure or policy is followed in the future
3. Was the incident response appropriate? How could it be improved?
4. Was every appropriate party informed in a timely manner?
5. Were the incident-response procedures detailed and did they cover the entire situation? How can they be improved?
6. Have changes been made to prevent a re-infection? Have all systems been patched, systems locked down, passwords changed, anti-virus updated, email policies set, etc.?
7. Have changes been made to prevent a new and similar infection?
8. Should any security policies be updated?
9. What lessons have been learned from this experience?

Notification to LEA

In the event that Student Data is accessed or obtained by an unauthorized individual, CodeHS shall provide notification to LEA within forty-eight (48) hours of discovering the breach.

1. The security breach notification shall be written in plain language, shall be titled “Notice of Data Breach,” and shall present the information described herein under the following headings: “What Happened,” “What Information Was Involved,” “What We Are Doing,” “What You Can Do,” and “For More Information.” Additional information may be provided as a supplement to the notice.
2. The security breach notification described above in section (a) shall include, at a minimum, the following information:
1. The name and contact information of the reporting LEA subject to the data breach.
2. A list of the types of personal information that were or are reasonably believed to have been the subject of a breach.
3. If the information is possible to determine at the time the notice is provided, then either (1) the date of the breach, (2) the estimated date of the breach, or (3) the date range within which the breach occurred. The notification shall also include the date of the notice.
4. Whether the notification was delayed as a result of a law enforcement investigation, if that information is possible to determine at the time the notice is provided.
5. A general description of the breach incident, if that information is possible to determine at the time the notice is provided.
3. At LEA’s discretion, the security breach notification may also include any of the following:
1. Information about what the agency has done to protect individuals whose information has been breached.
2. Advice on steps that the person whose information has been breached may take to protect himself or herself.
4. CodeHS agrees to adhere to all requirements in federal law with respect to a data breach related to the Student Data, including, when appropriate or required, the required responsibilities and procedures for notification and mitigation of any such data breach.
5. At the request and with the assistance of the District, CodeHS shall notify the affected parent, legal guardian or eligible pupil of the unauthorized access, which shall include the information listed in subsections (b) and (c), above.
6. In the event of a breach originating from LEA’s use of the Services, CodeHS shall cooperate with LEA to the extent necessary to expeditiously secure Student Data.

Questions?

To ask questions or comment on this Incident Response Plan, contact us at hello@codehs.com.