Events

An event is an observable change to the normal behavior of a system, environment, process, workflow or person (components). There are three basic types of events:

1. Normal—a normal event does not affect critical components or require change controls prior to the implementation of a resolution. Normal events do not require the participation of senior personnel or management notification of the event.
2. Escalation – an escalated event affects critical production systems or requires that implementation of a resolution that must follow a change control process. Escalated events require the participation of senior personnel and stakeholder notification of the event.
3. Emergency – an emergency is an event which may
   1. impact the health or safety of human beings
   2. breach primary controls of critical systems
   3. materially affect component performance or because of impact to component systems prevent activities which protect or may affect the health or safety of individuals
   4. be deemed an emergency as a matter of policy or by declaration by the available incident coordinator

Computer security and information technology personnel must handle emergency events according to well-defined computer security incident response plan.

Incident

An incident is an event attributable to a human root cause. This distinction is particularly important when the event is the product of malicious intent to do harm. An important note: all incidents are events but many events are not incidents. A system or application failure due to age or defect may be an emergency event but a random flaw or failure is not an incident.

Incident response team

The security incident coordinator manages the response process and is responsible for assembling the team. The coordinator will ensure the team includes all the individuals necessary to properly assess the incident and make decisions regarding the proper course of action. The incident team meets regularly to review status reports and to authorize specific remedies. The team should utilize a pre-allocated physical and virtual meeting place.^[3]

Incident investigation

The investigation seeks to determine the circumstances of the incident. Every incident will warrant or require an investigation. However, investigation resources like forensic tools, dirty networks, quarantine networks and consultation with law enforcement may be useful for the effective and rapid resolution of an emergency incident.

Initial incident management process

Author: Michael Berman (tanjstaffl)

1. Employee, vendor, customer, partner, device or sensor reports event to Help Desk.
2. Prior to creating the ticket, the help desk may filter the event as a false positive. Otherwise, the help desk system creates a ticket that captures the event, event source, initial event severity and event priority.
   1. The ticket system creates a unique ID for the event. IT Personnel must use the ticket to capture email, IM and other informal communication.
   2. Subsequent activities like change control, incident management reports and compliance reports must reference the ticket number.
   3. In instances where event information is "Restricted Access", the ticket must reference the relevant documents in the secure document management system.
3. The First Level Responder captures additional event data and performs preliminary analysis. In many organizations the volume of events is significant relative to the staff. As a result, automation may be applied, typically in the form of a SOAR (security orchestration, automation and response) tool,^[4] integrated with an intelligence API. The SOAR tool automates the investigation via a workflow automation workbook.^[4] The cyber intelligence API enables the playbook to automate research related to the ticket (lookup potential phishing URL, suspicious hash, etc.). The First Responder determines criticality of the event. At this level, it is either a Normal or an Escalation event.
   1. Normal events do not affect critical production systems or require change controls prior to the implementation of a resolution.
   2. Events that affect critical production systems or require change controls must be escalated.
   3. Organization management may request an immediate escalation without first level review – 2nd tier will create ticket.
4. The event is ready to resolve. The resource enters the resolution and the problem category into the ticket and submits the ticket for closure.
5. The ticket owner (employee, vendor, customer or partner) receives the resolution. They determine that the problem is resolved to their satisfaction or escalate the ticket.
6. The escalation report is updated to show this event and the ticket is assigned a second tier resource to investigate and respond to the event.
7. The Second Tier resource performs additional analysis and re-evaluates the criticality of the ticket. When necessary, the Second Tier resource is responsible for implementing a change control and notifying IT Management of the event.
8. Emergency Response:
   1. Events may follow the escalation chain until it is determined that an emergency response is necessary.
   2. Top-level organization management may determine that an emergency response is necessary and invoke this process directly.

Emergency response detail

Author: Michael Berman (tanjstaffl)

1. Emergency response is initiated by escalation of a security event or be direct declaration by the CIO or other executive organization staff. The CIO may assign the incident coordinator, but by default, the coordinator will be the most senior security staff member available at the time of the incident.
2. The incident coordinator assembles the incident response team. The team meets using a pre-defined conference meeting space. One of the (CIO, CSO or Director IT) must attend each incident team meeting.
3. The meeting minutes capture the status, actions and resolution(s) for the incident. The incident coordinator reports on the cost, exposure and continuing business risk of the incident. The incident response team determines the next course of action.
4. Lock-down and Repair – Perform the actions necessary to prevent further damage to the organization, repair impacted systems and perform changes to prevent a re-occurrence.
5. False Positive – The incident team determines this issue did not warrant an emergency response. The team provides a written report to senior management and the issue is handled as either a normal incident or it is closed.
6. Monitor and Capture – Perform a thorough investigation with continued monitoring to detect and capture the perpetrator. This process must include notification to the following senior and professional staff:
   1. CEO and CFO
   2. Corporate Attorney and Public Relations
7. Review and analyze log data to determine nature and scope of incident. This step should include utilizing virus, spyware, rootkit and other detection tools to determine necessary mitigation and repair.
8. Repair systems, eliminate vector(s) of attack, and mitigate exploitable vulnerabilities.
9. The Test Report documents the validation of the repair process.
   1. Test systems to ensure compliance with policy and risk mitigation.
   2. Perform additional repairs to resolve all current vulnerabilities.
10. Investigate incident to determine source of attack and capture perpetrator. This will require the use of forensics tools, log analysis, clean lab and dirty lab environments and possible communication with Law Enforcement or other outside entities.
11. The "Investigation Status Report" as captures all current information regarding the incident. The Incident response team uses this information to determine the next course of action. (See Ref 2 and Ref 3)