cleaning up Sparks

This commit is contained in:
Richard Kranendonk 2026-05-14 16:57:06 +02:00
parent b8d1d4e02f
commit 704e6dd07f
162 changed files with 393 additions and 1041 deletions

View file

@ -0,0 +1,7 @@
# Using AI for Threat Modeling
[Create a threat analysis chatbot](../../Various/Create%20a%20threat%20analysis%20chatbot.md)
[PLOT4AI](https://plot4.ai) (Privacy Library Of Threats 4 Artificial Intelligence): A threat modeling library to help you build responsible AI
by [Isabel Barbéra](https://www.linkedin.com/in/isabelbarbera/)

View file

@ -0,0 +1,48 @@
# About the connection between threat intelligence, analysis and modeling
### 🔄 Interplay Overview
|Concept|Role in Cybersecurity|How It Connects to the Others|
|---|---|---|
|**Threat Intelligence**|Collects and delivers data on threats|Feeds raw data into analysis and modelling|
|**Threat Analysis**|Interprets and assesses threat data|Uses intelligence to evaluate risks and impact|
|**Threat Modelling**|Maps out potential attack paths and scenarios|Uses analysis to simulate and prioritize threats|
---
### 🧠 Threat Intelligence → 🔍 Threat Analysis
- Threat intelligence provides **real-time data** on threat actors, malware, vulnerabilities, and attack trends.
- Analysts use this data to **identify patterns**, **assess relevance**, and **prioritize risks** based on the organization's context.
### 🔍 Threat Analysis → 🧩 Threat Modelling
- Analysis helps determine **which threats are most likely and impactful**.
- This guides threat modelling to focus on **realistic attack scenarios**, not just theoretical ones.
### 🧩 Threat Modelling → 🧠 Threat Intelligence
- Threat modelling reveals **gaps in visibility** or **missing threat data**.
- These insights can refine intelligence collection efforts, ensuring more targeted and useful data.
---
### 🛡️ Real-World Example
Imagine a financial institution:
1. **Threat Intelligence** detects a surge in phishing campaigns targeting banking apps.
2. **Threat Analysis** reveals that attackers are exploiting MFA fatigue and targeting mobile users.
3. **Threat Modelling** simulates how these attacks could bypass defenses and identifies weak points in mobile app authentication.
This leads to:
- Updating detection rules.
- Strengthening MFA protocols.
- Training users on phishing awareness.
---
Together, these disciplines create a **feedback loop** that strengthens an organization's ability to **predict, prevent, and respond** to cyber threats.
Would you like a visual diagram or a case study to illustrate this further?

View file

@ -1,8 +1,4 @@
---
tags:
- project/iso27DIY
- type/explainer
---
# About implementation and proof
The auditor will require proof of the implementation of the ISMS and all its individual controls. Proper implementation means a control is risk-based, theres a policy describing the why and how of its implementation, its results are monitored or measured, its effectiveness is evaluated, and possible improvements to the implementation of the control are identified.

View file

@ -1,11 +1,4 @@
---
tags:
- iso27001
- policy
- control
- risk
---
# About policies, controls, and risks
`Within a ISO 27001 compliant ISMS, is it possible to implement a control without having a policy for that control?`

View file

@ -1,9 +1,4 @@
---
tags:
- project/iso27DIY
- type/explainer
---
## About the Statement of Applicability
# About the Statement of Applicability
In essence, the Statement of Applicability shows the outcome of the risk treatment process ([6.1.3a](../../Corpus/Standards/MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md)). It is usually presented as a table of Annex A controls, together with a short explanation for the selection *or* exclusion of each, and its implementation status.

View file

@ -0,0 +1,130 @@
See also:
- [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
- [Identity and Access Management (IAM)](../Identity%20and%20Access%20Management%20(IAM).md)
- [RBAC Access levels](../../Literature%20notes/RBAC%20Access%20levels.md)
- [CRUD Matrices](../Information%20Security/CRUD%20Matrices.md)
Source: [](../../Attachments/Certified%20Ethical%20Hacker%20Exam%20Guide%202021.pdf)
- Mandatory Access Control (MAC):
- Every object gets a label
- Confidential, secret, top secret, etc
- The administrator decides who gets access to what security level;
- Users cannot change these settings
- Used on old systems (e.g. Top Secret Gov. information)
- Discretionary Access Control (DAC):
- Used in most OS
- Owner of the data defines access
- Very flexible access control; Very weak security
- Role-based Access Control (RBAC):
- Access to resources is defines by a set of rules defined by a role in your organization/job function (Manager, Director etc)
- e.g., "Administrators can read, write, and delete all files," "Employees can only read certain files."
- Administrators provide access based on the role of the user
- Rights are gained implicitly instead of explicitly
- In Windows, use Groups to provide role-based access control
- e.g. Admin Groups --> Rights and Perms,
- Sales Group --> Rights and Perms
Also found, with Gemini, 2 juni 2025:
- Attribute-Based Access Control (ABAC):
- e.g., "Only users from the 'Finance' department located in 'Head Office' can access this financial report."
- Relationship-Based Access Control (ReBAC)
- e.g., "Friends can view my photos."
## Mandatory vs. Discretionary access control
Source: Wikipedia, dec. 2024
In mandatory access control (MAC), the security policy is centrally controlled by a policy administrator and is guaranteed (in principle) to be enforced for all users. Users cannot override the policy and, for example, grant access to files that would otherwise be restricted.
By contrast, discretionary access control (DAC) allows users the ability to make policy decisions or assign security attributes. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control).
Systems can implement both MAC and DAC simultaneously, where DAC refers to one category of access controls that subjects can transfer among each other, and MAC refers to a second category of access controls that imposes constraints upon the first.
Occasionally, a system as a whole is said to have "discretionary" or "purely discretionary" access control when that system lacks mandatory access control.
## Different access control models
Access control models govern how users are granted access to resources in a system. This document compares **RBAC (Role-Based Access Control)**, **ABAC (Attribute-Based Access Control)**, **NGAC (Next-Generation Access Control)**, and **PBAC (Policy-Based Access Control)**, outlining their differences, advantages, and disadvantages.
### RBAC (Role-Based Access Control)
- **Definition**: Access is granted based on roles assigned to users. A role represents a set of permissions, and users inherit permissions from their assigned roles. RBAC is policy-neutral in the sense that it can be used to implement MAC or DAC.
- **Key Components**: Users, roles, and permissions.
**Pros:**
- Simple and intuitive to implement for organizations with clear hierarchical structures.
- Reduces administrative overhead when managing permissions.
- Well-suited for stable environments with predictable access needs.
**Cons:**
- Lacks flexibility; difficult to handle exceptions or dynamic contexts (e.g., time-based restrictions).
- Role explosion: Managing a large number of roles becomes cumbersome as the system scales.
- Not context-aware.
### ABAC (Attribute-Based Access Control)
- **Definition**: Access is granted based on attributes of users, resources, actions, and the environment. Attributes can include user roles, resource sensitivity, location, time, and more.
- **Key Components**: Policies, attributes, and conditions.
**Pros:**
- Highly flexible and fine-grained access control.
- Supports dynamic, context-aware decisions (e.g., granting access only during work hours or from specific locations).
- Eliminates role explosion.
**Cons:
- Complex to implement and manage due to the need for a robust attribute infrastructure.
- Policy authoring can be error-prone and challenging for administrators.
- Requires real-time evaluation, which may impact performance.
### NGAC (Next-Generation Access Control)
- **Definition**: A standards-based approach that integrates various access control concepts, combining RBAC, ABAC, and policy-based models. It uses a graph-based structure to represent relationships between users, attributes, and policies.
- **Key Components**: Graphs (users, attributes, and policies) and decision engines.
**Pros:**
- Flexible and adaptable to different access control needs.
- Unified framework for managing diverse access control models.
- Highly efficient for environments requiring a mix of models.
**Cons:
- Complexity in setup and management.
- Limited adoption and tooling support compared to RBAC or ABAC.
### PBAC (Policy-Based Access Control)
- **Definition**: Access is managed through explicitly defined policies that dictate who can access what under which conditions. Often overlaps with ABAC.
- **Key Components**: Policies, rules, and conditions.
**Pros:**
- Fine-grained control with a focus on clear, centralized policy definition.
- Scalable for distributed systems or multi-tenant architectures.
- Strongly aligned with regulatory compliance requirements.
**Cons:
- Similar to ABAC, policy complexity can grow quickly.
- Administrators require expertise to define and maintain accurate policies.
- Performance overhead due to policy evaluation.
## Summary Comparison
| Feature / Model | RBAC                      | ABAC            | NGAC        | PBAC        |
| -------------------------- | ------------------------- | --------------- | ----------- | -------------- |
| **Flexibility** | Low                       | High          | High        |  High          |
| **Complexity** | Low | High           | Moderate    |  Moderate      |
| **Context-Awareness** | No                        | Yes           | Yes         |  Yes           |
| **Scalability** | Limited (role explosion)  | High          | High        |  High          |
| **Ease of Implementation** | Easy                   | Difficult     | Moderate    |  Moderate      |
| **Adoption** | Widespread               | Increasing    | Emerging    |  Increasing    |
## Choosing the Right Model
- Use **RBAC** for environments with stable, well-defined roles and minimal need for contextual decisions.
- Use **ABAC** or **PBAC** for systems requiring dynamic, context-aware, and fine-grained access control.
- Consider **NGAC** if a unified, standards-based approach is necessary and you need to integrate multiple models.
The decision depends on your organization's complexity, security needs, and resource availability.

View file

@ -0,0 +1,49 @@
# Relevant articles for Access Control
The prevention of unauthorized access to classified data is fundamentally supported by a comprehensive set of controls across organizational, physical, and technological domains, particularly those focusing on **Confidentiality** (one of the core Information Security Properties).
The relevant clauses and controls, primarily derived from ISO/IEC 27002:2022 (referenced in Annex A of ISO/IEC 27001:2022), are detailed below:
### 1. Controls Focused on Data Identification, Classification, and Handling
To prevent unauthorized access to classified data, the data itself must first be identified and properly protected according to its sensitivity:
- **5.12 Classification of information:** Information should be **classified according to the organization's information security needs based on confidentiality**, integrity, availability, and relevant interested party requirements. This helps ensure the identification and understanding of the protection needs of information.
- **5.13 Labelling of information:** An appropriate set of procedures for **information labelling** should be developed and implemented in accordance with the adopted classification scheme. Labelling communicates the classification and supports automation of protection controls.
- **5.10 Acceptable use of information and other associated assets:** Rules for the acceptable use and procedures for handling information and other associated assets should be identified, documented, and implemented. This involves **access restrictions supporting the protection requirements for each level of classification**.
- **5.33 Protection of records:** Records must be protected from unauthorized access.
- **5.34 Privacy and protection of PII:** The organization should identify and meet requirements regarding the **preservation of privacy and protection of Personally Identifiable Information (PII)** according to applicable laws, regulations, and contractual requirements, since PII is often considered sensitive or classified.
- **7.7 Clear desk and clear screen:** **Clear desk rules** for papers and removable storage media and clear screen rules for information processing facilities should be defined and enforced to reduce the risk of unauthorized access or loss of information outside of normal working hours.
### 2. Controls Related to Identity, Access Management, and Privileges
These controls directly manage who (or what) is authorized to access resources and classified data:
- **5.15 Access control:** **Rules to control physical and logical access** to information and other associated assets should be established and implemented based on business and information security requirements. Access rules should adhere to principles like "need-to-know".
- **8.3 Information access restriction:** **Access to information and other associated assets should be restricted** in accordance with the established topic-specific policy on access control. Public or anonymous access should generally not be granted to storage locations containing sensitive information.
- **8.2 Privileged access rights:** The allocation and use of **privileged access rights should be restricted and managed**. Inappropriate use of system administrator privileges is a major factor contributing to system failures or breaches.
- **5.16 Identity management:** The **full life cycle of identities should be managed** to ensure unique identification of individuals and systems and enable appropriate assignment of access rights.
- **5.17 Authentication information:** The allocation and management of authentication information (e.g., passwords, tokens) must be controlled by a management process, including advising personnel on appropriate handling, to ensure **proper entity authentication**.
- **8.5 Secure authentication:** **Secure authentication technologies and procedures** (like multi-factor authentication) should be implemented based on information access restrictions and the access control policy.
- **5.18 Access rights:** Access rights should be provisioned, reviewed, modified, and removed in accordance with the access control policy. This process ensures access is defined and authorized according to business needs.
- **8.18 Use of privileged utility programs:** The use of utility programs capable of overriding system and application controls must be restricted and tightly controlled to ensure they do not harm information security.
- **8.4 Access to source code:** Read and write access to source code, development tools, and software libraries should be appropriately managed to **maintain the confidentiality of valuable intellectual property**.
### 3. Technological Controls for Data Protection and Leakage Prevention
These technical measures actively protect classified data from disclosure:
- **8.12 Data leakage prevention:** Measures should be applied to systems, networks, and devices that process, store, or transmit sensitive information **to detect and prevent unauthorized disclosure and extraction of information**.
- **8.11 Data masking:** Data masking techniques (like pseudonymization or anonymization) should be used in accordance with access control policies and legal requirements **to limit the exposure of sensitive data**.
- **8.24 Use of cryptography:** Rules for the effective use of cryptography, including key management, should be defined and implemented to protect the **confidentiality** and integrity of information.
- **8.1 User endpoint devices:** Information stored on, processed by, or accessible via user endpoint devices must be protected against associated risks. This includes requirements for physical protection, storage device encryption, and logical access controls.
- **6.7 Remote working:** Security measures must be implemented when personnel are working remotely to **protect information accessed, processed, or stored outside the organizations premises**.
### 4. Segregation and Operational Controls
These controls prevent classified data from being compromised via unauthorized operational pathways or environments:
- **8.31 Separation of development, test and production environments:** Development, testing, and production environments should be **separated and secured** to **protect the production environment and data from compromise**. This prevents the compromise of live production data by activities in development or testing.
- **8.33 Test information:** Test information must be appropriately selected, protected, and managed. This typically involves using **access controls comparable to production** and avoiding the direct copying of sensitive production data into test environments unless masking is used.
- **5.3 Segregation of duties:** Conflicting duties and responsibilities should be segregated to reduce the risk of bypassing information security controls.
- **8.22 Segregation of networks:** Groups of services, users, and systems should be segregated in the organizations networks to split the network into security boundaries and control traffic between them.

View file

@ -0,0 +1,13 @@
# Access Control
While [authorization](../../Standards/ISO27x/Authorization.md) is primarily concerned with establishing the policies and rules that dictate access (i.e. *what* a person or system is allowed to do), **access control** is the _system_ or _process_ that enforces those defined permissions.
See:
- [Gedachten over rechtenstructuren](../Information%20Security/Gedachten%20over%20rechtenstructuren.md)
- [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
- [Access Control Models](Access%20Control%20Models.md)
- [ISO 27001 A 9 Access control](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%209%20Access%20control.md)
- [a-5.15-Access-control](../../Standards/ISO27x/OST/27002/EN/a-5.15-Access-control.md)

Binary file not shown.

After

Width:  |  Height:  |  Size: 96 KiB

View file

@ -0,0 +1,104 @@
# Assets, Ownership, and Risk: Structured Overview
## 1. Core Concept: What Is an Asset?
An **information asset** is anything that has value to an organization. It can take many forms:
- Printed or electronic documents
- Intellectual property and proprietary knowledge
- Personal data
- Knowledge of processes
- Physical items
- Information systems that process, store, or transmit information
**Selected definitions:**
| Source | Definition |
| ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ISO/IEC 27000:2018 | Anything that has value to an organization (e.g. printed documents, electronic documents, intellectual property, personal data, knowledge of processes, physical items). |
| NIST SP 800-53 | Information and the information systems that process, store, and transmit that information. |
| DAMA-DMBOK | A resource of value that an organization uses to understand, operate, and innovate. |
| Gartner IT Glossary | A collection of information that is defined and managed as a standalone entity and is considered of value. |
| (ISC)² CISSP Official Study Guide (Chapple, Stewart et al., p.64) | Anything within an environment that should be protected — anything used in a business process or task. If an organization places any value on an item and deems it important enough to protect, it is labeled an asset for purposes of risk management and analysis. |
**Examples of assets (CISSP):** computer files, network services, system resources, processes, programs, products, IT infrastructure, databases, hardware devices, furniture, product recipes/formulas, intellectual property, personnel, software, facilities.
**Consequences of asset loss or disclosure:**
- Overall security compromise
- Loss of productivity
- Reduction in profits
- Additional expenditures
- Discontinuation of the organization
- Numerous intangible consequences
## 2. Assets in Relation to Vulnerabilities, Threats, and Risks
The relationship between the four concepts can be summarized as:
> A threat exploits an exposed vulnerability to damage an asset, which results in a risk to the organization.
This relationship is known as the **Operations Security Triple** (assets, vulnerabilities, threats).
**On risk materialization:**
A risk can be seen as a theoretical threat scenario. When a risk "materializes," an anticipated or potential threat has actually taken place — exploiting a vulnerability, affecting an asset, and resulting in actual harm or loss.
## 3. Asset Ownership
### ISO 27001 Requirements
ISO 27001 explicitly requires asset ownership in two controls:
- **A.8.1.2** — Every asset should have an owner.
- **A.9.2.5** — Asset owners must periodically evaluate access rights.
### Determining Ownership: The RUMC Model
*The following model was shared by Remco Landegge, Security Expert Radboud UMC (2 December 2024). Remove all references to Radboudumc before reusing.*
When asset or process ownership is unclear, it can be determined by mapping the situation to one of four scenarios:
![](../rumc-eigenaarschap.png)
**Situation 1 (B1): Asset/process used within a single organizational unit**
The head or director of that organizational unit is the owner **(E1)**.
*Note: for institutes, this applies only to assets/processes needed within their own unit — not to those required for the complete core task.*
**Situation 2 (B2): Asset/process used across multiple departments, or a department and a centre**
The director of the core task in which the asset/process is used is the owner **(E2)**. The owner operates independently and in a facilitating role, to ensure all stakeholders (across departments and/or centres) are involved in decisions about functionality, security, and service levels.
**Situation 3 (B3): Asset/process used across multiple institutes**
The directors of the institutes involved jointly determine who the owner is **(E3)**. The owner operates independently and in a facilitating role to ensure stakeholder involvement across institutes.
**Situation 4 (B4): Asset/process spanning (virtually) all parts of the organization, with no owner claimed**
First, determine whether the asset/process is actually needed. The three institute directors and directors of supporting services jointly decide **(E4)**. If no consensus is reached, the Board of Directors appoints an owner **(E4)**.
---
## Notes on Linked Content
The source files reference the following related notes in the vault:
- [Vulnerability 1](../Vulnerability%201.md)
- [Threat](../../Literature%20notes/Threat.md)
- [Risks](../Risks.md)
- [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)
![Asset classes](Asset%20classes.png)

View file

@ -0,0 +1,33 @@
---
tags:
- infosec
- type/explainer
---
# Authorization vs. Access Control
[Authorization](../../Standards/ISO27x/Authorization.md) defines _what_ a user (or system) is allowed to do, [access control ](Access%20Control.md) is the _system_ or _process_ that enforces those defined permissions.
## Authorization
- **What it is:** Authorization is the **process of determining what a verified user (or system) is allowed to do or access** once their identity has been confirmed (authenticated). It's about defining the **rights, privileges, or permissions** associated with a specific identity.
- **The "Why":** It answers the question, "What can this person/system do?"
- **Policy-driven:** Authorization is primarily concerned with establishing the policies and rules that dictate access. These policies can be based on various factors like Roles, Attributes or Relationships (see [Access Control Models](Access%20Control%20Models.md)).
- **Examples:**
- A bank's policy stating that only the account holder can access their individual account online.
- A department head deciding that everyone in their department has access to a specific shared drive.
- Defining that a "guest" user has very limited access to a website.
## Access Control
- **What it is:** Access control is the **mechanism or system that enforces the authorization policies**. It's the technical implementation that actually grants or denies access to a resource based on the authorized permissions.
- **The "How":** It answers the question, "How is the 'what' actually applied and managed?"
- **Enforcement:** Access control is the act of putting those policies into practice. It involves:
- Checking a user's identity ([Authentication](../../Standards/ISO27x/Authentication.md)).
- Consulting the pre-defined [Authorization](../../Standards/ISO27x/Authorization.md)authorization rules.
- Granting or denying access to specific resources (files, applications, data, network segments, physical locations, etc.) or actions (read, write, delete, execute).
- **Examples:**
- An Access Control List (ACL) on a file system that specifies which users or groups can read, write, or execute a particular file.
- A firewall rule that allows or denies traffic based on source IP address and port.
- A system that prompts for an administrator password before allowing software installation.
- Physical security systems like keycard readers that only grant entry to authorized personnel.

View file

@ -0,0 +1,25 @@
# Het belang van een Bedrijfscontinuïteitsplan
Het hebben van een bedrijfscontinuïteitsplan (BCP) is cruciaal voor een organisatie om verschillende redenen:
1. **Minimale Uitvaltijd:** Een BCP helpt ervoor te zorgen dat kritieke bedrijfsfuncties kunnen doorgaan tijdens en na een ramp of onverwachte gebeurtenis. Dit minimaliseert uitvaltijd en de bijbehorende financiële verliezen.
2. **Risicobeheer:** Door potentiële risicos te identificeren en hier van tevoren op voor te bereiden, kan een organisatie deze risicos effectiever beheren en verminderen. Een BCP identificeert kwetsbaarheden en implementeert beschermingsmaatregelen en procedures om deze aan te pakken.
3. **Bescherming van Data en Bezittingen:** Een uitgebreid BCP omvat strategieën om belangrijke data en organisatorische bezittingen te beschermen en te herstellen, waardoor het risico op dataverlies of -corruptie wordt verminderd en bedrijfsactiviteiten zonder significante verstoring kunnen doorgaan.
4. **Behoud van Klantenvertrouwen:** Het snel en efficiënt reageren op een crisis helpt het vertrouwen van klanten, leveranciers en andere belanghebbenden te behouden, en toont aan dat de organisatie betrouwbaar en veerkrachtig is, zelfs onder uitdagende omstandigheden.
5. **Zorg voor Naleving:** Veel sectoren zijn onderworpen aan wettelijke vereisten met betrekking tot rampenherstel en bedrijfscontinuïteit. Een formeel BCP zorgt voor naleving van deze voorschriften, wat helpt om juridische problemen en boetes te vermijden.
6. **Bescherming van Medewerkers:** Een BCP geeft prioriteit aan de veiligheid van medewerkers door procedures te hebben voor communicatie, evacuatie en continuïteit van werk in een veilige omgeving. Het waarborgen van het welzijn van medewerkers bevordert loyaliteit en productiviteit.
7. **Financiële Stabiliteit:** Door operationele verstoringen en financiële verliezen te minimaliseren, ondersteunt een BCP de financiële stabiliteit van een organisatie tijdens en na een onvoorziene gebeurtenis. Deze stabiliteit kan cruciaal zijn voor het nakomen van contractuele verplichtingen en het behouden van het vertrouwen van investeerders.
8. **Concurrentievoordeel:** Organisaties die tijdens verstoringen operationeel kunnen blijven, hebben een concurrentievoordeel ten opzichte van degenen die dat niet kunnen. Deze betrouwbaarheid kan een onderscheidende factor zijn op de markt.
9. **Faciliteren van Herstel:** Een BCP biedt een duidelijke routekaart voor herstel, met details over rollen, verantwoordelijkheden en procedures die moeten worden gevolgd na een verstoring, wat de terugkeer naar normale operaties versnelt.
10. **Opbouwen van Organisatorische Veerkracht:** Het proces van het ontwikkelen en onderhouden van een BCP helpt bij het bevorderen van een cultuur van veerkracht, waardoor de organisatie beter is voorbereid op een breed scala aan potentiële bedreigingen en veranderingen in het zakelijke milieu.
Al met al helpt een goed opgesteld bedrijfscontinuïteitsplan een organisatie om verstoringen te anticiperen, erop te reageren en ervan te herstellen, wat zorgt voor langdurige duurzaamheid en succes.

View file

@ -0,0 +1,24 @@
# Business Impact Analysis (BIA)
Business Impact Analysis (BIA) is an activity within the proces of Business Continuity Planning ([BCP](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)).
The goal of a Business Impact Analysis (BIA) process is
A Business Impact Analysis (BIA) examines the potential impacts of disruptions, such as financial losses, reputational damage, regulatory penalties, and operational continuity.
The outcomes help to prioritize business activities and resources to enable the resumption of product and service delivery after a (major) disruption[^1].
Guidelines and tooling:
- [Guidelines for business impact analysis ISO 22317](../../Standards/ISO27x/ISO%2022317%20Guidelines%20for%20business%20impact%20analysis.md)
- [Assessing reputational risks](../../Various/Assessing%20reputational%20risks.md)
- [BIA Workshop](../../Standards/ISO27x/Implementation%20Products/BIA%20Workshop.md)
- [TLP impact matrix](../../Literature%20notes/Traffic%20Light%20Protocol%20TLP.md)
- Afhankelijkheid tussen systemen/voorzieningen?
- Resource Breakdown Structure (RBS)
- Fishbone Diagram (Ishikawa/Cause and Effect): Useful for identifying root causes of dependencies and resource constraints in processes.
ISO 27001 Controls:
- [5.29:](../../MoCs/ISO_27002_2022_5.29_MoC%20Information%20security%20during%20disruption.md) Information security during disruption
- [5.30:](../../MoCs/ISO_27002_2022_5.30_MoC%20ICT%20readiness%20for%20business%20continuity.md) ICT readiness for business continuity
- [5.9:](../../MoCs/ISO_27002_2022_5.9_MoC%20Inventory%20of%20information%20and%20other%20associated%20assets.md) Inventory of information and other associated assets regarding assets marked Critical on the Availability aspect
[^1]: See [Disaster Recovery Planning](Disaster%20Recovery%20Planning.md)

View file

@ -0,0 +1,122 @@
---
tags:
- iso27001
- audit
---
# Challenges in auditing a one man company
Compliance with the ISO 27001 standard presents unique challenges for a one-man company (or sole proprietor), primarily due to limited resources, expertise, and the need to fulfill all roles typically distributed among multiple staff members in larger organizations. Below are the specific challenges and practical strategies to overcome them.
## Specific Challenges for a One-Man Company
- **Limited Management Support and Involvement**
- In a one-man company, while the owner is both management and staff, the lack of a team can mean missing out on diverse perspectives and checks and balances. The owner may also struggle to balance daily operations with the demands of implementing and maintaining an ISMS[1].
- **Resource Constraints**
- Sole proprietors often face tight budgets and limited time, making it difficult to allocate sufficient resources to compliance activities such as risk assessments, documentation, and ongoing monitoring[2][1].
- **Complexity of Documentation**
- ISO 27001 requires comprehensive documentation, including policies, risk assessments, and records. Managing all documentation single-handedly can be overwhelming and time-consuming[2][1].
- **Lack of Specialized Knowledge**
- The owner may lack expertise in information security, making it challenging to interpret and implement the standards requirements correctly[1].
- **Continuous Monitoring and Improvement**
- Maintaining and improving the ISMS requires ongoing effort, including regular reviews, internal audits, and updates to controls. This is difficult for a sole proprietor who may already be stretched thin[3].
- **Employee Awareness and Training**
- Although there are no employees, the owner must still ensure personal awareness and training, and may miss out on the benefits of peer learning and accountability[1][3].
## Strategies to Overcome These Challenges
- **Prioritize and Simplify Documentation**
- Focus on essential documents such as the Information Security Policy, Risk Treatment Plan, and Statement of Applicability. Use templates and streamline processes to reduce the documentation burden[1][3].
- **Leverage External Expertise**
- Consider hiring an ISO 27001 consultant or using online tools and platforms designed for small businesses to guide you through the process and provide templates and checklists[3][4].
- **Automate Where Possible**
- Use software solutions that automate risk assessments, documentation management, and compliance tracking. This can save time and reduce errors[4].
- **Conduct Regular Self-Assessments**
- Schedule periodic reviews of your ISMS to ensure it remains effective and up to date. Treat these as mini-audits, checking against the standards requirements[3][5].
- **Stay Informed and Trained**
- Invest in self-training through online courses, webinars, and resources specific to ISO 27001. This will help you understand the standard and stay current with best practices[1][5].
- **Collaborate with Peers or Networks**
- Join professional networks or forums where you can share experiences, ask questions, and learn from others facing similar challenges[1].
- **Use Open Source and Cost-Effective Tools**
- Implement open-source or affordable security tools to manage risks and controls within your budget constraints[2].
## Summary Table: Challenges vs. Solutions
| Challenge | Solution for One-Man Company |
|-----------------------------------|---------------------------------------------|
| Limited management support | Owner as both management and implementer |
| Resource constraints | Prioritize, automate, and use consultants |
| Complex documentation | Simplify, use templates, centralize records |
| Lack of specialized knowledge | Training, external expertise, peer networks |
| Continuous monitoring | Self-assessments, automation |
| Employee awareness/training | Self-training, online resources |
By adopting these strategies, a one-man company can navigate the complexities of ISO 27001 compliance, build a robust information security posture, and demonstrate commitment to protecting sensitive data[2][1][3].
Sources
[1] Challenges and Solutions to Face - Implementing ISO 27001 in SMEs Safely https://www.linkedin.com/pulse/challenges-solutions-face-implementing-iso-27001-smes-soumyajit-das-2ihec
[2] 10 Common ISO 27001 Challenges in Achieving Compliance https://compleye.io/articles/10-common-iso-27001-challenges-in-achieving-compliance/
[3] ISO 27001 for small businesses - a detailed guide https://www.dataguard.com/blog/iso-27001-for-small-businesses-a-detailed-guide
[4] A Guide to ISO 27001 for Small Business https://sprinto.com/blog/iso-27001-for-small-businesses/
[5] ISO 27001 for Startups https://www.brightdefense.com/resources/iso-27001-for-startups/
[6] ISO 27001 for Startups: Ten Best Practices https://drata.com/grc-central/get-started-iso-27001/iso-27001-for-startups
[7] Is ISO 27001 possible for a small company? : r/sysadmin - Reddit https://www.reddit.com/r/sysadmin/comments/q1vb3h/is_iso_27001_possible_for_a_small_company/
[8] Overcoming Common ISO 27001 Challenges for Small ... https://systemi.se/2025/01/19/iso-27001-challenges-for-small-companies/
[9] Can a business with a single employee gain ISO27001 certification? https://security.stackexchange.com/questions/238533/can-a-business-with-a-single-employee-gain-iso27001-certification
[10] 5 Challenges Your Business Must Overcome to Secure ISO 27001 Certification - MG Environmental Consulting https://mgenviro.com/5-challenges-your-business-must-overcome-to-secure-iso-27001-certification/
[11] Key Challenges for Small Companies in ISO 27001 Certification https://www.genspark.ai/spark/key-challenges-for-small-companies-in-iso-27001-certification/9d5cabe6-c856-461a-9337-fd105d0e3d95
[12] Common ISO 27001 Challenges & How to Overcome Them - Iseo Blue https://iseoblue.com/post/common-challenges-in-implementing-iso-27001-and-how-to-overcome-them/
[13] ISO 27001 Solutions: Expert Guidance https://isocouncil.com.au/iso-27001-problems-solutions/
[14] 3 Common ISO 27001 Implementation Challenges https://www.itgovernanceusa.com/blog/3-iso-27001-implementation-challenges-and-how-to-overcome-them
[15] ISO 27001:2022 Transition Challenges and How to Use ... https://www.itgovernance.co.uk/blog/iso-27001-2022-transition-challenges-and-how-to-use-iso-27002
[16] A Comprehensive Guide on ISO 27001 for Small Businesses - Socurely https://socurely.com/a-comprehensive-guide-on-iso-270001-for-small-business/
[17] What is ISO 27001 Compliance? [Steps to Implement it] https://sprinto.com/blog/iso-27001-compliance/
## Compliance challenges by Clause and Control
For a one-person company pursuing ISO 27001 certification, specific clauses and controls present inherent compliance challenges due to structural requirements that conflict with a single-person operation. These difficulties arise from the standard's design for organizational segregation and oversight, not merely from resource constraints. Key challenges include:
### 1. **Segregation of Duties (Annex A 5.3)**
The control mandates separation of conflicting responsibilities (e.g., development vs. deployment, access authorization vs. usage) to prevent fraud or errors. A solo operator inherently cannot segregate duties, as one person performs all roles[1][2].
*Overcoming it*: Document compensatory controls like automated approval workflows, third-party validations, or detailed activity logs to demonstrate oversight[2].
### 2. **Internal Audits (Clause 9.2)**
Requires independent audits of the ISMS. Self-auditing violates the independence principle[3][2].
*Overcoming it*: Hire an external auditor for periodic checks, or use automated audit tools with third-party verification[5][3].
### 3. **Management Review (Clause 9.3)**
Demands formal reviews of the ISMS by management, separate from operational roles. A sole proprietor cannot separate these functions[3].
*Overcoming it*: Maintain meticulous records of self-reviews, supplemented by external consultant assessments to add objectivity[4][3].
### 4. **Employee Competence/Training (A.7.2.2)**
Requires evidence of staff training and competence. With no employees, compliance is conceptually incongruous[4][3].
*Overcoming it*: Document the owners training/certifications and outsource specialized tasks to certified professionals[3].
### 5. **Incident Management (A.5.24)**
Relies on reporting lines and escalation paths, which are absent in a one-person structure[3].
*Overcoming it*: Implement automated incident detection tools and contract with third-party response services for escalation[3].
### Structural vs. Effort-Based Challenges
These issues stem from the standards assumption of organizational hierarchy, not effort or cost:
- **Segregation of Duties** and **Internal Audits** require role separation impossible for one person[1][2].
- **Management Review** lacks hierarchical separation[3].
- **Employee-focused controls** (e.g., training) become nonsensical without staff[4].
### Mitigation Strategies
- **Externalize critical functions**: Use consultants for audits, incident response, and specialized tasks[5][3][2].
- **Automate oversight**: Deploy tools for logging, approvals, and monitoring to simulate checks[4][2].
- **Document rigorously**: Compensate for structural gaps with exhaustive records of decisions, validations, and risk acceptances[4][3].
While achievable, certification requires creatively addressing these inherent conflicts through external support and technology, not merely scaling down larger-organization processes[5][2].
Sources
[1] ISO 27001:2022 Annex A 5.3 Segregation of Duties https://www.isms.online/iso-27001/annex-a/5-3-segregation-of-duties-2022/
[2] Can a business with a single employee gain ISO27001 ... https://security.stackexchange.com/questions/238533/can-a-business-with-a-single-employee-gain-iso27001-certification
[3] ISO 27001 for small businesses - a detailed guide https://www.dataguard.com/blog/iso-27001-for-small-businesses-a-detailed-guide
[4] How to Implement ISO 27001 Clause 4.1 and Pass The Audit https://hightable.io/iso-27001-clause-4-1-understanding-the-organisation-and-its-context/
[5] Is ISO 27001 possible for a small company? : r/sysadmin https://www.reddit.com/r/sysadmin/comments/q1vb3h/is_iso_27001_possible_for_a_small_company/
[6] What is ISO 27001? An easy-to-understand explanation. https://advisera.com/27001academy/what-is-iso-27001/
[7] Challenges and Solutions to Face - Implementing ISO 27001 in SMEs Safely https://www.linkedin.com/pulse/challenges-solutions-face-implementing-iso-27001-smes-soumyajit-das-2ihec
[8] Can an Individual Get ISO 27001 Certified? https://travasecurity.com/learn-with-trava/blog/can-an-individual-get-iso-27001-certified/
[9] The Challenges of Adopting ISO 27001 Controls: A Comprehensive Guide for CISOs and IT Administrators https://heimdalsecurity.com/blog/iso-27001-controls-challenges/
[10] Don't Make These 5 Mistakes When Implementing ISO 27001 https://insightassurance.com/dont-make-these-5-mistakes-when-implementing-iso-27001/

View file

@ -0,0 +1,70 @@
# Classificatie van risico's
Risico's kunnen worden ingedeeld in diverse categorieën, die elk een andere bron van gevaar vertegenwoordigen:
- **Omgevingsrisico's**: Deze risico's ontstaan door natuurlijke en externe factoren waar je weinig controle over hebt. Denk hierbij aan natuurrampen zoals overstromingen, brand, aardbevingen, of extreme weersomstandigheden. Ook stroomuitval of een storing in de koeling van een serverruimte vallen hieronder.
- **Organisatorische risico's**: Deze risico's zijn gerelateerd aan de bedrijfsprocessen en -structuur. Voorbeelden zijn een gebrek aan duidelijke beleidsregels, onvoldoende budget voor beveiliging, of een slechte interne communicatie over beveiligingsincidenten. Ook het niet correct uitvoeren van procedures of het ontbreken van een noodplan kan leiden tot grote risico's.
- **Procesmatige risico's**: Deze risico's komen voort uit de dagelijkse operationele procedures. Dit omvat onder andere verouderde back-up procedures, het ontbreken van een strikte procedure voor het toekennen van toegangsrechten, of een ineffectief patch management-proces voor software.
- **Compliance- en juridische risico's**: Deze risico's zijn het gevolg van het niet voldoen aan wet- en regelgeving, zoals de Algemene Verordening Gegevensbescherming (AVG) of sector-specifieke regels. Een gebrek aan naleving kan leiden tot hoge boetes en reputatieschade.
## Detaillering
Informatiebeveiligingsrisico's kunnen op diverse manieren worden geclassificeerd. Een veelgebruikte methode is door ze in te delen op basis van de oorzaak. Deze classificatie helpt organisaties om een gestructureerde aanpak te hanteren bij het identificeren en mitigeren van bedreigingen.
### Classificatie van Risico's op basis van Oorzaken
Risico's voor de informatiebeveiliging kunnen in de volgende categorieën worden ingedeeld:
---
#### 1. Omgevingsrisico's
Deze risico's zijn het gevolg van externe factoren en natuurverschijnselen die buiten de controle van een organisatie vallen. Ze kunnen de fysieke infrastructuur en daarmee ook de informatiesystemen bedreigen. Voorbeelden zijn:
- **Natuurrampen**: Zoals overstromingen, branden, aardbevingen of extreme weersomstandigheden.
- **Stroomuitval**: Langdurige onderbrekingen in de stroomvoorziening kunnen leiden tot het uitvallen van servers en netwerken.
- **Fysieke storingen**: Denk aan storingen in koelsystemen van datacenters, wat kan leiden tot oververhitting van apparatuur.
---
#### 2. Organisatorische Risico's
Deze risico's vloeien voort uit de interne structuur en bedrijfscultuur van een organisatie. Ze zijn gerelateerd aan managementbeslissingen en het ontbreken van duidelijke richtlijnen. Voorbeelden zijn:
- **Gebrek aan beleid**: Het ontbreken van duidelijke beveiligingsbeleidsregels of procedures.
- **Onvoldoende budget**: Een tekort aan financiële middelen voor de implementatie van beveiligingsmaatregelen.
- **Gebrekkige communicatie**: Slechte of onduidelijke communicatie over beveiligingsincidenten en risico's tussen verschillende afdelingen.
---
#### 3. Procesmatige Risico's
Deze risico's ontstaan door de dagelijkse operationele procedures en processen binnen een organisatie. Ze hebben te maken met de manier waarop taken worden uitgevoerd. Voorbeelden zijn:
- **Verouderde procedures**: Procedures voor back-ups of herstel van data die niet regelmatig worden getest of geüpdatet.
- **Onjuiste configuratie**: Fouten in de configuratie van netwerken of software die onbedoelde kwetsbaarheden creëren.
- **Slechte toegangscontrole**: Het niet tijdig intrekken van toegangsrechten van voormalige medewerkers.
---
#### 4. Compliance- en Juridische Risico's
Deze risico's ontstaan door het niet naleven van wet- en regelgeving, contractuele verplichtingen of industriële normen. Het kan leiden tot aanzienlijke boetes, juridische problemen en reputatieschade. Voorbeelden zijn:
- **Schending van de AVG**: Het verwerken van persoonsgegevens zonder de juiste juridische basis of beveiligingsmaatregelen.
- **Contractbreuk**: Het niet voldoen aan de beveiligingseisen die met klanten of partners zijn overeengekomen.
- **Niet voldoen aan standaarden**: Het negeren van sector-specifieke normen zoals de ISO 27001 voor informatiebeveiliging.

View file

@ -0,0 +1,29 @@
# Classifying Integrity
See also: [Business Impact Analysis (BIA)](Business%20Impact%20Analysis%20(BIA).md), [A 8.2 Information Classification](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2%20Information%20classification.md#ISO%2027001%20A%208.2%20Information%20classification)
Prompt to Perplexity AI on 2025-06-10: `In the field of information security, we identify and implement risk mitigating measures to safeguard the confidentiality, integrity, and availability of information. To establish levels of confidentiality, we use the instrument of data classification to establish levels of availability we can use business impact analysis. What instruments do we have to classify the necessity of integrity of information`
Sources:
[dataguard](https://www.dataguard.com/blog/classifying-information/)
[CISecurity](https://www.cisecurity.org/-/media/project/cisecurity/cisecurity/data/media/files/uploads/2020/06/Information-Classification-Standard.docx)
[Dataguard](https://www.dataguard.com/blog/classifying-information/)
[CIO Platform Nederland](https://www.cio-platform.nl/l/en/library/download/urn:uuid:b095d62e-4915-4904-bec3-2d49ad94548f/2016+data+classification+guide+cio+platform+nederland+(eng).pdf?format=save_to_disk)
[isms online](https://www.isms.online/iso-27002/control-5-12-classification-of-information/)
To classify the necessity of integrity of information, organizations use instruments similar to those for confidentiality and availability, often integrated into data classification schemes based on the CIA triad (Confidentiality, Integrity, Availability). Specifically for integrity, classification levels typically reflect how critical it is that data remains accurate, consistent, and trustworthy throughout its lifecycle.
## Instruments to Classify Integrity Necessity
- **Integrity Classification Levels:** These define the impact of integrity loss on business processes and range from low to high, for example:
- *Unknown:* No extra integrity protection needed; breaches cause no consequential damage.
- *Low:* Some mistakes allowed; basic security required; breaches cause minor damage.
- *Middle:* Few mistakes allowed; integrity protection essential; breaches cause serious damage.
- *High:* No mistakes allowed; breaches cause very extensive damage [3](https://www.cio-platform.nl/l/en/library/download/urn:uuid:b095d62e-4915-4904-bec3-2d49ad94548f/2016+data+classification+guide+cio+platform+nederland+\(eng\).pdf?format=save_to_disk).
- **Data Classification Standards:** Many organizations use classification standards that assign integrity levels alongside confidentiality and availability, ensuring tailored protection measures based on the risk and impact of integrity breaches [2](https://www.cisecurity.org/-/media/project/cisecurity/cisecurity/data/media/files/uploads/2020/06/Information-Classification-Standard.docx) [3](https://www.cio-platform.nl/l/en/library/download/urn:uuid:b095d62e-4915-4904-bec3-2d49ad94548f/2016+data+classification+guide+cio+platform+nederland+\(eng\).pdf?format=save_to_disk) [4](https://www.isms.online/iso-27002/control-5-12-classification-of-information/).
- **Risk Assessment and Impact Analysis (BIA):** While BIA is often used for availability, it also helps assess the impact of integrity loss on business operations, reputation, and compliance, informing the classification and prioritization of integrity controls [6](https://www.neumetric.com/business-impact-analysis-incybersecurity/) [9](https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8286D.pdf).
- **CIA-Based Classification Frameworks:** Frameworks like ISO 27001 and organizational policies define criteria and controls for integrity classification, often involving senior management ownership, periodic review, and training to ensure appropriate handling based on integrity requirements [1](https://www.dataguard.com/blog/classifying-information/) [4](https://www.isms.online/iso-27002/control-5-12-classification-of-information/) [7](https://en.wikipedia.org/wiki/Information_security).
## Summary
To classify the necessity of integrity, organizations use structured classification schemes that rate the importance of data accuracy and trustworthiness, supported by risk assessments and business impact analyses. These classifications guide the implementation of controls such as checksums, digital signatures, auditing, and version control to maintain data integrity [3](https://www.cio-platform.nl/l/en/library/download/urn:uuid:b095d62e-4915-4904-bec3-2d49ad94548f/2016+data+classification+guide+cio+platform+nederland+\(eng\).pdf?format=save_to_disk) [10](https://blog.riskrecon.com/the-cia-triad-securing-digital-information-and-data) [11](https://www.techtarget.com/whatis/definition/Confidentiality-integrity-and-availability-CIA).

View file

@ -0,0 +1,9 @@
# Control ownership
See also [Risk ownership](../Risk%20ownership.md), [Asset ownership](Asset%20ownership.md)
Principe:
> Control ownership can best be assigned to the individual or team that has both the resources and the skills to effectively implement the control. (And does not have conflicting interests)
Indeling:
> Control ownership: maak een matrix met categorieën controls vs. teams/rollen in de organisatie.

View file

@ -0,0 +1,10 @@
# Data breach procedure
Previous work:
- Post mortem Ultimaker LinkedIn Learning incident
- Pixelpool Data breach procedure
- CISSP cursus
Relevant ISO 27001 clauses/controls:
- [ISO 27001 A 16.1 Management of information security incidents and improvements](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2016.1%20Management%20of%20information%20security%20incidents%20and%20improvements.md)

View file

@ -0,0 +1,64 @@
# Data Classification
**Definition:**
"A *data classification* identifies the value of the data to the organization. Classification labels, the method by which they are assigned, and the required protection associated with the different labels, are identified in a policy."
Source: [CISSP_OSG_Chapter_5](../../../Standards/CISSP/CISSP_OSG_Chapter_5.md#Defining%20data%20Classifications)
Classification criteria should be risk based, for instance on potential damage to the organization, the privacy of individuals, national security, economic interests, or other critical concerns.
## Examples from SANS forum
Source: https://sth-community.sans.org/t/y4yt81n
Retrieved: 2 september 2024
Public
Internal
Confidential
1. No risk - Open
2. Some risk - Internal
3. Significant risk - Confidential
4. Unrestricted
5. Restricted-External
6. Restricted-Internal
7. Confidential
- Public
- Internal
- Confidential
- Restricted
Restricted, Confidential, Internal Use, and Public
We have Confidential Information (CI) and Personal Information (PI). Both CI and PI are categorized as Red, Orange and Yellow for sensitivity (from most to least sensitive). Then there's Green Information, which is public.
| | |
|---|---|
|General Use|Emails and documents with this label are not sensitive and can be shared both internally and externally with no risk of harm and without restriction.|
|Confidential Internal Use Only|This label applies to sensitive information that should not leave the organization but is not as critical as those under the "Highly Confidential" classification. Use this for information that if disclosed outside, could still cause harm but is primarily intended for internal stakeholders.|
|Confidential Third Party Authorized|This label applies to sensitive information that can be shared with third parties who have been vetted and authorized under specific conditions. This might include business partners or vendors who need access to certain information to provide services or support.|
|Highly Confidential Internal Use Only|This label applies to the most sensitive information that if disclosed, could result in severe damage to the organization. Access should be limited to a very select group of internal stakeholders, and it should not be shared outside the organization.|
|Highly Confidential - Third Party Authorized|This label applies to extremely sensitive information that must sometimes be shared with third parties, under very strict controls and only when absolutely necessary. This could include sharing with legal counsel, auditors, or regulatory bodies who require access to fulfill their obligations to the organization.|
Just before I left the Bank of England, we rebuilt our classification scheme - [https://www.bankofengland.co.uk/-/media/boe/files/about/human-resources/iscs-external-guidance.pdf](https://www.bankofengland.co.uk/-/media/boe/files/about/human-resources/iscs-external-guidance.pdf) is the reference. We had used UNCLASSIFIED, BANK CONFIDENTIAL, SECRET and TOP SECRET previously, but moved to OFFICIAL-BLUE, OFFICIAL-GREEN, OFFICIAL-AMBER and OFFICIAL-RED for the non SECRET levels - we wanted labels that were not using simple language as we found that using words like confidential were difficult to track in DLP systems, causing far too many false positives.
One of the reasons for the move was that the UK government was looking to change their scheme to a traffic light system also, so we moved to where they were heading.
From a user perspective it is complex to figure out a classification. That's why some of our institutions reverse the process and start with the person and what they want to do.
Leiden University has a tool picker that is publicly available, to help employees and students pick the correct tool (and indirectly the level of security and privacy that that tool offers).
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)
See also:
[Datatags System](../../../Literature%20notes/Datatags%20System.md)
[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)
[Traffic Light Protocol (TLP)](../../../Literature%20notes/Traffic%20Light%20Protocol%20TLP.md)

View file

@ -0,0 +1,34 @@
ChatGPT prompt, requested 6 januari 2025:
`The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of documents in a childcare organization
In a childcare organization, the Traffic Light Protocol (TLP) can be used to manage and classify information based on its sensitivity and the appropriate sharing audience. Here's how the different TLP labels might be applied:
1. **TLP:RED**
- **Examples of Documents:**
- Child protection reports or sensitive incident reports involving specific children or staff that are under investigation.
- Confidential parental complaints or legal documents involving the welfare of specific children.
- Emergency response plans detailing actions for critical incidents affecting child safety.
- Personal records of children and staff, such as health information or background checks, requiring high confidentiality.
2. **TLP:AMBER**
- **Examples of Documents:**
- Internal assessments or evaluations regarding program effectiveness or staff performance that require restricted sharing.
- Reports on non-critical incidents involving children that need to be shared only with relevant staff and authorities.
- Draft policies or procedures under consideration that have not been finalized or publicly announced.
- Strategy documents for program development or expansions that are not for public release but may be shared with select partners or stakeholders.
3. **TLP:GREEN**
- **Examples of Documents:**
- Staff training manuals and educational resources intended for internal use but could be shared with partners for collaborative learning.
- Updates on non-sensitive program changes or organizational developments shared internally among staff.
- General guidance or informational documents that support day-to-day operations and could be made available to partnership organizations.
- Documents outlining health and safety protocols that are not proprietary and can facilitate broader industry best practices.
4. **TLP:CLEAR**
- **Examples of Documents:**
- Public newsletters and announcements about upcoming events or programs open to the community.
- Marketing materials, brochures, and digital content intended for parents and the general public.
- General policy documents and guidelines on topics such as enrolment, non-sensitive health practices, or general childcare tips.
- Information about community involvement activities or open days intended to engage and inform the public about the organization's work.
These examples illustrate how the TLP can be an effective tool in a childcare organization to manage information sharing, protecting sensitive data and ensuring that information is shared with the appropriate audience.

View file

@ -0,0 +1,34 @@
ChatGPT prompt, requested 6 januari 2025:
`The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of documents in a commercial services organization`
The Traffic Light Protocol (TLP) is a system for classifying sensitive information to facilitate information sharing. It consists of different color-coded labels, each indicating the level of sensitivity and the degree of sharing permitted. Here's how these might apply in a commercial services organization:
1. **TLP:RED**
- **Examples of Documents:**
- Internal reports on a severe data breach or security incident that is currently under investigation.
- Legal documents related to ongoing litigation or disputes.
- Executive communications containing strategic decisions that could significantly impact the company's operations or reputation if disclosed.
- Crisis management plans and tactics being deployed in real-time.
2. **TLP:AMBER**
- **Examples of Documents:**
- Internal audit findings and potential vulnerabilities that need to be addressed.
- Draft versions of sensitive projects or product developments not yet publicly announced.
- Employee performance reviews and confidential HR investigations.
- Negotiation strategies or contract terms involving significant vendors or partners.
3. **TLP:GREEN**
- **Examples of Documents:**
- Internal newsletters and policy updates meant for all employees but not for public or competitor knowledge.
- Market analysis reports or industry research intended to guide internal strategy but not yet published externally.
- Training materials and resources meant for internal skill-building and organizational development.
- Summary reports on non-critical projects or initiatives that may be shared with specific partners under NDA.
4. **TLP:CLEAR**
- **Examples of Documents:**
- Press releases and publicly available company announcements.
- Marketing materials and brochures intended for public distribution.
- White papers and research reports approved for public or client distribution.
- General information about company policies and procedures that are not sensitive or proprietary.
These examples serve to illustrate how TLP labeling can be employed within a commercial services organization to manage the dissemination of information effectively, depending on its sensitivity and intended audience.

View file

@ -0,0 +1,46 @@
ChatGPT prompt, requested 6 januari 2025:
`The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of information found in the information security function of the organization and its systems`
### The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of information found in the information security function of the organization and its systems
The Traffic Light Protocol (TLP) is a system designed to facilitate sharing sensitive information by specifying what can be shared and with whom. Here are typical examples of information under each TLP label within an organization's information security function:
1. **TLP:RED**
- **Example Information:** Detailed specifics on a newly discovered zero-day vulnerability affecting critical systems, incident investigation reports with sensitive details, personal data of incident responders or affected parties, or intelligence on imminent threats that could lead to significant harm.
- **Sharing Guidelines:** Intended for the named recipients only. Extreme caution is required due to the sensitive nature of the information. It should not be shared beyond the intended recipients without explicit permission.
2. **TLP:AMBER**
- **Example Information:** Incident detection techniques, indicators of compromise (IOCs) that might be used by threat actors, internal security processes or system configurations, and vulnerabilities that are being actively exploited but are not publicly known.
- **Sharing Guidelines:** Restricted to individuals or groups within the recipients organization who need to know in order to prevent or mitigate the impact of incidents.
3. **TLP:GREEN**
- **Example Information:** General threat intelligence reports, summaries of common attack vectors, security awareness materials, lessons learned from incidents (with sensitive details redacted), and industry best practices for various security processes.
- **Sharing Guidelines:** Information can be shared within the community or group but not publicly. It can be shared with peers and partner organizations within the same sector or community.
4. **TLP:CLEAR**
- **Example Information:** Publicly available security advisories, general security policies, declassified information about previous incidents, and announcements that have already been made public.
- **Sharing Guidelines:** Information can be freely shared with anyone, including the general public. Offers the least restriction and encourages wide dissemination.
Using TLP labels allows organizations to better control the dissemination of sensitive information, ensuring it reaches those who need it while preventing leakage to unintended parties.
### Answer the same question, but now focus on information that would facilitate gaining access to systems and information of the organization
When considering the potential for facilitating unauthorized access to an organization's systems and information, heres how different types of sensitive information might be categorized under each TLP label:
1. **TLP:RED**
- **Example Information:** Administrative credentials, passwords, or encryption keys for critical systems; architectural diagrams of the network including security solutions and defenses in place; detailed security vulnerability assessments and penetration testing results exposing critical vulnerabilities; and detailed incident reports that expose system weaknesses.
- **Sharing Guidelines:** This information is highly sensitive and should only be shared with specific, authorized individuals who require it for critical tasks. It must not be shared beyond these individuals without explicit permission due to the risk of compromise.
2. **TLP:AMBER**
- **Example Information:** Configuration details of critical security systems (e.g., firewalls, intrusion detection/prevention systems), lists of known vulnerabilities within less critical systems, scripts or tools used for internal security checks, and access controls or user privilege levels of staff within the organization.
- **Sharing Guidelines:** Information should only be shared with personnel or departments directly involved in securing or maintaining systems. It should not be distributed beyond these necessary recipients within the organization.
3. **TLP:GREEN**
- **Example Information:** General guidelines on password policies, which IT systems are in place along with their general functions but without exposing critical configurations, high-level security framework overviews, and anonymized metrics on system access attempts (e.g., frequency of login attempts).
- **Sharing Guidelines:** This information can be shared within the community or with partner organizations, enabling sharing of best practices or awareness of common challenges without exposing sensitive details that might facilitate system access.
4. **TLP:CLEAR**
- **Example Information:** Public security policies, non-sensitive security training materials aimed at general staff awareness, historical data on resolved security incidents without sensitive details, and general announcements regarding security posture improvements.
- **Sharing Guidelines:** Such information can be freely shared with the public, including stakeholders outside the organization, since it does not directly compromise the security of systems or facilitate unauthorized access.
By appropriately classifying information related to access facilitation, organizations can better protect their systems from unauthorized access while still disseminating necessary security information effectively.

View file

@ -0,0 +1,34 @@
ChatGPT prompt, requested 6 januari 2025:
`The FIRST TLP standard recognizes 4 labels, RED, AMBER, GREEN and CLEAR. For each label, give typical examples of the kinds of documents in a hospital
In a hospital setting, managing information sensitivity is crucial for maintaining patient confidentiality and operational integrity. Here's how the Traffic Light Protocol (TLP) might be applied:
1. **TLP:RED**
- **Examples of Documents:**
- Detailed patient medical records containing sensitive personal health information.
- Incident reports related to severe patient safety issues or medical errors under investigation.
- Legal documents concerning ongoing malpractice litigation or sensitive negotiations.
- Emergency response plans or security protocols related to current high-risk situations.
2. **TLP:AMBER**
- **Examples of Documents:**
- Internal audit reports assessing compliance with healthcare regulations like HIPAA.
- Strategic planning documents for upcoming service expansions or new medical programs.
- Internal memos detailing sensitive operational changes or staffing adjustments.
- Clinical trial results or research findings not yet published or publicly disclosed.
3. **TLP:GREEN**
- **Examples of Documents:**
- Internal newsletters updating staff on non-sensitive policy changes or hospital initiatives.
- Training manuals for medical and administrative staff intended for internal distribution.
- Non-confidential aggregate data reports used for internal performance tracking or quality improvement.
- Educational materials for staff that might also be available for partner healthcare organizations under certain conditions.
4. **TLP:CLEAR**
- **Examples of Documents:**
- Public health announcements or educational brochures available to patients and the public.
- Press releases about hospital achievements, new programs, or community events.
- General policy documents that are applicable and accessible to patients, such as visiting hours or parking information.
- Community engagement materials promoting health and wellness initiatives.
These examples illustrate how a hospital can employ the TLP labeling system to appropriately safeguard sensitive information while facilitating necessary information sharing within and outside the organization.

View file

@ -0,0 +1,9 @@
# Disaster Recovery Planning
See also:
- [a-5.30-ICT-readiness-for-business-continuity](../../Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md)
- [Business Continuity Planning (BCP)](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
- [SANS Incident Response step 5 Recovery](../../Standards/SANS/SANS%20Incident%20Response%20step%205%20Recovery.md)
- [Checklist for auditing Business Continuity and Disaster Recovery](../../Literature%20notes/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Business%20Continuity%20and%20Disaster%20Recovery.md)
- [CISSP_OSG_Chapter_18](../../Standards/CISSP/CISSP_OSG_Chapter_18.md)
- [Def_Sec_Handbook_Chapter_6](../../Literature%20notes/Def_Sec_Handbook_Chapter_6.md)

View file

@ -0,0 +1,38 @@
# Sources for the Context sessions
## PECB Lead Auditor Training
[PECB 27001 LA S05 E01a - Context of the organization](../../Standards/ISO27x/PECB-Lead-Auditor-Training/PECB%2027001%20LA%20S05%20E01a%20-%20Context%20of%20the%20organization.md)
## Sparks
[The ISMS in its context](The%20ISMS%20in%20its%20context.md)
[Context analysis](../../Literature%20notes/Context%20analysis.md)
## Mark I content
[ISO27DIY Video A.4 Context and Scope - Internal issues](../../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Video%20A.4%20Context%20and%20Scope%20-%20Internal%20issues.md)
[ISO27DIY Video A.2 Context and Scope - Stakeholders](../../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Video%20A.2%20Context%20and%20Scope%20-%20Stakeholders.md)
[ISO27DIY Video A.3 Context and Scope - Regulations and Contracts](../../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Video%20A.3%20Context%20and%20Scope%20-%20Regulations%20and%20Contracts.md)
## Standard
[ISO_27001_2022_4.1_MoC Understanding the organization and its context](../../Corpus/Standards/MoCs/ISO_27001_2022_4.1_MoC%20Understanding%20the%20organization%20and%20its%20context.md)
[ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties](../../Corpus/Standards/MoCs/ISO_27001_2022_4.2_MoC%20Understanding%20the%20needs%20and%20expectations%20of%20interested%20parties.md)
[ISO_27001_2022_4.3_MoC Determining the scope of the information security management system](../../Corpus/Standards/MoCs/ISO_27001_2022_4.3_MoC%20Determining%20the%20scope%20of%20the%20information%20security%20management%20system.md)
[ISO_27001_2022_4.4_MoC Information security management system](../../Corpus/Standards/MoCs/ISO_27001_2022_4.4_MoC%20Information%20security%20management%20system.md)
## From the 'canvas'
Besturingsmodel (4.1)
Functiehuis (4.1)
Organogram (4.1)
Bedrijfsprocessen (4.1)
SWOT (4.1)
- [SWOT Analyses template](../SWOT%20Analyses%20template.md)
DESTEP (4.2)
Stakeholder analyse (4.2)
Wet- en regelgeving (4.2, A5.31-A5.34)
## Further research
- [ ] Assets?
- [ ] Impactbepaling uit [Dataclassificatie Humankind](../../../Clients/Humankind/Dataclassificatie%20Humankind.md)