Information Security Incident Response Standard

This Standard and supporting procedures are designed to provide EClaims Group with a documented and formalized Incident Response Plan.

Overview

This Standard defines roles and responsibilities concerning identification, response, isolation, eradication, recovery, and communication in the event of a breach of security to which all staff must adhere to in the course of conducting business operations.

It is based on industry best practices, international privacy requirements, and other applicable regulatory requirements.

This Standard clearly defines to whom it applies and under what circumstances, and it includes the definition of a breach, roles and responsibilities, standards and metrics (e.g., to enable prioritization of the Incidents), as well as reporting, remediation, and feedback mechanisms. The Standard is made easily available to all personnel whose duties involve data privacy and security protection.

Scope

This Standard applies to all employees and Third-parties.It applies to any records that contain personal or other EClaims Group‘s information in any format and on any media, whether in electronic or paper form, as well as the Critical Information Assets required to deliver EClaims Group’s product and services.

Composition of CSIRT

CSIRT (Cyber Security Incident Response Team) is a cross-functional team of consistent and temporary members from different departments whose tasks are distributed between them.

For certain security incidents CSIRT will include temporary members depending on the nature and scope of the incident. Temporary CSIRT members may include, but not limited to:

1. Human Resource representative

2. Finance department representative

3. Other team members from operations, technology or specific asset owners may be involved in the CSIRT for a given incident, as appropriate, to reasonably ensure that maximum visibility into the incident is obtained for investigative and response purposes.

Regardless of status within CSIRT - temporary or consistent member, everyone engaged in CSIRT activities should always safeguard security incident data and restrict access to it because it often contains sensitive information. Security incident communications (e.g., emails), specific documents and other data related with CSIRT activities should be encrypted, if possible, and must follow the Traffic Light Protocol (TLP) for information classification so that only authorized personnel can read and/or access them.

Consistent team members are defined in the ANNEX A - MEMBERS OF CSIRT.

Roles and Responsibilities

Cyber Security Incident Response Team (CSIRT) - is responsible for minimizing the damage to or vulnerability of information assets throughout the lifecycle of an incident. This includes further investigation of the incident, mitigation plan and/or actions of immediate risks involved, breach notification, documentation and conducting a post-mortem of the incident.

Cyber Security Incident Response Team Leader (CSIRTL) - this role should be assigned to CISO/CIO, unless mandated to another dedicated person. The CSIRTL will own all incidents handled by the CSIRT and be responsible for managing and coordinating the overall response and reporting activities for security incidents handled by the CSIRT.

Cyber Security Incident Response Manager (CSIRM) - coordinates day-today work of incident handling team; decide how to act in problematic situations; determines, with assistance from CSIRH and CSIFR, the severity of an incident; advise on how to handle incidents, Escalate if necessary; propose improvements for CSIRT work, organize periodic meetings for discussions about incident handling work within team; report to CSIRTL and higher management if needed.

Cyber Security Incident Response Handlers (CSIRH) - responsible for analyzing incoming incidents that were assigned to the team; propose improvements in the incident handling process; follow and track new types of incidents, attacks techniques etc.

Cyber Security Incident First Responders (CSIFR) - anyone within the EClaims Group can act as a first responder, given the fact that a person is familiar with incident response plan and has gone through introduction trainings on incident responder duties. CSIFR are responsible for reporting potential security incident (-s) by informing CIRTL, please refer to the Reporting Methods section. They may be assigned as temporary CSIRT members to assist in response to specific incidents as needed. Temporary CSIRT team members may include subject matter experts for particular systems, applications or business issues involved in the incident. Temporary team members are generally assigned to an incident by their managers at the request of the CSIRT Team Leader, and serve for the duration of the incident.

Legal Department - when engaged by the CSIRTL, a representative from the Legal Department will assist to advise the CSIRT on legal matters relating to evidence handling, breach notification or other related matters.

Reputation Department - when engaged by the CSIRTL, will establish and maintain communication with customers, employees, media and other stakeholders. As well as coordinate the efforts required to regain trust with customers and partners.

Security Event, Incident and Data Breach Definition

Security Event Definition - Security event is any observable occurrence (a change in the normal behavior of a given system, process, environment, or workflow) that could potentially have information security implications.

Security Incident Definition - not all events are Incidents, but all Incidents are events. A security Incident is an event that threatens the security, confidentiality, integrity, or availability of Information Assets, information systems, and/or the networks that deliver the service, customers’ personal data, including, but not limited to user credentials, traffic interception, payment data, device information or any other type of personal data. Any violation of computer security policies, acceptable use policies, or standard computer security practices is an Incident.

Data Breach Definition - A data breach is a type of security Incident. All data breaches are security Incidents, but not all security Incidents are data breaches. Data breach is a security (or privacy) Incident that meets specific legal definitions per country and/or region.

Security Event or Incident Reporting

Notice of all security events, including detailed information about the event, irrespective of origin, must be immediately forwarded to CSIRT, see 7.2 Reporting Contacts. In general, this will be done through forwarding or sending an email to the dedicated email inbox.

Reporting Contacts:

Internal contacts to report security events/incidents:

• Dedicated email for general security related inquiries: [email protected]

• Dedicated email for reporting security events/incidents: [email protected]

• Dedicated Communication channel to register incidents: #risk or tag @security

• Incident report form (<- link to the form is needed)

• Operating Hours: 09:00 - 18:00, Weekdays

• Timezone: UTC+3 (EEST)

• In case of emergency, please refer to “Annex A - Member of CSIRT” for direct contact list

Communication channel for External inquiries:

• Dedicated email for general security related inquiries: [email protected]

• Operating Hours: 08:00 - 17:00, Weekdays

• Timezone: UTC+3 (EEST)

• Operating Hours: 24/7/365

Plan Testing and Training

At least once a year, a mock Incident will be initiated to facilitate testing of the current plan. The exact Incident to be tested will be at the discretion of the CSIRT.

All Employees that could have an active role within Incident response will be part of the test process.

Training regarding Incident response responsibilities must be performed regularly to ensure employee’s readiness for test and actual Incidents.

Document Administration

Enforcement - Violations of this incident response plan will result in disciplinary action, in accordance with EClaims Group’s information security policies and procedures and human resources policies. EClaims Group’s disciplinary process is outlined in the Internal Work Rules.

Program Review - CSIRM shall review this Incident Response Plan and the security measures defined herein at least annually, or whenever there is a material change in EClaims Group’s business practices that may reasonably implicate the security, confidentiality, integrity, or availability of records containing personal or other sensitive information. EClaims Group shall retain documentation regarding any such program review, including any identified gaps and action plans.

Annex A - Members of CSIRT

Members of CSIRT Responsible people in CSIRT may vary depending on the affected product. The following table explains who should be included in the process of remediation and damage control in case of a Security Incident.

EClaims

CEOs	Daiva Meškauskienė
Product Owner	Henrikas Meškauskas
Technical Lead	Giedrius Kilikevičius
CISO (temp)	Giedrius
Reputation Department	Henrikas Meškauskas
CRO	Giedrius
Legal	Daiva Meškauskienė
CSIRTL	CISO
CSIRM
CSIRH	CSIRT, AppSec, WebSec teams
CSIFR	Any EClaims Group Employee

Annex B - RASCI Matrix

Responsible - Person who is responsible for executing or doing the activity

Accountable - Person who owns, approves, and is the final decision maker for the activity

Support - Person who is allocated to responsible person, support helps complete the task

Consulted - Person who can provide further information or feedback for performing the activity

Informed - Person who only needs to be informed about the activity's progress or status

Incident Identification	I	I	I	RC
Determine Level of risk	A	S	R	S	C	C	I*	I*	I*
Update Incident Record/Timeline	I	R	A	S
Incident Logging	R	AR	R
Incident Categorization	S	AR	S		I*	I	I*	I	I*
External Notification and Communication (if applies)	S	S	S		AR	R	I*	I	I*
Incident Prioritization	S	AR	S		C	C		C	C
Investigation and Diagnosis	A	S	S		I	I		C	C
Management Escalation	AR	S	S		C	C		C/I	C
Resolution and Recovery	AR	S	S					C/I	C
Incident Closure	AR	S	S		I*	I*	I*	C/I	I*
Lessons Learned / Post Mortem report	AR	S	S		I*	I*	I*	I*	I*
Final Report	AR	S	S		I*	I*	I*	I*	I*

* Only when incident is classified as Critical

Annex C - Security Incident Impact and Prioritization

A security incident is prioritized based on the Impact and Urgency of the reported security event. Impact: Defines how widely the security incident affects Corporate Group

High	Negative impact to business reputation, negative user reaction, financial and liability impacts.	DDoS attacks, phishing site, unauthorized access to Corporate Group information, PII compromise
Medium	Important or severe impact. Important disruption of business operations.	Malware distribution, performance issue affecting a small number of assets
Low	Limited impact or minor disruption to business operations.	Spam, copyright issues

Urgency: Defines the level of business criticality of the affected service(s)

High	Core of business or critical support services are affected	Unauthorized disclosure of confident; Affected resource(s) has a severe impact to production; Incident investigation and response is transferred to law enforcement; Widespread damage actively impacting multiple teams/departments; Severe impact on resources to the extent of knowledge; User or resource is affected and there is confirmation that personal or confidential information is compromised; There is active public interest in the incident; Reconnaissance attempts are preceded by an attack; Incident investigation and response is transferred to law enforcement; Disruption is wide spread across multiple business units
Medium	General services are affected.	Unauthorized disclosure of confidential information has not been determined; Incident involves business critical services; Affected resource(s) has a moderate impact to production. Moderate impact on resources to the extent of knowledge; User or resource is affected and there is the potential for compromise of personal or confidential information; There is the potential for public interest; Incident affects few business units within the Corporate Group Reconnaissance attempts remain consistent;
Low	Non-critical services and/or non-data are affected	Unauthorized disclosure of confidential information has not occurred; Incident does not involve mission critical services; Affected resource(s) is not considered business critical; Minimal impact on resources to the extent of knowledge; User or resource is affected that does not deal with personal or confidential information; Low potential for public interest; Reconnaissance attempts have minimal impact on resources; Incident is within a single business unit;

Annex E - Security Incident Classification

Abusive Content	Spam	"Unsolicited Bulk Email", this means that the recipient has not granted verifiable permission for the message to be sent and that the message is sent as part of a larger collection of messages, all having a functionally comparable content
Malicious Code	Virus, Malware, Trojan, Rootkit etc.	Software that is intentionally included or inserted in a system for a harmful purpose. A user interaction is normally necessary to activate the code.
Information Gathering	Scanning	Attacks that send requests to a system to discover weak points. This includes also some kind of testing processes to gather information about hosts, services and accounts. Examples: DNS querying, ICMP, SMTP (EXPN, RCPT, …), port scanning
	Sniffing	Observing and recording of network traffic (wiretapping).
	Social Engineering	Gathering information from a human being in a non‐technical way (e.g. lies, tricks, bribes, or threats).
Intrusion Attempts	Exploiting known vulnerabilities	An attempt to compromise a system or to disrupt any service by exploiting vulnerabilities with a standardized identifier such as CVE name (e.g. buffer overflow, backdoor, cross site scripting, etc.).
	Login attempts	Multiple login attempts (Guessing / cracking of passwords, brute force).
	New attack signature	An attempt using an unknown exploit
Availability	DoS, DDoS, Outage etc.	By this kind of an attack a system is bombarded with so many packets that the operations are delayed or the system crashes. The availability also can be affected by local actions (destruction, disruption of power supply, etc.) - or by Act of God, spontaneous failures or human error, without malice or gross neglect being involved.
Fraud	Unauthorized use of resources	Using resources for unauthorized purposes including profit-making ventures (E.g. the use of e-mail to participate in illegal profit chain letters or pyramid schemes).
	Copyright	Offering or Installing copies of unlicensed commercial software or other copyright protected materials
	Phishing	Masquerading as another entity in order to persuade the user to reveal a private credentials or information.
Vulnerability Discovery	Nessus Scanning	Vulnerabilities identified by our self by scanning internal/external infrastructure
Other	All incidents which don't fit in one of the given categories should be put into this class	If the number of incidents in this category increases, it is an indicator that the classification scheme must be revised.
Test	Meant for testing	n/a

Revision History

Version	Author	Approved By	Revision date	Approval date
0.1	LŠ	GK	2023-05-20	2023-05-23
0.2	LŠ	DM	2023-11-02	2023-11-02
0.3	GK	DM	2024-09-10	22024-09-10