Internal Incident Identification

Internal incident sources are the primary incident declaration channel by volume. Incidents are usually identified by the information technology (IT) teams such as the network, desktop, or IT surveillance teams, the users through the help desk, or even IT partners. After being analyzed by the IT teams, certain events may be flagged as cybersecurity incidents if the cause of the incident is related to information security (e.g., a breach of confidentiality or system unavailability due to malicious actions or data theft). To make this process operational, communicate a list of the different types of incident you want to track with examples. Start small and increase the list over the years. These technical incidents must be dealt within an appropriate incident management tool of the IT department in order to be efficient and to manage the large “industrial” scale of occurrences.

External Incident Identification

External incident sources are the secondary incident sources declaration channel by volume. They usually originate from coworkers, external partners, or law enforcement, which may contact the information security team to declare an incident. This is where you will probably encounter the most critical incident and probably need to internally store them in a separate tool to ensure confidentiality as the usual internal IT incident management tools are accessible by hundreds of people.

Qualifying Incidents

A structured and formal qualification process must be put in place to ensure that an identified incident will be managed with the appropriate level of attention. Several criteria need to be agreed and used to evaluate incidents. These should include:

• Sensitivity of the data or processes concerned (e.g., research and development [R&D] and data dealt with by VIP’s, the Very Important People in the company such as Senior Management).
• The functional perimeter (e.g., number of users or entities impacted).
• The technical perimeter (e.g., number of workstations/servers impacted, partner’s systems).
• The probable cause of the cybersecurity incident (e.g., malevolence, human error).

Following this qualification, the incident may be managed normally with predefined processes or it may trigger escalation to the crisis management process.

The Investigation Team

The investigation team’s objective is to identify when the attack started, the vulnerabilities exploited, and consequences of the attack (such as stolen documents or corrupted systems). It analyzes all available internal and external technical elements. It tries to identify the attack’s source and the extent of the information system’s compromise. The team is made up of digital investigation and forensics specialists focused on reacting quickly to information system crises. Its specialists are often externally sourced and embedded from companies that have a computer security incident response team (CSIRT) or a computer emergency response team (CERT). The targeted organization’s technical experts are also integrated into the team to provide an understanding of the context.

The Defense Team

The defense team prepares all the technical actions for repelling the attacker and correcting the vulnerabilities exploited during the attack. Its work often goes beyond the acute phase of the crisis in order to consolidate and correct the attacked system in depth and over time. It includes internal specialists with knowledge of the organization’s tools and systems combined with external experts with knowledge of the attacker’s methods to prevent against any rebound attacks or secondary infections.

The Steering Team

The steering team creates the link between the investigation and defense teams. It also liaises with internal parties (particularly the CDU for decisions and the CRO/ERM function for enterprise support) and with external operational parties (such as law enforcement or government services, depending on context). The steering team gives a business sense to the technical information and provides key elements to prepare a response to the attack across all its dimensions. It passes on relevant information to internal and external communication teams and can also validate communications to ensure that information’s technical accuracy and that such information is safe to disclose.

These teams work hand in hand. Investigation provides elements to defense that then put forward plans for steering to approve. Steering follows the various action plans, communicates with all the other concerned parties, and drives the work forward. It must also try to anticipate as far as possible the crisis’s next steps by identifying the most likely scenarios that could develop in relation to known attack cases.

The size of these teams may vary widely. A simple attack such as the defacing of Web pages with rhetoric, can mobilize from two to three people sharing the different roles. A more complex attack, bringing about, for example, loss of control of several systems and in particular the information system management infrastructure (such as the active directory), can mobilize tens of people internally and externally for several weeks. The resolution of a complex attack can take over three months and the costs can reach tens of millions of euros.

Alert and Qualification

A first incident, whether internal or reported from outside, is enough to trigger the alert. It has to be qualified by the security teams in order to identify its severity and to dispel any doubts. Qualification is based both on system or data sensitivity, on the threat’s technical level (e.g., using standard or homemade malware) and on the risk of the incident’s spread beyond the initial scope of discovery. If the first analyses show early signs of a well-prepared attack and the target’s sensitivity level is high, it is mandatory to trigger the crisis management mechanism using the predefined process.

Crisis Handling: Carrying Out the Investigation and Building a Defense Plan

Once the incident has been qualified, the teams in the cybersecurity crisis unit (i.e., investigation, defense, steering) will begin to investigate and prepare a defense plan.

Executing the Plan and Surveillance

The management decision by the CDU to execute the defense plan is certainly the most complex and critical one to make during an information system attack crisis. Executing it may signify a slowdown or even a halt to some organization services, complicating investigation and also revealing to the attacker that its attack has been discovered.

Except in case of emergencies (i.e., the emergency-button procedure), the plan is launched when the investigation team considers they have near-full or full visibility on the attack, and the defense plan is rated as feasible and optimally effective and efficient. The deployment of the plan needs to ensure smooth functioning and solid efficiency by the investigation team using heightened monitoring. Launching the plan can also lead to the deployment of internal or external communication plans based on the visibility or reach of the actions.

Three scenarios are foreseeable from experience with past crises. These depend on the feedback from heightened monitoring. They are:

1. The threat has been eradicated. The attacker no longer has access to the information system. The situation is back under control.
2. The threat has returned. The attacker accesses the information system via a different modus operandi that was not previously observed or discovered during the investigations. It is therefore necessary to restart the investigation and defense processes, being aware that the attacker knows it has been discovered.
3. The threat evolves. The attacker launches new actions, which could go as far as attempted mass destruction of the information system (e.g., the wiping of servers and all data) in vengeance or to hide the tracks of its actions.

These scenarios—regardless of their likelihood ratings—need to be anticipated in the defense plan. If “mass destruction” begins, the drastic but considered response of an entire shutdown of the organization information system must be considered by management.

If the defense plan has been carried out successfully, it is necessary to start a return to normal. The reopening of services interrupted or impaired during crisis is organized in coordination with the business lines. This reopening can begin only if the services have been restored to a secure state to prevent the attack recurring.

Crisis Closure

The crisis unit may be stood down on three conditions: once the defense plan has been executed, the systems are back up and running, and if there is no indication of an upsurge or recurrence of the attack. This action must balance speed of normalization with alertness to the return of the attack and threat. Monitoring actions need to carry on long term to be capable of identifying any comeback.

One lesson from past attacks is that certain investigative actions bear results only after several days or even weeks. So what is discovered then can lead to remobilizing the recently dismantled crisis units. In addition, once the attacker has been discovered or driven away, it could deliberately hide him/her to come back stronger later on.

A special remediation project integrating security from the outset is required to drive remediation. This depends on the degree of reconstruction required on the affected information systems. An enterprise debriefing phase, often led by the ERM function or CRO, is also necessary in order to identify all the lessons learned from the crisis.