Does security incident information sharing benefit the new (data) gold?

A security incident is understood as an event that has a negative effect on the properties of confidentiality, integrity or availability, known also as the CIA triad, of communication networks, services or data – stored, under processing or in transit. A security incident may affect any of the CIA triad combinations. A brief summary of the CIA triad is provided below.

• Confidentiality entails that data are not made available or disclosed under unauthorised conditions. For instance, when encryption is not working or communication is hacked or private messages are accessible to attackers, then confidentiality is impacted.
• Integrity requires that the accuracy and completeness of data are maintained and assured, throughout their lifecycle. For instance, when network configuration data are altered or log information is tampered, then integrity is compromised.
• Availability guarantees that data or services must be available, when they are rightfully required. For example, when service continuity is disrupted or a service outage is taking place, then the property of availability is negatively impacted.

According to article 40 of the European Electronic Communications Code (EECC), the providers of public communications networks or services have the responsibility to notify the competent security authority in case of a security incident, especially, when this can have a significant impact on the operation of networks or services. The significance of a security incident can be determined by the number of affected users, the duration of the incident, the geographical spread of the affected areas, the degree to which the functioning of the network or service is affected and the degree of impact on economic and societal activities.

It is also stipulated that, where appropriate, the competent authority concerned will inform the competent authorities in other Member States and ENISA and may also inform the public, when this is determined to be in the interest of the public.

We are already living in an era where data are considered to be the new gold or, the very least, one of the valuable assets for individuals, institutions and enterprises. Obtaining access to data, may entail new opportunities for products differentiation and market penetration, improved customer satisfaction, better chances to enter a market or more educated decisions in situations handling. In this respect, the enabling factor is the access to data or, in other words, the sharing of data with interested parties.

At the same time information security became a corner stone for developing communication networks and services. Designs are done thinking about security from day zero, throughout the architecture layers. Of course, in case a security incident appears, reaction and handling processes are important, but, as indicated before, sharing of the security incident related data can prove to be valuable for the security experts and the teams involved in handling the security incident.

When considering security incidents, one should keep in mind that there are certain elements of information that, once determined, can provide a clear description of the operational context and an accurate representation of what happed. Such relevant information elements are:

• Threat, which identifies a potential negative action or event
• Asset, which determines the physical or logical object(s) that a Threat can endanger
• Vulnerability, which identifies a weakness of the Asset that the Threat can exploit, so as to materialise an attack and diminish the value of the Asset
• Counter measure, which determines a set of actions that can be undertaken to combat against a Threat or mitigate the Vulnerability of the Asset
• Context, which identifies some contextual information like time, location, administrative domain, etc, within which the attack is taking place and evolving.

This set of information elements that describe an attack are critical not only for fighting against the attack, but also for alerting and raising the awareness for any other potential subjects of the attack, as well as the relevant security authorities, both at local and pan-European level. As already indicated above, if data is the new gold, then security incident information and sharing or making it available is undoubtably part of the solution.

The sharing of security incident information can facilitate:

• Obtaining feedback on security incidents, as well as their impact, trends and root causes
• Create a security incidents map that depict aggregated statistical information and identify the frequency and impact across geographies
• Exchange of experiences and lessons learned among relevant authorities and providers, which can in turn improve the way security incidents or vulnerabilities are dealt with
• Evaluate the effectiveness of security measures in place and regularly revise them, so as to be prepared for the evolving attack methodologies

In this context, sharing of security incident information, both at local and European levels, is legally required and operationally important. In this respect, the role of the Data Owner, who has and maintains the source information, is of critical importance. Practically, the Data Owner can define the set of local, regional and European organisations and respective authorities with whom sharing of security incident information will be permitted. In other words, the Data Owner, defines a circle of trust, that includes other interested service operators or providers, as well as competent security authorities, like local/regional Computer Security Incident Response Teams (CSIRT) and/or ENISA, and provide to them regular feedings of security incident information.

The Data Owner, based also on the legal obligations, could determine the way the shared information will be handled. For instance, there could be two distinctive options: Read and Process. The former, could only permit that the shared information is used only for reporting purposes and cannot be used for any other type of processing. The Read option allows the Data Owner to share information and raise the awareness with other parties. The second option, Processing, could permit the shared information to be used for further processing, including statistical analysis or even some kind of Machine Learning processing. Furthermore, the Data Owner could also specify the periodicity of sharing security incident information or any inactive periods, where sharing is deactivated, always in accordance to the established regulations and also considering any established best practices.

At the same time, the entities interested or obliged by law to receive the shared security incident information, will need to express their interest and formally register for getting shared information, defining also the potential Data Owners from which shared information is to be received.

This approach creates, practically, two groups of entities, the Data Owners, that are going to share information and the Data Receivers, which are going to obtain information. Between those two sets, a number of possible rules or policies may be established, to dictate the conditions of sharing information, as well as the conditions for delivering shared information. Based on this, one could also envisage entities that are having a facilitator role, between Data Owners and Data Receivers, which maintain and implement the necessary sharing policies and communication capabilities. At the same time, such an entity could also undertake the role of processor of shared information, providing added value services for the Data Receivers, while saving the processing cost for the Data Owners.

Within Incidents Information Sharing Platform (I2SP) of the PHOENIX project, the foreseen rules and practices will be further explored and analyzed as we will take a deep dive into the topics of sharing policies and information sharing and the resulting situational awareness that these subjects promote. The findings of this analysis will be briefly overviewed in a subsequent blog post.