Worked on metadata standard for Corpus, plus RTP
This commit is contained in:
parent
68f1c38681
commit
10c440ec83
4 changed files with 274 additions and 14 deletions
67
Corpus/ISO 27002 Themes and Attributes.md
Normal file
67
Corpus/ISO 27002 Themes and Attributes.md
Normal file
|
|
@ -0,0 +1,67 @@
|
||||||
|
# ISO 27002 Themes and Attributes
|
||||||
|
|
||||||
|
## Themes
|
||||||
|
|
||||||
|
In ISO 27002, controls are categorized into four main themes:
|
||||||
|
* **Organizational** (Clause 5 - all controls numbered 5.n)
|
||||||
|
* **People** (Clause 6 - all controls numbered 6.n)
|
||||||
|
* **Physical** (Clause 7 - all controls numbered 7.n)
|
||||||
|
* **Technological** (Clause 8 - all controls numbered 8.n)
|
||||||
|
|
||||||
|
## Attributes
|
||||||
|
|
||||||
|
Every control is associated with five attributes, which allow organizations to view and categorize the controls from different perspectives. The attributes and their possible values are:
|
||||||
|
|
||||||
|
### Information Security Properties
|
||||||
|
|
||||||
|
Views controls from the perspective of which characteristic of information the control contributes to preserving.
|
||||||
|
* Confidentiality
|
||||||
|
* Integrity
|
||||||
|
* Availability
|
||||||
|
### Control Type
|
||||||
|
|
||||||
|
Views controls from the perspective of when and how the control modifies risk regarding the occurrence of an information security incident.
|
||||||
|
* Preventive
|
||||||
|
* Detective
|
||||||
|
* Corrective
|
||||||
|
|
||||||
|
|
||||||
|
### 3. Cybersecurity Concepts
|
||||||
|
|
||||||
|
Based on the cybersecurity framework concepts defined in ISO/IEC TS 27110.
|
||||||
|
|
||||||
|
|**Attribute**|**Description**|**Purpose**|**Control Examples**|
|
||||||
|
|---|---|---|---|
|
||||||
|
|**Identify**|Activities to understand the business context, the resources that support critical functions, and the related risks.|To develop the organizational understanding to manage risk to systems, assets, data, and capabilities.|Inventory of information (5.9), Risk assessment (5.1), Identification of legal requirements (5.31).|
|
||||||
|
|**Protect**|Safeguards to ensure the delivery of critical infrastructure services and limit the impact of a potential security event.|To prevent or contain the impact of a potential cybersecurity event.|Access control (8.3), Information encryption (8.24), Secure authentication (8.5), Physical security (7.1).|
|
||||||
|
|**Detect**|Activities to identify the occurrence of a cybersecurity event in a timely manner.|To enable timely discovery of security events to minimize damage.|Logging (8.15), Monitoring activities (8.16), Intrusion detection (8.1).|
|
||||||
|
|**Respond**|Actions taken regarding a detected cybersecurity incident to contain its impact.|To take action once an incident is discovered to keep it from spreading or getting worse.|Incident response planning (5.24), Reporting events (5.25), Incident management (5.26).|
|
||||||
|
|**Recover**|Activities to restore any capabilities or services that were impaired due to a cybersecurity incident.|To restore "business as usual" and support timely resilience.|Backup (8.13), ICT readiness for business continuity (5.30), Post-incident learning.|
|
||||||
|
### 4. Operational Capabilities
|
||||||
|
The Operational Capabilities help practitioners understand the functional area a control belongs to.
|
||||||
|
|
||||||
|
|**Capability**|**Description**|
|
||||||
|
|---|---|
|
||||||
|
|**Governance**|Policies, frameworks, and management oversight.|
|
||||||
|
|**Asset Management**|Identification and protection of information assets and hardware.|
|
||||||
|
|**Information Protection**|Technical and organizational measures to keep data secure.|
|
||||||
|
|**Human Resource Security**|Security relating to the lifecycle of employment (hiring to termination).|
|
||||||
|
|**Physical Security**|Protecting physical premises, equipment, and facilities.|
|
||||||
|
|**System and Network Security**|Hardening infrastructure, managing traffic, and securing connections.|
|
||||||
|
|**Application Security**|Security within software development and business applications.|
|
||||||
|
|**Secure Configuration**|Standardizing settings for hardware, software, and services.|
|
||||||
|
|**Identity and Access Management**|Managing who can access what (IAM).|
|
||||||
|
|**Threat and Vulnerability Management**|Identifying risks and patching security holes.|
|
||||||
|
|**Continuity**|Resilience and recovery planning for disruptions.|
|
||||||
|
|**Supplier Relationships Security**|Managing risks from third parties and the supply chain.|
|
||||||
|
|**Legal and Compliance**|Meeting laws, regulations, and contractual obligations.|
|
||||||
|
|**Information Security Assurance**|Auditing and monitoring to ensure controls are working.|
|
||||||
|
|**Information Security Incident Management**|Detecting and responding to security events.|
|
||||||
|
|
||||||
|
### 5. Security Domains
|
||||||
|
|
||||||
|
Views controls from the perspective of four high-level information security domains.
|
||||||
|
* Governance_and_Ecosystem
|
||||||
|
* Protection
|
||||||
|
* Defence
|
||||||
|
* Resilience
|
||||||
77
Corpus/Obsidian Front Matter Syntax.md
Normal file
77
Corpus/Obsidian Front Matter Syntax.md
Normal file
|
|
@ -0,0 +1,77 @@
|
||||||
|
# Obsidian Front Matter Syntax
|
||||||
|
|
||||||
|
**Obsidian’s front matter follows YAML syntax**, with a few **important caveats**.
|
||||||
|
### What works (standard YAML)
|
||||||
|
|
||||||
|
Obsidian uses **YAML front matter** at the top of a note, delimited by `---`. Most standard YAML features work as expected, see this short example:
|
||||||
|
|
||||||
|
```YAML
|
||||||
|
---
|
||||||
|
|
||||||
|
title: My Note
|
||||||
|
|
||||||
|
tags:
|
||||||
|
|
||||||
|
- obsidian
|
||||||
|
|
||||||
|
- yaml
|
||||||
|
|
||||||
|
published: true
|
||||||
|
|
||||||
|
rating: 4.5
|
||||||
|
|
||||||
|
created: 2026-04-21
|
||||||
|
|
||||||
|
---
|
||||||
|
```
|
||||||
|
|
||||||
|
This includes:
|
||||||
|
|
||||||
|
- Key–value pairs
|
||||||
|
- Lists (arrays)
|
||||||
|
- Booleans, numbers, strings, dates
|
||||||
|
- Nested objects
|
||||||
|
|
||||||
|
### Obsidian-specific limitations & quirks
|
||||||
|
|
||||||
|
Although it’s YAML, Obsidian does **not support the full YAML spec equally everywhere**:
|
||||||
|
|
||||||
|
1. **Tabs are not allowed**
|
||||||
|
YAML requires spaces for indentation. Tabs can break parsing.
|
||||||
|
|
||||||
|
2. **Advanced YAML features may not be recognized** These may technically be valid YAML but are not reliably usable in Obsidian:
|
||||||
|
|
||||||
|
- Anchors (`&` / `*`)
|
||||||
|
- Complex inline objects
|
||||||
|
- Multi-document YAML
|
||||||
|
|
||||||
|
3. **Everything is treated as metadata, not logic** Obsidian doesn’t “execute” YAML — it just reads values for:
|
||||||
|
|
||||||
|
- Properties panel
|
||||||
|
- Search
|
||||||
|
- Filters
|
||||||
|
- Plugins (e.g., Dataview)
|
||||||
|
|
||||||
|
4. **Some plugins impose their own expectations** For example:
|
||||||
|
|
||||||
|
- `tags` should usually be a list of strings
|
||||||
|
- Dates may need to be ISO-like (`YYYY-MM-DD`) for queries to work
|
||||||
|
|
||||||
|
5. **Inline formatting is treated as plain text** Links or markdown inside front matter are just strings:
|
||||||
|
|
||||||
|
`author: "[[Richard Kranendonk]]"`
|
||||||
|
``
|
||||||
|
|
||||||
|
### ✅ Best practice
|
||||||
|
|
||||||
|
Think of Obsidian front matter as:
|
||||||
|
|
||||||
|
> **“Well-behaved, simple YAML meant for metadata, not configuration logic.”**
|
||||||
|
|
||||||
|
Stick to:
|
||||||
|
|
||||||
|
- Scalars (strings, numbers, booleans)
|
||||||
|
- Lists
|
||||||
|
- Simple nesting
|
||||||
|
- Spaces (not tabs)
|
||||||
|
|
||||||
50
Corpus/Standards/ISO27x/Risk Treatment Plan.md
Normal file
50
Corpus/Standards/ISO27x/Risk Treatment Plan.md
Normal file
|
|
@ -0,0 +1,50 @@
|
||||||
|
# Risk Treatment Plan
|
||||||
|
|
||||||
|
Find faults or omissions in my reasoning.
|
||||||
|
|
||||||
|
The Canonical Form of a policy is:
|
||||||
|
>To mitigate the risk of R, control C will be implemented on asset A under the responsibility of asset owner AO. The effectiveness will be measured through method M and will be evaluated by risk owner RO, against established risk criteria RC.
|
||||||
|
|
||||||
|
To establish the compliance of the implementation of a specific control to the ISO 27001 standard, the auditor will look for the following:
|
||||||
|
- the risk that the control is supposed to mitigate
|
||||||
|
- the risk owner
|
||||||
|
- the scope of the control, in terms of organizational scope (certain business activities, organizational units) and asset(s) protected
|
||||||
|
- the control owner
|
||||||
|
- a description of the 'how' or the activities involved in the implementation, including roles and responsibilities
|
||||||
|
- how the effectiveness of the control will be established, when, and by whom
|
||||||
|
- how the effectiveness of the control will be evaluated, when, and by whom
|
||||||
|
- possible exemptions to the policy
|
||||||
|
- how exceptions will be handled
|
||||||
|
- where all this is documented (policies, logs etc., evaluation)
|
||||||
|
- for this documentation: Version information and who has authoured and signed off on the policy, Revision dates (+ next evaluation)
|
||||||
|
- what the change procedure is for a relevant policy
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
**"Formally":**
|
||||||
|
- A policy formally expresses the intentions and direction of management. Rather than detailing exactly _how_ a task should be executed, the overarching information security policy is supported by "topic-specific policies" **as needed** to mandate the implementation of controls for specific target groups or security areas (such as access control, physical security, or secure development).
|
||||||
|
- **The Role of a Procedure (The "How"):** The specific steps on _how_ to carry out an activity or process are defined in a **procedure**. For example, Control 5.37 requires organizations to maintain "documented operating procedures" that provide personnel with the detailed, step-by-step instructions needed to ensure the correct and secure operation of information processing facilities
|
||||||
|
- It is also important to note that a control is broadly defined as **any measure that modifies or maintains risk**. Therefore, a control itself can take the form of a policy, a procedure, a process, or a technical hardware/software function
|
||||||
|
|
||||||
|
|
||||||
|
Version Control
|
||||||
|
|
||||||
|
| Type | Value |
|
||||||
|
| --------------- | ----- |
|
||||||
|
| Version number: | x.xx |
|
||||||
|
| Version date: | x.xx |
|
||||||
|
| Document owner: | name |
|
||||||
|
| Approved by: | name |
|
||||||
|
| Approved on: | date |
|
||||||
|
| Next review: | date |
|
||||||
|
|
||||||
|
The Document Owner is responsible for development and implementation of the policy.
|
||||||
|
|
||||||
|
- [ ] Check Standard on documentation and ownership
|
||||||
|
|
||||||
|
|
||||||
|
## Approved
|
||||||
|
Name: | name
|
||||||
|
--- | ---
|
||||||
|
Signature: | signature
|
||||||
|
Date: | date
|
||||||
|
|
@ -1,21 +1,87 @@
|
||||||
# Corpus Metadata
|
# Corpus Metadata
|
||||||
|
|
||||||
- All notes in this Obsidian vault need metadata.
|
- All notes in this Obsidian vault need metadata.
|
||||||
- These metadata need to follow the [Obsidian Front Matter Syntax](../../Content%20Factory/Obsidian%20Front%20Matter%20Syntax.md).
|
- These metadata need to follow the [Obsidian Front Matter Syntax](Obsidian%20Front%20Matter%20Syntax.md).
|
||||||
- Every note will get a field ’notetype’ in its front matter – see below for possible values.
|
- Obsidian calls metadata key-value pairs 'Properties'
|
||||||
|
- In this Corpus we use General properties (every note should have them) and Specific properties (depending on the kind of note, can be inferred from other properties)
|
||||||
|
|
||||||
## Notetypes for Obsidian Corpus
|
## General metadata
|
||||||
|
|
||||||
Every note will get a field ’notetype’ in its front matter.
|
### Notetype
|
||||||
|
|
||||||
The field will have one of the following values:
|
The `notetype` field will have one of the following values:
|
||||||
- guide: guided, hands-on lessons, learning by doing, interactive lessons
|
- `guide`: guided, hands-on lessons, learning by doing, interactive lessons
|
||||||
- explanation: background and context to the standards, paraphrases of the original standard texts, opinion, discussion, underlying principles, interpretation
|
- `explanation`: background and context to the standards, paraphrases of the original standard texts, opinion, discussion, underlying principles, interpretation
|
||||||
- application: steps to solve a specific, real-world problem. Implementing the standard in real world environments, implementation aids, implementation examples, templates, etc.
|
- `application`: steps to solve a specific, real-world problem. Implementing the standard in real world environments, implementation aids, implementation examples, templates, etc.
|
||||||
- reference: for original standard texts, dictionaries, terms and definitions.
|
- `reference`: for original standard texts, dictionaries, terms and definitions.
|
||||||
- other: for all notes that, by there content, cannot be placed in one for the previous categories.
|
- `other`: for all notes that, by there content, cannot be placed in one for the previous categories.
|
||||||
|
|
||||||
Note:
|
Note:
|
||||||
- The original standard texts in the OST folder and subfolders are also tagged with “sourcetext”. The body of these notes must never be changed!
|
- Notes in the iso27DIY-gis/guide folder and subfolders are typically of the `guide` type.
|
||||||
- Notes in the iso27DIY-gis/guide folder and subfolders are typically of the guide type.
|
- Notes in iso27DIY-gis/reference and subfolders are typically of the `explanation` or `application` type.
|
||||||
- Notes in iso27DIY-gis/reference and subfolders are typically of the explanation or application type.
|
|
||||||
|
### Language
|
||||||
|
For the language property we use the language code as defined in ISO 639-1.
|
||||||
|
|
||||||
|
|
||||||
|
## Metadata for ISO 27001 and 27002 Original Standard Texts
|
||||||
|
- The original texts of the ISO 27001 and ISO 27002 standards can be found in the OST folder and subfolders.
|
||||||
|
- These notes are tagged with “sourcetext”.
|
||||||
|
- The body of these notes must never be changed!
|
||||||
|
- Specific properties for ISO 27002 OST notes are deduced from chapter 4 of the standard ("Themes and Attributes"). They are: `theme`, `control_type`, `information_security_properties`, `cybersecurity_concepts`, `operational_capabilities`, and `security_domains`.
|
||||||
|
- For the possible values of these properties, see [ISO 27002 Themes and Attributes](ISO%2027002%20Themes%20and%20Attributes.md).
|
||||||
|
|
||||||
|
|
||||||
|
## Phases for ISMS implementation
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# Enrichment Prompt Examples
|
||||||
|
|
||||||
|
## Adding front matter to original ISO clauses and controls
|
||||||
|
|
||||||
|
- We are going to add front matter to the files in folder iso27diy-corp/Corpus/Standards/ISO27x/OST/27002/EN.
|
||||||
|
- To do this, you will need access to this folder and its contents. Check that you have access, and if not, stop the process immediately and get into contact with the user to fix the problem.
|
||||||
|
- You also need to be able to read the [Original Standard Text](../iso27diy-corp/Corpus/Standards/ISO27x/OST/27002/EN/ISO%2027002_2022_EN.docx). If you cannot access or read this document, stop the process immediately and get into contact with the user to fix the problem.
|
||||||
|
- See [_Corpus-metadata](../iso27diy-corp/Corpus/_Corpus-metadata.md) for instructions on adding metadata.
|
||||||
|
- Each note in this folder (with a few exceptions) represents an ISO 27002 Control.
|
||||||
|
- Additionally to what is described in the Corpus Metadata note, each control will get metadata fields according to [ISO 27002 Themes and Attributes](ISO%2027002%20Themes%20and%20Attributes.md) - note can be found in the Content Factory folder.
|
||||||
|
|
||||||
|
Additionally, you will add the following metadata key-value pairs:
|
||||||
|
```YAML
|
||||||
|
notetype: sourcetext
|
||||||
|
standard: ISO 27002
|
||||||
|
version: 2022
|
||||||
|
language: EN
|
||||||
|
type: control
|
||||||
|
id: A.<x.yy>
|
||||||
|
title: <control title>
|
||||||
|
```
|
||||||
|
|
||||||
|
- The `<x.yy>` part of the `id` and the `<control title>` can often be found in the content of the markdown note as a level 2 header.
|
||||||
|
- THIS IS MOST IMPORTANT: Do not make up or infer any of these themes, attributes and values. If you cannot extract them from the note itself, refer to the Original Standard Text.
|
||||||
|
- When you cannot extract the information from the note itself, or from the Original Standard Text, mark the note with the tag REVIEW.
|
||||||
|
|
||||||
|
## Adding more front matter
|
||||||
|
We are now going to work on files in iso27diy-corp/Corpus/Standards/ISO27x/OST/27001/NL/
|
||||||
|
|
||||||
|
Write a simple program or script to add properly formatted YAML front matter (for Obsidian) to the markdown files in the iso27diy-corp/Corpus/Standards/ISO27x/OST/27001/NL/ directory.
|
||||||
|
|
||||||
|
Here is an example for c-6.3-Planning-van-wijzigingen.md:
|
||||||
|
```
|
||||||
|
notetype: reference
|
||||||
|
standard: ISO 27001
|
||||||
|
version: 2023
|
||||||
|
language: NL
|
||||||
|
type: clause
|
||||||
|
id: "C.6.3"
|
||||||
|
title: "Planning van wijzigingen"
|
||||||
|
tags:
|
||||||
|
- iso27001/2023/EN
|
||||||
|
- sourcetext
|
||||||
|
status: active
|
||||||
|
```
|
||||||
|
|
||||||
|
`id` and `title` are specific to the file, the other kv-pairs are the same for all files.
|
||||||
|
|
||||||
|
Do a test run to see if your program has the intended effect. Check back with the user if you encounter exceptions.
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue