blob: fb7b9654d97f80a8727082d3ef018da7d3d29148 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
= PLantUML Diagrams for GnuPG Key Signing and Reproducible Builds (SLSA4)
0.0.2
:pdf-page-size: A3
:pdf-page-layout: landscape
// tag::inhalt[]
I am trying to model implicit and explicit trust in Zero Trust Architecture diagrams for Threat Modeling.
So I need to bring together the Blue Team/White Hat perspective and the Red Team/Black Hat stuff.
== DFD: Keysigning Simple
image::100-GnuPG-Keysigning-DFD.png[]
== SEQ: Keysigning with ID check and WoT
image::100-GnuPG-Keysigning-SEQ-KSP-WoT.png[]
== NetBSD RelEng Attack STRIDE
The ISO Image is built, signed and uploaded to the WWW server, as well as the Signature file and checksums.
Evil Black Hat hacks the webserver, and swaps the ISO image for a manipulated one with a valid Signature.
The manipulated Signature verifies the fake-integrity of the manipulated ISO image, but not the authenticity.
image::300-NetBSD-RelEng-STRIDE.png[]
== Supply-chain Levels for Software Artifacts
=== SLSA L1
A simple threat model for SLSA Level 1:
image::200-ThreatModel-SLSA1-DownloadSig.png[]
=== Reproducible Builds SLSA L4
Modeling Trust, Trust Anchors and Boundaries and Attack Vectors for SLSA4:
The whole process draws heavy inspiration from those implemented by NetBSD, Debian, NixOS and the Tor Browser!
. general goals
.. Build process produces identical artefacts (bit-for-bit) from the same source and inputs
.. independent parties can rebuild and verify outputs match the original -> verify freedom from insider threat!
.. require a deterministic build environments
.. all build steps, dependencies, and tooling are tightly controlled and audited
. security goals:
.. detect tampering in build pipelines or artefacts
.. prevents hidden backdoors introduced during compilation or packaging by a malicious insider
.. ensure integrity of supply chain, dependencies and build tools
.. enables independent verification without trusting the original builder
.. drastrically reduce insider and supply chain attack surface
. Zero Trust:
.. never trust, always verify!
.. verifiable evidence (rebuild && compare)
.. eliminates implicit trust in build pipeline
.. build system considered untrustworthy
.. combine with signed artefacts and attestation frameworks for full supply chain integrity
==== The whole implementation
* Trust Boundaries: Rectangles
* Attack Vectors: Red Arrows
image::201-ThreatModel-SLSA4-ReproducibleBuilds.png[]
* Trust Anchor: Green Anchor
image::202-ThreatModel-SLSA4-ReproducibleBuilds-TrustAnchor.png[]
=== Motivation/Business Layer: Risk/Security Overlay
image::203-SLSA4-ReproducibleBuilds-L1-Motivation.png[]
// end::inhalt[]
|
