From d02e1cd7c7b0fd6004993f40defa7b31e60ac9c2 Mon Sep 17 00:00:00 2001 From: "hubert.siwik" Date: Thu, 7 Nov 2024 12:14:35 +0100 Subject: [PATCH 1/5] Add a blog announcement for an updated Zero Trust paper Signed-off-by: hubert.siwik --- .../blog/zero-trust-new-paper-announcement.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 website/content/blog/zero-trust-new-paper-announcement.md diff --git a/website/content/blog/zero-trust-new-paper-announcement.md b/website/content/blog/zero-trust-new-paper-announcement.md new file mode 100644 index 000000000..c67fb8be8 --- /dev/null +++ b/website/content/blog/zero-trust-new-paper-announcement.md @@ -0,0 +1,19 @@ +--- +title: "An updated CNCF Zero Trust White Paper is looming" +date: 2024-11-07 12:00:00 +0000 +author: Hubert Siwik +--- + +What comes to mind when you think of Zero Trust security? Personally, I had a distorted understanding of this concept +until now, seeing it as an approach that blindly assumed that security, once granted, was eternal or... at least valid +until the next release. It roughly presumed that access policy wouldn't be violated, the network perimeter wouldn't be +breached, and a vulnerable pod wouldn't be exploited. Up until now… + +After reading the Zero Trust paper by the CNCF security team, my understanding of this philosophy has radically changed, +and my previous view shifted into something I'd call "Limited Trust." For some, the CNCF paper introduces, and for +others reminds, of a notion of total lack of confidence, regardless of the request's source. It enforces +a "trust nothing" policy, relying on metrics that are constantly evaluated and adjusted according to the current context. +Stolen credentials of a benign user or an exploited Kubernetes instance will no longer be a foothold for significant damage, +as non-standard activity is expected to be quickly identified and neutralised. This is the key takeaway from the document. + +To learn how to actually implement this, immerse yourself in the reading. From d81625f9b5a8509ba776a38df37c6f13790a47d0 Mon Sep 17 00:00:00 2001 From: Hubert Siwik Date: Fri, 8 Nov 2024 07:51:58 +0100 Subject: [PATCH 2/5] Update website/content/blog/zero-trust-new-paper-announcement.md Co-authored-by: Eddie Knight Signed-off-by: Hubert Siwik --- website/content/blog/zero-trust-new-paper-announcement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/content/blog/zero-trust-new-paper-announcement.md b/website/content/blog/zero-trust-new-paper-announcement.md index c67fb8be8..b596368e9 100644 --- a/website/content/blog/zero-trust-new-paper-announcement.md +++ b/website/content/blog/zero-trust-new-paper-announcement.md @@ -9,7 +9,7 @@ until now, seeing it as an approach that blindly assumed that security, once gra until the next release. It roughly presumed that access policy wouldn't be violated, the network perimeter wouldn't be breached, and a vulnerable pod wouldn't be exploited. Up until now… -After reading the Zero Trust paper by the CNCF security team, my understanding of this philosophy has radically changed, +After reading the TAG Security Zero Trust white paper, my understanding of this philosophy has radically changed, and my previous view shifted into something I'd call "Limited Trust." For some, the CNCF paper introduces, and for others reminds, of a notion of total lack of confidence, regardless of the request's source. It enforces a "trust nothing" policy, relying on metrics that are constantly evaluated and adjusted according to the current context. From cc16094ce761e9ee65ae94865160eaccf8553f37 Mon Sep 17 00:00:00 2001 From: Hubert Siwik Date: Fri, 8 Nov 2024 07:52:07 +0100 Subject: [PATCH 3/5] Update website/content/blog/zero-trust-new-paper-announcement.md Co-authored-by: Eddie Knight Signed-off-by: Hubert Siwik --- website/content/blog/zero-trust-new-paper-announcement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/content/blog/zero-trust-new-paper-announcement.md b/website/content/blog/zero-trust-new-paper-announcement.md index b596368e9..1d97df63c 100644 --- a/website/content/blog/zero-trust-new-paper-announcement.md +++ b/website/content/blog/zero-trust-new-paper-announcement.md @@ -1,5 +1,5 @@ --- -title: "An updated CNCF Zero Trust White Paper is looming" +title: "A reader's perspective on the latest Zero Trust White Paper" date: 2024-11-07 12:00:00 +0000 author: Hubert Siwik --- From f0fbf4c8bbdc71d8ce3550dcd55b6dcdd091621e Mon Sep 17 00:00:00 2001 From: Hubert Siwik Date: Fri, 8 Nov 2024 07:53:09 +0100 Subject: [PATCH 4/5] Update website/content/blog/zero-trust-new-paper-announcement.md Co-authored-by: Eddie Knight Signed-off-by: Hubert Siwik --- website/content/blog/zero-trust-new-paper-announcement.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/website/content/blog/zero-trust-new-paper-announcement.md b/website/content/blog/zero-trust-new-paper-announcement.md index 1d97df63c..c44bdb95f 100644 --- a/website/content/blog/zero-trust-new-paper-announcement.md +++ b/website/content/blog/zero-trust-new-paper-announcement.md @@ -10,8 +10,8 @@ until the next release. It roughly presumed that access policy wouldn't be viola breached, and a vulnerable pod wouldn't be exploited. Up until now… After reading the TAG Security Zero Trust white paper, my understanding of this philosophy has radically changed, -and my previous view shifted into something I'd call "Limited Trust." For some, the CNCF paper introduces, and for -others reminds, of a notion of total lack of confidence, regardless of the request's source. It enforces +and my previous view has shifted into something closer to _Limited_ Trust. The emphasis I took away +was on the notion of total lack of confidence, regardless of the request's source. It enforces a "trust nothing" policy, relying on metrics that are constantly evaluated and adjusted according to the current context. Stolen credentials of a benign user or an exploited Kubernetes instance will no longer be a foothold for significant damage, as non-standard activity is expected to be quickly identified and neutralised. This is the key takeaway from the document. From 82c0dd431ba66acb986a2d247c54ccb2368bc36e Mon Sep 17 00:00:00 2001 From: Hubert Siwik Date: Fri, 8 Nov 2024 07:53:23 +0100 Subject: [PATCH 5/5] Update website/content/blog/zero-trust-new-paper-announcement.md Co-authored-by: Eddie Knight Signed-off-by: Hubert Siwik --- website/content/blog/zero-trust-new-paper-announcement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/content/blog/zero-trust-new-paper-announcement.md b/website/content/blog/zero-trust-new-paper-announcement.md index c44bdb95f..bef4c8294 100644 --- a/website/content/blog/zero-trust-new-paper-announcement.md +++ b/website/content/blog/zero-trust-new-paper-announcement.md @@ -14,6 +14,6 @@ and my previous view has shifted into something closer to _Limited_ Trust. The e was on the notion of total lack of confidence, regardless of the request's source. It enforces a "trust nothing" policy, relying on metrics that are constantly evaluated and adjusted according to the current context. Stolen credentials of a benign user or an exploited Kubernetes instance will no longer be a foothold for significant damage, -as non-standard activity is expected to be quickly identified and neutralised. This is the key takeaway from the document. +as non-standard activity is expected to be quickly identified and neutralised. To learn how to actually implement this, immerse yourself in the reading.