- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Wed, 16 Aug 2023 14:04:55 +0100
- To: Rob Brennan <rob.brennan@ucd.ie>
- Cc: public-dpvcg@w3.org, Julio Hernandez <julio.hernandez@adaptcentre.ie>, Delaram Golpayegani <delaram.golpayegani@adaptcentre.ie>, Rob Brennan <rob.brennan@adaptcentre.ie>
Hi Rob - thanks (again) for the inputs. --- Re. mitigated by relation - I understand why it should be "addressed" rather than "mitigated", but we already have 'mitigation' in DPV from the wording in GDPR and others. In this case, the 'mitigation' label is really meant to be a mitigation or reduction of risk. Also, we have not touched upon 'controls' and 'treatment' e.g. detection, monitoring, avoid, share, etc. which are not 'mitigation'. They also 'address' a risk - so if this is what you mean then we can have 'addressedBy' as the parent relation for mitigation and these concepts which all point to risk. Does this fit what you have in mind? --- Re. moving risk concepts to RISK extension - IF I am interpreting you correctly, I don't think anything else in DPV makes use of Risks, but we do have a lot of other extensions and applications use it (e.g. DPIA). So maybe its better to keep the existing terms in DPV, and repeat them in RISK extension with sameAs relations. --- Separately, how do we express or distinguish 'potential consequences' from 'materialised consequences' for an incident? Context is information required to answer the question: what are potential consequences arising from a data breach incident and how will you mitigate them? I can think of two ways: 1) We express another Risk instance with Incident as the cause (incident as Threat?); and then express the consequences of this Risk with their likelihood etc. This matches the definitions of Risk and Incident as being potential and realised events respectively, but forces creation of another Risk instance whereas most use-cases would typically want to do "has potential consequence" directly. :Incident dpv:hasConsequence :Consequence-A . # consequence of incident :Incident dpv:hasRisk :Risk . # incident leads to more risks :Risk dpv:hasConsequence :Consequence-B . # potential consequences 2) We associate a consequence with incident, and declare the consequence as a risk to indicate it is potential. If the potential consequence is realised, another instance of consequence as an incident is declared which can be associated with its risk (assessment). I think I like this more because it works better with data breach / incident reporting, but I don't know if this is okay for general risk documentation. :Incident dpv:hasConsequence :Consequence-B . :Consequence-B a dpv:Risk, dpv:Consequence . # risk = potential event :Incident dpv:hasConsequence :Consequence-C . :Consequence-C a dpv:Incident ; dpv:refersToRisk :Consequence-B . In your modelling, you have 'characterised by' relation for risks to consequences, and 'has consequence' label for incident to consequences. In DPV, we prefer to keep the hasConsequence label for any concept that is associated with a consequence to simplify the use in many different places. Regards, Harsh On 16/08/2023 10:18, Rob Brennan wrote: > Hi > > looks OK to me. > I would again suggest (but not a critical issue) that the > relationship between Risk and RiskMitigation is not really "mitigatedBy" > but "addressedBy" > > wrt to modularisation and deletion of base risk concepts in DPV, my > thoughts are > a) you should follow your standard style for DPV modules > b) if no style then declaring the base in DPV and importing it into > Risk/referring to it in risk is IMO better style if risk is a key > concept of DPV. It costs very little to add a new vocab (ie both DPV and > Risk if working with risks) but conceptually it is hard to understand a > base module that does not cover all key concepts. > > rgds > rob > > On Tue, 15 Aug 2023 at 22:26, Harshvardhan J. Pandit <me@harshp.com > <mailto:me@harshp.com>> wrote: > > Hi. After discussions with Rob, Julio, and Delaram, we have > consensus on > the below concepts for risk assessment. Please let us know if you have > further thoughts or these are okay. Risk concepts are required for > DPIA, > Data Breach, and Incident guides and examples, which are currently > paused while risk concepts are finalised. > > Additional question: Since we already have some risk concepts in main > DPV, and some in RISK extension, there is an open question (from me) > whether it makes sense to move all concepts to RISK extension? To do > this without immediately affecting existing uses, we can repeat the > concepts in RISK extension with a note on risk concepts in main DPV > stating they are being deprecated in the future. > > --- RISK assessment concepts --- > > - Risk: Potential event > * associated using hasRisk with system or asset > * e.g. System hasRisk Risk > - Incident: Realised 'risk' event > * NOT a subclass of Risk > * associated with Risk using refersToRisk (new) > * e.g. Incident refersToRisk Risk > - Consequence: potential effect of a risk > * associated using hasConsequence > * indicates what is affected by hasConsequenceOn > - Impact: potential effect of a consequence > * associated using hasImpact > * indicates what is affected by hasImpactOn > - RiskMitigationMeasure: measures to 'control' the risk > * is associated with Risk using mitigatesRisk > * synonymous with Risk Control > * is referred to by Risk using isMitigatedByMeasure > * specific 'control types' to be added later e.g. remove risk source > * Though the term 'Control' is preferred in standards, we > already had > Risk Mitigation Measure in DPV as the term used in regulations > - Risk Source: the 'cause' or 'source' of a Risk (new) > * associated using hasRiskSource > * exists for compatibility with ISO 31K > * Threat and Threat Source are specific categories of Risk Sources > - Threat: Risk source event which causes Risk (new) > * is associated with Risk using causedByThreat > * e.g. Risk causedByThreat Threat > * e.g. Incident causedByThreat Threat > - Threat Souce: Source of threat event (new) > * is associated with Threat using hasThreatSource > * e.g. Threat hasThreatSource ThreatSource > * includes agent and non-agent sources > - Vulnerability: Intrinsic property of a system or asset that is > utilised by the Threat Source in a Threat event to cause Risk (new) > * is associated with system or asset using isVulnerabilityOf (new) > * e.g. Vulnerability isVulnerabilityOf System > * is referred to by a system or asset using hasVulnerability (new) > * e.g. System hasVulnerability Vulnerability > * These are helpful to keep track of Vulnerabilities > * is associated with Threat using isExploitedBy (new) > * e.g. Vulnerability isExploitedBy Threat > * is referred to by Threat using exploitsVulnerability (new) > * e.g. Threat exploitsVulnerability Vulnerability > * The below relation between Risk/Incident and Vulnerability is > necessary as without it the risk has to go through Threat to > understand the vulnerability. Is okay if the graph is only > referring > to a single risk, but for multiple threats and > vulnerabilities, Risk > is modelled as a combination of specific Threat and > Vulnerability - > which this relation permits. > * is referred to by Risk using causedByVulnerability (new) > * e.g. Risk causedByVulnerability Vulnerability > * e.g. Incident causedByVulnerability Vulnerability > - Likelihood and hasLikelihood to represent and specify the likelihood > associated with an event > - Severity and hasSeverity to represent and associate the severity > associated with an event > - RiskLevel and hasRiskLevel to specify the 'level' of Risk. Level > (qualitative) is inclusive of Score (quantitative) > - The rest of the ISO glossary applies as usual e.g. Risk Owner with > relation hasRiskOwner, processes for Risk Management, Risk > Identification, Risk Assesment, etc. These are to be added later. > > - Harsh > > On 31/07/2023 18:28, Harshvardhan J. Pandit wrote: > > Hi. > > > > After reading through both NIST SP 800-30 Rev. 1 Guide for > Conducting > > Risk Assessments [2] and ISO/IEC 29134:2017 Information technology — > > Security techniques — Guidelines for privacy impact assessment, > the I > > think the concepts map as follows: > > > > --- > > > > Threat Source (NIST) and Risk Source (ISO) are the same concept, and > > refer to the "agent" that was the source of the risk. It is > described as > > having "capability" and "intent" (or lack of). So employees, > hackers, > > etc. are threat/risk sources. > > > > Threat Event (NIST), Threat (ISO), and Event (ISO) are the same > concept. > > In NIST and DPV we talk about risk as a negative event whereas > ISO talks > > about risk as both positive and negative and uses Threat only for > > negative events. Sources give rise to Threat/Event. A list of > these is > > in Annex III – Toolbox threat taxonomy of Interoperable EU Risk > > Management Toolbox [3]. Examples given include fire, software > defects, > > information leaks. > > > > Vulnerability (NIST, ISO) is a property of an "asset" (tangible e.g. > > machine or intangible e.g. process) that gives rise to an > opportunity > > for the Threat/Event to occur, mostly by the Threat/Source taking > > advantage of it or due to it. > > > > Predisposing Conditions (NIST) is the context within which the > > Vulnerability occurs, e.g. a software bug exists within a process of > > system update schedules. This concept is not explicit in the ISO > > glossary, but can be considered as part of "Risk Source" (ISO) > given its > > broad usage. > > > > Consequence (NIST, ISO) is the outcome of the Threat/Event, and > is the > > effect on something or someone. Consequence is explained as both the > > effect and the impact, with some criteria typically including how it > > affects the organisation. In DPVCG, we consider Impact as a type of > > consequence which is significant by some measure, and Consequence > as the > > precursor. E.g. Service Disruption is a Consequence, and its > Impact on > > an Entity could be Financial Loss. > > > > Risk (NIST, ISO) is a cosmetic concept i.e. it only describes the > > combination of Threat/Event x Vulnerability with Consequence x > Severity. > > Which means "anything" can be a risk is one interpretation, but a > > pragmatic approach is to start from one end (e.g. Threat/End) and > then > > use Risk as a concept to provide common descriptions. This allows > the > > same 'risk' concept to collect multiple similar causes and > consequences, > > which makes its management easier. > > > > This is why Risk assessment guidelines do not have a list of > "Risk", but > > will have lists of "Threats" and "Vulnerabilities". As a result, > it is > > common to see explanations jump straight from Threat/Event to > > Consequence, e.g. "a device with IDs was stolen which caused a > phishing > > scam", where the inherent "Risk" description would be "data > breach" or > > "unauthorised information access", etc. > > > > --- > > > > I propose we use the ISO terms, but with the NIST workflow [3 > pg.12] as: > > > > 1. Risk Source (actor or asset) > > 2. Threat Event (event causing risk) > > 3. Vulnerability (weakness of asset or process) > > 4. Risk (Threat Event caused by or arising from Risk Source by > > exploiting or being enabled through Vulnerability) > > 5. Consequence (effect of Threat Event) > > 6. Impact (Consequence of significance on an Entity). > > > > --- > > > > [1] > > > https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breach-examples/ <https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breach-examples/> > > [2] https://csrc.nist.gov/pubs/sp/800/30/r1/final > <https://csrc.nist.gov/pubs/sp/800/30/r1/final> > > [3] > > > https://www.enisa.europa.eu/publications/interoperable-eu-risk-management-toolbox <https://www.enisa.europa.eu/publications/interoperable-eu-risk-management-toolbox> > > > > --- > > > > See below three examples from ICO's data breach examples [1] for > further > > discussion. > > > > 1 Case study 3: Working on an unencrypted laptop > > ================================================ > > > > 1.1 Facts > > ~~~~~~~~~ > > > > What happened? An employee lost his briefcase, containing > work on an > > unencrypted laptop and unredacted paper files relating to a > sensitive > > court case – including information on criminal convictions and > health > > information. Initially, the employee told his manager that he > > believed the laptop was encrypted and the paper files were > > redacted. The manager reported the incident to the IT > department, who > > remotely wiped the laptop. At that point, the data controller > did not > > report the breach to the ICO as they believed there was little > or no > > risk to data subjects, though they did record the incident on > their > > breach log. After being informed by the IT department that > the laptop > > was unencrypted, and after the employee discovered the paper > files had > > not been redacted, the controller reported the breach to the > ICO and > > informed the data subjects. > > > > Why was this a problem? The paper files were unredacted and not > > secured, so somebody could have accessed sensitive data. As > the laptop > > was unencrypted, there was no way for the controller to know > whether > > the data had been accessed. Therefore, they could not be > certain that > > a risk to the data subjects would not occur. > > > > What did the data controller do? They updated the internal > breach log > > to reflect the new information and documented the developing > > situation, including the way the breach changed from being not > > reportable to reportable. On discovering the possibility of a > risk to > > data subjects, the controller correctly reported the breach to > the ICO > > and informed the data subjects. The controller was then able > to use > > their internal breach log to explain the delay in reporting > the breach > > to the ICO, outside the required 72 hours. > > > > > > 1.2 Modelling using NIST concepts > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > ,---- > > | Incident: Data Breach - Potential disclosure of data > > | > > | Threat Event: Lost briefcase with laptop > > | Threat Source: Human Failure - Employee > > | Vulnerability: Lack of Safeguards - data was unencrypted and > files > > were unredacted > > | > > | Consequence: Unauthorised Disclosure of Data > > | > > | Impact: Harm > > | Impact On: data subject > > `---- > > > > > > 2 Case study 4: Sending medication to the wrong patient > > ======================================================= > > > > 2.1 Facts > > ~~~~~~~~~ > > > > What happened? A courier, delivering medication for a Scottish > > pharmacy, delivered one set of medication to the wrong patient > > (Patient A). Patient A called the pharmacy to complain. The > > pharmacist then realised the prescription was for a different > patient > > with a similar name (Patient B). After contacting the courier, the > > unopened medication was collected and delivered to Patient B. > > > > Why was this a problem? Patient A and Patient B both > complained to > > the pharmacist. Patient B felt their medical information and > address > > had been shared inappropriately with Patient A. > > > > What did the data controller do? The pharmacist decided that > any risk > > to Patient B was unlikely, due to the actions of Patient A, the > > pharmacy and the courier. However, they decided to report the > breach > > to the ICO in case Patient B subsequently complained to the > ICO about > > how their personal data had been handled. > > > > Did the data controller need to report the breach? As the > pharmacy > > had concluded it was unlikely there was a risk to Patient B, the > > breach did not need to be reported to the ICO. There would be no > > further action for the pharmacy to take, assuming they had > documented > > the details of the breach, their decision not to report and any > > safeguards put in place to prevent a recurrence. > > > > > > 2.2 Modelling using NIST concepts > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > ,---- > > | Incident: Data Breach - disclosed prescription to wrong patient > > | > > | Threat Event: UnauthorisedInformationDisclosure "A courier, > > delivering medication for a Scottish pharmacy, delivered one set of > > medication to the wrong patient" > > | Threat Source: Human Failure - "pharmacist then realised the > > prescription was for a different patient with a similar name > (Patient B)" > > | Vulnerability: not specified > > | > > | Consequence: Detriment > > | Consequence On: Patient A > > | > > | Consequence: Detriment, Unauthorised Disclosure of Data > > | Consequence On: Patient B > > | > > | Impact: PrivacyImpact > > | Impact On: Patient B > > `---- > > > > > > 3 Case Study 5: A phishing attack > > ================================= > > > > 3.1 Facts > > ~~~~~~~~~ > > > > What happened? A law firm employee failed to recognise a phishing > > attack. They received an email, clicked a link to download a > document, > > then inadvertently entered login credentials into what they > believed > > was a legitimate website. A while later, the employee > contacted the > > company’s IT department as they noticed they were no longer > receiving > > emails. > > > > Why was this a problem? The data controller discovered the > employee’s > > email account had been compromised when they entered their login > > details. A forwarding rule had also been set up, diverting the > > employee’s emails to a third party. Additionally, the third > party had > > responded to several emails using a spoofed email account, > advising > > the recipients of a change in bank details. This resulted in two > > clients making significant payments to the third party. The > > controller also discovered that the compromised email account > > contained scanned copies of client ID documents. > > > > What did the data controller do? The controller reported the > breach > > to the ICO and notified affected clients about the breach. The > > controller identified a high risk to affected clients’ rights and > > freedoms, partly due to the financial detriment that two clients > > experienced after making payments to the third party. It is also > > likely that other clients will have received emails asking for > > payments. Also, the controller identified that there was a > high risk > > of identity theft or fraud, due to scanned copies of ID documents > > being held on the compromised account. > > > > > > 3.2 Modelling using NIST concepts > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > ,---- > > | Incident: Data Breach - compromised employee email account > > | > > | Threat Event: PhishingScam "received an email, clicked a > link to > > download a document, then inadvertently entered login credentials > into > > what they believed was a legitimate website" > > | Threat Source: Human Failure "Law firm employee failed to > recognise > > a phishing attack" > > | Vulnerability: not specified > > | > > | Consequence: Identify Fraud > > | Consequence on: Employee > > | > > | Consequence: Misuse of Breached Information, PhishingScam, > Spoofing > > | Consequence On: Client > > | > > | Impact: FinancialLoss, Identify Fraud > > | Impact On: Client > > | > > | PersonalData: PersonalDocuments, OfficialID (Sensitive > Personal Data) > > | > > | Impact Assessment: High Risk > > | Notifications: DPA and Data Subject > > `---- > > > > Regards, > > Harsh > > > > On 13/07/2023 22:21, Harshvardhan J. Pandit wrote: > >> Hi. > >> > >> This email discusses the risk management / assessment related > concepts > >> in DPV following today's meeting. See > >> https://w3c.github.io/dpv/meetings/meeting-2023-07-13#t04 > <https://w3c.github.io/dpv/meetings/meeting-2023-07-13#t04> for minutes. > >> > >> The goal is to provide sufficient concepts to enable a > simplified risk > >> assessment, and to document its causes and consequences. Please > let us > >> know your thoughts, criticisms, suggestions. > >> > >> A) Current Risk related concepts > >> > >> Risk as the central concept, which can have a RiskLevel, > Severity, and > >> Likelihood. RiskMitigationMeasure which mitigates a risk, and > >> ResidualRisk which represents a risk remaining after mitigation. > >> Consequence is the effect of a risk which could be on a system, > >> process, or entity, which then leads to an Impact on an entity. > >> > >> The RISK extension extends each of these concepts. It provides > >> quantified risk levels, severity levels, and likelihood levels, > >> categories of RiskMitigationMeasures as types of controls (e.g. > >> avoiding risk source), and a taxonomy of Consequences and > Impacts. It > >> also provides a list of Risk Assessment Techniques and Risk > >> Methodologies. > >> > >> B) Existing Proposed Concepts > >> > >> These concepts were discussed in previous meetings and have been > >> proposed. > >> > >> RiskThreat to represent incidents or conditions which lead to > the risk > >> being realised or taking place. For example, for a Risk of Data > >> Breach, the Threat would be Unauthorised Access. > >> > >> RiskVulnerability to represent weaknesses or limitations within a > >> system or a process which lead to the threat being realised or > taking > >> place. In the above example, the vulnerability would be a software > >> condition or weak password policy which leads to unauthorised > access. > >> > >> RiskSource to represent conditions or events (or lack of them) > which > >> lead a RiskThreat being realised. In the above example, the risk > >> source would be lack of appropriate software update routines or > staff > >> security training. > >> > >> C) Complete Example > >> > >> The example from the incident reporting proposal (see > >> > https://lists.w3.org/Archives/Public/public-dpvcg/2023Jul/0006.html > <https://lists.w3.org/Archives/Public/public-dpvcg/2023Jul/0006.html>) > >> is reused here in a shortened form. > >> > >> 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 software not being > updated > >> 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' for the organisation and Scams for > readers > >> of the > >> service. > >> > >> This can be expressed as the following concepts: > >> > >> Risk: Data Loss (or Data Breach) > >> Threat: Unauthorised System Access > >> Vulnerability: Weak Authentication > >> Risk Source: Software not updated, and Lack of Security Training > >> Threat Actor: External Malicious Hacker > >> Consequence: Service Disruption > >> Impact: Financial Loss (Organisation), Scams (Subscribers) > >> > >> Mitigations (or Controls) are applied at each point as follows: > >> > >> First, to fix vulnerabilities, the risk sources are mitigated > either > >> by avoiding or removing it, for example by using auto-updates, > and by > >> putting in monitors to detect when software is out of date. > >> > >> Second, the Threat can be similarly mitigating by putting in > measures > >> to make it more difficult for the Threat Actor to act. For example, > >> limiting access to known IP addresses (removing), or limiting > password > >> retries (reducing). > >> > >> D) Questions raised > >> > >> 1) Does the above make sense? Are there aspects that should be > fixed > >> or improved? > >> 2) Do we need more risk specific concepts? What are they? For > example, > >> the list of terms from ISO 31073:2022 are > >> https://github.com/coolharsh55/riskonto/blob/master/riskos.ttl > <https://github.com/coolharsh55/riskonto/blob/master/riskos.ttl> > >> 3) Should we increase the taxonomies provided? For example, add > >> specific vulnerabilities, threats, sources similar to how we have > >> consequences and impacts? > >> > >> E) Additional Risk Management Concepts > >> > >> The below concepts relate to Risk Management and are from ISO risk > >> management standards. They represent organisational processes > related > >> to management of risk in relation to the above discussed > concepts. In > >> the ISO Risks Management framework, they represent various steps / > >> tasks in addition to risk assessment. These were not included > within > >> the 'simplified' risk assessment vocabulary present in DPV, but are > >> included here for completeness of proposed concepts. > >> > >> RiskAssessment > >> RiskIdentification > >> RiskAnalysis > >> RiskEvaluation > >> RiskAcceptance > >> ThreatIdentification > >> ThreatEvaluation > >> RiskControlAssessment > >> RiskTreatment > >> RiskPerception > >> RiskCriteria > >> RiskOwner > >> > >> Regards, > > > > -- > --- > Harshvardhan J. Pandit, Ph.D > Assistant Professor > ADAPT Centre, Dublin City University > https://harshp.com/ <https://harshp.com/> > -- --- Harshvardhan J. Pandit, Ph.D Assistant Professor ADAPT Centre, Dublin City University https://harshp.com/
Received on Wednesday, 16 August 2023 13:05:12 UTC