removed emojis, merged 2 folders, removed duplication
This commit is contained in:
parent
9b7b3a3a85
commit
24403ce731
92 changed files with 106 additions and 1432 deletions
|
Before Width: | Height: | Size: 87 KiB After Width: | Height: | Size: 87 KiB |
|
|
@ -1,4 +0,0 @@
|
|||
|
||||
|
||||
[PLOT4AI](https://plot4.ai) (Privacy Library Of Threats 4 Artificial Intelligence): A threat modeling library to help you build responsible AI
|
||||
by [Isabel Barbéra](https://www.linkedin.com/in/isabelbarbera/)
|
||||
|
|
@ -1 +1,5 @@
|
|||
[Create a threat analysis chatbot](../Drafts%20and%20Ideas/Controls/Create%20a%20threat%20analysis%20chatbot.md)
|
||||
[Create a threat analysis chatbot](Create%20a%20threat%20analysis%20chatbot.md)
|
||||
|
||||
|
||||
[PLOT4AI](https://plot4.ai) (Privacy Library Of Threats 4 Artificial Intelligence): A threat modeling library to help you build responsible AI
|
||||
by [Isabel Barbéra](https://www.linkedin.com/in/isabelbarbera/)
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
See also:
|
||||
- [Authorization vs Access Control](Authorization%20vs%20Access%20Control.md)
|
||||
- [Identity and Access Management (IAM)](../Drafts%20and%20Ideas/Identity%20and%20Access%20Management%20(IAM).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)
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
* The relationship between assets, vulnerabilities, and threats is often called the Operations Security Triple.
|
||||
|
||||
[Assets](Assets.md)
|
||||
[Vulnerability](../Drafts%20and%20Ideas/Vulnerability.md)
|
||||
[Vulnerability 1](Vulnerability%201.md)
|
||||
[Threat](../📚️%20Literature%20notes/Threat.md)
|
||||
[Risks](Risks.md)
|
||||
|
||||
|
|
|
|||
13
Corpus/Sparks/Ideas about enforcement 1.md
Normal file
13
Corpus/Sparks/Ideas about enforcement 1.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
# Ideas about enforcement
|
||||
The coverage of [[Enforcement tooling]] will not be complete, if only because their implementation will always be one step behind organizational reality. There will be information assets out of scope, by choice or accident.
|
||||
|
||||
There will be situations where the improper handling of assets is not prevented by such tooling, and employees would need to be aware of, or deduce from content, the classification of those assets, and make an informed decission on the proper handling.
|
||||
|
||||
The underlying idea is that I personally prefer that people have freedom of choice and be supported in making informed decissions.
|
||||
that is not only morally preferable, but it's a necessigty precisely because there will always be situations in which they *need* to decide for themselves.
|
||||
|
||||
There's also a link here to different stakeholders with different interests. Think of your stereotypical IT Guy, who wants to screw everything down, and Marketing Guy, who wants maximum freedom in the data lake.
|
||||
|
||||
Related:
|
||||
- [Labeling of information in the digital domain](Labeling%20of%20information%20in%20the%20digital%20domain.md).
|
||||
- [Stakeholder Analysis](Stakeholder%20Analysis.md)
|
||||
|
|
@ -5,3 +5,11 @@ See also:
|
|||
- [Authentication](../Standards/ISO27x/Authentication.md)
|
||||
- [Authorization](../Standards/ISO27x/Authorization.md)
|
||||
- [Identity and Access Management (IAM)](Identity%20and%20Access%20Management%20(IAM).md)
|
||||
|
||||
# Identification
|
||||
Identification is the claim of a subject of its identity.
|
||||
|
||||
See also:
|
||||
- [Authentication](../Standards/ISO27x/Authentication.md)
|
||||
- [Authorization](../Standards/ISO27x/Authorization.md)
|
||||
- [Identity and Access Management (IAM)](Identity%20and%20Access%20Management%20(IAM).md)
|
||||
|
|
|
|||
|
|
@ -6,6 +6,21 @@ In IAM, permission to access a resource isn't granted _directly_ to the end us
|
|||
|
||||
An _allow policy_, also known as an _IAM policy_, defines and enforces what roles are granted to which principals. Each allow policy is attached to a resource. When an authenticated principal attempts to access a resource, IAM checks the resource's allow policy to determine whether the action is permitted.
|
||||
|
||||
See:
|
||||
- [Identification](Identification.md) – "This is who I am"
|
||||
- [Authentication](../Standards/ISO27x/Authentication.md) – "This is how I prove it"
|
||||
- [Authorization](../Standards/ISO27x/Authorization.md) – "... then this is what you get access to"
|
||||
- [CISSP_Domain_5_1](../Standards/CISSP/CISSP_Domain_5_1.md), [CISSP_Domain_5_2](../Standards/CISSP/CISSP_Domain_5_2.md)
|
||||
- [Roles in Identity and Access Management (IAM)](../Literature%20notes/Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md)
|
||||
|
||||
## How IAM works
|
||||
|
||||
With IAM, you manage access control by defining _who_ (identity) has _what access_ (role) for _which resource_. For example, Compute Engine virtual machine instances, Google Kubernetes Engine (GKE) clusters, and Cloud Storage buckets are all Google Cloud resources. The organizations, folders, and projects that you use to organize your resources are also resources.
|
||||
|
||||
In IAM, permission to access a resource isn't granted _directly_ to the end user. Instead, permissions are grouped into _roles_, and roles are granted to authenticated _principals_. (In the past, IAM often referred to principals as _members_. Some APIs still use this term.)
|
||||
|
||||
An _allow policy_, also known as an _IAM policy_, defines and enforces what roles are granted to which principals. Each allow policy is attached to a resource. When an authenticated principal attempts to access a resource, IAM checks the resource's allow policy to determine whether the action is permitted.
|
||||
|
||||
See:
|
||||
- [Identification](Identification.md) – "This is who I am"
|
||||
- [Authentication](../Standards/ISO27x/Authentication.md) – "This is how I prove it"
|
||||
|
|
|
|||
|
|
@ -4,5 +4,5 @@
|
|||
[](../Attachments/TLP_Impact_matrix_NL.xlsx)
|
||||
|
||||
[BCP_Bedrijfscontinuïteitsplanning](../📚️%20Literature%20notes/BCP_Bedrijfscontinuïteitsplanning.md)
|
||||
[Business Impact Analysis (BIA)](../Sparks/Business%20Impact%20Analysis%20(BIA).md)
|
||||
[Business Impact Analysis (BIA)](..//Business%20Impact%20Analysis%20(BIA).md)
|
||||
|
||||
|
|
|
|||
|
|
@ -12,6 +12,25 @@ Labeling of digital information assets ‘close to the source’ – e.g. assign
|
|||
|
||||
Looking at it that way, any metadata that helps ensure the acceptable use and proper handling of information assets could be identified as ‘labeling’. A data dictionary that contains classification information could also be considered to use labeling.
|
||||
|
||||
Related:
|
||||
- [ISO 27001 A 8.2.1 Classification of information](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2.1%20Classification%20of%20information.md)
|
||||
- [ISO 27001 A 8.1.3 Acceptable use of assets](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.1.3%20Acceptable%20use%20of%20assets.md)
|
||||
- [[Enforcement tooling]]
|
||||
|
||||
[ISO 27001 A 8.2.2 Labelling of information](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2.2%20Labelling%20of%20information.md) makes procedures for information labelling in accordance with the classification scheme mandatory.
|
||||
|
||||
For physical assets it’s straightforward: a ‘restricted area’ sign on the door to the server room, a ‘classified’ mark on a folder, a ‘privacy sensitive’ sticker on a backup tape, etc.
|
||||
|
||||
But how would you implement labeling in the digital domain of databases, file systems, SaaS environments, etc.?
|
||||
|
||||
Brahman Thiyagalingham suggested in [this LinkedIn thread](https://www.linkedin.com/feed/update/urn:li:activity:6878704465160007680/?commentUrn=urn%3Ali%3Acomment%3A(groupPost%3A67493-6878704464929316864%2C6878973141931094016)&replyUrn=urn%3Ali%3Acomment%3A(groupPost%3A67493-6878704464929316864%2C6879367802243866624)) that, to ensure the proper handling of (digital) information assets, you would rely on "something like a proper RBAC model, Identity Access solution with a PAM, DRM and DLP". Implying the concept of labeling has been replaced by applying these tools.
|
||||
|
||||
It could be said that these tools apply labeling implicitely, because effective implementation of these solutions requires that the solution ’knows’ what forms of protection each information asset needs.
|
||||
That means classifying information assets (control 8.2.1) and determining acceptable use (control 8.1.3).
|
||||
Labeling of digital information assets ‘close to the source’ – e.g. assign a classification-label to a database column – will help create a consistent approach across individual solutions.
|
||||
|
||||
Looking at it that way, any metadata that helps ensure the acceptable use and proper handling of information assets could be identified as ‘labeling’. A data dictionary that contains classification information could also be considered to use labeling.
|
||||
|
||||
Related:
|
||||
- [ISO 27001 A 8.2.1 Classification of information](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.2.1%20Classification%20of%20information.md)
|
||||
- [ISO 27001 A 8.1.3 Acceptable use of assets](../Standards/ISO27x/legacy/ISO%2027001%202013/ISO%2027001%20A%208.1.3%20Acceptable%20use%20of%20assets.md)
|
||||
|
|
|
|||
4
Corpus/Sparks/List of possible partners 1.md
Normal file
4
Corpus/Sparks/List of possible partners 1.md
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
- [The Art of Service](The%20Art%20of%20Service.md) offers topical InfoSec Kanban boards
|
||||
- 'Certificeringsadvies' offers independent external audits, they were employed by Networking4all
|
||||
- [Muddassir via Gumroad](https://community.gumroad.com/c/share-your-wins/boring-fields-like-supply-chains-can-be-creative-enough-to-sell-digital-products?login_token=RyhWoyqXw2kT5de2eNp6RYjL6U4NY1aKLPmS#comment_wrapper_4014940). Runs a site on SCM and has offered to cross post content.
|
||||
|
||||
|
|
@ -12,4 +12,4 @@ Articulate the risk appetite to:
|
|||
|
||||
See [Topical InfoSec Kanban’s](../Literature%20notes/Topical%20InfoSec%20Kanban’s.md) for inspiration.
|
||||
|
||||
See also [Risk tolerance](../Sparks/Risk%20tolerance.md)
|
||||
See also [Risk tolerance](..//Risk%20tolerance.md)
|
||||
|
|
@ -6,5 +6,5 @@ NIST gives [several definitions](https://csrc.nist.gov/glossary/term/risk_tolera
|
|||
|
||||
"The level of risk or the degree of uncertainty that is acceptable to an organization."
|
||||
|
||||
See also [Risk appetite](../Drafts%20and%20Ideas/Risk%20appetite.md)
|
||||
See also [Risk appetite 1](Risk%20appetite%201.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -4,4 +4,4 @@
|
|||
Risks, threats and vulnerabilities are commonly misunderstood.
|
||||
|
||||
Fundamentally, vulnerability and risk management practices exist to achieve a minimum level of protection for an organization, which equates to a reduction in the total risk due to the protections offered by implemented controls. This can be conceptualized as a "risk management ecosystem" as it pertains to an organization's overall cybersecurity & data protection efforts. These ecosystem components have unique meanings that need to be understood to reasonably protect people, processes, technology and data, as shown below:
|
||||

|
||||

|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
[Assets, Vulnerabilities, Threats, Risks](Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
|
||||
[Vulnerability](../Drafts%20and%20Ideas/Vulnerability.md)
|
||||
[Vulnerability 1](Vulnerability%201.md)
|
||||
[Information security concepts MoC](../Information%20security%20concepts%20MoC.md)
|
||||
[Assets, Vulnerabilities, Threats, Risks](../📚️%20Literature%20notes/Assets,%20Vulnerabilities,%20Threats,%20Risks.md)
|
||||
|
||||
|
||||
See also slide decks made for workshop sessions. Those for Kaliber, Nedap and Networking4AL are the most recent.
|
||||
|
||||
See also [Risk appetite](../Drafts%20and%20Ideas/Risk%20appetite.md)
|
||||
See also [Risk appetite 1](Risk%20appetite%201.md)
|
||||
See also [Classificatie van risico's obv Oorzaken](Classificatie%20van%20risico's%20obv%20Oorzaken.md)
|
||||
|
||||
## Definitions
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
Bron: [SURF website](https://sec.surf.nl/asset/toolkit-risicobeoordeling/)
|
||||
|
||||
|
||||

|
||||

|
||||
|
||||
|
||||
**Powerpoint voor workshop**
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Data travels; how to make labels stick?
|
||||
|
||||
Links to the [Privacy](../Drafts%20and%20Ideas/Privacy.md) issue of [Data Provenance](Data%20Provenance.md) .
|
||||
Links to the [Privacy 1](Privacy%201.md) issue of [Data Provenance](Data%20Provenance.md) .
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,11 @@
|
|||
I foresee different user modes for AuditGlue:
|
||||
|
||||
- Guided implementation: the novice user is taken step by step through the process of setting up the ISMS, including the identification of risks and the definition of controls. There is a lot of content (text, animations, video's) explaining the process and ISO 27001.
|
||||
- Operational: aimed at users with ISO 27001 domain knowledge and experience. Offers traditional GRC software forms and dashboards
|
||||
- Audits: offers an interface to facilitate internal and external audits. Based on a matrix with the ISO 27001 clauses and controls, against columns for identified risks, defined controls, stated policies, implementation (planned or achieved), measurements, monitoring activities, and evaluation outcomes. Each cell contains (links to) proofs.
|
||||
|
||||
I foresee different user modes for AuditGlue:
|
||||
|
||||
- Guided implementation: the novice user is taken step by step through the process of setting up the ISMS, including the identification of risks and the definition of controls. There is a lot of content (text, animations, video's) explaining the process and ISO 27001.
|
||||
- Operational: aimed at users with ISO 27001 domain knowledge and experience. Offers traditional GRC software forms and dashboards
|
||||
- Audits: offers an interface to facilitate internal and external audits. Based on a matrix with the ISO 27001 clauses and controls, against columns for identified risks, defined controls, stated policies, implementation (planned or achieved), measurements, monitoring activities, and evaluation outcomes. Each cell contains (links to) proofs.
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
The choice between frontmatter and main text for internal links in Obsidian depends on the purpose and nature of the links:
|
||||
|
||||
**Put links in frontmatter when:**
|
||||
|
||||
- Creating structured metadata relationships (like tags, categories, or formal associations)
|
||||
- Building MOCs (Maps of Content) or index pages where you want clean, scannable link lists
|
||||
- Using plugins that specifically read frontmatter fields (like Dataview queries)
|
||||
- Creating "up" links to parent topics or broader categories
|
||||
- Setting up formal taxonomies or hierarchical relationships
|
||||
|
||||
**Put links in main text when:**
|
||||
|
||||
- The links are part of your natural writing flow and thinking process
|
||||
- You're making contextual connections that relate to specific ideas or sentences
|
||||
- The links represent your active thought process while writing
|
||||
- You want the links to be part of your reading experience when reviewing notes
|
||||
- The connections are discoveries or insights that emerged while writing
|
||||
|
||||
**Hybrid approach:** Many Obsidian users combine both methods. For example, you might put formal category links in frontmatter (`parent: [[Project Management]]`) while keeping contextual, thought-based links in the body text where they naturally arise during writing.
|
||||
|
||||
The main text approach tends to be more organic and supports the "thinking in writing" philosophy that many note-takers prefer, while frontmatter links are better for systematic organization and plugin automation. Consider your primary use case: if you're building a knowledge system for later querying and analysis, lean toward frontmatter structure. If you're thinking through ideas and making connections as you write, embed them naturally in your text.
|
||||
|
|
@ -4,8 +4,8 @@ A vulnerability is a weakness that exposes an asset to possible compromise. Weak
|
|||
|
||||
|
||||
See also:
|
||||
- [Assets](../Sparks/Assets.md)
|
||||
- [Risks](../Sparks/Risks.md)
|
||||
- [Assets](..//Assets.md)
|
||||
- [Risks](..//Risks.md)
|
||||
- [Threat](../📚️%20Literature%20notes/Threat.md)
|
||||
- [Vulnerability Disclosure Policy](Vulnerability%20Disclosure%20Policy.md)
|
||||
- [Dealing with a reported application vulnerability Log4j](Dealing%20with%20a%20reported%20application%20vulnerability%20Log4j.md)
|
||||
Loading…
Add table
Add a link
Reference in a new issue