Information Security Incident Management Process

Process defines actions, roles responsibilities, and metrics to respond in the occurrence of an Incident. The Process is made easily available to all personnel whose duties involve data privacy.

Scope

This Process applies to CSIRT, all Employees, and Third parties related to the Incident. It applies to any records that contain personal or other Corporate Group’s information in any format and on any media, whether in electronic or paper form, as well as the Mission Critical Information Systems and Assets required to deliver Corporate Group‘s product and services.

Process Diagram

Incident Management Procedures

Detection & Analysis

No.	Procedure	Description	Result	Responsible	Time Limits	Systems Used
	Event Detection	Noticed, observed security event reported to CSIRT to perform identification procedure to determine if a security event can be identified as a Incident.	Reported to CSIRT observed security event	CSIFR, CSIRH	Immediately after observation	Email, phone, Slack, Jira
2.	Security Incident Handling Request	Determined what the nature of the security event is, the severity and extent of the security event and any additional information needed. Information of value in reporting a security event should follow five W’s (Who, What, When, Where, Why) principle, if possible, in order to provide meaningful information. Who is it about? What/How happened? When did it take place? Where did it take place? Why did it happen? If the security event reported in the ticket is determined to be a major Incident the procedure outlined in Incident Response STandard ANNEX C will be used to evaluate and handle the Incident.	Registered ticket Informed notifier Provided meaningful information	CSIFR, CSIRH	2 work hours after initial report	CSIRT
3.	Triage (Relevance, Classification, Identification)	Determined if the security event is a security incident, the classification of the incident type and severity, that subsequent actions can be prioritized. Incident classification and categorization must be made according to Incident Response Standard ANNEX E Security Incident Severity Classification and Information Security Incident Response Standard ANNEX D Security Incident Categorization. The basic questions that should be answered in this phase are: Is it really an Incident? How does it relate to Corporate Group? Are there any previous security incidents related to this incident? Does it fit within the mandate the CSIRT has? What is the impact, classification and categorization? Is there collateral damage? How many people do you need to handle this Incident? Which Incident handler should be appointed to the incident? What type of data affected, the number of records, and the specific individual(s) impacted (if applicable) as a result of the incident? If the reported event is determined not to be an Incident, the CSIRH must inform the notifier about the decision.	Determined and documented incident type, classification, category, priority. Determined if escalation is needed and informed CSIRTL	CSIRH	3 work hours after initial security event report	SIEM

Containment, Eradication & Notification

No.	Procedure	Description	Result	Responsible	Time Limits	Systems Used
	Initial Breach Notification	Informed Legal and Reputation departments about breach and provided additional information. Legal department determine what disclosures are legally required, including whether Corporate Group must give notice to individuals or authorities. The content of the breach notice should include: A description of the incident in general terms, A description of the type of personal data that was the subject of the breach and likely consequences of the personal data breach, A description of the general actions of Corporate Group to protect the information from further unauthorized access and/or acquisition, A Corporate Group contact information that the individual may use to get further information or assistance, Advice that directs the individual to remain vigilant by reviewing account statements and monitoring free credit reports, where applicable to the nature of the breach, and The timing of the notification.	Informed Legal and Reputation departments about breach. Noticed customers, employees or authorities about breach.	CSIRTL, Legal Department, Reputation Department	72 hours after the breach confirmation	Email
2.	Determine Response Strategy	Identified which resources, both internal and external, are at risk and which harmful processes are currently running on resources that have been identified as at risk to determine Incident response strategy. To decide best strategy pre-defined playbooks may be used. MISP must be also used to identify potential incident correlation with similar Incidents that are happening at the same time or happened in the short term. Additional support tickets can be created for specific activities in other ticketing/tracking systems, but all of them should be referenced from/to Jira.	Determined response strategy	CSIRH, CSIRTL	4 work hours after initial security event report	Jira, GitLab, MISP
3.	Containment & Eradication	Determined whether the resources at risk (hardware, software, users, services etc.) require physical or logical remediation. Resources posing a significant threat to the continuity of the business are to be immediately removed or isolated, either physically or logically. When permissible, backups are to be conducted for the affected systems onto new media as this provides a critical snapshot of the system during its compromised state. This backup, though not advisable for any production level restore, can be used for forensic analysis for learning more about how the incident came about. Forensic analysis will be done using the internal resources available, if it required or needed a 3rd party forensic investigator will be requested. All the activities conducted for containment and eradication must be documented in RTIR, referencing operational activities conducted on support tickets.	Confined and eradicated source of incident.	CSIRH, CSIFR	8 work hours after initial security event report	Jira, GitLab
4.	Breach Notification	Identified the type of data affected, the number of records, and the specific individual(s) impacted (if applicable) as a result of the Incident. The CSIRTL will coordinate with the Legal and Reputation departments to determine what disclosures are legally required, including whether Corporate Group must give notice to individuals or authorities. The CSIRTL and Legal and Reputation departments should coordinate to determine whether individuals need to be notified about the incident and how Corporate Group will provide notice. In general, notices should be sent by email if possible. Breach notice will consist of an email message featuring the official Corporate Group logo, addressed to the individual at the last recorded. Any notices returned as undeliverable should be re-sent via another channel if alternate contact information is available.	Updated Legal and Reputation departments about breach. Noticed customers, employees or authorities about breach.	CSIRH, CSIRTL, Legal Department, Reputation Department	72 hours after the breach confirmation	Email

Recovery & Post-mortem Analysis

No.	Procedure	Description	Result	Responsible	Time Limits	Systems Used
	Recovery	If there is need, CSIFR may recover affected information assets from backups or restored to primary state. Recovery process must be documented and stored for future use. In addition, the different steps followed during this stage must be formally registered, including all the individual supporting tickets created. For large-scale incidents, recovery may take months; the intent of the early phases should be to increase the overall security with relatively quick (days to weeks) high value changes to prevent future Incidents.	Recovered affected information assets	CSIFR, CSIRH	According to disaster recovery plan	Jira
2.	Post-mortem Analysis	Post-mortem is conducted intended to analyze the root cause of the incident and the failure conditions that led to the incident being able to initially occur and then spread inside of the Corporate Group environment. This post-mortem should utilize the template Post-mortem report should be shared amongst technology and senior leadership stakeholders for review and discussion of remedial actions to prevent repeated issues.	Documented and published post-mortem analysis.	CSIRTL	2 workdays after eradication	Jira, GitLab
3.	Final Report	The Incident documented in a final report, which should include all the steps followed, conclusion, next steps and lessons learned. Final report should use the template.	Documented Incident in a final report	CSIRTL	5 workdays after eradication	Jira

Review and Update

This Policy must be maintained in accordance with the Information Security Policy.

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	2024-09-10