-
Notifications
You must be signed in to change notification settings - Fork 521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zero trust paper #1395
base: main
Are you sure you want to change the base?
Zero trust paper #1395
Conversation
Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
✅ Deploy Preview for tag-security ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…nto zero-trust-paper
Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dont believe this paper is ready for TOC liaison approval at this time. There are several formatting issues with the paper (such as inconsistent new lines) and the content of the paper could benefit from a significant amount of brevity in many areas that repeat or rephrase prior content. There are several areas of content that make leaps in logic or dont quite convey the meaning of a particular topic. Additionally, several sections don't provide the reader with new or meaningful guidance and examples in order to apply Zero Trust to their environments using cloud native tooling.
I have not read the paper in its entirety due to the number of areas that would greatly benefit from additional refinement by the authors. The paper is sorely needed, and i appreciate the time and effort by the contributors in putting this draft together for an initial review and feedback.
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
|
||
Contrary to what the name might suggest, the real world application of “Zero Trust” is far more nuanced than simply *trusting nothing*. The Zero Trust defense strategy assumes that the internal network is not to be trusted. This contrasts with a perimeter-based defense, which is designed to construct a trustworthy internal network. Instead, we can introduce measures to evaluate trustworthiness, then use such evaluations to control the network communications and its connected devices. | ||
|
||
While many of the well-worn concepts behind Zero Trust apply to *any* system, there remains a gap with regards to discussing Zero Trust from a Cloud Native perspective. This document seeks to codify the philosophy alongside an ideal design for implementing it in a Cloud Native system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would argue that none of the concepts in Zero Trust are well-worn and that it is still a challenge to apply them to any system, thus why there remains gaps in approach Zero Trust with cloud native in mind. If it were so well-worn, this paper would have been published in 2022 and many government agencies would not be releasing their ZT strategies in 2024.
While many of the well-worn concepts behind Zero Trust apply to *any* system, there remains a gap with regards to discussing Zero Trust from a Cloud Native perspective. This document seeks to codify the philosophy alongside an ideal design for implementing it in a Cloud Native system. | |
Zero Trust concepts have been around for a while, however there continues to be a gap in how industry can effectively adopt and apply them across all systems and applications in use, Cloud Native is no exception. This document seeks to codify the philosophy alongside a recommended design for implementing Zero Trust principles in Cloud Native systems and applications. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would argue that the concepts are well-worn, while I agree that it is still a challenge to apply them to any system :)
I.e. Many of the concepts defining how to build a ZTA are here with us for quite a while - not suggesting that we have the tools and mechanisms to implement them.
At the same time, I am also perfectly ok with the suggested change - so I would vote to accept it as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheFoxAtWork are you OK with us keeping it as is, or you like this to be changed per your suggestion?
BTW I tried to find you at the conference to say "hello", but no luck...
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
|
||
The authors have compiled their experience and research findings into a set of principles and approaches. While many of the concepts herein are a distillation of past publications, extending those findings has led to a new proposal to standardize the generation and utilization of “Confidence Levels” as a data type. Confidence Levels quantify the trustworthiness of entities within a system, allowing for more dynamic and responsive security measures. | ||
|
||
Confidence Levels can be produced by “Active Observers,” a previously unnamed category of tools. Active Observers continuously monitor and analyze the security-related attributes and behaviors of entities in the system to quantify trustworthiness. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps it is later, but this doesnt detail why active observers are being recommended, it just introduces the concept. Why are these beneficial specifically in cloud native for achieving Zero Trust and not in the broader technology ecosystem? Do they fill a un-noted gap that is critical to ZT implementation? Highly recommend adding in the illuminating moment that drives us towards active observers here so the reader is prepared for its more robust introduction later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheFoxAtWork, We are not stating or suggesting that active observers are beneficial specifically in cloud native for achieving Zero Trust - these are beneficial in the broader technology ecosystem.
We do state that “Active Observers,” are a previously unnamed category of tools - i.e. we help name and better define such tools and help explain how they are being used. There are mentioning of such capabilities in previous ZT docs, we take this one step further.
<td>Assume a Breach | ||
</td> | ||
<td>Every Image Includes Vulnerabilities | ||
</td> | ||
</tr> | ||
<tr> | ||
<td>2 | ||
</td> | ||
<td>Assume a Breach | ||
</td> | ||
<td>Every Service is Vulnerable | ||
</td> | ||
</tr> | ||
<tr> | ||
<td>3 | ||
</td> | ||
<td>Assume a Breach | ||
</td> | ||
<td>Every Service will be Exploited | ||
</td> | ||
</tr> | ||
<tr> | ||
<td>4 | ||
</td> | ||
<td>Assume a Breach | ||
</td> | ||
<td>The Cluster Network is Hostile | ||
</td> | ||
</tr> | ||
<tr> | ||
<td>5 | ||
</td> | ||
<td>Assume a Breach | ||
</td> | ||
<td>Clients will Send Malicious Requests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The heading/titling structure here does not match with that of Always Verify, which has a secondary phrase enhancement. Recommend either eliminating the enhancing phrase or adding an enhancing phrase to the Assume a Breach. It doesnt appear to add substantial value however and given the table is quite simple in its content, you can increase its value by providing a more clear example of what is meant or pose questions to the reader to have them consider the context:
Assume a breach: Clients will send malicious requests. In the case a client begins sending malicious requests, are you servers capable of authenticating the client and verifying its authorization to connect prior? In the event that a valid, authorized client is compromised, are your servers capable of validating the input in the event it is malformed? what about sending too many requests? Do you have detection rules in place to identify unusual behaviour by clients?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would further recommend linking each item in the table to the corresponding H3 below in the event a reader wishes to jump down into that content.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems repetitive to spell out each one in the table and also in the below H3 sections.
I believe the second column help connect the principles to the NIST Tenet which is part of covering where these principles come from.
@mrsabath can we manually add links to the table?
And do we also need it in the doc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we can do them manually, but we have to make sure that any changes in this document are also reflected in the Google Doc that would be used for rendering the PDF, so I suggest ONLY ONE PERSON does the updates in both places, otherwise we will get out of sync quickly. I am happy to do them, but I need to know exactly what to update. Since I am on KubeCon too, the edits might be delayed...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mrsabath
We continue to rely on you for making the changes and keeping the two documents inline.
Where a reviewer made a specific edit suggestion, I am trying to help by reading the text with the suggestion and adding a thumb up for support.
Where a reviewer commented without a specific edit suggestion, I am trying to either add my own specific edit suggestion or commenting that it may be preferable not do a change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realized what you did @davidhadas and thank you for that. I really appreciate your help with managing the edits. I think I merged all the suggestions that were approved by you unless they require some further explanation or investigation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like this one: #1395 (comment)
Are we keeping it as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the text on that comment can stay as is, but lets see if others will also see a need for change and what that change may be.
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
### 3. Every Service Will be Exploited | ||
|
||
Organizations must adopt the perspective that any cloud native deployed service is susceptible to exploitation at some point. When deploying a service, it is essential to assume that it may be exploited through various vectors, including internal malware infiltration, insider misuse, or unauthorized access to credentials or control systems. | ||
|
||
This assumption necessitates a comprehensive and proactive approach to security, wherein continuous monitoring and rapid response mechanisms are integral components. By acknowledging the inevitability of exploitation attempts, organizations can better prepare to detect and mitigate threats promptly, minimizing potential damage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm reading through these and trying to understand why we've chosen to talk about these challenges at a high level. We're not detailing anything about zero trust to the benefit of the reader.
for example, in the event a service is exploited, what specific capabilities, features, and tooling do we as cloud native security professionals recommend? Runtime detection tools assist in identifying if a host or workload was exploited. Tools that provide remote attestation have the ability to measure the integrity of files to detect if it has been tampered with.
these are specific recommendations we should be providing throughout this area of the paper that provide value to the reader.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We cover this later in the paper -
Here we spell out the principles to follow (adding one more detail to the overall ZT mindset the reader should maintain) - we suggest that the reader would consider that each and every service running on the CN may be exploited.
Later in the doc we discuss how should the reader detect such a situation and what should happen next.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TheFoxAtWork - Will you be ok with keeping this text as is given my comment above?
Co-authored-by: Emily Fox <33327273+TheFoxAtWork@users.noreply.github.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…-trust-whitepaper.md Co-authored-by: Emily Fox <33327273+TheFoxAtWork@users.noreply.github.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…-trust-whitepaper.md Co-authored-by: Emily Fox <33327273+TheFoxAtWork@users.noreply.github.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…-trust-whitepaper.md Co-authored-by: Emily Fox <33327273+TheFoxAtWork@users.noreply.github.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…-trust-whitepaper.md Co-authored-by: Emily Fox <33327273+TheFoxAtWork@users.noreply.github.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
Update the approvals metadata heading Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
Replace *open-source* with *open source* Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…-trust-whitepaper.md Co-authored-by: Emily Fox <33327273+TheFoxAtWork@users.noreply.github.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
community/resources/zero-trust-whitepaper/v1/cloud-native-zero-trust-whitepaper.md
Outdated
Show resolved
Hide resolved
…-trust-whitepaper.md Co-authored-by: David Hadas <david.hadas@gmail.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…-trust-whitepaper.md Co-authored-by: David Hadas <david.hadas@gmail.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…-trust-whitepaper.md Co-authored-by: David Hadas <david.hadas@gmail.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…-trust-whitepaper.md Co-authored-by: David Hadas <david.hadas@gmail.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…-trust-whitepaper.md Co-authored-by: David Hadas <david.hadas@gmail.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
…-trust-whitepaper.md Co-authored-by: David Hadas <david.hadas@gmail.com> Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
Signed-off-by: Mariusz Sabath <mrsabath@gmail.com>
Can we please get an update on where this is at? I know that some folkx were tied up with KubeCon but given that people should be well rested now, I'm keen to see what we can do to move this forward |
My understanding is that we have addressed most, if not all @TheFoxAtWork 's concerns and comments. |
Publishing CNCF Zero Trust White Paper.
This PR replaces the original #1229 as requested by TAG Security reviewers.
The Markdown is based on Google Doc: https://docs.google.com/document/d/18w243JXhGxNgJk0SS1gT-LWUw29F8KFrc1D1F9dvfhw/edit?usp=sharing
CNCF issue: #950
This is still a draft. I just started the conversion and it requires more Markdown work and cleanup