MDA

No:
Cybersecurity Policy

Updated: 01/07/2022

Issued by: ICTU

Cyber Incident Response
Owner: ICTU

1.0 Purpose
This policy outlines the general steps for responding to computer security incidents and
includes a standardized process flow,
(1) identifying the incident response (IR) stakeholders and establishes their roles
and responsibilities;
(2) describing incident triggering sources, incident types, and incident severity
levels;
(3) including requirements for annual testing, post-incident lessons-learned
activities, and collection of IR metrics for use in gauging IR effectiveness.
To ensure consistent security of the Nation through the response to cyber security
incidents by the Ministry Departments and Agencies (MDAs), allowing the
investigations, remedies, reports and response to cyber security incidents and data
breaches.
1.1 Goals
The goals of IR, as outlined in this policy, are to:
 Confirm whether an incident occurred;
 Provide a defined incident notification process;
 Promote the accumulation and documentation of accurate information;
 Establish required controls and standards for monitoring, incident reporting and
handling with clearly defined roles and responsibilities for proper retrieval and
handling of evidence;
 Contain the incident and stop any unwanted activity quickly and efficiently;
 Protect national systems while preventing disruption to government services
and network operations;
 Provide accurate reports and useful recommendations to management; and
 Prevent and/or mitigate future incidents from occurring.

Cyber Incident Response Policy Page 1 of 12

2.0 Authority
MDA

3.0 Scope
This policy applies to

4.0 Information Statement

4.1 IR Stakeholder Roles and Responsibilities
To respond effectively to a computer security incident, it is critical that all IR stakeholders
fully understand not only their roles and responsibilities in the IR process, but also the
roles and responsibilities of each IR stakeholder. This is necessary to
(1) avoid duplication of effort;
(2) minimize procedural gaps that may occur; and
(3) ensure rapid response to computer security incidents.
IR stakeholders include:
1. Accounting Officer– The, designee, provides for overall coordination of IR
including the escalation of an incident. The Designee leads incident response
services for the government entity.
2. Entity Leadership - Provides mainly IR oversight, with their Information
Technology Security Specialist (ICTSS) or designee, being the most ‘hands-on’
in terms of IR management activities.
3. Trinidad and Tobago Cyber Security Incident Response Team – The TTCSIRT
serves as a central group for detection, analysis, tracking, response to and
reporting of cyber threats and incidents. TTCSIRT responds to incidents by
providing hands-on technical IR and will recommend steps for staff to remediate
and mitigate such that it reduces the likelihood of future incidents.?
In addition, TTCSIRT facilitates collaboration and information sharing with other
entities that may be experiencing the same or similar incidents to assist in
resolving the problem more efficiently and effectively. TTCSIRT collects
information on the types of vulnerabilities that are being exploited and the
frequency of attacks and shares preventative information to help other
organizations protect themselves from similar attacks.?

Cyber Incident Response Policy Page 2 of 12

 4. First Responders – IT staff, such as network managers, system administrators,
and other technical personnel, will be called upon, as needed, to provide support
and tactical response to IR team.
5. Agency Incident Response Teams – Predefined teams must be ready which
include, at minimum, Executive Management, Legal and the Public Information
Officer. In some cases, Human Resources and Labor Relations may become
involved.
6. External Entities - In consultation with TTCSIRT, external entities may conduct
hands-on IR activities, such as investigative response activities, or may provide
guidance. External entities may include but are not limited to service providers, or
law enforcement, such as:
 TTPS Cyber Crime Unit
 Internet Service Providers

4.2 IR Process Flow

This IR process flow covers how to respond to specific situations for IR stakeholders to
ensure an effective and efficient response. The focus of the IR process is to eradicate
the problem as quickly as possible, while gathering actionable intelligence, to restore
business functions, improve detection, and prevent reoccurrence. An entity can adopt
the six step IR process flow as depicted below1:

1– 2– 3– 4– 5– 6–
Preparation Identification Containment Eradication Recovery Lessons-
Learned

Figure 4.1 – Incident Response Process Flow

Step 1: Preparation

Activities associated with this step include establishing IR teams; updating IR tools,
policies, procedures, forms and checklists; and ensuring IR communication procedures
and IR stakeholder contact lists are accurate and up-to-date. An entity must have a
defined and up to date Contact List and establish multiple communication channels with
all entities and individuals on the IR Contact List.

1
Based on the SANS Institute Incident Handling Step-by-Step

Cyber Incident Response Policy Page 3 of 12

An entity must assign responsibility for a central point of contact to coordinate
identification and reporting to the or ICT Manager. Typically, this is performed by the
entity’s designated security representative. As per the Information Security Policy, all
employees are required to report suspected information security incidents or
weaknesses to the appropriate Manager and designated security representative.
The ICTU will establish standard operating procedures (SOPs) for IR to reflect industry
standards and best practice. These SOPs will be followed during incident response. Any
exception must be properly documented. The ICTU must routinely vet and validate the
tools and techniques used for IR. In order to operate efficiently and effectively, the IR
process must be regularly tested. This must occur at least annually. This testing can be
accomplished with mock incident training or tabletop exercises using realistic scenarios
to provide a high-level outline and systematic walkthrough of the IR process and, to the
extent possible, must include all IR stakeholders. These training scenarios must include
specific 'discussion points' that represent key learning opportunities and incorporate
lessons learned, which can then be integrated into the IR process as part of its review.
Step 2: Identification
Identification involves review of anomalies to determine whether or not an incident has
occurred, and, if so, determining the nature of the incident. Identification begins with an
event, an anomaly that has been reported or noticed in a system or network. Detection
can be accomplished through technical sources (e.g., operations staff, anti-virus
software), non-technical sources (e.g., user security awareness and reporting), or both.
Keeping in mind, not every network or system event will be a security incident, the first
responder must be assigned to determine if there is an incident, categorize the incident
and escalate as necessary. Typically, this will be the entity’s ACCOUNTING OFFICER
or designated representative.
Incidents must be classified and escalated as soon as possible to the proper IR
stakeholders to promote collaboration and information sharing. Incident classification
requires the use of established incident categories together with an incident severity
matrix as a means for prioritizing incidents and determining appropriate IR activities.
Incident Categories
It is important to categorize common incidents experienced so that stakeholders can
better focus their IR activities. It should be noted that incidents can be classified into
more than one category, and classification may change as the investigation progresses.
An entity can adopt the Reference Incident Classification Taxonomy by European Union
Agency for Cybersecurity (ENISA) as follows:

https://www.enisa.europa.eu/publications/reference-incident-classification-taxonomy

Table 4.2 – Incident Categories

Cyber Incident Response Policy Page 4 of 12

Incident Severity Matrix

All information security incidents should be categorized according to severity level to

assist in determining the extent to which a formal IR is required. Severity levels are
based on the perceived business impact of the incident. Severity levels may change as
the investigation unfolds. General definitions and description of each severity level are
as follows:

Incident Severity Matrix

Level Definition Examples
Incidents that have a severe— Compromise of sensitive data
impact on operations — Widespread malicious code attack
High
— Unauthorized access to critical systems
— DDoS affecting the entire network
Incidents that have a — Small-scale DDoS attack
significant impact, or the — Website compromises
Medium
potential to have a severe — Unauthorized access (brute force attacks
impact, on operations against FTP, SSH, and other protocols)
Incidents that have a minimal — Network probes or system scans
impact with the potential for — Isolated virus infections
Low
significant or severe impact — Acceptable use violations
on operations

Table 4.3 – Incident Severity Matrix

Escalation Procedures
During an incident, clear and effective communication is critical. Escalation procedures
should address all lines of communication in the event an incident occurs. This includes
not only internal communication but external communications as well, when
appropriate. Communication should flow through all involved IR stakeholders so that
everyone has the necessary information to act and carry out their responsibilities in a
timely manner. Notification must be made as soon as possible but should not delay the
entity from taking appropriate actions to isolate and contain the effects of anything that
threatens the confidentiality, integrity and availability.
Each entity must have an IR escalation procedure that consists of
(1) an escalation matrix
(2) an up-to-date contact list with alternate contacts
(3) multiple communications channels

Cyber Incident Response Policy Page 5 of 12

all to ensure appropriate and accurate information is disseminated quickly to the
appropriate IR stakeholders.
Incident Scoping
Initial scoping is provided by the entity and includes:
 Identifying potential targets (e.g., known compromised systems, likely affected
systems, key systems);
 Defining external touch points (e.g., Internet, wireless, 3rd party, remote access
connections);
 Prioritizing likely scenarios (e.g., internal vs. external threat, targeted attack vs. a
target of opportunity); and
 Visualizing in-scope environment (e.g., network diagram, data flow).
Considerations for incident scoping activities are as follows:
 Relying on relevant and verified evidence sources;
 Reducing false positives and volume of data;
 Avoiding excessive scope and ‘scope creep’; and
 Realizing operational and resource limitations may affect scope.
As additional incident-related information develops during the IR process and as
additional stakeholders become involved, an incident typically requires re-scoping.
Incident Tracking & Reporting
A secure centralized tracking system that can accommodate ‘need to know’ access,
leads to a more efficient and systematic IR effort, as well as provides an audit trail should
the efforts lead to legal prosecution of the threat.
At a minimum, documentation of the incident must contain the following information:
 Date/time the incident was reported
 Type of Incident
 Reporting source of incident
 Summary of the incident
 Current status of the incident
 All actions taken concerning the incident
 Contact information for all involved parties
 Evidence gathered during incident investigation
 Relevant comments from IR team members
 Proposed next steps to be taken

Cyber Incident Response Policy Page 6 of 12

 Step 3: Containment

This step focuses on containing the threat to minimize damage. It is during this step that
information is collected to determine how the attack took place. All affected systems
within the enterprise should be identified so that containment (eradication and recovery)
is effective and complete.
Incident containment involves ‘stopping the bleeding’ and preventing the incident from
spreading. Containment can be accomplished by isolating infected systems, blocking
suspicious network activity, and disabling services among other actions. Containment
varies for each incident depending on the severity and risk of continuing operations.
Entity leadership makes decisions regarding containment measures based on
recommendations from the Accounting Officer.
Step 4: Eradication

Eradication involves removing elements of the threat from the affected systems or
network. Specific eradication measures depend on the type of incident, the number of
systems involved, and the types of operating systems and applications involved.
Eradication measures include but are not limited to reimaging infected systems and
enhanced monitoring of system activity. Remediation includes the repair of affected
systems and services, addressing residual attack vectors against other systems,
communication and instructions to affected parties and an analysis that confirms the
threat has been contained.
If the ACCOUNTING OFFICER or Privacy Officer reasonably believes that an exposure
of regulated data may have occurred, the ACCOUNTING OFFICER or Privacy Officer
will contact the Office of the General Counsel to provide situational information in
determining a proper response.
Analysis of information collected is an iterative process known as the after-action
analysis and occurs/reoccurs during both the containment and eradication phases.
Step 5: Recovery

Once the root cause of an incident has been eradicated, the recovery phase can begin.
The goals of this step are to:
(1) remediate any vulnerabilities contributing to the incident (and thus prevent future
incidents) and
(2) recover by restoring operations to normal.
At this phase, affected systems are returned to normal operation, hardened to prevent
similar future incidents, and heighten monitoring for an appropriate period of time.
Recovery activities must include rebuilding systems from trusted images/gold
standards, restoring systems from clean backups and replacing compromised files with
clean versions.

Cyber Incident Response Policy Page 7 of 12

Care must be taken to ensure that files restored from backup do not reintroduce
malicious code or vulnerabilities from the incident and that the system is clean and
secure before returning to production use. Once recovery has been completed, the IR
lead must validate/certify that the incident has been resolved.
Step 6: Post Incident Activity/Lessons Learned

An IR process is only as good as the ability to execute it successfully. Lessons learned

can be the results of actual IR activities or IR capability testing. These results should be
used to improve the IR process by identifying systemic weaknesses and deficiencies
and taking steps to improve on these. It is important that this take place relatively soon
after the incident is closed.
Lessons learned, or post-mortem, discussions provide
(1) a record of steps taken to respond to an attack
(2) investigative results into determining the root cause of the attack
(3) potential improvements to make, such as IR stakeholder training and certifications
process and procedural updates, and technical modifications.
Knowledge gained can be used in an effort to prevent and/or mitigate future incidents in
the form of proactive services. This may include testing the IR process, conducting
vulnerability assessments, providing computer security training, reviewing security
policies and procedures, and disseminating cyber security reminders.
Both incident reports and the results of these lesson-learned discussions should be
placed into a database established for future use and shared with all IR stakeholders for
situational awareness and professional development.
4.3 Incident Response Metrics
IR metrics must be compiled for each incident and reported to the ACCOUNTING
OFFICER for situational awareness when possible and practical.
These metrics allow IR stakeholders
(1) to measure IR effectiveness (and reveal potential gaps) over time;
(2) identify trends in terms of threat activities and in doing so;
(3) to provide justification for additional resources, including additional personnel,
training, and tools.

IR Metrics
Category Measurement Description
Incidents # Total Incidents / Year Total amount of incidents responded to per
year

Cyber Incident Response Policy Page 8 of 12

 IR Metrics
Category Measurement Description
# Incidents by Type / Year Total number of incidents by category
responded to per year
Time # Personnel Hours / Incident Total amount of labor spent resolving the
incident
# Days / Incident Total amount of days spent resolving
incident
# System Down-Time Hours / Total hours of system downtime until the
Incident incident is resolved
Cost Estimated Monetary Cost / Total estimated monetary cost per incident,
Incident to include containment, eradication, and
recovery, as well as collection & analysis
activities (this may include labor costs,
external entity assistance, tool
procurements, travel, etc.)
Damage # Systems Affected / Incident Total number of systems affected per
incident
# Records Compromised / Total number of records compromised per
Incident incident
Forensics # Total Forensics Leveraged Total number of incidents requiring
Incidents / Year forensics (collection & analysis) per year
# System Images Analyzed / Total number of system images analyzed
Incident per incident
# System Memory Dumps Total number of system physical memory
Examined / Incident dumps examined per incident

Table 4.4 – Incident Response Metrics

5.0 Compliance
This standard shall take effect upon publication. Compliance is expected with all
government policies and standards. Policies and standards may be amended at any
time.
If compliance with this standard is not feasible or technically possible, or if deviation from
this policy is necessary to support a business function, entities shall request an
exception through the Accounting Officer exception process.
5.1 Compliance Measurement

Cyber Incident Response Policy Page 9 of 12

Each business unit must be able to demonstrate that it has a written IRP in place, that it
is version controlled, and is available via the web. The policy should be reviewed
annually.
5.2 Exceptions
Any exception to this policy must be pre-approved by the ICTU and have a written
record.

6.0 Definitions of Key Terms

Term Definition
Event An event is an exception to the normal operation of IT
infrastructure, systems or services. Events may be identified
through the use of automated systems; reported violations to
the ICTSS or in the course of normal system reviews including
system degradation/outage. It is important to note that not all
events become incidents.
Incident An incident is an event that, as assessed by ISO staff, violates
the Acceptable Use Policy, Access Control Policy, Confidential
Data Policy, and Code of Conduct or threatens the
confidentiality, integrity, or availability of Information Systems
or Institutional Data.
Data Breach Unauthorized access, acquisition, use or disclosure of
Restricted Data. Data breach notifications are subject to
regulatory requirements following a privacy investigation and
risk assessment.
Regulated Data Regulated Data may have additional reporting and regulatory
Classification requirements when dealing with incidents.

7.0 Types of Regulated Data

Type Definition
Personally PII is defined as a person’s first name or first initial and last
Identifiable name in combination with one or more of the following data
Information (PII) elements:

 National-issued driver’s license number

 National-issued identification card number

Cyber Incident Response Policy Page 10 of 12

  National-issued passport number
 Financial account number in combination with a security
code, access code or password that would permit access to
the account
 Medical and/or health insurance information

Health Information HI is identified as “individually identifiable health information”

transmitted by electronic media, maintained in electronic
media, or transmitted or maintained in any other form or
medium. HI is considered individually identifiable if it contains
one or more of the following identifiers:
 Name
 Address (all geographic subdivisions smaller than state
including street address, city, village/borough, or zip
code)
 All elements of dates (except year) related to an
individual including birth date, admissions date,
discharge date, date of death
 Telephone numbers
 Fax numbers
 Electronic mail addresses
 Medical record numbers
 Health plan beneficiary numbers
 Any other unique identifying number, characteristic or
code that could identify an individual

8.0 Contact Information

Submit all inquiries and requests for future enhancements to the policy owner at:
[MDA Address]

9.0 Revision History

This standard shall be subject to periodic review to ensure relevancy.

Cyber Incident Response Policy Page 11 of 12

 Date Description of Change Reviewer

10.0 Related Documents

Cyber Incident Response Policy Page 12 of 12