Information security Incident
Management Policy
Document Summary
Item Value
Organization Information Dynamics India
Document Name Incident Management Policy
Classification Internal
Compliance Reference To: ISO 27001:2013 and ISO 20000:2011
Document Revision History
Date Version Prepared By
1
st
November 2018 1.1 Information Dynamics
29
th
December 2019 1.2 Information Dynamics
24
th
December 2020 1.3 Manivannan
24
th
December 2021 1.4 Deepak
Document Review History
Reviewed By Version Date Signature
Soundar 1.2 29
th
December 2019
Soundar 1.3 26
th
December 2020
Soundar 1.4 26
th
December 2021
Incident Management Information Dynamics Page 1
1. Purpose of the Incident Response Plan
An Incident Response Plan is required in order to bring needed resources together
in an organized manner to deal with an adverse event related to the safety and
security of Organization’s Business & Information Assets. This adverse event may
be malicious code attack, unauthorized access to Organizational systems,
unauthorized utilization of Organization services in denial of service attacks,
general misuse of systems, or hoaxes.
2. Purpose of the Incident Response Team
The purpose of Incident Response Team is to:
Protect Organizational Information assets,
Provide a central organization to handle incidents
Comply with (government or other) regulations,
Prevent the use of Organizational system in attacks against other systems
(which could cause us to incur legal liability),
Minimize the potential for negative exposure.
ISO 27001:2013 Domain Reference: A.16 – Information Security Incident Management
ISO 27001:2013 Reference
A.16.1.1 Responsibilities and procedures
A.16.1.2 Reporting information security events
A.16.1.3 Reporting information security weaknesses
A.16.1.4 Assessment of and decision on information security events
A.16.1.5 Response to information security incidents
A.16.1.6 Learning from information security incidents
A.16.1.7 Collection of evidence
ISO 20000:2011 Domain Reference: 6.6.3 – Information security changes and incidents
3. Scope
The scope of the policy will be applicable to all activities under the scope statement of
Information Dynamics.
Policy Controls
4. Incident Classification
Incident Management Information Dynamics Page 2
Security incidents will be classified according to incident categories and severity
of incident. Incident response will be based on classification.
A. Incident Categories
The following categories will be used to describe IT security incidents at
Information Dynamics. A single incident may have several different
categories.
1. Confidential data exposure
Customer Account details
Credit Card information
Identity theft
Other
2. Criminal activity/investigation
Search warrant or other court order
Litigation hold request (ala e-Discovery)
Online theft, fraud
Threatening communication
Pornography
Physical theft, break-in
3. Denial of Service
Single or distributed (DoS or DDoS)
Inbound or outbound
4. Digital Millennium Copyright Act (DMCA) violation (if exists)
Official DMCA notification from copyright owner or legal
representative
Illegal distribution of copyrighted or licensed material
(movies, music, software, games)
Illegal possession of copyrighted or licensed material
5. Malicious code activity
Worm, virus, Trojan
Botnet
Keylogger
Rootkit
6. Policy violation
The Organization’s policy violation
Violation of student code of conduct
Personnel action/investigation
7. Reconnaissance activity
Port scanning
Other vulnerability scanning
Unauthorized monitoring
8. Rogue server or service
Rogue file/FTP server for music, movies, pirated software,
etc.
Phishing scam web server
Botnet controller
Incident Management Information Dynamics Page 3
9. Spam source
Spam relay
Spam host
Computer on a block list
10. Spear Phishing
Scam e-mail targeting a relatively large number of <Name
of the Organization> e-mail addresses
11. Unauthorized access
Abuse of access privileges
Unauthorized access to data
Unauthorized login attempts
Brute force password cracking attempts
Stolen password(s)
12. Un-patched vulnerability
Vulnerable operating system
Vulnerable application
Vulnerable web site/service
Weak or no password on an account
13. Web defacement
Defacement of web site
Inappropriate post to Bank’s comments/blog section
Redirected web site
14. Un-authorized network access
Wire-less
Rogue LAN connection
Wire-tapping
15. No Incident or False-positive
When investigation of suspicious activity finds no
evidence of a security incident
B. Incident Severity
An incident will be categorized as one of three severity levels. These severity
levels are based on the impact to the organization and can be expressed in
terms of financial impact, impact to manufacturing, impact to sales, impact to
company’s image or impact to trust by company customers, etc. Following
table provides a listing of the severity levels and a definition/description of
each severity level.
Severity
Level
Description
Low Incident where the impact is minimal. Examples are harmless email
SPAM, isolated Virus infections, etc.
Medium Incident where the impact is significant. Examples are a delayed ability to
order or manufacture [Product Name], delayed delivery of critical
electronic mail or EDI transfers, etc.
High Incident where the impact is severe. Examples are a disruption to the
manufacturing or sales processes, company’s proprietary of confidential
information has been compromised, a virus
or worm has become wide spread and is affecting over 30 percent of the
employees, or Executive management
has reported it.
Incident Management Information Dynamics Page 4
5. Responding To An Incident
Six stages of response are described below:
4.1 Preparation
One of the most important facilities to a response plan is to know-how to use it
once it is in place. Knowing how to respond to an incident BEFORE it occurs
can save valuable time and effort in the long run.
4.2 Identification
Identify whether or not an incident has occurred. If one has occurred, the
response team can take the appropriate actions. The approach to the
Identification Stage involves:
1) Validating the incident
2) If an incident has occurred, identify its nature
3) Identifying and protecting the evidence
4) Logging and reporting the event or incident.
When a staff member notices a suspicious anomaly in data, a system, or the
network, he or she begins this identification process or immediately notify the
concerned person(s).
4.3 Containment
It involves in limiting the scope and magnitude of an incident. Because so
many incidents observed currently involve malicious code, incidents can
spread rapidly. This can cause massive destruction and loss of information.
As soon as an incident is recognized, immediately begin working on
containment. A decision on the operational status of the compromised system
itself will be made. Whether this system should be:
1) Shut down entirely
2) Disconnected from the network or
3) Be allowed to continue to run in its normal operational status (so
that any activity on the system can be monitored) will depend on
the risk to assets threatened by the incident.
4.4 Eradication
Removing the cause of the incident can be a difficult process. It can involve
virus removal, conviction of perpetrators, or dismissing employees. Should
follow good practices:
1) Determine the Cause and Symptoms
Use information gathered during the containment phase and collect
additional information. If a single attack method cannot be
determined list and rank the possibilities.
Incident Management Information Dynamics Page 5
2) Improve Defenses
Implement appropriate protection techniques such as firewalls
and/or router filters, moving the system to a new name/IP address,
or in extreme cases, porting the machine's functions to a more
secure operating system.
3) Perform Vulnerability Analysis
Use of vulnerability analysis tool to scan for vulnerable systems
that are connected to affected systems.
4.5 Recovery and Closure
Restoring a system to its normal business status is essential. Information
Security Office reviews the tracking system and closes tickets when
appropriate.
Once a restore has been performed, it is also important to verify that the
restore operation was successful and that the system is back to its normal
condition.
4.6 Follow-up
Some incidents require considerable time and effort. It is little wonder, then,
that once the incident appears to be terminated there is little interest in
devoting any more effort to the incident. Performing follow-up activity is,
however, one of the most critical activities in the response procedure. This
follow-up can support any efforts to prosecute those who have broken the law.
This includes changing any company policies that may need to be narrowed
down or be changed altogether.
6. Organization
To adequately respond to an intrusion or incident, predetermined teams will
participate depending on the incident characteristics. As the situation develops and
the impact becomes more significant, the various teams will be called to
contribute. Figure 1 depicts the Incident Response organization.
Incident Management Information Dynamics Page 6
7. Escalation Levels
Whenever the impact of the incident increases (severity level increases) the
escalation process will be invoked to involve all appropriate resources. Incidents
should be handled at the lowest escalation level that is capable of responding to
the incident with as few resources as possible in order to reduce the total impact,
and to keep tight control. Following table defines the escalation levels with the
associated team involvement.
Escalation
Level
Affected Team(s) Description
0 Technical Assessment Team Normal Operations.
Engineering groups monitoring for alerts
from various sources
1
Technical Assessment Team
Incident Response Coordinator
Communication Team
A threat has been discovered.
Determine defensive action to take.
Message employees of required actions if
necessary.
2
Incident Response Management
Incident Response Coordinator
Technical Assessment Team
Technical Support Team
Communications Team
A threat has manifested itself.
Determine course of action for
containment and eradication. Message
employees of required actions if necessary.
3
Incident Response Management
Incident Response Coordinator
Extended Team
Technical Assessment Team
Technical Support Team
Communications Team
Incident Response Support
Threat is wide spread or impact is
significant.
Determine course of action for containment
and eradication. Message employees.
Prepare to take legal action for financial
Incident Management Information Dynamics Page 7
Team restitution etc.
8. The Incident Response Process
The Incident Response Process is an escalation process where as the impact of the
incident becomes more significant or wide spread, the escalation level increases
bringing more resources to bear on the problem. At each escalation level, team
members who will be needed at the next higher level of escalation are alerted to
the incident so that they will be ready to respond if and when they are needed.
Incident Management Information Dynamics Page 8