Security incidents are adverse events that may damage information systems in a way that threatens a dimension of the information, such as Confidentiality, Integrity or Availability, which can be lost or compromised.
Security incidents are classified according to their family, based on the reference taxonomy provided by ENISA:
These security incidents can result in personal data breaches, physical security incidents or business continuity incidents.
The SOTER onboarding platform is a critical banking application with users’ personal data, which makes it quite attractive in terms of receiving attacks that could compromise the availability of the platform and the confidentiality and integrity of the data circulating on it. Therefore, SOTER has developed an incident response and reporting plan which includes an in-depth overview of standardisation activities and recommendations to respond to and report security incidents.
SOTER’s incident response and reporting plan
Currently, there are several cybersecurity incident management initiatives. Considering regional and local scopes, these are the most relevant, and used, as a basis for the definition of the incident response and report plan for SOTER:
Our incident response plan includes the following phases, as defined in the NIST directive:
Detection and Analysis
When a security incident occurs, it is not always detected instantaneously. This will depend on the necessary tools and the team in charge of detection. Detection mechanisms can be manual when they are notified directly by the team in charge or by intrusion detection tools.
Response and containment
Once the incident has been detected, identified, and analysed to categorize the impact, it is imperative to inform the administrative and technical contacts of the platform’s organization team, who are responsible for the management of the assets affected by the incident, before carrying out any containment or reactive measures involving the manipulation of the systems involved. This is a critical task for which a detailed Reporting Plan is developed.
The incident containment phase is based on limiting the severity of the incident as much as possible. To this end, the Platform should have detailed containment procedures for the different types of incidents. Mitigation measures should be as specific and efficient as possible so that their implementation does not affect the operation of other systems.
All actions taken in this phase should be documented, and all evidence collected during the process should be stored securely. If the incident involves legal proceedings, the evidence submitted shall be collected and handled following the rules laid down in the legislation in force.
Eradication or resolution of the incident (Recovery)
In this phase, the necessary actions are carried out so that the System recovers its capacities and provides service normally, restoring the affected information, services and resources. In addition, the search for protection measures must be initiated to prevent the incident from repeating itself.
System recovery will consist then in restoring the operation and, in some cases, it will be necessary to recover the information from the backups. Once the incident has been resolved and the systems are recovered, extensive monitoring is necessary to identify possible problems that have escaped analysis or to prevent the incident from recurring.
Post-incident activities (Continuous improvement)
While risk analysis and security plans exist, they should be reviewed and updated to ensure that any threat scenarios are addressed.
Post-incident activities consist in developing a report of the conclusions drawn from the incident management process, which should be completed and reviewed by all personnel involved in the incident.
The report and all evidence collected should be archived and kept under control so that only authorized personnel have access to it. Some evidence should be destroyed if the maximum retention period is legally required.
While incident reporting is implemented differently in each regulation, with different procedures, thresholds, etc., almost all regulators use a common procedure, a common template, and common thresholds for reporting to the Commission, ENISA, or any other entities.
The objective is to unify the requirements and procedures of the different regulations, which are similar, in a generic common reporting plan. When different regulations apply different criteria, the most restrictive will be chosen for the development of the common reporting plan.
The template of the common reporting plan must contain the relevant information of the incident and submitted to the competent authority. This template is composed of three different reports:
- Initial Report
- Intermediate Reports (1 or more)
- Final report
Authors: Eliseo Venegas Mayoral and Alvaro Romero Gomez, everis