cleaning up Sparks
This commit is contained in:
parent
b8d1d4e02f
commit
704e6dd07f
162 changed files with 393 additions and 1041 deletions
|
|
@ -12,7 +12,7 @@ It is moderately suitable for distribution to them in a company setting.
|
|||
- [ISO 27001 A.14.2.1 Secure development policy](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A.14.2.1%20Secure%20development%20policy.md)
|
||||
|
||||
Related:
|
||||
- [DevSecOps and ISO 27k](../Sparks/DevSecOps%20and%20ISO%2027k.md)
|
||||
- [DevSecOps and ISO 27k](../Various/Business%20processes/DevSecOps%20and%20ISO%2027k.md)
|
||||
|
||||
# Achieving Application Security in Agile
|
||||
Weave security thinking into the Agile process. Adding it on later will be less secure, more costly and will probably achieve not enough attention because of release deadlines.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ A risk occurs when there's a chance of an asset being compromised, through the e
|
|||
|
||||
Adapted from source: [Vigilant Software](https://www.vigilantsoftware.co.uk/blog/risk-terminology-understanding-assets-threats-and-vulnerabilities), retrieved December 8, 2021.
|
||||
|
||||
[Assets](../Sparks/Assets.md)
|
||||
[About Assets](../Sparks/About%20Assets.md)
|
||||
[Vulnerability 1](../Sparks/Vulnerability%201.md)
|
||||
[Threat](Threat.md)
|
||||
[Risks](../Sparks/Risks.md)
|
||||
|
|
|
|||
|
|
@ -7,17 +7,17 @@ Producten:
|
|||
## Literatuur
|
||||
|
||||
- BCP.mindnode op iCloud > Best Practices
|
||||
- evt. [CIS Critical Security Controls](../Sparks/CIS%20Critical%20Security%20Controls.md) als raamwerk
|
||||
- evt. [CIS Controls](../Sparks/Information%20Security/CIS%20Controls.md) als raamwerk
|
||||
- ISO-22301-2019 'Business continuity management systems' en ISO-22313-2020 'Guidance on the use of ISO 22301'
|
||||
- [CISSP, Chapter 3](../Standards/CISSP/CISSP_OSG_Chapter_3.md)
|
||||
|
||||
|
||||
Bedrijfscontinuïteitsplanning is een continu proces, met als doel het implementeren en onderhouden van beleid, procedures en processen om de impact van verstoringen te beheersen. Met andere woorden: bedrijfscontinuïteitsplanning richt zich op de continuïteit van bedrijfsprocessen, zo nodig met andere middelen.
|
||||
|
||||
Belangrijke onderdelen van Bedrijfscontinuïteitsplanning zijn de Bedrijfsimpact Analyse ([BIA](../Sparks/Business%20Impact%20Analysis%20(BIA).md)) en het Herstelplan ('Disaster Recovery Plan' / [DRP](..//Disaster%20Recovery%20Planning.md)).
|
||||
Belangrijke onderdelen van Bedrijfscontinuïteitsplanning zijn de Bedrijfsimpact Analyse ([BIA](../Sparks/ISMS/Business%20Impact%20Analysis%20(BIA).md)) en het Herstelplan ('Disaster Recovery Plan' / [DRP](..//Disaster%20Recovery%20Planning.md)).
|
||||
De BIA richt zich op het identificeren van de impact van verstoringen op de bedrijfsprocessen, en het Herstelplan richt zich op het herstel van de normale bedrijfsprocessen na een verstoring en de eventuele inzet van alternatieve middelen of werkwijzen .
|
||||
|
||||
Zie ook: [Het belang van een Bedrijfscontinuïteitsplan](../Sparks/Belang%20van%20een%20BCP.md) / [The importance of having a business continuity plan](../Sparks/Importance%20of%20a%20BCP.md).
|
||||
Zie ook: [Het belang van een Bedrijfscontinuïteitsplan](../Sparks/ISMS/Belang%20van%20een%20BCP.md) / [The importance of having a business continuity plan](../Sparks/Importance%20of%20a%20BCP.md).
|
||||
|
||||
|
||||
## Aanpak
|
||||
|
|
@ -34,7 +34,7 @@ Het proces (Beleid) volgens welke dit hele plan tot stand komt en beoordeeld/her
|
|||
|
||||
## Analyse
|
||||
|
||||
Zie: [Business Impact Analysis (BIA)](../Sparks/Business%20Impact%20Analysis%20(BIA).md)
|
||||
Zie: [Business Impact Analysis (BIA)](../Sparks/ISMS/Business%20Impact%20Analysis%20(BIA).md)
|
||||
|
||||
Stappen:
|
||||
- Bepalen bedrijfskritische processen (prioriteiten bepalen) en informatie-assets
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Relevant ISO 27001 clauses/controls:
|
|||
|
||||
Related:
|
||||
- [Operational Technology](../../Sparks/Operational%20Technology.md)
|
||||
- [DevSecOps and ISO 27k](../../Sparks/DevSecOps%20and%20ISO%2027k.md)
|
||||
- [DevSecOps and ISO 27k](../../Various/Business%20processes/DevSecOps%20and%20ISO%2027k.md)
|
||||
|
||||
## DevOps IoT: Ask This;
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Relevant ISO 27001 clauses/controls:
|
|||
- [ISO 27001 A 18 Compliance](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md)
|
||||
|
||||
Related:
|
||||
- [Examples of vendor selection questionnaires](../../Sparks/Examples%20of%20vendor%20selection%20questionnaires.md)
|
||||
- [Examples of vendor selection questionnaires](../../Sparks/Information%20Security/Examples%20of%20vendor%20selection%20questionnaires.md)
|
||||
|
||||
# Assessing Security Product Vendors? Ask this:
|
||||
1. When a faulty product is to be returned, what processes does the vendor have in place to ensure that no customer data exists on disks or storage before it is sent to one of return centers?
|
||||
|
|
|
|||
|
|
@ -1,4 +1,6 @@
|
|||
[](Cyber%20Security%20Governance%20Principles.pdf) by the Australian Institute of Company Directors and the Cyber Security Cooperative Research Centre, november 2024
|
||||
# Cyber Security Governance Principles
|
||||
|
||||
by the Australian Institute of Company Directors and the Cyber Security Cooperative Research Centre, november 2024.
|
||||
|
||||
The document outlines five key principles for governing organizational cyber resilience:
|
||||
|
||||
|
|
@ -10,3 +12,4 @@ The document outlines five key principles for governing organizational cyber res
|
|||
|
||||
For each principle the document outlines key points and identifies 'red flags' that indicate low quality or non existent governance.
|
||||
|
||||
|
||||
|
|
@ -1,9 +1,9 @@
|
|||
# Examples of TLP document classification for different industries
|
||||
|
||||
- [for information security](../Sparks/FIRST%20TLP%20labeled%20document%20examples%20for%20information%20security.md)
|
||||
- [for a commercial services organization](../Sparks/FIRST%20TLP%20labeled%20document%20examples%20commercial.md)
|
||||
- [for a childcare organization](../Sparks/FIRST%20TLP%20labeled%20document%20examples%20childcare.md)
|
||||
- [for a hospital](../Sparks/FIRST%20TLP%20labeled%20document%20examples%20hospital.md)
|
||||
- [for information security](../Sparks/ISMS/Data%20classification/FIRST%20TLP%20labeled%20document%20examples%20for%20information%20security.md)
|
||||
- [for a commercial services organization](../Sparks/ISMS/Data%20classification/FIRST%20TLP%20labeled%20document%20examples%20commercial.md)
|
||||
- [for a childcare organization](../Sparks/ISMS/Data%20classification/FIRST%20TLP%20labeled%20document%20examples%20childcare.md)
|
||||
- [for a hospital](../Sparks/ISMS/Data%20classification/FIRST%20TLP%20labeled%20document%20examples%20hospital.md)
|
||||
- [for a national government organization](FIRST%20TLP%20labeled%20document%20examples%20national%20government.md)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
See also: [Access Control Models](../Sparks/Access%20Control%20Models.md)
|
||||
See also: [Access Control Models](../Sparks/ISMS/Access%20Control%20Models.md)
|
||||
|
||||
## Rollen in autorisatiebeheer
|
||||
|
||||
|
|
|
|||
|
|
@ -10,10 +10,10 @@ For examples of defined roles, see:
|
|||
|
||||
Related:
|
||||
- [Asset ownership](../Sparks/Asset%20ownership.md)
|
||||
- [Control ownership](../Sparks/Control%20ownership.md)
|
||||
- [Control ownership](../Sparks/ISMS/Control%20ownership.md)
|
||||
- [Risk ownership](../Sparks/Risk%20ownership.md)
|
||||
- [Segregation of Duties](Segregation%20of%20Duties.md)
|
||||
- [Access Control Models](../Sparks/Access%20Control%20Models.md)
|
||||
- [Access Control Models](../Sparks/ISMS/Access%20Control%20Models.md)
|
||||
|
||||
**Roles according to CISSP (p. 23 ev.):**
|
||||
* Senior Manager: decides on policies, ultimately responsible.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
https://insights.sei.cmu.edu/blog/threat-modeling-12-available-methods/
|
||||
|
||||
Related:
|
||||
- [Create a threat analysis chatbot](../Sparks/Create%20a%20threat%20analysis%20chatbot.md)
|
||||
- [Create a threat analysis chatbot](../Various/Create%20a%20threat%20analysis%20chatbot.md)
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,6 +1,4 @@
|
|||
https://research.knowbe4.com/security-culture-survey
|
||||
|
||||
## The Seven Dimensions of Security Culture
|
||||
# The Seven Dimensions of Security Culture
|
||||
|
||||
The Security Culture Survey measures the sentiments of your users towards security in your organization – the psychological and social aspects that drive social behavior. Specifically, the SCS measures seven dimensions of security culture which include:
|
||||
|
||||
|
|
@ -8,7 +6,8 @@ The Security Culture Survey measures the sentiments of your users towards securi
|
|||
- **BEHAVIOR -** The actions and activities of employees that have direct or indirect impact on the security of the organization.
|
||||
- **COGNITION -** The employees’ understanding, knowledge and awareness of security issues and activities.
|
||||
- **COMMUNICATION -** The quality of communication channels to discuss security-related events, promote a sense of belonging, and provide support for security issues and incident reporting.
|
||||
|
||||
- **COMPLIANCE -** The knowledge of written security policies and the extent that employees follow them.
|
||||
- **NORMS -** Unwritten expectations regarding appropriate behaviors pertaining to usage of information technology in organizational context, perception of what practices are normal and unproblematic.
|
||||
- **RESPONSIBILITY -** The employees’ perceived role as a critical factor in sustaining or endangering the security of the organization.
|
||||
- **RESPONSIBILITY -** The employees’ perceived role as a critical factor in sustaining or endangering the security of the organization.
|
||||
|
||||
https://research.knowbe4.com/security-culture-survey
|
||||
|
|
@ -24,5 +24,5 @@ LINDDUN GO
|
|||
|
||||
OWASP
|
||||
RISMAN
|
||||
Data Maturity Models, zie [Data maturity model NL overheid](../Sparks/Data%20maturity%20model%20NL%20overheid.md)
|
||||
Data Maturity Models, zie [Data maturity model NL overheid](../Sparks/Information%20Security/Data%20maturity%20model%20NL%20overheid.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -4,5 +4,5 @@
|
|||
[[ISO_27002_2022_5.29_PE Information security during disruption \|Plain English]]
|
||||
ISO 27002:2013: 17.1.1, 17.1.2, 17.1.3
|
||||
|
||||
[Business Impact Analysis (BIA)](../Sparks/Business%20Impact%20Analysis%20(BIA).md)
|
||||
[Business Impact Analysis (BIA)](../Sparks/ISMS/Business%20Impact%20Analysis%20(BIA).md)
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,6 @@ ISO 27002:2013: n/a
|
|||
|
||||
See also:
|
||||
- [BCP_Bedrijfscontinuïteitsplanning](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
|
||||
- [Business Impact Analysis (BIA)](../Sparks/Business%20Impact%20Analysis%20(BIA).md)
|
||||
- [Disaster Recovery Planning](../Sparks/Disaster%20Recovery%20Planning.md)
|
||||
- [Business Impact Analysis (BIA)](../Sparks/ISMS/Business%20Impact%20Analysis%20(BIA).md)
|
||||
- [Disaster Recovery Planning](../Sparks/ISMS/Disaster%20Recovery%20Planning.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -6,5 +6,5 @@ ISO 27002:2013: 08.1.1, 08.1.2
|
|||
|
||||
[Brontekst](../ISO-27002-OST/ISO27002-NL-2022/a-5.9-Inventarisatie-van-informatie-en-andere-gerelateerde-bedrijfsmiddelen.md)
|
||||
|
||||
The inventory serves as input for the [Business Impact Analysis (BIA)](../Sparks/Business%20Impact%20Analysis%20(BIA).md)
|
||||
The inventory serves as input for the [Business Impact Analysis (BIA)](../Sparks/ISMS/Business%20Impact%20Analysis%20(BIA).md)
|
||||
[ISO_27001_2022_00_MoC Index EXT](ISO_27001_2022_00_MoC%20Index%20EXT.md)
|
||||
|
|
|
|||
|
|
@ -33,10 +33,10 @@ tags:
|
|||
[UI ideas](AuditGlue/System%20alternative/iso27DIY%20UI%20ideas.md)
|
||||
|
||||
### Agents
|
||||
[Create a proactive conversational agent](../Sparks/Create%20a%20proactive%20conversational%20agent.md)
|
||||
[Create an interview agent](../Sparks/Create%20an%20interview%20agent.md)
|
||||
[Create a proactive conversational agent](../Various/Create%20a%20proactive%20conversational%20agent.md)
|
||||
[Create an interview agent](../Various/Create%20an%20interview%20agent.md)
|
||||
[Agent Design Intent Card](AuditGlue/System%20alternative/Agent%20Design%20Intent%20Card.md)
|
||||
[Create a threat analysis chatbot](../Sparks/Create%20a%20threat%20analysis%20chatbot.md)
|
||||
[Create a threat analysis chatbot](../Various/Create%20a%20threat%20analysis%20chatbot.md)
|
||||
[Instruct an LLM on available tools](../Sparks/Instruct%20an%20LLM%20on%20available%20tools.md)
|
||||
[LLM Prompt types](../Sparks/LLM%20Prompt%20types.md)
|
||||
|
||||
|
|
@ -44,14 +44,14 @@ tags:
|
|||
[ISO27DIY Videos list](../🧱%20Projects/iso27DIY%20mk%20I/ISO27DIY%20Videos%20list.md)
|
||||
|
||||
## Platform
|
||||
[Design Document for ISO 27001 Certification Support Online Service](../Sparks/Design%20Document%20for%20ISO%2027001%20Certification%20Support%20Online%20Service.md)
|
||||
[Design Document for ISO 27001 Certification Support Online Service](../Various/Design%20Document%20for%20ISO%2027001%20Certification%20Support%20Online%20Service.md)
|
||||
[Personae and Roles](../Sparks/Personae%20and%20Roles.md)
|
||||
[TypeDB structure for ISO27DIY](../Sparks/TypeDB%20structure%20for%20ISO27DIY.md)
|
||||
[Client segregation](../Sparks/Client%20segregation.md)
|
||||
[Building functionality in Supabase](../Sparks/Building%20functionality%20in%20Supabase.md)
|
||||
[Client segregation in SaaS](../Sparks/Information%20Security/Client%20segregation%20in%20SaaS.md)
|
||||
[Building functionality in Supabase](../Various/Building%20functionality%20in%20Supabase.md)
|
||||
[SupaBase edge functions portability](../Sparks/SupaBase%20edge%20functions%20portability.md)
|
||||
[Connect LLM to Supabase to create content](../Sparks/Connect%20LLM%20to%20Supabase%20to%20create%20content.md)
|
||||
[Deciding which functionality goes where](../Sparks/Deciding%20which%20functionality%20goes%20where.md)
|
||||
[Connect LLM to Supabase to create content](../Various/Connect%20LLM%20to%20Supabase%20to%20create%20content.md)
|
||||
[Application architecture](../Various/Application%20architecture.md)
|
||||
[iso27DYI architecture with LLM](AuditGlue/System%20alternative/iso27DYI%20architecture%20with%20LLM.md)
|
||||
[iso27DIY stack deployment](AuditGlue/System%20alternative/iso27DIY%20stack%20deployment.md)
|
||||
[SurveyJS](../Sparks/SurveyJS.md)
|
||||
|
|
|
|||
|
|
@ -16,7 +16,10 @@ Several notes also have zero frontmatter at all.
|
|||
|
||||
**Step 1: Triage first, don't reorganize yet**
|
||||
|
||||
Before moving anything, do a first pass and tag each note with a simple `status` value in the frontmatter. I'd suggest three values: `promote` (ready or near-ready to move into the Corpus), `develop` (has substance but needs work), and `archive` (not ISO content, or irrelevant). This can be done quickly because most notes make it obvious within 10 seconds which bucket they're in.
|
||||
Before moving anything, do a first pass and tag each note with a simple `status` value in the frontmatter. This can be done quickly because most notes make it obvious within 10 seconds which bucket they're in.I'd suggest three values:
|
||||
- `promote` (ready or near-ready to move into the Corpus),
|
||||
- `develop` (has substance but needs work),
|
||||
- `archive` (not ISO content, or irrelevant).
|
||||
|
||||
**Step 2: Separate non-ISO content**
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +0,0 @@
|
|||
This next part is about the iso 27001 industry and its actors. Correct the following text so that the proper terms are used. Expand with other actors and their roles if necessary. This is the text:
|
||||
|
||||
- the standards organization develops the standard for a certain domain
|
||||
- the certification bureau checks if the standard is properly implemented within the organization and issues a certificate
|
||||
- Clients, regulatory bodies and other stakeholders of the organization demand the organization to be certified to proof adequate risk control within the domain
|
||||
- the organization implements the standard to get certified
|
||||
- the implementation consultant helps the organization to implement the standard
|
||||
- the internal auditor checks if the standard is properly implemented within the organization
|
||||
- The external auditor works for the certification bureau
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY/journey
|
||||
- type/explainer
|
||||
---
|
||||
|
||||
## Journey
|
||||
|
||||
We’ll start with analyzing the context of where the ISMS will operate. We’ll look at your organization, it’s structure and processes, important stakeholders and internal and external developments.
|
||||
|
||||
From that we’ll help you identify risks and opportunities, and define risk mitigating measures.
|
||||
|
||||
Together we will create policies, procedures and guidelines, and control implementation plans.
|
||||
|
||||
Gradually, we’ll work towards your first internal audit.
|
||||
|
||||
|
||||
++ increased understanding
|
||||
++ actually improving your security posture
|
||||
We know that we need to get your organization along, so we’ll start with risks and opportunities that matter to your stakeholders.
|
||||
|
||||
## Timeline
|
||||
we will adapt to your pace, but we will actively coach you, like your sports watch would.
|
||||
|
||||
## Interaction model
|
||||
|
||||
|
||||
Work iteratively, you can always come back later
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
# Interactie met de gebruiker
|
||||
|
||||
1. Gebruiker kiest een Lesmodule uit menu
|
||||
2. Content wordt getoond. Filmpje, tekst, afbeelding.
|
||||
3. De gebruiker krijgt een ‘taak’. Hij/zij heeft de keuze die nu uit te voeren, of te parkeren in de persoonlijke Takenlijst[^1] (onderdeel van GRC). De taak bevat een verwijzing naar de content, zodat die later weer opgepakt kan worden.
|
||||
4. De taak kan bestaan uit bijv:
|
||||
5. het uploaden van een document
|
||||
6. het invullen van een vragenlijst
|
||||
7. het vullen van een tabel (simpele spreadsheet met rij/kolom totalen bijv)
|
||||
8. Wat de gebruiker toevoegt wordt opgeslagen in de GRC-module
|
||||
9. De input van de gebruiker wordt gebruikt om nieuwe content te genereren, bijv. een beleidsdocument. Dit kan gebeuren met templates, logische regels, of LLM.
|
||||
10. Gegenereerde content wordt ter controle aangeboden aan de gebruiker. Die moet daar wijzigingen in aan kunnen brengen en uiteindelijk de productie akkoord verklaren.
|
||||
11. Na akkoord is er een wijziging in het ‘volwassenheidsniveau’ van het ISMS. Deze komt tot uitdrukking in het ‘Implementatie Dashboard’ (onderdeel van GRC). – kan dynamisch gegenereerd worden
|
||||
|
||||
- [ ] Uitwerken: Er zit onderlinge afhankelijkheid in: soms kun je stap 3 pas nemen als je stap 1 gedaan.
|
||||
- [ ] Volwassenheidsniveaus benoemen.
|
||||
|
||||
|
||||
[^1]: in een latere versie kunnen taken toegewezen worden aan een andere gebruiker.
|
||||
|
||||
|
||||
|
|
@ -1,417 +0,0 @@
|
|||
# The Merchant Vessel's Voyage: An ISMS Implementation Story
|
||||
|
||||
## **The Premise**
|
||||
|
||||
You're the captain of a merchant trading vessel, transporting valuable cargo across established trade routes. Your mission: deliver precious goods safely to distant ports while building a reputation for reliability and security that will sustain your trading company for years to come.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 1: Charting the Destination** (Setting the Goals)
|
||||
|
||||
Before leaving port, you gather your officers and backers around the navigation table. What defines success for this voyage?
|
||||
|
||||
- **The cargo's safe arrival**: Your hold contains valuable spices, silk, medical herbs, fine instruments - goods that merchants await
|
||||
- **The crew's safe return**: A ship without seasoned sailors is just expensive timber
|
||||
- **Maintaining your reputation**: In the trading world, trust is currency
|
||||
- **Regulatory compliance**: You must satisfy the Harbor Master's requirements and international maritime codes to operate legally
|
||||
- **Sustainable operations**: This isn't a single voyage - you're building a trading enterprise
|
||||
|
||||
You define your **scope**: Which routes will you sail? Which ports are included? What cargo types will you carry?
|
||||
|
||||
Your **security objectives** become clear: confidentiality (cargo manifests and trade secrets), integrity (goods arrive uncontaminated and authentic), availability (reliable delivery schedules).
|
||||
|
||||
You announce these goals to all stakeholders - the ship's owners, the crew, the merchants whose goods you carry.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 2: Reading the Waters** (External Issues)
|
||||
|
||||
Before you can plan your route, you must understand the world through which you'll sail:
|
||||
|
||||
- **Pirate activity**: Which waters are most dangerous? What are their tactics? Are they after cargo, ransom, or the ship itself?
|
||||
- **Weather patterns**: Monsoon seasons, hurricane zones, fog-prone straits
|
||||
- **Geopolitical tensions**: Which nations are at war? Where are trade embargoes? Which flags grant safe passage where?
|
||||
- **Port regulations**: Different harbors have different requirements - quarantine rules, inspection protocols, docking fees
|
||||
- **Competition**: Other trading companies, their routes, their security measures
|
||||
- **Technology changes**: New navigation instruments, faster ships, encrypted communication methods between trading houses
|
||||
- **Economic conditions**: Which goods are in demand? Where are prices best?
|
||||
|
||||
You gather intelligence from:
|
||||
|
||||
- Harbor masters' reports
|
||||
- Returning captains' debriefings
|
||||
- Maritime insurance underwriters
|
||||
- Coastal watchtowers' signals
|
||||
- Trading guild bulletins
|
||||
|
||||
This **external context** shapes every decision you'll make.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 3: Knowing Your Vessel** (Internal Issues, Assets, Strengths & Weaknesses)
|
||||
|
||||
Now you turn your attention inward. What are you working with?
|
||||
|
||||
### **Your Assets to Protect:**
|
||||
|
||||
- **The cargo** (your primary information assets): Spices in the forward hold, medicinal herbs requiring cool storage, sealed letters of credit, navigation charts showing profitable routes
|
||||
- **The ship itself**: Hull integrity, sail condition, water-tightness of hatches
|
||||
- **Your crew**: The navigator's expertise, the surgeon's knowledge, the carpenter's skills
|
||||
- **Your reputation and relationships**: Trust with merchants, favorable insurance rates, preferential port access
|
||||
- **Supporting systems**: The ship's boat (your backup), fresh water supplies, repair materials
|
||||
|
||||
### **Strengths:**
|
||||
|
||||
- Experienced first mate who's sailed these waters for 20 years
|
||||
- Recently reinforced hull
|
||||
- Disciplined crew with low turnover
|
||||
- Strong relationships with key ports
|
||||
|
||||
### **Weaknesses:**
|
||||
|
||||
- The navigator is brilliant but aging, with no clear successor trained
|
||||
- Your encryption methods for sensitive documents are known by former crew who now sail for competitors
|
||||
- The starboard cargo hold has a persistent leak
|
||||
- Only two crew members can operate the new navigational instruments
|
||||
- Your emergency procedures exist mostly in the captain's head
|
||||
|
||||
You conduct a thorough **inventory and assessment**: Who has access to what? Where are critical vulnerabilities? What depends on single points of failure?
|
||||
|
||||
---
|
||||
|
||||
## **Episode 4: Mapping the Dangers** (Risk Assessment)
|
||||
|
||||
With your destination set, external conditions understood, and internal capabilities assessed, you now systematically identify what could go wrong:
|
||||
|
||||
### **Risk Identification:**
|
||||
|
||||
- **Pirates in the Straits of Malacca**: High likelihood, severe impact (loss of cargo and possible crew)
|
||||
- **Storm season in the South China Sea**: Medium likelihood, catastrophic impact
|
||||
- **Crew illness/scurvy**: Medium likelihood, major impact on operations
|
||||
- **Cargo contamination from hold leak**: High likelihood, moderate impact
|
||||
- **Navigator incapacitation**: Low likelihood, severe impact
|
||||
- **Insider threat** (disgruntled crew revealing routes to competitors): Low likelihood, moderate impact
|
||||
- **Port authority seizure** due to paperwork errors: Medium likelihood, major impact
|
||||
- **Fire in the cargo hold**: Low likelihood, catastrophic impact
|
||||
|
||||
### **Risk Analysis:**
|
||||
|
||||
For each risk, you assess:
|
||||
|
||||
- **Likelihood**: Based on historical data (ships lost in these waters), current intelligence (pirate activity reports), ship conditions (that leaky hold)
|
||||
- **Impact**: What happens if this occurs? Loss of cargo value? Crew lives? Ship itself? Reputation damage?
|
||||
- **Existing controls**: What are you already doing? You have fire buckets, a daily inspection routine, experienced crew
|
||||
|
||||
### **Risk Evaluation:**
|
||||
|
||||
You plot these on a risk matrix with your officers. Which risks are acceptable for a merchant vessel? Your risk appetite is moderate - you're not running military secrets that require extreme measures, but you can't afford frequent losses either.
|
||||
|
||||
You prioritize: High likelihood + high impact risks must be addressed immediately. Low likelihood + low impact risks you'll accept.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 5: Plotting the Course** (Risk Treatment - Identifying Measures)
|
||||
|
||||
For each significant risk, you now decide your strategy:
|
||||
|
||||
### **Avoid:**
|
||||
|
||||
- **Don't sail during peak storm season**: Delay departure by three weeks
|
||||
- **Avoid notorious pirate waters entirely**: Take the longer, safer route
|
||||
|
||||
### **Reduce:**
|
||||
|
||||
- **Pirate encounters**: Sail in convoy with other merchants, hire additional armed crew, reinforce the captain's cabin (where valuables are stored), establish communication signals between convoy ships
|
||||
- **Cargo contamination**: Repair the hold leak, use sealed containers, implement daily inspection rounds
|
||||
- **Navigation failure**: Train two junior officers in advanced navigation, maintain duplicate charts stored separately, establish position verification protocols
|
||||
- **Fire**: Implement strict rules about open flames, station fire watch, conduct monthly fire drills, store water barrels strategically
|
||||
|
||||
### **Transfer:**
|
||||
|
||||
- **Cargo loss**: Purchase maritime insurance (though it's expensive and has limitations)
|
||||
- **Crew injury**: Contract with a maritime medical service in major ports
|
||||
|
||||
### **Accept:**
|
||||
|
||||
- **Minor cargo spoilage**: Some loss of spice potency is inevitable over long voyages; build this into pricing
|
||||
- **Wear on sails and rigging**: Routine deterioration; maintain replacement supplies
|
||||
|
||||
You create a **Statement of Applicability** - essentially a ship's security manifest that lists all maritime security controls, which ones you're implementing, which you're not, and why.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 6: The Ship's Standing Orders** (Policies and Procedures)
|
||||
|
||||
Now you formalize how your ship will operate. These aren't just the captain's whims - they're documented protocols that ensure consistency even when you're sleeping:
|
||||
|
||||
### **Access Control Policy** ("Who Goes Where"):
|
||||
|
||||
- **Cargo holds**: Only the quartermaster and captain have keys; entry logged in the ship's book
|
||||
- **Captain's cabin** (sensitive documents): Captain only; first mate has sealed emergency key
|
||||
- **Navigation room**: Navigator and trained officers only
|
||||
- **Critical supplies** (medical stores, emergency rations): Surgeon and quartermaster access; usage logged
|
||||
|
||||
### **Watch Standing Procedures** (Continuous Monitoring):
|
||||
|
||||
- Four-hour watches with clear handoff protocols
|
||||
- What to look for: other ships, weather changes, coastal landmarks
|
||||
- How to sound alarms for different threats
|
||||
- Night signal procedures
|
||||
|
||||
### **Cargo Handling Protocols**:
|
||||
|
||||
- Inspection upon loading (verify against manifest)
|
||||
- Daily hold inspections (check for water, pests, shifting)
|
||||
- Verification before unloading (ensure seals intact)
|
||||
- Chain of custody documentation
|
||||
|
||||
### **Emergency Response Procedures**:
|
||||
|
||||
- **Fire**: Specific roles assigned, equipment locations, communication signals
|
||||
- **Pirate attack**: Battle stations, valuable cargo disposal procedures (if necessary), surrender signals (if absolutely necessary)
|
||||
- **Man overboard**: Stop signals, rescue boat launch, recovery procedures
|
||||
- **Taking on water**: Damage assessment, pumping priorities, emergency port protocols
|
||||
|
||||
### **Navigation Protocols**:
|
||||
|
||||
- Position verification twice daily
|
||||
- Cross-checking between celestial navigation and known landmarks
|
||||
- Backup navigation methods
|
||||
- How to handle disagreement between navigator and captain
|
||||
|
||||
### **Communication Security**:
|
||||
|
||||
- How to encode sensitive messages
|
||||
- Which information can be shared in port
|
||||
- Procedures when crew members depart
|
||||
- How to verify identity of ships claiming to be friendly
|
||||
|
||||
### **Maintenance Standards**:
|
||||
|
||||
- Daily inspections (rigging, hull, pumps)
|
||||
- Weekly maintenance (sail repairs, deck treatment)
|
||||
- Monthly drills (fire, abandon ship, battle)
|
||||
- Equipment testing schedules
|
||||
|
||||
### **Crew Management**:
|
||||
|
||||
- Hiring procedures (background checks with previous captains)
|
||||
- Security training for new crew
|
||||
- Disciplinary procedures
|
||||
- Departure protocols (what they can take, what they must return)
|
||||
|
||||
Each policy answers: **What** must be done, **Why** it matters, **Who** is responsible, **When** and **How** it's done, and **What to do if** something goes wrong.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 7: Casting Off** (Implementation)
|
||||
|
||||
The planning is complete. Now comes the actual voyage - putting your measures into action:
|
||||
|
||||
### **Pre-Departure:**
|
||||
|
||||
- Reinforce the cargo hold (that leak must be fixed)
|
||||
- Install the new secure storage in the captain's cabin
|
||||
- Conduct security training for the crew on the new protocols
|
||||
- Brief all hands on the voyage plan and their roles
|
||||
- Load cargo with new inspection procedures
|
||||
- Verify all equipment is aboard and functional
|
||||
|
||||
### **Underway:**
|
||||
|
||||
- The watch rotation begins according to standing orders
|
||||
- Daily hold inspections reveal the repairs are holding
|
||||
- You drill the crew on emergency procedures weekly
|
||||
- Navigation protocols are followed - the junior officers are learning
|
||||
- Access logs are maintained for all sensitive areas
|
||||
- Incident reports are filed when protocols aren't followed (the cook accessed medical supplies without the surgeon present - why? turns out for a legitimate minor burn, but the procedure needs clarification)
|
||||
|
||||
### **Continuous Adjustment:**
|
||||
|
||||
- Three days out, you receive signals that pirates have been sighted ahead; you adjust course and increase watches
|
||||
- A storm forces you to secure cargo differently than planned - you document the new method
|
||||
- One crew member proves unreliable at watch; they're reassigned and additional training provided to their replacement
|
||||
|
||||
Implementation means **living** the procedures daily, not just having them written down.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 8: Keeping the Ship Supplied** (Resources and Competence)
|
||||
|
||||
A ship doesn't sail on good intentions. Throughout the voyage, you must ensure:
|
||||
|
||||
### **Financial Resources:**
|
||||
|
||||
- Budget for unexpected port fees
|
||||
- Reserve funds for emergency repairs
|
||||
- Insurance premiums
|
||||
- Crew wages (security depends on crew loyalty)
|
||||
|
||||
### **Human Resources:**
|
||||
|
||||
- Adequate crew size for watch rotations
|
||||
- Specialized skills: navigator, surgeon, carpenter, sailmaker
|
||||
- Training time - you can't expect new crew to know complex procedures instantly
|
||||
- Succession planning - you're actively training that junior navigator
|
||||
|
||||
### **Physical Resources:**
|
||||
|
||||
- Spare rigging and sails
|
||||
- Repair materials (timber, pitch, nails)
|
||||
- Security equipment (weapons, locks, sealing wax)
|
||||
- Safety equipment (fire buckets, rescue lines, ship's boat)
|
||||
- Extra supplies beyond minimum (because delays happen)
|
||||
|
||||
### **Knowledge Resources:**
|
||||
|
||||
- Navigation charts (and backups)
|
||||
- Ship's library of maritime procedures
|
||||
- Current intelligence from ports
|
||||
- Documentation of your own procedures and lessons learned
|
||||
|
||||
### **Time:**
|
||||
|
||||
- Adequate voyage timeline (rushing leads to cutting security corners)
|
||||
- Maintenance windows (you must occasionally heave-to for repairs)
|
||||
- Training time during long passages
|
||||
- Rest for crew (exhausted sailors make mistakes)
|
||||
|
||||
You establish **competence requirements**: What must each role know? The first mate must be able to take command. The quartermaster must know cargo handling. All crew must know basic emergency procedures.
|
||||
|
||||
You track **awareness**: Does everyone understand why these security measures matter? They'll follow procedures better if they understand they're protecting their own interests (cargo arrives = they get paid; ship is safe = they live).
|
||||
|
||||
---
|
||||
|
||||
## **Episode 9: The Ship's Log** (Documentation)
|
||||
|
||||
From the moment you leave port, you maintain meticulous records. In the maritime world, if it's not in the log, it didn't happen:
|
||||
|
||||
### **The Master Log:**
|
||||
|
||||
- Daily entries: position, weather, course, significant events
|
||||
- All decisions and why they were made
|
||||
- All incidents and how they were handled
|
||||
- Changes to procedures
|
||||
|
||||
### **Specialized Logs:**
|
||||
|
||||
- **Cargo manifest**: What's aboard, where it's stored, condition checks
|
||||
- **Watch log**: Who was on duty when, what they observed
|
||||
- **Maintenance log**: Repairs, inspections, equipment status
|
||||
- **Incident reports**: Anything unusual, even if minor
|
||||
- **Training records**: Who's been trained on what procedures
|
||||
- **Access logs**: Who entered sensitive areas when
|
||||
|
||||
### **Charts and Plans:**
|
||||
|
||||
- Navigation charts with your actual route (vs. planned)
|
||||
- Cargo stowage plans
|
||||
- Emergency evacuation plans
|
||||
- Crew roster with roles and competencies
|
||||
|
||||
### **Why This Matters:**
|
||||
|
||||
- **Learning**: What worked? What didn't? Your next voyage will be safer
|
||||
- **Accountability**: If something goes wrong, you can trace what happened
|
||||
- **Compliance**: Port authorities and insurers require documentation
|
||||
- **Continuity**: If you're incapacitated, your first mate needs to know everything
|
||||
- **Evidence**: If crew or cargo disputes arise, you have records
|
||||
- **Improvement**: You can't improve what you don't measure
|
||||
|
||||
The ship's log is your organizational memory - it outlasts any single voyage.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 10: Harbor Master's Inspection** (Audit and Review)
|
||||
|
||||
### **Internal Reviews (Ongoing):**
|
||||
|
||||
Throughout the voyage, you conduct regular self-assessments:
|
||||
|
||||
- **Daily bridge briefings**: What happened in the last 24 hours? What's ahead? Are procedures being followed?
|
||||
- **Weekly officer meetings**: Deeper review of security effectiveness, crew morale, equipment status
|
||||
- **Incident reviews**: Whenever something goes wrong (or almost goes wrong), you gather the relevant crew and analyze: What happened? Why? What will we do differently?
|
||||
- **Monthly drills**: Testing emergency procedures and evaluating performance
|
||||
|
||||
### **Port Audits (External):**
|
||||
|
||||
When you reach port, several inspections occur:
|
||||
|
||||
**Harbor Master's Security Inspection:**
|
||||
|
||||
- Are your cargo manifests accurate?
|
||||
- Are dangerous goods properly stored and documented?
|
||||
- Does your crew have proper credentials?
|
||||
- Are your safety and security measures adequate?
|
||||
- Do you meet international maritime security codes?
|
||||
|
||||
The Harbor Master is like your ISO 27001 auditor - they verify you're following established maritime security standards.
|
||||
|
||||
**Cargo Survey:**
|
||||
|
||||
- Merchants' representatives inspect their goods
|
||||
- Verifying seals are intact
|
||||
- Checking condition matches manifest
|
||||
- This proves your controls worked (or reveals where they didn't)
|
||||
|
||||
**Insurance Assessment:**
|
||||
|
||||
- Your insurer may inspect to verify you followed security protocols
|
||||
- This affects future premiums and coverage
|
||||
|
||||
### **Post-Voyage Review (Management Review):**
|
||||
|
||||
After reaching your destination, you conduct a comprehensive review with your officers and the ship's owners:
|
||||
|
||||
**What Worked:**
|
||||
|
||||
- The convoy strategy - no pirate encounters despite sailing through risky waters
|
||||
- Junior navigator training - you now have backup capability
|
||||
- Daily hold inspections caught problems early
|
||||
|
||||
**What Didn't:**
|
||||
|
||||
- The new watch rotation led to gaps in dawn coverage twice
|
||||
- Access logging was inconsistently followed (people got busy)
|
||||
- Fire drill times were too slow - crew needs more practice
|
||||
|
||||
**Metrics Analysis:**
|
||||
|
||||
- Incidents logged: 12 (down from 18 last voyage)
|
||||
- Security procedure compliance: 94% (target was 95%)
|
||||
- Cargo loss: 0.5% (within acceptable range)
|
||||
- On-time arrival: 2 days early (good)
|
||||
- Crew injuries: 1 minor (excellent)
|
||||
|
||||
**Risk Reassessment:**
|
||||
|
||||
- Are the risks you identified still accurate?
|
||||
- Did new risks emerge? (You encountered fog banks that weren't in your initial assessment)
|
||||
- Have external conditions changed? (Political tensions have eased in certain waters)
|
||||
- Are your controls still appropriate?
|
||||
|
||||
**Decisions for Next Voyage:**
|
||||
|
||||
- Adjust watch rotation based on lessons learned
|
||||
- Implement new access control procedure to improve compliance
|
||||
- Conduct more frequent fire drills
|
||||
- Update risk assessment to include fog navigation
|
||||
- Invest in better equipment for certain controls
|
||||
|
||||
### **Continuous Improvement:**
|
||||
|
||||
The voyage doesn't truly end when you reach port. You've learned from this journey, updated your procedures, and you're already preparing for the next departure. The ship's standing orders are now revised - Version 2.0 - incorporating everything you've learned.
|
||||
|
||||
You share lessons with other captains in your trading company. Best practices spread through the fleet.
|
||||
|
||||
**ISO Certification Parallel:** This comprehensive review - with documented evidence from your logs, demonstrated effectiveness of controls, and commitment to continuous improvement - is what convinces the Harbor Master (auditor) to certify your ship as meeting international security standards. The certificate isn't the end goal; it's recognition that you operate a secure, reliable, continuously improving operation.
|
||||
|
||||
---
|
||||
|
||||
## **The Journey Continues**
|
||||
|
||||
Unlike a fortress that, once built, stands static, your merchant vessel is always in motion. The sea changes. Threats evolve. Crews turn over. New ports open. Technology advances.
|
||||
|
||||
Your ISMS is the same - not a project with an end, but an operational discipline. The standing orders (policies) guide daily operations. The log (documentation) captures your organizational memory. The crew (your people) execute with competence and awareness. The inspections (audits) verify effectiveness. And the voyage (your business) continues, safer and more resilient because of the system you've built.
|
||||
|
||||
**The ISO 27001 certificate is your Letter of Marque** - official recognition that your vessel meets the standards required to trade safely in international waters, protecting the valuable cargo (information) entrusted to your care.
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
# iso27DYI: How this works
|
||||
|
||||
|
||||
## Structure
|
||||
|
||||
We've divided the ISMS implementation into a number of Episodes.
|
||||
|
||||
|
||||
- setting the goals
|
||||
- what's the lay of the land (relevant external issues)
|
||||
- how's our equipe, our assets that need to be protected (internal issues, strengths and weaknesses)
|
||||
- knowing the risks
|
||||
- identifying measures to mitigate the risks
|
||||
- creating the recipes (policies) for resilience in different areas / domains
|
||||
- implementing the risk mitigating measures
|
||||
- ensuring resources to implement and maintain everything
|
||||
- all the while documenting stuff as we go allong
|
||||
- audit and review how we're doing.
|
||||
|
||||
For every element of the ISO 27001 you need to be able to tell the auditor:
|
||||
|
||||
- what your method is for implementing the requirement
|
||||
- how and when you monitor the results of your implementation
|
||||
- how and when you evaluate the results and identify possible improvements
|
||||
- when you are planning to implement these improvements
|
||||
- who's involved and who's responsible for each of these steps.
|
||||
|
||||
In ISO27DIY we deal with this by providing Policy Cards for every Clause and Control of the ISO 27001.
|
||||
|
||||
There's always our Controls Library with everything in Plain English, support by our consultants. When the time is ready, you can plan a preliminiary audit.
|
||||
|
||||
## Principles
|
||||
- work with what you got - keep doing what you do but make it 'compliant'
|
||||
- work iteratively - you can always come back later
|
||||
|
||||
# Metadata
|
||||
- which 'slots' this scene fills
|
||||
|
|
@ -1,13 +0,0 @@
|
|||
# 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](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)
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
Zie ook: [DPOaaS offer Glownexus](../Literature%20notes/DPOaaS%20offer%20Glownexus.md)
|
||||
|
||||
|
|
@ -1 +0,0 @@
|
|||
... for the implementation.
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
Bron: mail Remco Landegge, Security Expert Radboud UMC, 2 december 2024
|
||||
|
||||
*Zie ook: [Risk ownership](Risk%20ownership.md)*
|
||||
|
||||
Team Architectuur, Security, Compliance and Informatie analyse
|
||||
Stafdienst Informatie Management
|
||||
|
||||
Elke [vrijdag](canary:event?ts=755175605.00) in de even weken roostervrij.
|
||||
Dit is het model wat wij gebruiken voor eigenaarschap binnen onze organisatie. Als je er iets van gebruikt dan alle verwijzingen naar Radboudumc verwijderen a.u.b.
|
||||
|
||||
Heb ook nog even naar jouw canvas aanpak gekeken, dit is grotendeels hetzelfde als wij nu hanteren binnen onze eigen risico methodiek (die ook al bekend is op de afdelingen). Het denken in risico’s is voor ziekenhuizen geen onbekend terrein 😉
|
||||
|
||||
**4.2 Wie is de eigenaar van een bedrijfsmiddel/bedrijfsproces?**
|
||||
|
||||
Het komt voor dat eigenaarschap van een bedrijfsmiddel en/of een bedrijfsproces onduidelijk is. In die gevallen kan het eigenaarschap van een bedrijfsproces/bedrijfsmiddel via het onderstaande schema worden bepaald.
|
||||
|
||||
|
||||
|
||||
Bovenstaande figuur beschrijft vier situaties:
|
||||
|
||||
**_Situatie 1: Bedrijfsmiddel/bedrijfsproces_** **_binnen één organisatieonderdeel. (B1)_**
|
||||
|
||||
Wanneer een bedrijfsmiddel/bedrijfsproces binnen slechts één organisatieonderdeel (centrum, afdeling, ondersteunende dienst, instituut) wordt gebruikt, dan is het hoofd/directie van het organisatieonderdeel de eigenaar **(E1)**. In deze situatie gaat het voor de instituten alleen over de bedrijfsmiddelen en bedrijfsprocessen die zij binnen hun eigen organisatieonderdeel nodig hebben, het gaat [hier](canary:event?ts=754743605.00) niet om de bedrijfsmiddelen/bedrijfsprocessen die nodig zijn binnen de complete kerntaak.
|
||||
|
||||
|
||||
**_Situatie 2: Bedrijfsmiddel/bedrijfsproces_** **_binnen meerdere afdelingen of een afdeling en een centrum. (B2)_**
|
||||
|
||||
Wanneer een bedrijfsmiddel of bedrijfsproces door verschillende afdelingen of een afdeling en een centrum wordt gebruikt, dan is de directie van de kerntaak waarin het bedrijfsmiddel/bedrijfsproces wordt gebruikt de eigenaar **(E2)**. Om te borgen dat alle belanghebbenden binnen de afdeling en/of centrum zijn betrokken bij het nemen van besluiten over functionaliteiten, beveiliging en service niveaus stelt de eigenaar zich onafhankelijk en facilitair op.
|
||||
|
||||
**_Situatie 3: Bedrijfsmiddel/bedrijfsproces_** **_binnen meerdere instituten. (B3)_**
|
||||
|
||||
Wanneer een bedrijfsmiddel of bedrijfsproces binnen de verschillende kerntaken wordt gebruikt, bepalen de directies van de betrokken instituten wie de eigenaar is **(E3)**. Om te borgen dat alle belanghebbenden binnen de instituten zijn betrokken bij het nemen van besluiten over functionaliteiten, beveiliging en service niveaus stelt de eigenaar zich onafhankelijk en facilitair op.
|
||||
|
||||
**_Situatie 4: Bedrijfsmiddel/bedrijfsproces_** **_beslaan (zo goed als) alle Radboudumc onderdelen. (B4)_**
|
||||
|
||||
Wanneer een bedrijfsmiddel of bedrijfsproces binnen het gehele Radboudumc bestaat zonder dat eigenaarschap genomen wordt, dient primair bepaald te worden of het bedrijfsproces of bedrijfsmiddel wel nodig is. De drie instituutsdirecties en de directeuren van de ondersteunende diensten bepalen gezamenlijk of het bedrijfsmiddel/proces wel nodig is. Indien dat het geval is, wijst men in samenspraak een eigenaar aan **(E4)**. Indien men [hier](canary:event?ts=754743605.00) niet in samenspraak uitkomt, wijst de RvB een eigenaar aan **(E4)**.
|
||||
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
|
||||
See also:
|
||||
- [Asset ownership policy of RUMC](Asset%20ownership%20policy%20of%20RUMC.md)
|
||||
- [Risk ownership](Risk%20ownership.md)
|
||||
- [Control ownership](Control%20ownership.md)
|
||||
|
||||
|
||||
**ISO 27001 explicit mention of asset ownership:**
|
||||
- A.8.1.2 Asset should have an owner
|
||||
- A.9.2.5 Asset owners must periodically evaluate access rights
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
* The relationship can be summarized as: A threat exploits an exposed vulnerability to damage an asset, which results in a risk to the organization.
|
||||
* A risk can be seen as a theoretical threat scenario. If a risk "materializes," an anticipated or potential threat has actually taken place, exploiting a vulnerability and affecting an asset, which results in actual harm or loss.
|
||||
* The relationship between assets, vulnerabilities, and threats is often called the Operations Security Triple.
|
||||
|
||||
[Assets](Assets.md)
|
||||
[Vulnerability 1](Vulnerability%201.md)
|
||||
[Threat](../📚️%20Literature%20notes/Threat.md)
|
||||
[Risks](Risks.md)
|
||||
|
||||
See also: [](../Attachments/Certified%20Ethical%20Hacker%20Exam%20Guide%202021.pdf)
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
See also:
|
||||
- slide decks made for workshop sessions. Those for Kaliber, Nedap and Networking4AL are the most recent.
|
||||
|
||||
An "information asset" refers to a valuable and meaningful piece of information that an organization or individual possesses, uses, or relies upon to achieve their objectives. Information assets can take various forms, including data, documents, intellectual property, proprietary knowledge, and more. They are considered valuable resources that contribute to decision-making, operational efficiency, innovation, and overall business success. Here are a few definitions of "information asset":
|
||||
|
||||
1. **ISO/IEC 27000:2018** (Information Security Management Systems - Overview and Vocabulary):
|
||||
"Information asset: Anything that has value to an organization (e.g. printed documents, electronic documents, intellectual property, personal data, knowledge of processes, physical items)."
|
||||
|
||||
2. **NIST Special Publication 800-53** (Security and Privacy Controls for Federal Information Systems and Organizations):
|
||||
"Information asset: Information and the information systems that process, store, and transmit that information."
|
||||
|
||||
3. **The Data Management Body of Knowledge (DAMA-DMBOK)**:
|
||||
"Information asset: A resource of value that an organization uses to understand, operate, and innovate."
|
||||
|
||||
4. **The University of Texas at Austin - Information Security Office**:
|
||||
"Information asset: Any knowledge that has potential value to an organization or an individual, including but not limited to business data, personal data, research data, proprietary data, and internal and external communications."
|
||||
|
||||
5. **Gartner IT Glossary**:
|
||||
"Information asset: A collection of information that is defined and managed as a standalone entity and is considered of value."
|
||||
|
||||
In essence, an information asset is a piece of information that holds value and significance, whether for its role in decision-making, competitive advantage, regulatory compliance, research, or other organizational functions. Proper management, protection, and utilization of information assets are crucial to an organization's success and security.
|
||||
|
||||
## Related:
|
||||
|
||||
- [Assets, Vulnerabilities, Threats, Risks](Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
|
||||
- [Asset management in ISO 27001](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208%20Asset%20management.md)
|
||||
- [Asset lifecycle in the Defensive Security Handbook](../📚️%20Literature%20notes/Asset%20lifecycle.md)
|
||||
- [Asset ownership](Asset%20ownership.md)
|
||||
- [How to develop an Asset Inventory](How%20to%20develop%20an%20Asset%20Inventory.md)
|
||||
- [Asset management in the Defensive Security Handbook](../Literature%20notes/Def_Sec_Handbook_Chapter_2.md)
|
||||
|
||||
|
|
@ -1,2 +0,0 @@
|
|||
[Seven Dimensions of Security Culture](../Literature%20notes/Seven%20Dimensions%20of%20Security%20Culture.md)
|
||||
|
||||
|
|
@ -1,77 +0,0 @@
|
|||
The ISO27DIY video series teaches you a workshop based approach for implementing an ISO 27001-compliant Information Security Management System (ISMS) in your own organization. The ISO27DIY video series will be available for free.
|
||||
|
||||
These are the current blurbs on the different properties:
|
||||
– see also [🧰 Resource portal](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/🧰%20Resource%20portal.md)
|
||||
|
||||
# ISO27DIY.com website
|
||||
Main website via [Carrd.co](https://iso27diy.com):
|
||||
> ISO27DIY offers a method for implementing an ISO 27001- compliant Information Security Management System (ISMS) in your organization. The ISO27DIY workshop video series will be available for free
|
||||
|
||||
Description for bookmarks and search engine listings:
|
||||
> Learn how to implement ISO 27001 yourself
|
||||
|
||||
# Rent-a-DPO personal site
|
||||
Personal site via [Carrd.co](https://rent-a-dpo.co):
|
||||
> **Trust is Good, Secure is Better**
|
||||
>
|
||||
> Hi, I’m Richard Kranendonk. Since 2017 I’ve helped dozens of organizations, from local charities to internationals, to achieve and maintain their ISO 27001 certification, and to become and remain GDPR compliant.
|
||||
>
|
||||
> Building on 20+ years experience in implementing information technology and organizational change, I can help you design and execute your information security and data protection strategy.
|
||||
>
|
||||
|
||||
**Title:** Rent-a-DPO
|
||||
**Description:** ISO 27001 information security management | GDPR data protection | Strategy and execution
|
||||
|
||||
# Twitter
|
||||
[iso27diy twitter bio](https://twitter.com/iso27diy):
|
||||
🧰 Do ISO 27001 yourself 🔖 Get certified without hiring consultants ⚖️ Control your information security 🧘♀️ Make customers feel safe!
|
||||
|
||||
@richardk twitter bio
|
||||
Making the Internets safer by helping organizations protect their data | @ISO27DIY | ISO 27001 | GDPR | CISSP | ECPC-B | #buildinpublic #indiehacker #nocode
|
||||
|
||||
**Proposed coming out tweet:**
|
||||
It took me a burnout and a psycho boss to make the jump and start building my own service. I feel excited and scared at the same time.
|
||||
#buildinpublic #indiehacker #nocode @thisiskp_ @IndieHackers @makerpad @NocodeHQ
|
||||
|
||||
|
||||
# Revue
|
||||
[Revue](https://www.getrevue.co/app/accounts/ISO27DIY/edit)
|
||||
Newsletter issues description: ISO27DIY newsletter – Learn how to implement ISO 27001 yourself
|
||||
|
||||
# Gumroad
|
||||
|
||||
[Gumroad iso27diy profile](https://app.gumroad.com/iso27diy)
|
||||
ISO27DIY – a method for implementing ISO 27001 in your organization. Get yourself certified.
|
||||
|
||||
[Gumroad personal profile]
|
||||
[Gumroad community introduction](https://community.gumroad.com/c/gumroad-introductions/making-the-jump)
|
||||
|
||||
# Indie Hackers
|
||||
[Indie Hackers profile](https://www.indiehackers.com/rkranendonk)
|
||||
> Making the Internets safer, one ISO 27001 certification at a time 👷♂️ ISO27DYI workshop video series 🎬 AuditGlue documentation software 📑
|
||||
|
||||
[Introduction post:](https://www.indiehackers.com/post/making-the-jump-7ed124b1d1)
|
||||
|
||||
> Hi, I’m Richard. I finally decided to make the jump and start building my own service. I feel excited and scared at the same time.
|
||||
>
|
||||
> I firmly believe that it’s essential that every organization is able to manage their Cybersecurity risks. Not only from a commercial standpoint – being a trustworthy service provider –, but also because safety of information is a requirement for personal freedom and the stability of our society.
|
||||
>
|
||||
> Organizations, especially smaller ones, should be able to acquire the necessary skills without needing to spend large amounts of cash on consultant fees and expensive software.
|
||||
>
|
||||
> So here’s what I’m building:
|
||||
>
|
||||
> 1. a series of YouTube videos, explaining how you can implement ISO 27001* in your organization yourself.
|
||||
> 2. an accompanying membership portal, ISO27DIY.com offering support and additional resources (tooling, templates, example documents, etc.)
|
||||
> 3. a place to create and collect all the necessary documentation to get your ISO 27001 certification: AuditGlue.com
|
||||
>
|
||||
> *) If you’re not familiar with ISO 27001, it’s an international standard for managing information security. Certification for this standard is increasingly becoming a knock-out criterium for vendor selection shortlists.
|
||||
>
|
||||
> I would really appreciate it if you’d sign up for my newsletter on ISO27DIY.com, even if it’s just for moral support ;-)
|
||||
|
||||
Product motivation:
|
||||
> Every organization should be able to manage their information security and achieve ISO 27001 certification, without the need for expensive software or consultants.
|
||||
|
||||
# NoCodeHQ
|
||||
|
||||
# Makerpad community
|
||||
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- prompting
|
||||
---
|
||||
Create a website for iso27DYI.com.
|
||||
Use this logo and this hero image.
|
||||
The landing page must look like this:
|
||||
|
||||
The subscription part will be handled by MailerLite.com.
|
||||
I want a ‘hamburger menu’ in the top right.
|
||||
|
||||
There is a blog page at iso27DYI.com/blog.
|
||||
|
||||
The site will be hosted at Netlify.com
|
||||
|
||||
Use the Hugo framework (see https://gohugo.io/).
|
||||
|
||||
Do not create custom JavaScript unless absolutely necessary.
|
||||
|
||||
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
Borging van security is idealiter in bestaande management systemen en sturcturen van de organisatie.
|
||||
Dat moet breder zijn dan alleen medewerkers die direct betrokken zijn bij security of IT.
|
||||
|
||||
Zo moet er een wedersijdse reflectie zijn tussen het functiehuis en de -profielen en de RBAC voor applicaties.
|
||||
Bijv,: de inkoper mag niet de creditfacturen ter betaling stellen. Of: de medewerker van de Klantenservice die extra rechten nodig heeft in het CRM, dat moet ook te zien zijn in de functieomschrijving.
|
||||
|
||||
En de management verantwoordelijkhden voor veilig werken opp de afdeling, moeten ook leiden tot performance evaluatie op dat punt, naast performance op personeel, klanten en financieen.
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
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](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)
|
||||
|
|
@ -1 +0,0 @@
|
|||
[Repository](https://github.com/certsocietegenerale/IRM/tree/main) of Incident Response playbooks by CERT Societe Generale
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
... door een onafhankelijke Partij
|
||||
|
||||
Uit opdracht: "Bescherming tegen actuele *externe* dreigingen".
|
||||
|
||||
Dus een [Pentest](../../Clients/Humankind/Pentest%20Humankind.md).
|
||||
|
||||
Het andere subject onder de kop "Voorzien in basisveiligheid" is:
|
||||
> Verzekering Beschikbaarheid: backups en noodvoorzieningen, calamiteitenplan
|
||||
|
||||
Heeft het zin om de check op afdoende Backups en noodvoorzieningen door de leveranciers mee te nemen in de Scan? Want dat kan eigenlijk alleen afgelezen worden uit de SLA's?
|
||||
|
||||
**Gesprek 13 augustus:**
|
||||
Opties:
|
||||
* Scenario 1: scan aan de buitenkant met kans op restrisico’s in de binnenkant (niet de voorkeur)
|
||||
* Scenario 2: contractonderhandeling met Ilionx doorzetten, in gesprek gaan met Ilionx, jullie hoeven niks op papier te zetten maar er zit wel iemand bij die lastige vragen stelt. Dus een onafhankelijke techneut die vragen stelt. Plus een pentest.
|
||||
|
||||
**Vraagstelling**
|
||||
Wie zijn jullie?
|
||||
Scope:
|
||||
- Ilionx
|
||||
- Infrastructuur op eigen locaties (wifi) - steekproef op 1 locatie - internetverbinding, modem, wifi-router, accesspoints
|
||||
- Niet: EDM, want Nox en Barracuda
|
||||
- Niet MerCash/KidsVision, want al NFIR scan gedaan
|
||||
- Er is een reactie geweest van KidsConnect over wat ze gaan doen met de bevindingen van de NFIR scan, die mag John met mij delen.
|
||||
Ruimte voor suggesties in aanpak
|
||||
Heb je voldoende voor een eerste aanbieding? Of moet je meer weten
|
||||
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
**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.
|
||||
|
||||
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)
|
||||
[Data classification examples from SANS forum](Data%20classification%20examples%20from%20SANS%20forum.md)
|
||||
[Key Topics for a Classified Information Security Policy](Key%20Topics%20for%20a%20Classified%20Information%20Security%20Policy.md)
|
||||
[Traffic Light Protocol (TLP)](../Literature%20notes/Traffic%20Light%20Protocol%20TLP.md)
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
[CISSP_OSG_Chapter_4](../Standards/CISSP/CISSP_OSG_Chapter_4.md)
|
||||
[Continuous Compliance products](Continuous%20Compliance%20products.md)
|
||||
[ISO 27001 A 18 Compliance](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md)
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
# The ISMS in its context
|
||||
|
||||
The primary purpose of the ISMS is to Control information security risks, that may impede on the organization achieving its goals.
|
||||
|
||||
The ISMS does not exist in a vacuum. It interacts with the internal and external context of the organization. 
|
||||
|
||||
An effective ISMS relies on a relationship between / the interplay of organizational goals, its context, threats and risks to the CIA of information, and available resources.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
@mikepsecuritee @richardk @iso27diy @tugboatlogic @TrustVanta @DrataHQ @DrataHQ has an incredible product😎
|
||||
Tweet by @amanda_robs 22 nov 2021
|
||||
|
||||
@mikepsecuritee @richardk @iso27diy @tugboatlogic @TrustVanta @DrataHQ You might also want to check out @merkely_ 😇
|
||||
Tweet by @meekrosoft 23 nov 2021
|
||||
|
||||
|
||||
|
|
@ -1 +0,0 @@
|
|||
[Threat Modeling](../📚️%20Literature%20notes/Privacy%20Threat%20Modeling.md)
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
# Cracking passwords in 2024
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
|
||||
|
||||
|
||||
“An asset is anything within an environment that should be protected. It is anything used in a business process or task. It can be a computer file, a network service, a system resource, a process, a program, a product, an IT infrastructure, a database, a hardware device, furniture, product recipes/ formulas, intellectual property, personnel, software, facilities, and so on.
|
||||
|
||||
If an organization places any value on an item under its control and deems that item important enough to protect, it is labeled an asset for the purposes of risk management and analysis. The loss or disclosure of an asset could result in an overall security compromise, loss of productivity, reduction in profits, additional expenditures, discontinuation of the organization, and numerous intangible consequences.”
|
||||
|
||||
— (ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide by Mike Chapple, James Michael Stewart, et al.
|
||||
https://amzn.eu/6EvlQju, P.64
|
||||
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
ISO 27001 seems to have a sort of outdated linear view of building and testing.
|
||||
How do the controls fit in with DevSecOps?
|
||||
|
||||
Related:
|
||||
[ISO 27001 A.14.2.8 System security testing](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A.14.2.8%20System%20security%20testing.md)
|
||||
[ISO 27001 A.14.2.9 System acceptance testing](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A.14.2.9%20System%20acceptance%20testing.md)
|
||||
[Red, Blue, and Purple Teams](../Literature%20notes/Red,%20Blue,%20and%20Purple%20Teams.md)
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
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)
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
# Example of ISO 27001 mystique
|
||||
|
||||
ISO 27001 is a framework, and you cannot successfully implement it by treating the text of the standard as a series of instructions to be followed in the order in which they were printed. If you try that, things will become very confusing very quickly.
|
||||
|
||||
For example, the requirement of having an information security policy is first (?) mentioned in [Chapter 5.1](../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), "Leadership and commitment", where it says that top management must have it established, *together* with information security objectives. Then in [Chapter 5.2](../Standards/ISO27x/OST/27001/EN/c-5.2-Policy.md), 'Policy', it states that these objectives form *part of* the information security policy, referencing forward to [Chapter 6.2](../MoCs/ISO_27001_2022_6.2_MoC%20Information%20security%20objectives%20and%20planning%20to%20achieve%20them.md), "Information security objectives and planning to achieve them", which demands that organizations should set objectives consistent with the policy. Of course there's also a corresponding Control called "Policies for information security" ([5.1](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md)), which explains that there will be an information security policy at the highest level of the organization, including objectives "or the framework for setting objectives", and further "topic-specific policies as needed", which of course need their own objectives.
|
||||
|
||||
Programmers may love this kind of recursiveness when it's in coding exercises.
|
||||
|
||||
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
---
|
||||
|
||||
|
||||
|
||||
- [ISO_27002_2022_5.10_PE Acceptable use of information and other associated assets](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.10_PE%20Acceptable%20use%20of%20information%20and%20other%20associated%20assets.md)
|
||||
- [ISO_27002_2022_5.13_PE Labelling of information](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.13_PE%20Labelling%20of%20information.md)
|
||||
- [ISO_27002_2022_5.32_PE Intellectual property rights](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.32_PE%20Intellectual%20property%20rights.md)
|
||||
- [ISO_27002_2022_5.7_PE Threat intelligence](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.7_PE%20Threat%20intelligence.md)
|
||||
- [ISO_27002_2022_5.22_PE Monitoring, review and change management of supplier services](../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.22_PE%20Monitoring%2C%20review%20and%20change%20management%20of%20supplier%20services.md)
|
||||
- [ISO_27002_2022_5.1_PE Policies for information security](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.1_PE%20Policies%20for%20information%20security.md)
|
||||
- [ISO_27002_2022_5.20_PE Addressing information security within supplier agreements](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.20_PE%20Addressing%20information%20security%20within%20supplier%20agreements.md)
|
||||
- [ISO_27002_2022_5.23_PE Information security for use of cloud services](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.23_PE%20Information%20security%20for%20use%20of%20cloud%20services.md)
|
||||
- [ISO_27002_2022_5.19_PE Information security in supplier relationships](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.19_PE%20Information%20security%20in%20supplier%20relationships.md)
|
||||
- [ISO_27002_2022_5.8_PE Information security in project management](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.8_PE%20Information%20security%20in%20project%20management.md)
|
||||
- [ISO_27002_2022_5.12_PE Classification of information](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.12_PE%20Classification%20of%20information.md)
|
||||
- [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)
|
||||
- [ISO_27002_2022_5.27_PE Learning from information security incidents](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.27_PE%20Learning%20from%20information%20security%20incidents.md)
|
||||
- [ISO_27002_2022_5.21_PE Managing information security in the ICT supply chain](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.21_PE%20Managing%20information%20security%20in%20the%20ICT%20supply%20chain.md)
|
||||
- [ISO_27002_2022_5.2_PE Information security roles and responsibilities](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.2_PE%20Information%20security%20roles%20and%20responsibilities.md)
|
||||
- [ISO_27002_2022_8.28_PE Secure coding](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_8.28_PE%20Secure%20coding.md)
|
||||
- [ISO_27002_2022_5.3_PE Segregation of duties](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_5.3_PE%20Segregation%20of%20duties.md)
|
||||
- [ISO_27002_2022_8.9_PE Configuration management](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_8.9_PE%20Configuration%20management.md)
|
||||
- [ISO_27002_2022_8.26_PE Application security requirements](../../../iso27DIY-gis/reference/Paraphrased/ISO27002-2022-EN/ISO_27002_2022_8.26_PE%20Application%20security%20requirements.md)
|
||||
- [ISO 27x Control PE template](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/📒%20Templates/ISO%2027x%20Control%20PE%20template.md)
|
||||
-
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
- [Dropbox](../Literature%20notes/Dropbox%20Supplier%20Security%20Requirements.md)
|
||||
- [Google](https://vsaq-demo.withgoogle.com)
|
||||
|
||||
Related:
|
||||
- [Vendor security MoC](Vendor%20security%20MoC.md)
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
Auditors verschillen
|
||||
Wat de een genoeg vindt, vindt de ander onvoldoende.
|
||||
Maar: je moet het erg bont maken om je certificering te verliezen. Je krijgt de kans te verbeteren/herstellen.
|
||||
|
||||
En cynisch: je kiest je CI zelf, en een CI zal liever niet bekend willen staan als de CI met de laagste succes ratio.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
This note relates to the [ISO27DIY Business model](../Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Business%20model.md)
|
||||
|
||||
Probleem: de GRC software wordt aangekocht om een operationeel probleem van de compliance officer op te lossen.
|
||||
|
||||
De software komt meestal pas later (en wordt pas gevuld als de kennis van wat ISO is en van het proces er al is, als het jargon al is ingesleten)
|
||||
|
||||
Eerst komt de consultant uitleggen hoe ISO werkt en wordt hulp geboden bij Wat je Waar moet documenteren, en Hoe (denk aan de risico-identificatie en de stakeholder-analyse: wat is een in-scope risico, hoe verwoordt je het precies. Wat is een stakeholder, wat is zijn in-scope belang, etc.).
|
||||
Dan ontstaat de documentatie, meestal in Excel en Word documenten.
|
||||
Dan de realisering dat het onhandig is en niet schaalt.
|
||||
Dan wordt software geselecteerd en geïmplementeerd.
|
||||
Pas dan wordt de software daadwerkelijk gebruikt, en meestal door een deskundige staffunctionaris.
|
||||
|
||||
Inmiddels staat het dan zover af van de dagelijkse praktijk op de werkvloer, dat de heilige graal van security by design en in de haarvaten van de organisatie, niet gehaald kan worden.
|
||||
Voor iedere (interne) audit is extra effort nodig om te graven in de operationele documentatie om de audit documentatie naar boven te krijgen.
|
||||
|
||||
Wat nu als je de documentatie kun genereren op het moment dat relevante feiten (identificatie en weging van risico’s, keuze van maatregelen, bewaken van de implementatie, monitoren van de resultaten en bijsturen) plaatsvinden? Door ze voorafgaand aan een SCRUM, Team- of afdelingsoverleg of ontwerpmeeting te agenderen, en ze in de notulen te ‘marken’? Door operationele reports en logs te koppelen naar de ISO-administratie?
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
[Cyber Security Governance Principles](Cyber%20Security%20Governance%20Principles.md)
|
||||
[Data Governance](../📚️%20Literature%20notes/Data%20Governance.md)
|
||||
[Checklist for auditing Data Governance](../Literature%20notes/Checklists%20Gerardus%20Blokdyk/Checklist%20for%20auditing%20Data%20Governance.md)
|
||||
|
|
@ -1,4 +1,6 @@
|
|||
[Create a threat analysis chatbot](Create%20a%20threat%20analysis%20chatbot.md)
|
||||
# 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
|
||||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
# About the connection between threat intelligence, analysis and modeling
|
||||
|
||||
### 🔄 Interplay Overview
|
||||
|
|
@ -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 it’s individual controls. Proper implementation means a control is risk-based, there’s a policy describing the why and how of it’s implementation, it’s results are monitored or measured, it’s effectiveness is evaluated, and possible improvements to the implementation of the control are identified.
|
||||
|
||||
|
|
|
|||
|
|
@ -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?`
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
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](CRUD%20Matrices.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)
|
||||
Source: [](../../Attachments/Certified%20Ethical%20Hacker%20Exam%20Guide%202021.pdf)
|
||||
|
||||
- Mandatory Access Control (MAC):
|
||||
- Every object gets a label
|
||||
13
Corpus/Sparks/ISMS/Access Control.md
Normal file
13
Corpus/Sparks/ISMS/Access Control.md
Normal 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)
|
||||
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 96 KiB After Width: | Height: | Size: 96 KiB |
104
Corpus/Sparks/ISMS/Assets Ownership and Risk Overview.md
Normal file
104
Corpus/Sparks/ISMS/Assets Ownership and Risk Overview.md
Normal 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:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -6,7 +6,7 @@ tags:
|
|||
|
||||
# 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](../../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
|
||||
|
||||
|
|
@ -23,8 +23,8 @@ tags:
|
|||
- **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.
|
||||
- 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.
|
||||
24
Corpus/Sparks/ISMS/Business Impact Analysis (BIA).md
Normal file
24
Corpus/Sparks/ISMS/Business Impact Analysis (BIA).md
Normal 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)
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Classificatie op basis van risico-oorzaken
|
||||
# Classificatie van risico's
|
||||
|
||||
Risico's kunnen worden ingedeeld in diverse categorieën, die elk een andere bron van gevaar vertegenwoordigen:
|
||||
|
||||
|
|
@ -1,17 +1,8 @@
|
|||
---
|
||||
title: Classifying Integrity
|
||||
source: https://www.perplexity.ai/search/351dee5b-0f9f-419b-bec2-381b6e285401
|
||||
author:
|
||||
- "[[Perplexity AI]]"
|
||||
published:
|
||||
created: 2025-06-10
|
||||
description: What instruments do we have to classify the necessity of integrity of information?
|
||||
tags:
|
||||
- clippings
|
||||
---
|
||||
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)
|
||||
# Classifying Integrity
|
||||
|
||||
Prompt: `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`
|
||||
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/)
|
||||
|
|
@ -1,4 +1,6 @@
|
|||
See also [Risk ownership](Risk%20ownership.md), [Asset ownership](Asset%20ownership.md)
|
||||
# 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)
|
||||
|
|
@ -1,3 +1,5 @@
|
|||
# Data breach procedure
|
||||
|
||||
Previous work:
|
||||
- Post mortem Ultimaker LinkedIn Learning incident
|
||||
- Pixelpool Data breach procedure
|
||||
|
|
@ -5,4 +7,4 @@ Previous work:
|
|||
|
||||
|
||||
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)
|
||||
- [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)
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
# 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
|
||||
|
||||
|
|
@ -9,10 +19,10 @@ Confidential
|
|||
2. Some risk - Internal
|
||||
3. Significant risk - Confidential
|
||||
|
||||
1. Unrestricted
|
||||
2. Restricted-External
|
||||
3. Restricted-Internal
|
||||
4. Confidential
|
||||
4. Unrestricted
|
||||
5. Restricted-External
|
||||
6. Restricted-Internal
|
||||
7. Confidential
|
||||
|
||||
- Public
|
||||
- Internal
|
||||
|
|
@ -35,8 +45,20 @@ Just before I left the Bank of England, we rebuilt our classification scheme -
|
|||
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)
|
||||
[https://web.universiteitleiden.nl/assets/toolpicker/?lang=en](https://web.universiteitleiden.nl/assets/toolpicker/?lang=en)
|
||||
|
||||
|
||||
|
||||
|
||||
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)
|
||||
|
||||
|
||||
9
Corpus/Sparks/ISMS/Disaster Recovery Planning.md
Normal file
9
Corpus/Sparks/ISMS/Disaster Recovery Planning.md
Normal 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)
|
||||
3
Corpus/Sparks/Incident Response playbooks.md
Normal file
3
Corpus/Sparks/Incident Response playbooks.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
# Incident Response playbooks
|
||||
|
||||
[Repository](https://github.com/certsocietegenerale/IRM/tree/main) of Incident Response playbooks by CERT Societe Generale
|
||||
|
|
@ -1,6 +1,8 @@
|
|||
# CIS Critical Security Controls
|
||||
|
||||
https://www.cisecurity.org/controls
|
||||
|
||||
Cyber attacks exploit bad cuyber hygiene
|
||||
Cyber attacks exploit bad cyber hygiene
|
||||
CIS are security best practices for strengthening your security posture to defend agains top threats
|
||||
|
||||
maps to lots of frameworks
|
||||
|
|
@ -8,7 +10,7 @@ maps to lots of frameworks
|
|||
Safeguards are identified by attack patterns from the MITRE ATT&CK* framework
|
||||
we verified that the CIS Controls are effective at defending against 86% of the ATT&CK (sub-)techniques found in the ATT&CK framework. More importantly, the Controls are highly effective against the top five attack types found in industry threat data.
|
||||
|
||||
|
||||
|
||||
Source: CIS Community Defense Model version 2.0
|
||||
|
||||
|
||||
|
|
@ -29,10 +31,10 @@ IG3 assets contain sensitive information or functions that are subject to regula
|
|||
Safeguards selected for IG3 must abate targeted attacks from a sophisticated adversary and reduce the impact of zero-day attacks.
|
||||
|
||||
|
||||
|
||||
|
||||
Source: CIS Controls v8.1 PDF, pp 8-12
|
||||
|
||||
|
||||
|
||||
List of the CIS Controls in v8, and how many Safeguards in each are applicable to each Implementation Group. [source](https://www.cisecurity.org/controls/implementation-groups)
|
||||
|
||||
See CIS_Controls_Version_8.1_6_24_2024.xlsx for a table that shows all safeguards mapped to the three Implementation Groups.
|
||||
|
|
@ -1,8 +1,4 @@
|
|||
---
|
||||
tags:
|
||||
- infosec
|
||||
- type/explainer
|
||||
---
|
||||
# CRUD Matrices
|
||||
|
||||
A CRUD matrix defines what actions a user (or process) is allowed to perform on a certain object, typically a data entity such as a table or record in a database.
|
||||
|
||||
|
|
@ -33,7 +29,7 @@ In the form below, we can see which authorizations each role has for different o
|
|||
| Sales Rep | CRUD | R | RU | R | R |
|
||||
| Stock Manager | - | - | - | R | RU |
|
||||
|
||||
A CRUD matrix is a helpful tool for [Access Control Models](Access%20Control%20Models.md), and several well-known CRUD extensions have been introduced to address specific needs, for example:
|
||||
A CRUD matrix is a helpful tool for [Access Control Models](../ISMS/Access%20Control%20Models.md), and several well-known CRUD extensions have been introduced to address specific needs, for example:
|
||||
([source](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete))
|
||||
|
||||
- **CRUDL (Create, Read, Update, Delete, List):** Adds a "List" operation to explicitly support retrieving collections of records, which is especially useful in applications where listing and searching are distinct from simple reading of single records.
|
||||
|
|
@ -1,7 +1,5 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
---
|
||||
# Architectural patterns for client segregation in SaaS systems
|
||||
|
||||
SaaS systems implement client segregation through several architectural patterns, each with distinct tradeoffs between security, efficiency, and complexity:
|
||||
|
||||
## Physical Segregation (Dedicated Infrastructure)
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
# Cracking passwords in 2024
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,10 +1,12 @@
|
|||
# BYOK: Customer Managed Keys
|
||||
|
||||
|
||||
Asked Gemini, 30 juni 2025.
|
||||
Prompt: `What is meant by 'Bring your own encryption key?`
|
||||
|
||||
Related:
|
||||
- [a-8.24-Use-of-cryptography](../Standards/ISO27x/OST/27002/EN/a-8.24-Use-of-cryptography.md)
|
||||
# Customer Managed Keys
|
||||
- [a-8.24-Use-of-cryptography](../../Standards/ISO27x/OST/27002/EN/a-8.24-Use-of-cryptography.md)
|
||||
|
||||
|
||||
'Bring Your Own Encryption Key' (BYOK), also sometimes referred to as 'Bring Your Own Encryption' (BYOE) or 'Customer Managed Keys' (CMK), is a cloud computing security model that allows organizations to use and manage their own encryption keys for data stored in cloud environments, rather than relying on the cloud service provider to generate and manage the keys.
|
||||
|
||||
|
|
@ -1,4 +1,5 @@
|
|||
# Data maturity model NL overheid
|
||||
|
||||
Een data maturity model helpt Nederlandse overheidsorganisaties bij het beoordelen, verbeteren en volwassen maken van hun datamanagementpraktijken. Het model dient als een raamwerk om de huidige status van een organisatie op het gebied van data te beoordelen en verbeterplannen te identificeren.
|
||||
|
||||
### Elaboratie:
|
||||
|
|
@ -1,3 +1,4 @@
|
|||
# Dealing with a reported application vulnerability
|
||||
# Context
|
||||
A vulnerability in a widely used open source library is published.
|
||||
|
||||
|
|
@ -32,16 +33,16 @@ Do an impact analyses and identify a treatment:
|
|||
|
||||
|
||||
## Relevant ISO 27001 controls
|
||||
The main control of interest here is [ISO 27001 A 12.6.1 Management of technical vulnerabilities](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.6.1%20Management%20of%20technical%20vulnerabilities.md), which ensures timely awareness of vulnerabilities through [ISO 27001 A 6.1.4 Contact with special interest groups](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%206.1.4%20Contact%20with%20special%20interest%20groups.md), evaluation of an organization’s exposure, and having set [ISO 27001 A 16.1.1 Responsibilities and procedures](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2016.1.1%20Responsibilities%20and%20procedures.md) to enable a quick and effective response.
|
||||
The main control of interest here is [ISO 27001 A 12.6.1 Management of technical vulnerabilities](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.6.1%20Management%20of%20technical%20vulnerabilities.md), which ensures timely awareness of vulnerabilities through [ISO 27001 A 6.1.4 Contact with special interest groups](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%206.1.4%20Contact%20with%20special%20interest%20groups.md), evaluation of an organization’s exposure, and having set [ISO 27001 A 16.1.1 Responsibilities and procedures](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2016.1.1%20Responsibilities%20and%20procedures.md) to enable a quick and effective response.
|
||||
|
||||
Stopping the gap:
|
||||
- [[ISO 27001 A 13.1.1 Network controls]]
|
||||
- [[ISO 27001 A 13.1.2 Security of network services]]
|
||||
- [ISO 27001 A 12.5.1 Installation of software on operational systems](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.5.1%20Installation%20of%20software%20on%20operational%20systems.md)
|
||||
- [ISO 27001 A 12.5.1 Installation of software on operational systems](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.5.1%20Installation%20of%20software%20on%20operational%20systems.md)
|
||||
|
||||
Preventative measures:
|
||||
- [ISO 27001 A 12.6.2 Restrictions on software installation](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.6.2%20Restrictions%20on%20software%20installation.md)
|
||||
- [ISO 27001 A 12.6.2 Restrictions on software installation](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2012.6.2%20Restrictions%20on%20software%20installation.md)
|
||||
- [[ISO 27001 A 14.1.1 Information security requirements analysis and specification]]
|
||||
- [[ISO 27001 14.2.1 Secure development policy]]
|
||||
- [[ISO 27001 A 14.2.7 Outsourced development]]
|
||||
- [ISO 27001 A 18 Compliance](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md) of systems
|
||||
- [ISO 27001 A 18 Compliance](../../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md) of systems
|
||||
|
|
@ -1,8 +1,10 @@
|
|||
# Examples of Risk Avoidance
|
||||
|
||||
*ChatGPT prompt: In risk management, risks can be assigned a treatment strategy. Generally this is a choice between mitigate, transfer, accept or avoid. Give me some examples of possible courses of actions for risks in the 'avoid' category.*
|
||||
|
||||
*ChatGPT output, August 22, 2024:*
|
||||
|
||||
Certainly! When a risk is categorized under 'avoid,' it means taking steps to eliminate the possibility of the risk occurring. Here are some examples of possible courses of action for risks in the 'avoid' category:
|
||||
When a risk is categorized under 'avoid,' it means taking steps to eliminate the possibility of the risk occurring. Here are some examples of possible courses of action for risks in the 'avoid' category:
|
||||
|
||||
1. **Changing the Project Scope:**
|
||||
- If a project involves a high-risk task, one can alter the project's scope to exclude that task altogether, thereby avoiding the risk.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# Examples of vendor selection questionnaires
|
||||
|
||||
- [Dropbox](../../Literature%20notes/Dropbox%20Supplier%20Security%20Requirements.md)
|
||||
- [Google](https://vsaq-demo.withgoogle.com)
|
||||
|
||||
Related:
|
||||
- [Vendor security MoC](../Vendor%20security%20MoC.md)
|
||||
|
|
@ -1,3 +1,5 @@
|
|||
# Key Topics for a policy on handling classified information
|
||||
|
||||
A comprehensive policy on handling classified information should address the following key topics to ensure its security and confidentiality:
|
||||
|
||||
1. Classification Levels and Criteria:
|
||||
BIN
Corpus/Sparks/Pasted image 20260514155842.png
Normal file
BIN
Corpus/Sparks/Pasted image 20260514155842.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 106 KiB |
|
|
@ -2,5 +2,5 @@
|
|||
tags:
|
||||
- business_process
|
||||
---
|
||||
[CICD pipeline components](CICD%20pipeline%20components.md)
|
||||
[CICD pipeline components](../Various/Business%20processes/CICD%20pipeline%20components.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Also see:
|
|||
See also:
|
||||
- [a-5.30-ICT-readiness-for-business-continuity](../Standards/ISO27x/OST/27002/EN/a-5.30-ICT-readiness-for-business-continuity.md)
|
||||
- [BCP_Bedrijfscontinuïteitsplanning](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
|
||||
- [Disaster Recovery Planning](Disaster%20Recovery%20Planning.md)
|
||||
- [Disaster Recovery Planning](ISMS/Disaster%20Recovery%20Planning.md)
|
||||
|
||||
3 Phases:
|
||||
- Prevention
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ aliases:
|
|||
See also under [Threat](../📚️%20Literature%20notes/Threat.md)
|
||||
|
||||
[Open Group Risk Analysis Standard (O-RA)](https://pubs.opengroup.org/security/o-ra/)
|
||||
[Open Group FAIR \ ISO 27005 Cookbook for Risk Assessment](FAIR%20ISO%2027005%20Cookbook.pdf)
|
||||
[Open Group FAIR \ ISO 27005 Cookbook for Risk Assessment](../Standards/ISO27x/FAIR%20ISO%2027005%20Cookbook.pdf)
|
||||
|
||||
[SURF Toolkit risicobeoordeling](SURF%20Toolkit%20risicobeoordeling.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -13,8 +13,8 @@ Zie ook:
|
|||
[SCF Risk Categories for Establishing a Risk Catalog](../Standards/other/SCF%20Risk%20Categories%20for%20Establishing%20a%20Risk%20Catalog.md)
|
||||
[SCF Threat Categories for Establishing a Threat Catalog](../Standards/other/SCF%20Threat%20Categories%20for%20Establishing%20a%20Threat%20Catalog.md)
|
||||
|
||||
[](Carnegie%20Mellon%20Taxonomy%20of%20Operational%20Cyber%20Security%20Risks%20Version%202.pdf)
|
||||
[CRF Threat Taxonomy 2024](CRF-Threat-Taxonomy-v2024.pdf)
|
||||
[](Taxonomy%20of%20Operational%20Cyber%20Security%20Risks.pdf)
|
||||
[CRF Threat Taxonomy 2024](Information%20Security/CRF-Threat-Taxonomy-v2024.pdf)
|
||||
[Enisa Threat Taxonomy](https://www.enisa.europa.eu/topics/cyber-threats/threats-and-trends/enisa-threat-landscape/threat-taxonomy)
|
||||
[MITRE ATT&CK](https://attack.mitre.org)
|
||||
[MITRE D3FEND](https://d3fend.mitre.org)
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue