Notes added
This commit is contained in:
parent
6e5af94e46
commit
edf18ed518
3 changed files with 66 additions and 0 deletions
25
Corpus/InfoSec-concepts-MoC-Suggestions-for-improvement.md
Normal file
25
Corpus/InfoSec-concepts-MoC-Suggestions-for-improvement.md
Normal file
|
|
@ -0,0 +1,25 @@
|
||||||
|
[Claude Chat](https://claude.ai/share/a27adc09-6f72-4951-b20d-ce6b94b23f92):
|
||||||
|
|
||||||
|
OK, clear picture. Here's the honest assessment:
|
||||||
|
|
||||||
|
**What you have** is a manually curated, vault-specific MoC — essentially a flat link directory organized loosely by concept cluster. It's useful as a navigation aid but it's not a taxonomy, it has no definitions, inconsistent depth across topics, and it'll drift out of sync as your vault grows.
|
||||||
|
|
||||||
|
**Standardized alternatives worth knowing about:**
|
||||||
|
|
||||||
|
**NIST IR 7298 (Glossary of Key Information Security Terms)** Probably the closest drop-in. It's a freely available, regularly revised glossary of ~1000 terms, directly derived from NIST SP 800-x publications and FIPS standards. Flat A–Z with authoritative definitions. No topology though.
|
||||||
|
|
||||||
|
**ISO/IEC 27000:2018** You already reference ISO 27002 Annex A in your frontmatter. ISO 27000 is specifically the vocabulary and definitions standard for the whole 27k family. If you're building ISO27DIY content, this is the canonical source. It's not free, but you presumably have it.
|
||||||
|
|
||||||
|
**NIST Cybersecurity Framework (CSF) 2.0 — Taxonomy** Organizes concepts into Functions → Categories → Subcategories. Gives you a proper hierarchy rather than a flat list. Better as a _structure_ than a dictionary.
|
||||||
|
|
||||||
|
**MITRE ATT&CK / CAPEC** Only relevant if you go deep on threat modeling — not general InfoSec concepts.
|
||||||
|
|
||||||
|
**The real question:** what is this MoC _for_ in your context?
|
||||||
|
|
||||||
|
If it's internal navigation in your vault → keep it, it's fine for that, no standard replaces it.
|
||||||
|
|
||||||
|
If it's meant to underpin the ISO27DIY corpus/knowledge base → you should anchor definitions to ISO 27000 + NIST IR 7298, and restructure around the CSF taxonomy or the ISO 27001/27002 clause structure instead of this ad hoc list.
|
||||||
|
|
||||||
|
If it's for end-user-facing content (glossary in the platform) → NIST IR 7298 is the most defensible, plain-English source to derive from.
|
||||||
|
|
||||||
|
Which of those is the actual use case?
|
||||||
|
|
@ -5,6 +5,8 @@ Related:
|
||||||
tags:
|
tags:
|
||||||
- type/MoC
|
- type/MoC
|
||||||
---
|
---
|
||||||
|
[[InfoSec-concepts-MoC-Suggestions-for-improvement]]
|
||||||
|
|
||||||
[Assets](/Assets.md)
|
[Assets](/Assets.md)
|
||||||
[NIST Asset Types](📚️%20Literature%20notes/NIST%20Asset%20Types.md)
|
[NIST Asset Types](📚️%20Literature%20notes/NIST%20Asset%20Types.md)
|
||||||
[Asset lifecycle](📚️%20Literature%20notes/Asset%20lifecycle.md)
|
[Asset lifecycle](📚️%20Literature%20notes/Asset%20lifecycle.md)
|
||||||
|
|
|
||||||
39
Corpus/Sparks folder cleanup suggestions.md
Normal file
39
Corpus/Sparks folder cleanup suggestions.md
Normal file
|
|
@ -0,0 +1,39 @@
|
||||||
|
# Sparks folder cleanup suggestions
|
||||||
|
## The core problem
|
||||||
|
|
||||||
|
The Sparks folder is a landing zone that was never cleaned up. It has at least four distinct categories mixed together:
|
||||||
|
|
||||||
|
1. **ISO 27001/27002 content** — notes that belong in the Corpus proper, tagged with `isotags` and a `notetype`
|
||||||
|
2. **Platform/product notes** — ISO27DIY-specific stuff (blurbs, prompts, design docs, partner lists)
|
||||||
|
3. **Tooling/dev notes** — Supabase, Rasa, LLM prompts, Bolt.new, Git, etc.
|
||||||
|
4. **Clutter/stubs** — single-link notes, raw dumps, files that are clearly just placeholders
|
||||||
|
|
||||||
|
Several notes also have zero frontmatter at all.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Suggested steps
|
||||||
|
|
||||||
|
**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.
|
||||||
|
|
||||||
|
**Step 2: Separate non-ISO content**
|
||||||
|
|
||||||
|
Notes like `Bolt.new prompt.md`, `Blurbs.md`, `Rules to get better code.md`, `SurveyJS.md`, `slot_config_schema.sql` etc. have no place in an ISO 27001 corpus. Move them to a `iso27diy-corp/Product` or `iso27diy-corp/Dev` folder. Don't delete anything yet.
|
||||||
|
|
||||||
|
**Step 3: Add frontmatter to `promote` candidates**
|
||||||
|
|
||||||
|
For notes that are ready to move, add the required frontmatter: `notetype`, `language`, `status: active`, and `isotags`. The `_Corpus-metadata.md` gives you everything you need. Start with the most mature notes — `Shadow IT risks`, `Ransomware`, `Risk management`, `Access Control` are obvious candidates.
|
||||||
|
|
||||||
|
**Step 4: Move promoted notes to the right Corpus location**
|
||||||
|
|
||||||
|
Once frontmatter is in place, move them to the appropriate subfolder in Corpus (MoCs, Literature notes, etc. depending on `notetype`). Notes without a clear home yet stay in Sparks until you know where they belong.
|
||||||
|
|
||||||
|
**Step 5: Deal with stubs last**
|
||||||
|
|
||||||
|
Notes like `Awareness.md` (single wikilink, nothing else) and `Governance.md` (three links, no content) are either index notes waiting to grow, or orphans. Decide then: expand them or merge them into a MoC.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
The subfolders `About iso27diy`, `C4 model for software development`, `Context, Strategy, and Leadership`, and `ISMS` probably need the same triage treatment — want me to check what's in those too before you start?
|
||||||
Loading…
Add table
Add a link
Reference in a new issue