Re: Risk Assessment concepts

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/
> [2] https://csrc.nist.gov/pubs/sp/800/30/r1/final
> [3] 
> 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 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) 
>> 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
>> 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/

Received on Tuesday, 15 August 2023 21:26:48 UTC