Cleaning up the Sparks folder

Corpus/Sparks/ISMS/Access Control Models.md

@@ -1,6 +1,6 @@
 See also:
 - [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
-- [Identity and Access Management (IAM)](../Identity%20and%20Access%20Management%20(IAM).md)
+- [Identity and Access Management (IAM)](../Information%20Security/Identity%20and%20Access%20Management%20(IAM).md)
 - [RBAC Access levels](../../Literature%20notes/RBAC%20Access%20levels.md)
 - [CRUD Matrices](../Information%20Security/CRUD%20Matrices.md)
 

Corpus/Sparks/ISMS/Assets Ownership and Risk Overview.md

@@ -97,7 +97,7 @@ The source files reference the following related notes in the vault:
 - [Risk ownership](../Risk%20ownership.md)
 - [Control ownership](Control%20ownership.md)
 - [Asset lifecycle](../../Literature%20notes/Asset%20lifecycle.md)
-- [How to develop an Asset Inventory](../How%20to%20develop%20an%20Asset%20Inventory.md)
+- [How to develop an Asset Inventory](How%20to%20develop%20an%20Asset%20Inventory.md)
 
 
  ![Asset classes](Asset%20classes.png)

Corpus/Sparks/ISMS/Data classification/Data Classification.md

@@ -50,7 +50,7 @@ Leiden University has a tool picker that is publicly available, to help employee
 It does not solve the classification labeling problem if you have a single mandatory system in mind, but I can imagine that asking them about what goal they want to achieve makes it easier for employees to see classification as helpful and useful.
 [https://web.universiteitleiden.nl/assets/toolpicker/?lang=en](https://web.universiteitleiden.nl/assets/toolpicker/?lang=en)
 
-![](../../Informatie_classificatie_matrix.xlsx)
+![](../Informatie_classificatie_matrix.xlsx)
 
 
 See also:
@@ -58,7 +58,7 @@ See also:
 [Def_Sec_Handbook_Chapter_2](../../../Literature%20notes/Def_Sec_Handbook_Chapter_2.md#Information%20classification)
 [ISO 27002:2022 NL A5.12](../../../Standards/ISO27x/OST/27002/NL/a-5.12-Classificeren-van-informatie.md)
 [Designing an information management scheme](../../../Literature%20notes/Designing%20an%20information%20management%20scheme.md)
-[Key Topics for a policy on handling classified information](../../Key%20Topics%20for%20a%20policy%20on%20handling%20classified%20information.md)
+[Key Topics for a policy on handling classified information](../../Policy%20examples/Key%20Topics%20for%20a%20policy%20on%20handling%20classified%20information.md)
 [Traffic Light Protocol (TLP)](../../../Literature%20notes/Traffic%20Light%20Protocol%20TLP.md)
 
 

Corpus/Sparks/ISMS/How to develop an Asset Inventory.md

@@ -0,0 +1,46 @@
+# How to develop an asset inventory
+
+https://www.isms.online/iso-27001/how-to-develop-an-asset-inventory-for-iso-27001/
+
+Relevant ISO 27001 clauses/controls:
+- [ISO 27001 A 8.1.1 Inventory of assets](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.1.1%20Inventory%20of%20assets.md)
+- [ISO 27001 C 6.1.2 Information security risk assessment](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20C%206.1.2%20Information%20security%20risk%20assessment.md)
+
+See also:
+- [Assets, Vulnerabilities, Threats, Risks](../../Literature%20notes/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
+
+
+# 3D Asset Inventory
+
+The criticality of an asset can be defined as the **impact of compromise** on the 3 aspects of Confidentiality, Integrity and Availability.
+
+E.g.:
+
+Asset | Confidentiality | Integrity | Availability
+----- | --- | --- | ---
+Public website | 0 | 2 | 3
+Password file | 3 | 2 | 3
+Debtors info | 3 | 3 | 1
+
+We can also assess the **probability of compromise**  on the same 3 aspects:
+
+Asset | Confidentiality | Integrity | Availability
+----- | --- | --- | ---
+Public website | 0 | 2 | 1
+Password file | 1 | 1 | 2
+Debtors info | 1 | 2 | 1
+
+Now we can calculate the Risk Score as Impact times Probability for each of the 3 aspects:
+
+Asset | Confidentiality | Integrity | Availability
+----- | --- | --- | ---
+Public website | 0 | 4 | 3
+Password file | 3 | 2 | 6
+Debtors info | 3 | 6 | 3
+
+
+This would lead to the following priority list for risk mitigation:
+1. Integrity of Debtors info
+2. Availability of Password file
+3. Integrity of Public website
+4. etc.

Corpus/Sparks/ISMS/ISMS audit flags.md

@@ -0,0 +1,10 @@
+# ISMS audit flags
+
+This guideline supports practitioners conducting audits of Information Security Management Systems (ISMSs) built on ISO/IEC 27001. It provides practical reference material organised around two complementary audit tools: green flags — the evidence and documentation an auditor should expect to find in a functioning ISMS — and red flags — the indicators that signal a dysfunctional, failing, or nonconformant system.
+
+The guideline does not prescribe how to audit, nor does it address the content of individual security controls. Its scope is the management system itself: whether it is properly designed, genuinely operating, and delivering value to the organisation. Because ISO/IEC 27001 is deliberately broad in its requirements, this document fills the interpretive gap with experience-based guidance on what adequate evidence looks like in practice, and what warning signs are worth investigating further.
+
+Intended primarily for internal auditors and certification auditors working with ISO/IEC 27001-based ISMSs, it is also relevant to those assessing information service providers such as cloud and managed security vendors. The guidance draws on four decades of practitioner experience and is offered as a supplement to — not a replacement for — formal audit checklists and professional judgement.
+
+![](../SecAware%20ISMS%20audit%20flags.docx)
+

Corpus/Sparks/ISMS/Ideas about enforcement.md

@@ -0,0 +1,14 @@
+# Ideas about enforcement
+
+The coverage of [[Enforcement tooling]] will not be complete, if only because their implementation will always be one step behind organizational reality. There will be information assets out of scope, by choice or accident.
+
+There will be situations where the improper handling of assets is not prevented by such tooling, and employees would need to be aware of, or deduce from content, the classification of those assets, and make an informed decission on the proper handling.
+
+The underlying idea is that I personally prefer that people have freedom of choice and be supported in making informed decissions.
+that is not only morally preferable, but it's a necessigty precisely because there will always be situations in which they *need* to decide for themselves.
+
+There's also a link here to different stakeholders with different interests. Think of your stereotypical IT Guy, who wants to screw everything down, and Marketing Guy, who wants maximum freedom in the data lake.
+
+Related:
+- [Labeling of information in the digital domain](Labeling%20of%20information%20in%20the%20digital%20domain.md).
+- [Stakeholder Analysis](../Stakeholder%20Analysis.md)

Corpus/Sparks/ISMS/Ideas on Risk Ownership.md

@@ -0,0 +1,28 @@
+# Ideas on Risk Ownership
+
+As far as conformity with '27001 goes, risk owners must be identified within the information security risk assessment process as per 6.1.2 c) 2), and risk owners must approve risk treatment plans and acceptance of residual risks as per 6.1.3 f).   
+
+However, 27001 does not specify how they are to be identified, nor what their obligations or expectations might be beyond those noted in 6.1.3 f).  
+
+So, aside from that, we have the discretion to do whatever works best for our organisations - perhaps formally define the role, nominate people or functions or departments, prepare a policy and procedure, or whatever we like really.  Or not: remember that if you have a policy or procedure within your ISMS, you are naturally expected to do what it says, consistently.  So, be careful with the wording, operation, oversight and assurance.
+
+This is a governance matter for senior management.  It is tricky for anyone other than them to insist that workers (including management generally) do anything, especially if it means they are personally accountable for any failings, and implies giving them the authority and resources to 'make it so'.  
+
+ISO/IEC 27005 defines 'risk owner' succinctly as the “Person or entity with the accountability and authority to manage a risk”, summing it up nicely.
+ISO 27005:2022 Clause 3.1.5: **risk owner =** person or entity with the accountability and authority to manage a _risk_
+
+I define 'risk owner' as the "Organisation, rôle or person who notionally ‘owns’ and may be held to account if a risk eventuates, causing unacceptable impacts, on the basis that they patently failed to ensure it was adequately treated e.g. mitigated with controls.  As the explicit or implicit owner of residual risk, they also have an interest in the incident management and business continuity arrangements."
+By the way, 'risk owner' is just one example or application of the general concept of 'ownership'.  Some others include: asset owner, control owner, data owner, information owner, infrastructure owner, network owner, process owner, system owner, service owner and problem owner.  SImilar considerations can apply to them all, particularly the ideas that the nominal owners should be (a) trusted agents or custodians for the true legal owners, acting on their behalf and protecting their interests; and (b) personally accountable for the associated decisions, actions or inactions etc., motivating them to achieve the true owners' expectations or requirements.  
+
+In specifying your ISMS-related governance arrangements, I would caution against going too far beyond the standard's requirements unless: 
+
+(a) you have good business reasons for doing so, 
+
+(b) management is fully aware of and agrees to the arrangements including the implications on resourcing, oversight, roles and responsibiltiies, accountability etc., and 
+
+(c) you are prepared to ensure that the arrangements are actually going to be used consistently as specified - in order to avoid nonconformities being raised by the auditors.        
+
+**Hinson tip**: using weasel-words such as "as appropriate", "if justified" or "should" rather than "shall" or "must" in your strategies, policies and procedures leaves a little room for management discretion to cope with particular circumstances, and yet still conform.  Reserve the "shalls" and "musts" for those situations where there really is absolutely no choice (although, even there, you _may_ have a mechanism for management to authorise specific exemptions, explicitly accepting the associated risks).   This approach also leaves _you_ some leeway to adjust the management controls later, tightening or relaxing them based on experience - all part of ISMS maturity.
+
+Kind regards/Ngā mihi,
+Gary

Corpus/Sparks/ISMS/KPIs in Incident Response.md

@@ -0,0 +1,72 @@
+---
+tags:
+  - metrics
+Related:
+  - "[ISO_27002_2022_5.24_PE Information security incident management planning and preparation](../../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.24_PE%20Information%20security%20incident%20management%20planning%20and%20preparation.md)"
+---
+# KPIs in Incident Response
+
+Here are 20 essential KPIs, with short definitions to guide your tracking and improvement efforts:
+
+1. Mean Time to Detect (MTTD): Avg. time taken to identify an incident.
+
+
+2. Mean Time to Respond (MTTR): Avg. time between detection and first mitigation action.
+
+
+3. Mean Time to Contain (MTTC): Avg. time to stop the incident from spreading.
+
+
+4. Mean Time to Resolve (MTTRv): Avg. time to fully fix and close the incident.
+
+
+5. Number of Incidents Detected: Total incidents identified in a time period.
+
+
+6. Percentage of Incidents by Severity Level: Distribution of incidents by criticality.
+
+
+7. First Response Time: Time from detection to initial analyst response.
+
+
+8. Number of Reopened Incidents: Count of incidents reopened after closure.
+
+
+9. False Positive Rate: Percentage of alerts flagged as incidents that weren’t real.
+
+
+10. Detection Accuracy: Ratio of true positives to total alerts.
+
+
+11. SLA Compliance Rate: % of incidents resolved within agreed SLA timelines.
+
+
+12. Incident Recurrence Rate: Rate at which similar incidents reoccur.
+
+
+13. User-Reported vs. System-Detected Incidents: Comparison of manually vs. automatically detected issues.
+
+
+14. Cost per Incident: Average financial impact of each incident.
+
+
+15. Time to Escalation: Time from detection to escalation to a higher tier/team.
+
+
+16. Incident Closure Rate: % of incidents resolved within a defined period.
+
+
+17. Incident Root Cause Categories: Classification of underlying causes.
+
+
+18. Volume of Phishing/Malware/Ransomware Incidents: Count of incidents by type.
+
+
+19. Percentage of Automated vs. Manual Responses: Share of responses handled automatically.
+
+
+20. Resolution SLA Breach Rate: % of incidents resolved after SLA deadlines.
+
+
+
+Tracking these helps teams reduce downtime, improve security posture, and meet business expectations.

Corpus/Sparks/ISMS/Labeling of information in the digital domain.md

@@ -0,0 +1,37 @@
+[ISO 27001 A 8.2.2 Labelling of information](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2.2%20Labelling%20of%20information.md) makes procedures for information labelling in accordance with the classification scheme mandatory.
+  
+For physical assets it’s straightforward: a ‘restricted area’ sign on the door to the server room, a ‘classified’ mark on a folder, a ‘privacy sensitive’ sticker on a backup tape, etc.  
+  
+But how would you implement labeling in the digital domain of databases, file systems, SaaS environments, etc.?
+
+Brahman Thiyagalingham suggested in [this LinkedIn thread](https://www.linkedin.com/feed/update/urn:li:activity:6878704465160007680/?commentUrn=urn%3Ali%3Acomment%3A(groupPost%3A67493-6878704464929316864%2C6878973141931094016)&replyUrn=urn%3Ali%3Acomment%3A(groupPost%3A67493-6878704464929316864%2C6879367802243866624)) that, to ensure the proper handling of (digital) information assets, you would rely on "something like a proper RBAC model, Identity Access solution with a PAM, DRM and DLP". Implying the concept of labeling has been replaced by applying these tools.
+
+It could be said that these tools apply labeling implicitely, because effective implementation of these solutions requires that the solution ’knows’ what forms of protection each information asset needs.
+That means classifying information assets (control 8.2.1) and determining acceptable use (control 8.1.3). 
+Labeling of digital information assets ‘close to the source’ – e.g. assign a classification-label to a database column – will help create a consistent approach across individual solutions.
+
+Looking at it that way, any metadata that helps ensure the acceptable use and proper handling of information assets could be identified as ‘labeling’. A data dictionary that contains classification information could also be considered to use labeling. 
+
+Related:
+- [ISO 27001 A 8.2.1 Classification of information](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2.1%20Classification%20of%20information.md)
+- [ISO 27001 A 8.1.3 Acceptable use of assets](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.1.3%20Acceptable%20use%20of%20assets.md)
+- [[Enforcement tooling]]
+
+[ISO 27001 A 8.2.2 Labelling of information](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2.2%20Labelling%20of%20information.md) makes procedures for information labelling in accordance with the classification scheme mandatory.
+  
+For physical assets it’s straightforward: a ‘restricted area’ sign on the door to the server room, a ‘classified’ mark on a folder, a ‘privacy sensitive’ sticker on a backup tape, etc.  
+  
+But how would you implement labeling in the digital domain of databases, file systems, SaaS environments, etc.?
+
+Brahman Thiyagalingham suggested in [this LinkedIn thread](https://www.linkedin.com/feed/update/urn:li:activity:6878704465160007680/?commentUrn=urn%3Ali%3Acomment%3A(groupPost%3A67493-6878704464929316864%2C6878973141931094016)&replyUrn=urn%3Ali%3Acomment%3A(groupPost%3A67493-6878704464929316864%2C6879367802243866624)) that, to ensure the proper handling of (digital) information assets, you would rely on "something like a proper RBAC model, Identity Access solution with a PAM, DRM and DLP". Implying the concept of labeling has been replaced by applying these tools.
+
+It could be said that these tools apply labeling implicitely, because effective implementation of these solutions requires that the solution ’knows’ what forms of protection each information asset needs.
+That means classifying information assets (control 8.2.1) and determining acceptable use (control 8.1.3). 
+Labeling of digital information assets ‘close to the source’ – e.g. assign a classification-label to a database column – will help create a consistent approach across individual solutions.
+
+Looking at it that way, any metadata that helps ensure the acceptable use and proper handling of information assets could be identified as ‘labeling’. A data dictionary that contains classification information could also be considered to use labeling. 
+
+Related:
+- [ISO 27001 A 8.2.1 Classification of information](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2.1%20Classification%20of%20information.md)
+- [ISO 27001 A 8.1.3 Acceptable use of assets](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.1.3%20Acceptable%20use%20of%20assets.md)
+- [[Enforcement tooling]]