Diff v1 → v2
v1: bot legacy · 2026-07-28T06:36:36Z
v2: bot legacy · 2026-07-28T06:37:40Z
# Security Baseline: NSM Grunnprinsipper & EU Regulation > **When to use it:** when you need to know what "secure enough" actually means for a > Norwegian or EU-facing product — which regulation bites, when, and which concrete > engineering controls satisfy it. Reach for it when scoping security work, answering a > customer security questionnaire, preparing for CRA or NIS2/digitalsikkerhetsloven, adding > an SBOM, writing a vulnerability disclosure policy, or deciding how much hardening a - > service warrants. Complements [[Red Team: Four Adversaries, Kill-Chain or It's Locked]], + > service warrants. Complements [[Red Team|Red Team: Four Adversaries, Kill-Chain or It's Locked]], > which attacks a system — this one tells you what to build in the first place. Two different things get called "security requirements": **frameworks** that tell you what good looks like, and **law** that tells you what you must do or be fined. Keep them apart. NSM's grunnprinsipper are the former; CRA and NIS2 are the latter. ## What actually applies to you | Regime | Who | Status / dates | Teeth | |---|---|---|---| | **NSM grunnprinsipper** v2.1 | Anyone; written for critical-function operators | Guidance, June 2024. Not law — but the basis sector regulators build on | None directly; cited in contracts and audits | | **Digitalsikkerhetsloven** | Norwegian essential/important entities | In force **1 Oct 2025** (implements NIS1) | Supervisory | | **NIS2** (via digitalsikkerhetsloven) | ~5 000 Norwegian entities, up from ~600 | NIS2-adapted amendments scheduled **1 Jul 2026**, registration deadline **1 Oct 2026**, sector audits from ~mid-2027 | Up to **4 %** of global turnover; ~3 MNOK cap for public bodies | | **Cyber Resilience Act** | Anyone placing "products with digital elements" on the EU market — including software | Reporting obligations **11 Sep 2026**; full obligations **11 Dec 2027** | Up to **€15 M or 2.5 %** of global turnover | | **GDPR** | Personal data | In force | Up to €20 M / 4 % | | **DORA** | Financial entities and their ICT providers | In force Jan 2025 | Sector supervisory | ⚠️ **Verify the NIS2 date before you rely on it.** Norway is EEA, not EU, so NIS2 must be incorporated into the EEA agreement before Norwegian implementation. That incorporation was still pending in mid-2026 and the 1 July 2026 target has slipped before. Check [nsm.no](https://nsm.no/) for the current position rather than trusting a table — including this one. The trap worth naming: **CRA scope is much wider than people assume.** It is not an IoT law. Commercially supplied software is a "product with digital elements". If you ship a SaaS product into the EU with any downloadable or on-premise component, assume you are in scope until a lawyer says otherwise. ## The engineering baseline — NSM's 21 principles Four categories, 21 principles, 118 measures. The value is the ordering: you cannot protect what you have not mapped, and category 1 is where almost everyone is weakest. ### 1. Identifisere og kartlegge | # | Principle | What it means in a repo | |---|---|---| | 1.1 | Kartlegg styringsstrukturer, leveranser og understøttende systemer | A written service catalogue: what this system does, who owns it, what it depends on | | 1.2 | Kartlegg enheter og programvare | Dependency inventory — this is your **SBOM**, and it is also a CRA obligation | | 1.3 | Kartlegg brukere og behov for tilgang | Documented roles and what each may reach | ### 2. Beskytte og opprettholde | # | Principle | Concrete control | |---|---|---| | 2.1 | Ivareta sikkerhet i anskaffelses- og utviklingsprosesser | Security in the SDLC: threat model at design, review gate before merge | | 2.2 | Etabler en sikker IKT-arkitektur | Segmentation, least privilege between tiers, no flat networks | | 2.3 | Ivareta en sikker konfigurasjon | Hardened, reproducible config as code; **secure by default** | | 2.4 | Beskytt virksomhetens nettverk | Deny-by-default ingress/egress | | 2.5 | Kontroller dataflyt | Know and constrain what leaves the system | | 2.6 | Ha kontroll på identiteter og tilganger | MFA, scoped tokens, no shared accounts, revocation that works | | 2.7 | Beskytt data i ro og i transitt | TLS everywhere, encryption at rest, managed keys | | 2.8 | Beskytt e-post og nettleser | SPF/DKIM/DMARC, CSP and security headers | | 2.9 | Etabler evne til gjenoppretting av data | Backups **you have restored from**, offline copy | | 2.10 | Integrer sikkerhet i prosess for endringshåndtering | Every change reviewed, logged, revertible | ### 3. Oppdage | # | Principle | Concrete control | |---|---|---| | 3.1 | Oppdag og fjern kjente sårbarheter og trusler | Automated dependency + container scanning, patch SLA | | 3.2 | Etabler sikkerhetsovervåkning | Structured audit logging with retention | | 3.3 | Analyser data fra sikkerhetsovervåkning | Alerts a human actually sees; logs nobody reads are theatre | - | 3.4 | Gjennomfør inntrengingstester | Periodic pentest — see [[Red Team: Four Adversaries, Kill-Chain or It's Locked]] | + | 3.4 | Gjennomfør inntrengingstester | Periodic pentest — see [[Red Team|Red Team: Four Adversaries, Kill-Chain or It's Locked]] | ### 4. Håndtere og gjenopprette | # | Principle | Concrete control | |---|---|---| | 4.1 | Forbered virksomheten på håndtering av hendelser | A runbook naming who decides, who communicates, who fixes | | 4.2 | Vurder og klassifiser hendelser | Severity scale mapped to legal reporting clocks | | 4.3 | Kontroller og håndter hendelser | Contain → eradicate → recover, with evidence preserved | | 4.4 | Evaluer og lær av hendelser | Blameless post-mortem feeding back into controls | That last one is the [[The Compounding Layer|compounding layer]] applied to security: an incident you do not learn from you have merely survived. ## CRA: the obligations that land on engineers Most CRA compliance is paperwork owned by someone else. Four parts are yours. **1 — SBOM.** Annex I Part II requires a machine-readable SBOM covering **at least top-level dependencies**, kept current for the entire support period. No format is mandated; use CycloneDX or SPDX, both of which market surveillance authorities recognise. ```bash # Generate in CI, attach to every release artifact — not a one-off document syft dir:. -o cyclonedx-json > sbom.cdx.json grype sbom:sbom.cdx.json --fail-on high ``` The SBOM requirement lives inside the *vulnerability-handling* rules, which tells you the intent: it is an operational tool for answering "am I affected?" in minutes, not a document you file. If yours cannot answer that question, it is not doing its job. **2 — Secure by default.** The product ships with a secure configuration and a minimised attack surface, and can be reset to its original state. No default credentials. Nothing sensitive on by default. Debug endpoints off in production builds. **3 — Vulnerability handling as a lifecycle.** Remediate without undue delay, test and review regularly, and *publish* information about fixed vulnerabilities. A coordinated disclosure policy and a monitored contact are part of the obligation: ``` /.well-known/security.txt Contact: mailto:security@example.com Policy: https://example.com/security-policy Preferred-Languages: no, en Expires: <ISO-8601, keep it in the future> ``` **4 — The reporting clocks.** From **11 September 2026**, actively exploited vulnerabilities and severe incidents must be notified: | Deadline | What | |---|---| | **24 hours** | Early warning | | **72 hours** | Full notification | | **14 days** | Final report, after a corrective measure is available | Twenty-four hours is a *detection* requirement disguised as a reporting one. If you cannot tell that you are being exploited, the clock is already running and you do not know it. This is why 3.2/3.3 above are not optional. ## Verification: OWASP ASVS 5.0 Frameworks say what to achieve; ASVS gives you testable requirements. Version 5.0.0 (May 2025) is ~350 requirements across 17 chapters, up from 286 across 14, with passwords realigned to NIST SP 800-63, post-quantum considerations added, and outdated practices removed. - **L1** — deliberately lowered entry bar. The first layer of defence; where to start. - **L2** — standard practice for anything holding real data. **This is the default target.** - **L3** — high assurance, for systems where compromise is severe. Pick a level, write it in the constitution, and make it a review dimension rather than an annual audit. "We follow ASVS" with no level named means nothing. ## The recipe: what to actually add ```bash # Supply chain — in CI, on every build syft / cdxgen → SBOM, attached to the release grype / trivy / osv → fail the build on known-exploitable gitleaks → secrets, on pre-commit AND in CI cosign → sign artifacts, verify at deploy # Runtime TLS everywhere · deny-by-default egress · scoped short-lived tokens structured audit log: who, what, when, from where — with retention security headers + CSP · SPF/DKIM/DMARC on the sending domain # Paper that engineering owns /.well-known/security.txt · coordinated disclosure policy incident runbook with the 24h/72h/14d clocks written into it restore-tested backups, with the date of the last successful restore ``` ## Gotchas **Backups you have never restored are not backups.** Principle 2.9 says *gjenoppretting* — recovery — not *sikkerhetskopiering*. Record the date of the last successful restore drill; if it is blank, treat the control as failed. **Do not conflate NSM grunnprinsipper with compliance.** They are excellent engineering guidance and they are not law. Following all 118 measures does not make you NIS2-compliant, and being NIS2-compliant does not mean you followed them. Track the two separately. **The 24-hour CRA clock starts at awareness, not at triage.** "We were still investigating" is not a defence. Decide in advance who is authorised to file an early warning on incomplete information — that decision made at 02:00 during an incident is the wrong time. **Scope creep is a real risk here, in both directions.** Regulation is the one area where [[The Restraint Principle: YAGNI for Agents|restraint]] does *not* apply to safety controls — input validation, error handling, authorization, and audit logging are load-bearing. But it absolutely applies to compliance *machinery*: a bespoke policy-management system for a five-person team is over-building. Buy the boring thing or use a checklist. **Security theatre passes audits.** Logs nobody reads, an SBOM generated once and committed, a disclosure address routing to an unmonitored inbox — all of these satisfy a checkbox and none of them work. The test for every control: *what would tell us it failed?* ## See also - - [[Red Team: Four Adversaries, Kill-Chain or It's Locked]] — adversarial validation of what this baseline builds + - [[Red Team|Red Team: Four Adversaries, Kill-Chain or It's Locked]] — adversarial validation of what this baseline builds - [[The Compounding Layer]] — incident learnings that become enforced rules - [[Rails Production Playbook]] — deny-by-default conventions in a concrete stack - [NSM grunnprinsipper for IKT-sikkerhet](https://nsm.no/regelverk-og-hjelp/grunnprinsipper/) — the source, v2.1 (June 2024) - [Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) and [CRA reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) — European Commission - [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) — v5.0.0, May 2025