Re: Risk Assessment concepts

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 Monday, 31 July 2023 17:29:03 UTC