Re: Data Breach concepts

Hi. Below in this email there are three items.
Part A contains the proposal for Incident based vocabulary, which is an 
upper/top vocabulary upon which the data breach concepts will be modelled.
Part B contains the specialisations of incident types and notifications 
required by NIS2, which is proposed to go in a NIS2 extension.
Part C contains other relevant proposals for DPV, RISK, and TECH extensions.

This is not an exhaustive analysis of NIS2, since much of the entities 
and contents are regarding cybersecurity processes - which were not 
taken in scope for this work. However, the intention is to enable enough 
modelling to proceed with the data breach extension. Therefore, based on 
the use of Part A - we will either remodel the data breach concepts 
(small changes) and I will complete the 7+ sections with examples from 
EDPB and ICO.

Since this is a lot of material, it would be better to have as much of a 
discussion / feedback on the mailing list as possible so we can use the 
time in the meeting call to reach conclusions / decisions.

-----------------------
PART A - Incidents
-----------------------

# Incidents

The focus of the Data Breach vocabulary was on breaches as a central 
event. Instead, we now have `Incident` as the central concept, defined 
as "an event with the potential to cause a negative consequence". Though 
the concept 'incident' is generic, here we are referring to it within 
the cybersecurity context. `DataBreach` would be a subtype of 
`Incident`. In addition, `Incident` is defined as a subtype of 
`dpv:Risk` so as to enable using risk assessment, mitigation, and 
management concepts to describe information associated with it.

## Annotations and Metadata

Annotation and metadata properties used to describe data breaches and 
reports will now be used to describe incidents and incident reports. For 
example, to represent temporal information, such as starting and ending 
time - `dct:temporal` is to be used. If this is not available, then 
`dpv:NotAvailable` is used as the value.  Or, `dct:creator` will be used 
to declare the author of a report.

## Status

Incidents have statuses indicating their state in time, represented by 
`IncidentStatus` and associated using `hasStatus`. These statuses will 
be used for all incidents, including for the Data Breach extension, and 
the existing `DataBreachStatus` will be removed. Types of statuses are:

- IncidentStatusUnknown: the status of a incident is unknown
- IncidentSuspected: the state where a incident is suspected, but has 
not yet been confirmed. This can be due to lack of information, or 
because the process of detection and investigation is still ongoing.
- IncidentOngoing: the incident is ongoing i.e. still active
- IncidentHalted: the incident has halted or paused with a high 
likelihood of resuming or recurring
- IncidentConcluded: the incident has stopped or finished or concluded 
without any active mitigation and with a low likelihood of resuming or 
recurring
- IncidentTerminated: the incident has been stopped or terminated 
through the use of a mitigation or deterrent measure with a low 
likelihood of resuming or recurring
- IncidentMitigated: the incident has been mitigated against future 
recurrences i.e. a measure has been applied to prevent the same or 
similar incident from recurring

## Types of Incidents

Based on the CIA model, incidents are classified according to their 
impacts on systems and information. This same categorisations for Data 
Breach will be removed, and these concepts should be used instead.

- ConfidentialityIncident: the confidentiality of system or information 
has been affected
- IntegrityIncident: the integrity of system or information has been 
affected
- AvailabilityIncident: the availability of system or information has 
been affected

In addition to these, incidents are also categorised based on their 
causes and intention.

- DeliberateIncident: the incident was caused with human deliberation 
e.g. with malicious intent
- AccidentalIncident: the incident was accidental, but still due to 
human or human-controlled contexts e.g. employee accidentally deleted 
data or a system malfunctioned
- EnvironmentalIncident: the incident was caused due to environmental 
factors outside human control e.g. power outage

Another categorisation is based on the certainty of the incident and its 
success.

- SuspectedIncident: the incident is suspected of having occurred e.g. 
suspicious network traffic detected
- NearMissIncident: the incident was almost successful in taking place 
e.g. an attempt was made to access systems but was thwarted by the 
network firewall
- ConfirmedIncident: the incident successfully took place but did not 
cause any consequences e.g. an attacker could access internal network 
and data but no service was disrupted
- SignificantIncident: the incident successfully took place and caused 
consequences e.g. an attacker accessed and deleted data leading to 
service disruption

Yet another categorisation is based on the jurisdictions affected.

- CrossBorderIncident: an incident affecting multiple jurisdictions 
through services being provided to or involving individuals in multiple 
jurisdictions.

## Identifiers

The concept `IncidentIdentifier`, a subtype of `dpv:Identifier`, is to 
be used to denote the identifier associated with an incident, along with 
other annotations and metadata, e.g. to indicate its provenance and 
issuing entity using DCT. Identifiers are associated using 
`dpv:hasIdentifier`.

# Reports

The concept `IncidentReport` is to be used to document information about 
an incident, its handling, assessments, and notifications. The concept 
`DataBreachReport` will be a subtype of `IncidentReport` to distinguish 
the separate requirements and use of data breach reports from (generic) 
information reports.

`IncidentSuspectedReport` is to be used when an incident is suspected. 
It describes the suspected incident and outlines further steps or 
measures that should be or have been taken to confirm or prepare against 
the incident.

`IncidentDetectionReport` is to be used when an incident has been 
detected. It describes the information available at the time of 
detection, and is the basis for the preliminary reporting and warning 
notifications sent to authorities and stakeholders.

`IncidentAssessmentReport` is to be used to describe the assessment of 
an incident in terms of its causes, affected systems, exploited 
vulnerabilities, consequences, impacts, and other pertinent details.

`IncidentHandlingReport` is to be used to describe the handling of an 
incident in terms of what caused it, how it was detected, an assessment 
of its impacts, what measures were taken in response to the incident to 
mitigate it and prevent it, and notifications communicated regarding it. 
This report is expected to be the final report compiling all available 
information either by directly including it or as links to other reports.

To reflect the nature of reports being compiled in an intermediate 
manner based on ongoing investigations and availability of information, 
the reports should be annotated with `ActivityStatus` to denote whether 
they are planned, ongoing, or complete.

The reports in Data Breach extension will be redefined to be subtypes of 
appropriate incident reports as:

- `DataBreachReport` subtype of `IncidentReport`
- `DataBreachDetectionReport` subtype of `IncidentDetectionReport`
- `DataBreachPreliminaryReport` subtype of `IncidentAssessmentReport`
- `DataBreachOngoingReport` subtype of `IncidentAssessmentReport`
- `DataBreachConcludingReport` subtype of `IncidentHandlingReport`

# Notifications

The concept `IncidentNotice` represents notifications (as 
communications) sent regarding an incident. It is a subtype of 
`dpv:Notice`. The corresponding notices in the Data Breach extension 
will be declared as subtypes of `IncidentNotice`. Schema.org vocabulary 
will be used to denote temporal information as well as the parties 
involved in communications, with `dct:subject` used to refer to incident 
as the subject of the notice.

# Risk Assessments

The following concepts are used to describe a typical risk assessment 
for this work. As an example, consider the following which reflects both 
a security incident and a data breach.

An organisation provides a service, called "NewsRHere", which is served 
by using its internal information management system or CRM called 
"newsDB" that stores the news articles as well as subscription 
information. This system has a vulnerability resulting in 'weak 
authentication' that arises because of the technological limitations of 
the tool as well as a 'lack of security training' being provided to the 
employees. As a result, there is a threat of 'unauthorised system 
access' where a 'malicious hacker' exploits this vulnerability and gains 
access to newDB and deletes or corrupts data resulting in 'data loss'. 
As a consequence, there is 'service disruption' to NewsRHere, which 
results in 'financial loss' and 'loss of data' for the readers of the 
service.

Modelling this with the relevant concepts, we have:

:newsDB a dpv:Technology .

:NewsRHere a dpv:Service ;
     dpv:hasData :NewsArticles ;
     dpv:hasPersonalData :UserSubscriptionInfo ;
     dpv:hasDataSubject dpv:Subscriber ;
     dpv:hasLegalBasis dpv:Contract ;
     dpv:hasPurpose dpv:ServiceProvision ;
     dpv:isImplementedByTechnology :newsDB .

:IncidentX123 a security:Incident, security:DataBreach ;

     # Security Incident information #
     rdf:type security:AvailabilityIncident ;
     rdf:type security:DeliberateIncident ;
     rdf:type risk:LossData ;
     dct:description "unauthorised access by unknown parties leading to 
data loss";
     risk:hasThreat :NewsDB-hacked ; # NOTE: new concept Threat

     # Data Breach information #
     dpv:hasPersonalData :UserSubscriptionInfo ;
     dpv:hasDataVolume dpv:HugeDataVolume ;
     dpv:hasDataSubject dpv:VulnerableDataSubject ;
     dpv:hasDataSubjectScale dpv:LargeScaleOfDataSubjects ;
     dpv:hasProcessing dpv:Store ;
     dpv:hasProcessingScale dpv:LargeScaleProcessing ;
     dpv:hasJurisdiction legal:IE, legal:FR, legal:DE ;

     # Impact Assessment information #
     dpv:hasConsequence risk:ServiceInterruption ;
     dpv:hasConsequenceOn :NewsRHere ;
     dpv:hasImpact risk:FinancialLoss, risk:DataLoss ;
     dpv:hasImpactOn dpv:Subscriber .

:NewsDB-hacked a risk:Threat ;
     rdf:type risk:UnlawfulSystemAccess ;
     risk:hasVulnerability :NewsDB-WeakAuthentication ;
     risk:hasRiskSource risk:LackOfSecurityTraining ;
     risk:hasThreatActor :MaliciousUnknownHacker .

:NewsDB-WeakAuthentication a risk:Vulnerability ;
     risk:isVulnerabilityOf :newsDB .

To represent the reports, the same information can be included as a link 
(using dct:subject) below, or directly within the report as in the Data 
Breach examples.

:IncidentReport1 a DataBreachDetectionReport, IncidentDetectionReport ;
     dct:subject :IncidentX123 ;
     dct:created "timestamp" ;
     dct:creator "author" ;
     dpv:hasDataSource "who detected this" ;
     dct:description "comments" ;

:IncidentReport1 a DataBreachPreliminaryReport, IncidentAssessmentReport ;
     dct:subject :IncidentX123 ;
     dct:created "timestamp" ;
     dct:creator "author" ;
     dct:description "comments" ;
     dpv:hasActivityStatus dpv:Completed ;
     dpv:hasAuditStatus dpv:AuditApproved .

:IncidentReport1 a DataBreachOngoingReport, IncidentAssessmentReport ;
     dct:subject :IncidentX123 ;
     dct:created "timestamp" ;
     dct:creator "author" ;
     dct:description "comments" ;
     dpv:hasActivityStatus dpv:Completed ;
     dpv:hasAuditStatus dpv:AuditApproved .

:IncidentReport1 a DataBreachConcludingReport, IncidentHandlingReport ;
     dct:subject :IncidentX123 ;
     dct:created "timestamp" ;
     dct:creator "author" ;
     dct:dateSubmitted "date of submission" ;
     dct:dateAccepted "date of approval" ;
     dct:description "comments" ;
     dpv:hasActivityStatus dpv:Completed ;
     dpv:hasAuditStatus dpv:AuditApproved .

-----------------------
PART B - NIS2
-----------------------

# NIS2 specific concepts

In NIS2, Incidents are the central concept, and are categorised based 
as: 1) deliberate, accidental, environmental; 2) impacting availability, 
authenticity/integrity, confidentiality; 3) suspected or near-miss. The 
incident categorisation in the proposed concepts reflects this.

The concept 'Significant Impact' in NIS2 refers to incidents that have 
an impact on service provision in a significant manner, such as where 
there is a potential for operational disruption and/or financial loss; 
or where there is a cross-border element for service or individuals 
affected (with significant material or non-material damages). In the 
proposed concepts, the 'Significant Impact' has been defined in a 
reduced manner as leading to consequences. Therefore, the NIS2 specific 
definition will have to be in NIS2 extension.

For Significant Incidents, NIS2 has various notifications. The one from 
organisation to authorities consists of several notifications at various 
stages. These would be modelled as indicated below in the NIS2 extension.

1) "Early Warning" within 24 hours of detection containing cause of the 
incident and whether it was unlawful or malicious and whether there is 
cross-border impact. This is covered in the proposed concepts.

2) "Incident Notification" within 72 hours of detection, which contains 
updates on the earlier information as well as initial assessment of 
severity and impact of the incident as well as any 'indicators of 
compromise'. This is covered with the risk assessment concepts, e.g. 
risk level, likelihood and severity. For 'indicators of compromise' - I 
am not sure what this information is, so perhaps the threat, threat 
actor, and vulnerability information is to be used.

3) "Intermediate Report" upon request - which provides updates, if any, 
to previous information.

4) "Progress Report" to be sent within 1 month of detection if the 
incident handling has not been completed by then, with updates to 
previous information.

5) "Final Report" to be sent within 1 month of incident handling i.e. 
completing the incident recovery etc. This should contain the 
applied/ongoing measures, 'detailed description' - not sure what this 
means, and threat type / root cause - which is covered with threat and 
vulnerability concepts.

The organisation may also send notifications to stakeholders using their 
services, where these would contain risk mitigations to be applied and 
existence of threats. The authorities can also send notifications to the 
organisation (upon request, within 24 hours or early warning) containing 
"initial feedback" and guidelines on measures that can be taken in 
response to a breach. There are several other notifications, e.g. with 
CSIRT and single contact points, which have not been in scope of this work.

-----------------------
PART C DPV developments
-----------------------

TOMs: In several places there are specific technical and organisational 
measures mentioned, such as policies for risk analysis, information 
system security, backup management, access control, and so on. All of 
these should be taken as proposals and added to the existing TOMs 
vocabulary in DPV.

RISK: The incident handling contains measures taken to 1) prevent; 2) 
detect; 3) analyse; 4) contain; 5) respond; and 6) recover from the 
incident. These reflect typical types of risk related controls that 
either work to prevent the risk (e.g. modifying the threat, 
vulnerability, source), detect (e.g. potential for incidents, 
heuristics, events taking place), response (e.g. reduce the affected 
data/system), and recover (e.g. backups, password resets). Our (pending) 
risk management terminology should be developed to cover these.

TECH: NIS2 has a lot of emphasis on supply chain security, where 
entities are required to assess their "exposure to risk" and to assess 
things based on their "size". Since NIS2 focuses on entities classified 
as "essential" or "important" within the critical infrastructure, 
resilience and security knowledge are considered important as 
obligations. Supply chain is mentioned in terms of 'Direct Supplier' and 
'Service Provider'. These are concepts of consequence when developing 
the TECH extension.

TECH: In the annexes, NIS2 has categories of organisations and their 
services, which are important from a digital infrastructure perspective. 
For examples, services provided by the following entities are considered 
important or critical - DNS, TLD, Cloud Computing, Data Centre, CDN, 
Managed Services, Managed Security, Online Market Places, Online Search 
Engines, Social Networking, etc. These should be added to the TECH 
extension as types of services.

TECH: The following roles are mentioned in NIS2: Provider, Recipient, 
Operator, Manufacturer. Extrapolating these, we also get Developer, 
Distributor, Deployer.

TECH: Based on the text in NIS2, the following is a vocabulary based on 
the provision method: Infrastructure, Component, Platform, Application, 
Service (IaaS, PaaS, SaaS, NaaS). These reflect in what form the 
technology is provided or used.

TECH: Based on NIS2, the following are deployment methods: public, 
private, community, hybrid. These reflect who will be the users of the 
technologies.

TECH: Based on NIS2, technology is mentioned regarding usage as: for 
Internal Operations, or for Service Provision. This should be reflected 
in the TECH extension to distinguish how the technology is being used. 
Similarly, NIS2 also refers to update mechanisms, which in the TECH 
extension would be related to Automated or Manual updates, Direct from 
developer or provider or a third party.

-- END --

Regards,
-- 
---
Harshvardhan J. Pandit, Ph.D
Assistant Professor
ADAPT Centre, Dublin City University
https://harshp.com/

Received on Tuesday, 11 July 2023 17:41:29 UTC