Module05IncidentResponsePlan.docx

2
Incident Response Plan

Incident Response Plan

By

Students name

Course Name_ year_ term quarter Rasmussen College

Professor’s Name

Deliverable 5 – Incident Response Plan

Document Control

Organization

[Name]

Title

[Document Title]

Author

[Document Author – Named Person]

Filename

[Saved Filename]

Owner

[Document Owner – Job Role]

Subject

[Document Subject – e.g. IT Policy]

Protective Marking

[Marking Classification]

Review date

Revision History

Revision Date

Revisor

Previous Version

Description of Revision

Document Approvals

This document requires the following approvals:

Sponsor Approval

Name

Date

Document Distribution

This document will be distributed to:

Name

Job Title

Email Address

Contributors

Development of this policy was assisted through information provided by the following organizations:

Policy Statement

[Name] will ensure that it reacts appropriately to any actual or suspected incidents relating to information systems and information within the custody of the Organization.

Purpose

The aim of this policy is to ensure that [Name] reacts appropriately to any actual or suspected security incidents relating to information systems and data.

Scope

This document applies to all Departments, Partners, Employees of the organization, contractual third parties and agents of the organization who use [Name] IT facilities and equipment or have access to, or custody of, customer information or [Name] information.

All users must understand and adopt the use of this policy and are responsible for ensuring the safety and security of the Organization systems and the information that they use or manipulate.

All users have a role to play and a contribution to make to the safe and secure use of technology and the information that it holds.

Definition

This policy needs to be applied as soon as information systems or data are suspected to be, or are actually affected by an adverse event which is likely to lead to a security incident.

The definition of an “information management security incident” (‘Information Security Incident’ in the remainder of this policy and procedure) is an adverse event that has caused or has the potential to cause damage to an organization’s assets, reputation and/or personnel. Incident management is concerned with intrusion, compromise and misuse of information and information resources, and the continuity of critical information systems and processes.

An Information Security Incident includes, but is not restricted to, the following:

· The loss or theft of data or information.
· The transfer of data or information to those who are not entitled to receive that information.
· Attempts (either failed or successful) to gain unauthorized access to data or information storage or a computer system.
· Changes to information or data or system hardware, firmware, or software characteristics without the Organization knowledge, instruction, or consent.
· Unwanted disruption or denial of service to a system.
· The unauthorized use of a system for the processing or storage of data by any person.

Examples of some of the more common forms of Information Security Incidents have been provided in Appendix 2.

Risks

[Name] recognizes that there are risks associated with users accessing and handling information to conduct official business.

This policy aims to mitigate the following risks [amend the list as appropriate]:

· To reduce the impact of information security breaches by ensuring incidents are followed up correctly.
· To help identify areas for improvement to decrease the risk and impact of future incidents.

Non-compliance with this policy could have a significant effect on the efficient operation of the Organization and may result in financial loss and an inability to provide necessary services to our customers.

Procedure for Incident Handling

Events and weaknesses need to be reported at the earliest possible stage as they need to be assessed by an [Name a role – although likely to be an Information Security Advisor]. The Advisor [or other named role] enables the [Name a department – e.g. Information Services department] to identify when a series of events or weaknesses have escalated to become an incident. It is vital for the [Name a department – e.g. Information Services department] to gain as much information as possible from the business users to identify if an incident is occurring.

For full details of the procedure for incident handling, please refer to Appendix 3.

Policy Compliance

If any user is found to have breached this policy, they may be subject to [Name’s] disciplinary procedure. If a criminal offence is considered to have been committed further action may be taken to assist in the prosecution of the offender(s).

If you do not understand the implications of this policy or how it may apply to you, seek advice from [name appropriate department].

Policy Governance

The following table identifies who within [Name] is Accountable, Responsible, Informed or Consulted with regards to this policy. The following definitions apply:

· Responsible – the person(s) responsible for developing and implementing the policy.
· Accountable – the person who has ultimate accountability and authority for the policy.
· Consulted – the person(s) or groups to be consulted prior to final policy implementation or amendment.
· Informed – the person(s) or groups to be informed after policy implementation or amendment.

Responsible

[Insert appropriate Job Title]

Accountable

[Insert appropriate Job Title. It is important that only one role is held accountable.]

Consulted

[Insert appropriate Job Title, Department or Group Department, Employee Panels, etc.]

Informed

[Insert appropriate Job Title, Department or Group.]

Review and Revision

This policy, and all related appendices will be reviewed as it is deemed appropriate, but no less frequently than every 12 months.

Policy review will be undertaken by [Name an appropriate role].

References

The following [Name] policy documents are directly relevant to this policy [amend the list as appropriate]:

· Email Policy.
· Internet Acceptable Use Policy.
· Software Policy.
· GCSx Acceptable Usage Policy and Personal Commitment Statement.
· Computer, Telephone and Desk Use Policy.
· Removable Media Policy.
· Remote Working Policy.
· IT Access Policy.
· Legal Responsibilities Policy.
· Information Protection Policy.
· Human Resources Information Security Standards.
· IT Infrastructure Policy.
· Communications and Operation Management Policy.

Key Messages

· All staff should report any incidents or suspected incidents immediately by [enter appropriate details here].
· We can maintain your anonymity when reporting an incident if you wish.
· If you are unsure of anything in this policy, you should ask for advice from [name an appropriate department]

Appendix 1 – Process Flow; Reporting an Information Security Event or Weakness

[Include a diagram similar to the one below if required]

Appendix 2 – Examples of Information Security Incidents

Examples of the most common Information Security Incidents are listed below. It should be noted that this list is not exhaustive.

Malicious

· Giving information to someone who should not have access to it – verbally, in writing or electronically.
· Computer infected by a Virus or other malware.
· Sending a sensitive e-mail to ‘all staff’ by mistake.
· Receiving unsolicited mail of an offensive nature.
· Receiving unsolicited mail which requires you to enter personal data.
· Finding data that has been changed by an unauthorized person.
· Receiving and forwarding chain letters – including virus warnings, scam warnings and other emails which encourage the recipient to forward onto others.
· Unknown people asking for information which could gain them access to data (e.g. a password or details of a third party).

Misuse

· Use of unapproved or unlicensed software on [Name] equipment.
· Accessing a computer database using someone else’s authorization (e.g. someone else’s user id and password).
· Writing down your password and leaving it on display / somewhere easy to find.
· Printing or copying confidential information and not storing it correctly or confidentially.

Theft / Loss

· Theft / loss of a hard copy file.
· Theft / loss of any [Name] computer equipment.

Appendix 3 – Procedure for Incident Handling

[Please replace with your local procedures as appropriate]

Reporting Information Security Events or Weaknesses

The following sections detail how users and IT Support Staff [or equivalent] must report information security events or weaknesses. Appendix 1 provides a process flow diagram illustrating the process to be followed when reporting information security events or weaknesses [include if so required].

Reporting Information Security Events for all Employees

Security events, for example, a virus infection, could quickly spread and cause data loss across the organization. All users must understand, and be able to identify that any unexpected or unusual behavior on the workstation could potentially be a software malfunction. If an event is detected users must:

· Note the symptoms and any error messages on the screen.
· Disconnect the workstation from the network if an infection is suspected (with assistance from IT Support Staff [or equivalent department]).
· Not use any removable media (for example USB memory sticks) that may also have been infected.

All suspected security events should be reported immediately to the Information Services Helpdesk [or equivalent department] on [state phone number].

If the Information Security event is in relation to paper or hard copy information, for example, personal information files that may have been stolen from a filing cabinet, this must be reported to Senior Management and either the Data Protection Officer or Caldecott Guardian [or equivalent posts] for the impact to be assessed.

The Information Services Helpdesk [or equivalent] will require you to supply further information, the nature of which will depend upon the nature of the incident. However, the following information must be supplied [amend the list as appropriate]:

· Contact name and number of person reporting the incident.
· The type of data, information or equipment involved.
· Whether the loss of the data puts any person or other data at risk.
· Location of the incident.
· Inventory numbers of any equipment affected.
· Date and time the security incident occurred.
· Location of data or equipment affected.
· Type and circumstances of the incident.

Reporting Information Security Weaknesses for all Employees

Security weaknesses, for example, a software malfunction, must be reported through the same process as security events. Users must not attempt to prove a security weakness as such an action may be considered to be misuse.

Weaknesses reported to application and service providers by employees must also be reported internally to Information Services [or equivalent department]. The service provider’s response must be monitored and the effectiveness of its action to repair the weakness must be recorded by Information Services [or equivalent department].

Reporting Information Security Events for IT Support Staff [or equivalent staff]

Information security events and weaknesses must be reported to a nominated central point of contact within Information Services [or equivalent department] as quickly as possible and the incident response and escalation procedure must be followed.

Security events can include:

· Uncontrolled system changes.
· Access violations – e.g. password sharing.
· Breaches of physical security.
· Non compliance with policies.
· Systems being hacked or manipulated.

Security weaknesses can include:

· Inadequate firewall or antivirus protection.
· System malfunctions or overloads.
· Malfunctions of software applications.
· Human errors.

The reporting procedure must be quick and have redundancy built in. All events must be reported to at least two nominated people within Information Services [or equivalent department] who must both be required to take appropriate action. The reporting procedure must set out the steps that are to be taken and the time frames that must be met. [It may be more appropriate to establish a single line of reporting with demonstrable accountability of the person / role required to take action on the reported event]

An escalation procedure must be incorporated into the response process so that users and support staff are aware who else to report the event to if there is not an appropriate response within a defined period.

Incidents must be reported to the Business Continuity Management teams [or equivalent departments] should the incident become service affecting.

Management of Information Security Incidents and Improvements

A consistent approach to dealing with all security events must be maintained across the organization. The events must be analysed and the Security Advisor [or equivalent role] must be consulted to establish when security events become escalated to an incident. The incident response procedure must be a seamless continuation of the event reporting process and must include contingency plans to advise the organzation on continuing operation during the incident.

All high and medium incidents should be reported to [enter details here]. All low incidents should be reported to [enter details here]. To decide what level of impact an incident has users should refer to the Risk Impact Matrix in Appendix 4.

Collection of Evidence

If an incident may require information to be collected for an investigation, strict rules must be adhered to. The collection of evidence for a potential investigation must be approached with care. Internal Audit [or equivalent department] must be contacted immediately for guidance, and strict processes must be followed for the collection of forensic evidence. If in doubt about a situation, for example concerning computer misuse, contact the [Name an appropriate department – e.g. IT Helpdesk] for advice.

Responsibilities and Procedures

Management responsibilities and appropriate procedures must be established to ensure an effective response against security events. The security advisor from Information Services [or equivalent department] must decide when events are classified as an incident and determine the most appropriate response.

An incident management process must be created and include details of:

· Identification of the incident, analysis to ascertain its cause and vulnerabilities it exploited.
· Limiting or restricting further impact of the incident.
· Tactics for containing the incident.
· Corrective action to repair and prevent reoccurrence.
· Communication across the organization to those affected.

The process must also include a section referring to the collection of any evidence that might be required for analysis as forensic evidence. The specialist procedure for preserving evidence must be carefully followed.

The actions required to recover from the security incident must be under formal control. Only identified and authorized staff should have access to the affected systems during the incident and all of the remedial actions should be documented in as much detail as possible.

The officer responsible for an incident should risk assess the incident based on the Risk Impact Matrix (please refer to Appendix 4). If the impact is deemed to be high or medium this should be reported immediately to [enter appropriate details here].

Learning from Information Security Incidents

To learn from incidents and improve the response process incidents must be recorded and a Post Incident Review conducted. The following details must be retained:

· Types of incidents.
· Volumes of incidents and malfunctions.
· Costs incurred during the incidents.

The information must be collated and reviewed on a regular basis by Information Services [or equivalent department] and any patterns or trends identified. Any changes to the process made as a result of the Post Incident Review must be formally noted.

The information, where appropriate, should be shared with the Warning, Advice and Reporting Point (WARP) to aid the alert process for the region

Rasmussen College

Security Incident or
weakness observed
Incident Report Raised
and Logged
Line Management
Advised
Is Assistance
Required?
Contact and evaluate
action with appropriate
authority
Evaluate Appropriate
Action
Does Security Forum
need to make a
decision?
Incident report
updated as
necessary with
timescales etc.
Security Forum
decides action
Action TakenIncident Report Closed
Incident Reports
collated and passed to
security forum
Security Forum reviews and
if appropriate changes
policy
YES
NO
YES
NO
Process Flow – Security Incident Reporting
Activity
Documentation
Security Incident or weakness observed

Incident Report Raised and Logged

Line Management Advised

Is Assistance Required?

Contact and evaluate action with appropriate authority

Evaluate Appropriate Action

Does Security Forum need to make a decision?

Incident report updated as necessary with timescales etc.

Security Forum decides action

Action Taken

Incident Report Closed

Incident Reports collated and passed to security forum

Security Forum reviews and if appropriate changes policy

YES

NO

YES

NO

Process Flow – Security Incident Reporting

Activity

Documentation