Incident Response Plan

Incident Response

The ability to respond to events, incidents, threats that pose a negative effect on our network is known as Incident response.

The primary goal is to limit the disruption to the network, services and business processes.

The incident response should be planned prior to any incident happen. Below are some of key considerations to keep in mind;

• There should be a Incident response team formed and trained with adequate knowledge of incident management.
• There should be formal policies and procedures drafted and communicated to all stakeholders.
• Necessary tools should be identified and kept with easy access.
• There should be Senior Management Support obtained before the team planning and operation. 
• The escalation matrix should be documented and shared with stakeholders.

Incident Response Life Cycle

 

 

 

Preparation Phase:

In preparation phase, the response team need to check the capability of incident response. There should be coordination and planning how to identify the requirements. There should be plans for implementation such as:

• Developing policies, process, and procedures.
• Define and establish incident handling criteria.
• Classification of risk and criticality.
• Define post incident review process and change management process.

Identification Phase:

 In this phase, there should be identification of suspicious activity or any unusual behavioral activity that might affect or compromise the infrastructure or business. There should be proactive detection, reactive detection and monitoring implemented to detect the intrusions, analyse network traffic, review audit logs, Use of Honey pots etc.

Contain Phase:

In this phase the detected incidents, intrusions should be sorted, categorized. There should be correlation and prioritization of incidents. Response team should also isolate the infected system as on immediate basis such as pull network cables, isolate from router/VLAN.

NB: Forensic evidence should be kept intact.

Eradicate and Remediate Phase:

In this phase core team have more responsibility to restore or rebuild the system, restore from saved media, backups to its baseline configuration. Team should work more proactively to scan the system once again, remove the malware, and do the system hardening.

Lessons Learned Phase:

In this phase, team should document all the findings, process to remediation, take feedback from the team. This post incident activity is also important and it help to protect and defend the future incidents or events. All the process should be kept information for KEDB and future reference.

Every organization should also use certain frameworks such as NIST Cyber Security Framework for a systematic process approach which can help in overall risk management process. Later we will cover the Cyber Security Framework (CSF) in an another blog.

Please share your feedback. Thanks!

 -DR

 

 

Incident Management

Incident Management

An incident is any kind of disruption to an organization's IT services as well as to other services that affects a single user/ a team or the entire business operation. It hampers the normal business continuity. An incident is an unplanned disruption. It can happen anytime without prior notice. 

An incident can be ideally divided in to two types such as system generated incident or user logged incident. System generated incident are automatic in nature. 

Example of System generated incident

• Virus detection by antivirus software.

Example of user logged incident

• An user suddenly noticed there is an unauthorized access to a system or someone rushed in to office premise intentionally. He immediately informs the internal incident response team about the matter.

Example of Incidents can be range from civil repair work to cyber attacks. An incident can be many types such as;

• UPS failure
• Air conditioning failure
• Network devices failure
• Hard disk failure
• Access control failure
• Internet failure
• Software issue
• DDoS attack
• Cyber attack
• Backup failure
• System failure
• Virus attack
• Printer issue
• Natural calamities such as Fire outbreak, cyclone, flood, earthquake.

Incident Management is compromises of set of processes and principles adopted to return a service operation in to normal functioning after the incident occurs and ideally should complete it within the SLA (Service Level Agreement) time frame.

So an incident need to be identified, prioritized based on its impact and urgency, then accessed to resolve. An Incident management covers every aspect of an incident throughout its life cycle.

Process brief

The entire incident management process should be documented prior to implementation. There must be some key roles and responsibilities defined for the core team members such as Incident Manager, Incident Process owner, Process operator, etc. 

An incident management process has different steps with different approach. Below are the general steps;

Incident identification

Identify an Incident, type of incident etc.

Incident Logging or incident recording

Log or record the incident, log the time stamp, occurrence place, affected area, any root cause. Many automation software are there to do this task. Earlier manually people record the incident in registers or excel sheets. Assign a ticket/token to an incident with Incident number.

Incident Categorization and prioritization

Categorize the incident based on risk and severity level such as High, Medium, Low. Prioritize the incident based on how urgency to resolve it. Or we can say, Prioritization helps the Incident Management team to examine and understand the importance of the incident and the timelines within which the issue needs to be resolved.

There must be incident priority matrix established. An incident priority matrix is a documented guide where the incident priority level is set before, such as critical, high, medium, low, no impact.

In incident priority matrix, the urgency to resolve the issue, response time, resolution time, MAT (maximum allowable time) need to be defined as per the defined SLA (Service level agreement) or MSA (Master Service Agreement).

Incident assignment to team or owner

Create task for resolve, Provide resolution

Technical Team or subject matter experts (SME) to work on the incident, research, diagnosis, investigate on the issue or recorded incident. 

SLA adherence during resolution

Follow SLA timelines for resolution process.

Escalation if further investigation required or failure in resolution at L1 level.

Escalate in case of it is a major incident and L1 support cannot support it. 

Provide resolution

The goal of the Incident Management is to restore the business or services as soon as possible, hence resolution is very important. The resolution provided could either be a work in progress / a temporary fix or a permanent resolution.

Close the incident

Close the incident once resolution is carried out. In case, If post providing the resolution to the customer no feedback or further escalation received on the issue within 24 hours from the resolution time, then the issue will deemed as closed. 

Take user feedback on the closure and document all the process for the incident

Need to check with customer, client how they are happy with the resolution process. And collect if any feedback is there. 

Finally add the incident resolution process to KEDB.

KEDB:

KEDB is nothing it is Known error data base and it is very useful one in terms if incident management. 

During an incident occurs, initially KEDB is referred in that case to check as if any previous similar incident occurred in past and the process to resolve this is available in the database. So that it will minimize the time of resolution process. Hence KEDB should be updated in regular intervals to record all the incidents and problems. KEDB can further be categorized based on domains. 

Similarly there is Problem Management Process, i can provide a little brief on it;

A problem is nothing, it is unresolved incident or when an incident happens frequently in the system or organization. Problems can be identified from major incidents, combination of multiple incidents.

The problem management process is a similar kind of incident management process. However a change management process is an additional process which is linked to problem management process.

For example, during a problem investigation and root cause analysis (RCA) stage, it was finalized that the problem cannot be solved until we have to change it. It may be involved as buying a new hardware, software, hire new resource, and change in scope. So here change management process will act how to change the process.

So this is a basic understanding about incident and problem. If you have further questions or comments please provide.

Thanks!

-DR