This document is intended to define the management of information security incidents. Its objective is to establish clear guidelines and procedures to ensure that information security incidents are correctly recorded, reported and handled.
It also aims, through continuous improvement and the use of incident history, to create preventive and protective measures against the recurrence of incidents, as well as to feed into risk analysis and the review of other security controls and processes.
This plan is based on all activities, controls and processes of the Information Security Management System (ISMS).
This document is public and is intended to be accessed by employees of 2CLIX TECNOLOGIA EIRELI and its customers.
RESPONSIBILITIES
Every employee is responsible for notifying a security event to the Security team or to the person responsible for the affected area.
A security event is considered to be any event that affects the availability, integrity or confidentiality of the organization and of its own information and that of its customers. This includes events occurring on the organization’s premises and its physical assets, as well as on its digital assets and applications.
The Security team must register all event reports communicated through corporate communication channels. These records must be created following the Incident Record model stored in a specific folder within the Information Security files.
Once the occurrence has been recorded, the Security team must also handle it by collecting evidence from auditing and monitoring tools and managing communication about the incidents to the affected areas and individuals. The Security team must also initiate internal system normalization protocols.
The Administration team is responsible for contacting customers, suppliers and authorities. They must be provided with the reports and evidence gathered by the Security team and must initiate the system normalization protocols that require external communication.
It is the joint responsibility of the Security and Administration teams to prepare a control and resolution plan, as well as to provide bulletins containing information on timelines and system conditions during incident resolution.
Each incident must be treated seriously and, depending on its severity, the Administration team may call an extraordinary meeting with the Security team and representatives from the Support, Development and Projects teams to define the best resolution path for the incident.
NOTIFICATION
Notifications of events or incidents may arise in different ways, depending on how the event was detected.
SIEM
Security events detected by the SIEM and by the team that monitors the logs collected by this system must be communicated directly to the System Administrator or the Security Manager, with information and evidence relating to the security event.
Unavailability of Web Environments
Events related to the availability of web environments, servers and databases are detected by the monitoring application. This application detects unavailability and its level of impact and automatically creates a record, sending an email alert to designated users (Security Manager and System Administrator) indicating where the unavailability occurred, its severity and how long it has been ongoing.
In this application, custom reports can also be created, allowing employees to generate an alert even when scanners and automations do not detect partial unavailability.
User/Customer Tickets
Tickets regarding suspicious system behavior reported by customers, as well as suspected or actual security events in their environments that reach the Support team, must be forwarded to the Security team through the company’s communication channels together with all evidence collected from the customer.
Internal Events
If, during the use of workstations, performance of duties or use of the organization’s physical environments, a suspicious event is identified, the Security team and System Administrator must be contacted by the employee who identified the issue through the organization’s communication channels. This initial notification must be followed by evidence collection and event logging by the Security team.
Critical Events
When a security event is highly critical and its impact must be mitigated with speed and urgency, notification must be sent directly to the System Administrator or to the competent Authorities, depending on the occurrence. Normalization and data mitigation protocols must be initiated together with the logging processes. The Security team must work together with the System Administrator to ensure that evidence is preserved, affected parties are notified and normalization is achieved as quickly as possible.
VULNERABILITY
Every vulnerability found must be reported, even if it is only a suspected vulnerability or a scanner false positive.
Employees or Suppliers
When a vulnerability or suspicion is found by a member of the employee or supplier teams, the Security team must be informed through the organization’s communication channels. This notification must be logged by the Security team, which must begin an investigation to verify the existence and potential impact of the vulnerability and prepare a communication summarizing the security improvements that the identification and correction of the vulnerability will bring.
Customers and Users
Vulnerabilities or suspicions identified by customers must be communicated through the organization’s contact channels, going through Support via help center, email or phone. In such cases, Support must collect all information and evidence that the customer has regarding the vulnerability and prepare an email summarizing this information for the Security team. During this contact, the Support team must instruct the user not to exploit the vulnerability and thank them for the report.
The Security team must investigate the vulnerability and prepare an official communication about the risk and the control and correction measures applied to address it. This communication must be sent by Support to the customer who reported the vulnerability.
EVENT EVALUATION
Events must be evaluated based on their severity and impact. Low to medium criticality events must be evaluated by the Security team, which must gather all evidence and store it in the folders and directories dedicated to the secure storage of such information. Once the events have been evaluated and their causes and impacts identified, the Security team must initiate the actions necessary to normalize and correct the incident.
High or very high criticality events must be evaluated by the Security team together with the System Administrator and, depending on the event, a representative from the Support and Development teams. For these events, logging and evidence collection must take place concurrently with normalization actions and correction of the causes of the incident.
If the reported event is assessed as a Security Incident, evidence collection must begin from the sources that identified the event and move through audit trails, contacting the Data Center and suppliers to check status or specific records in their services, verifying change plans as well as reviewing code. Depending on the severity and type of incident, it may be necessary to hire a specialist to perform forensic analysis on affected machines, networks and other assets.
All evidence collected must be saved both in the company’s digital repositories and on the backup server to maintain redundancy.
If the reported event is not considered a security event, a report must be generated explaining the causes of the event, its impacts and the evidence justifying why it is not considered a Security Incident.
INCIDENT RESPONSE
Once a security incident has been identified and confirmed, the Security team together with the System Administrator must determine the cause of the problem and its scope of impact.
Once the cause has been found, a diagnosis must be prepared indicating the actions necessary for normalization and, where possible, correction of the issue that caused the incident. This diagnosis is then shared with the necessary employees and suppliers so that corrective actions can be taken and the incident can be normalized.
At the same time, while normalization is underway, all those affected by the incident must be notified about the current situation, estimated time for normalization and, where applicable, estimated time for full correction if the incident requires additional maintenance.
EVIDENCE COLLECTION
Evidence includes all information that provides proof of the event, its causes or impacts. Evidence collection therefore begins with the material provided at the time of event notification, such as: screenshots, alert emails about suspicious interactions, antivirus alerts, network or firewall alerts, and even photos. From this starting point, the Security team must seek evidence in audit trails, reviewing logs of both the platform and internal systems; the SIEM, Database, IDS and Azure must be checked for records that corroborate the reported incident.
If the incident occurs on a physical asset, the device will be removed from the network and sent to a consulting firm for forensic analysis.
Once all evidence of the occurrence and impact of the incident has been gathered, it will be analyzed to identify the cause of the incident and define the best course of action to correct that cause and normalize everything that was affected.
CONTINUOUS IMPROVEMENT
At the end of the entire Incident handling process, when systems and networks have been normalized and the causes identified and addressed, a final report must be prepared by the Security team containing feedback on the occurrence, the controls used for correction and possible improvements in processes, controls or equipment to prevent recurrence of the incident.
Based on this report, the proposed improvements may be forwarded to the Administration team, following the Change Management process for implementation.
Training sessions may also be scheduled to reinforce processes or provide refresher training for employees who need it.
DOCUMENT MANAGEMENT
This document is valid from the date of its most recent approval and is the responsibility of the Administration team of 2CLIX TECNOLOGIA EIRELI. The update cycle for this document is annual and must always be based on an assessment of the effectiveness and suitability of this document in relation to the company’s other policies and processes.
To ensure a concise and clear assessment, the following evaluation criteria will be used:
- Feedback from interested parties regarding the effectiveness and impact of the ISMS;
- Trend in the number of recurring security incidents;
- Incident response time;
- Trend in incidents caused by misuse of personal equipment;
- Feedback from training sessions;
- Trend in the number of serious security incidents caused by failure to notify by customers or employees;
- Feedback from customers and employees after handling of incidents;
- Trend in occurrences caused by unclear or incomplete definitions of incident management procedures.
