Zero Trust

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

------------------------------
Philip Griffiths
Head of Business Development
NetFoundry
------------------------------

Philip, can you clarify what you mean by "they have opted for technology that flips our technology, specifically networking, approaches on their head'.  I am not challenging this, just the meaning did not come through clearly enough to be disambiguous. 

Of course your point about authenticate after access is very relevant.  In order to address IIOT/IOT cybersecurity, initial network layer authentication, by one means or another, is essential.  And with thousands of small device protocols proliferating, authentication must come prior to allowing an IOT device access to a network.  Because once a well designed piece of code is in the network, there are enough rat holes for it to find its way with unintended consequences.  I know I don't need to tell you that, however it does seem to have escaped the notice of many people.  

Best Regards

------------------------------
Nya Murray
Director
Trac-Car

Original Message:
Sent: Jun 26, 2023 04:30:08 AM
From: Philip Griffiths
Subject: Zero Trust definition - do we need to update it??

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

------------------------------
Philip Griffiths
Head of Business Development
NetFoundry
------------------------------

Yes Nya, they have adopted an open source technology which implements authenticate-before-connect, zero trust connectivity. I wrote a blog today on how its a game-changing, using the MOVEit hack as an example - https://www.linkedin.com/feed/update/urn:li:activity:7079418976472059904/.

Chatting to someone in CSA on DM, I will take a stab at writing a more explicit definition on ABC to see what people think. I 100% agree with your point about IoT/IIoT. It makes me think of a hack (I cannot remember the name) on an SDK of a Chinese SW vendor, which included a TCP stack being deployed into camera vendor HW which had an exploit. I remember thinking, if only the SDK included a ZT overlay using ABC, the exploit could not occur from the internet. Further, recent noise has been made about trusting cameras from China... how about if the camera was shipped with a ZT overlay so you could block all outbound FW ports except to your ZT overlay network... even if a backdoor exists, it cannot connect to C&C or exfiltrate data.

Philip, can you clarify what you mean by "they have opted for technology that flips our technology, specifically networking, approaches on their head'.  I am not challenging this, just the meaning did not come through clearly enough to be disambiguous. 

Of course your point about authenticate after access is very relevant.  In order to address IIOT/IOT cybersecurity, initial network layer authentication, by one means or another, is essential.  And with thousands of small device protocols proliferating, authentication must come prior to allowing an IOT device access to a network.  Because once a well designed piece of code is in the network, there are enough rat holes for it to find its way with unintended consequences.  I know I don't need to tell you that, however it does seem to have escaped the notice of many people.  

Best Regards

------------------------------
Nya Murray
Director
Trac-Car

Original Message:
Sent: Jun 26, 2023 04:30:08 AM
From: Philip Griffiths
Subject: Zero Trust definition - do we need to update it??

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

------------------------------
Philip Griffiths
Head of Business Development
NetFoundry
------------------------------

For messages/notifications coming directly from IOT devices to a cloud service, all network protection on e.g. firewalls and antiDDOS, and of course the Ziti network authentication that your technology offers is a valuable addition to the arsenal.  Other tools are field level data encryption, mutual certificate authentication, and adoption of device level identity verification, including MFA.  I believe that all of these methods are required to address the fact that people have not understood that if you let something into the network, it is far too late to authenticate at the application layer, unless the information is unclassified and very network segmented.

I have been thinking about the additional capabilities of IPV6.  For some time now I've been convinced that a new industry standard definition of Single Packet Authentication, with some kind of ubiquitous validation, using the additional capabilities of the IPV6 packet, would be useful.  I have been too busy to go any further than that in my thinking.  I don't believe there is a one size fits all, because every network cybersecurity prevention method I've looked at has flaws for determined hackers, particularly the well resourced ones.  I'm glad you brought up the topic, and if everyone has an open minded approach, I think there is room for trying to develop a standard that can be adopted by vendors and suppliers. Definitely multi-layering for IOT would provide more security.  Let's see if anyone else who has a deep technical knowledge is interested in addressing this topic. Not one for learners, however I am sure there are some experts out there who have views.  :)   Nya.

Yes Nya, they have adopted an open source technology which implements authenticate-before-connect, zero trust connectivity. I wrote a blog today on how its a game-changing, using the MOVEit hack as an example - https://www.linkedin.com/feed/update/urn:li:activity:7079418976472059904/.

Chatting to someone in CSA on DM, I will take a stab at writing a more explicit definition on ABC to see what people think. I 100% agree with your point about IoT/IIoT. It makes me think of a hack (I cannot remember the name) on an SDK of a Chinese SW vendor, which included a TCP stack being deployed into camera vendor HW which had an exploit. I remember thinking, if only the SDK included a ZT overlay using ABC, the exploit could not occur from the internet. Further, recent noise has been made about trusting cameras from China... how about if the camera was shipped with a ZT overlay so you could block all outbound FW ports except to your ZT overlay network... even if a backdoor exists, it cannot connect to C&C or exfiltrate data.

Philip, can you clarify what you mean by "they have opted for technology that flips our technology, specifically networking, approaches on their head'.  I am not challenging this, just the meaning did not come through clearly enough to be disambiguous. 

Of course your point about authenticate after access is very relevant.  In order to address IIOT/IOT cybersecurity, initial network layer authentication, by one means or another, is essential.  And with thousands of small device protocols proliferating, authentication must come prior to allowing an IOT device access to a network.  Because once a well designed piece of code is in the network, there are enough rat holes for it to find its way with unintended consequences.  I know I don't need to tell you that, however it does seem to have escaped the notice of many people.  

Best Regards

------------------------------
Nya Murray
Director
Trac-Car

Original Message:
Sent: Jun 26, 2023 04:30:08 AM
From: Philip Griffiths
Subject: Zero Trust definition - do we need to update it??

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

------------------------------
Philip Griffiths
Head of Business Development
NetFoundry
------------------------------

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

------------------------------
Philip Griffiths
Head of Business Development
NetFoundry
------------------------------

I don't know that we need to update the definition unless there's something that contradicts SDP guidance, which I don't think  there is. 
While it's probably debatable, I'm thinkin that "user, device, app and transaction must be continually verified" includes the notion of authentication (verification) before allowing a connection. This said, there's certainly room for further elaborating what it all means, best practices, etc. in other documents and forums (e.g. Network, Identity and Device Pillar research and training materials). For example the identity pillar workgroup is formulating guidance on use of certificates (and mutual TLS) in ZT and the Networks Pillar team is starting to formulate what their guidance should look like (leveraging previous SDP work of course).  I'd encourage you to get involved with one or both of those workgroups to provide inputs such as this.

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

Philip, I think what is missing is the requirement to provide a context for common Zero Trust scenarios, because one size does not fit all.  It bothers me that people want to be prescriptive of Zero Trust, because it is not a process rules based workflow. I think the NIST ZTA publication has set the stage scene, and they are quite humble in their descriptions, declining to be definitive, rather using language such as 'strategy' and 'tenets', which I think is smart.  You and I know that for resources to be properly secured, the perimeter is a movable fence.  I think a lot of people who don't have a network orientation are still thinking in concepts of wire and boxes with a fixed perimeter.  This requires definition.  Anything with an internet connection is part of a global network.  And that is where the real risk lies.  Defining network endpoints and securing them is a great start, but it is not infallible.  An SDP approach to networking attempts a set of security practices to secure a network. However SDP is in its infancy. Today, there is no such thing as a secure network perimeter, because cybersecurity depends on the quality of not only network interconnections, but also all the current practices of transport, session, and application in the OSI sense.  To think there is a  set of rules and definitions for Zero Trust is misguided. Most people are carrying baggage of past technical paradigms, and there are a lot of unconscious misconceptions relating to old concepts prior to virtualization and the cloud revolution.  The CSA Zero Trust initiative is no exception. So I don't think we need new definitions, I think we must recognize that to be too prescriptive is a case of reductio ad absurdum. I hope the IEEE initiative that is commencing takes a strategic architecture view rather than a process oriented engineering POV. And I agree. The reason I raised the need to write a paper on ZT with the old SDP group way back in 2019 is because so many suppliers are claiming ZT credentials without understanding the complex dependencies between Device, Network, Identity, Application Workflow and Data, and these fields of knowledge are categoric points of view, not siloes, of course one transaction, one packet, one message, triggered by an event, touches each capability..  I try to think through every cybersecurity scenario, from both build time and runtime, from a risk context perspective.    My view is to describe ICT/IOT security from a services view, information processing driven by complex event handling.  We inherited this approach from radio technologies developed during WW2 allied with encoding that is becoming increasingly cryptic.  I would like to go back to basics before we constrain the technology future to earlier models of compute, network and data capability. Particularly because it is clear that AI and ML are based on mathematical models that at root remain unchanged.  Now we can  run them in parallel with huge amounts of CPU, which provides more accuracy. However this is still behavioral conjecture that takes the past and projects it into the future.  We can do better than that, and we are rethinking computing in view of probability theory and quantum mechanics.  Interesting times ahead. Best, Nya.

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

Agreed. I like NIST 800-207 too, but I am less of a fan of 800-207a (for Cloud-Native) as I believe it becomes too prescriptive and leaves out a lot of core and important aspects for cloud-native environments (I can share some more notes on this if anyone is interested, I have already sent them to NIST). Some people think of networking as wire and boxes with a fixed perimeter; someone yesterday was telling me ZTN was all about 'bouncers', to which I heavily disagreed. 

You are 100% correct with, "Anything with an internet connection is part of a global network.  And that is where the real risk lies." As Grace Hopper said, " The most dangerous phrase in the language is 'we've always done it this way". Just because we have accepted this risk for decades and thrown things on the public internet that shouldn't be, doesn't mean we should continue doing it. This is why SDP and ABC with no inbound ports are crucial. Even better, if we assume with breach and that networks are "considered compromised and hostile", we should move to a model where we do not trust the underlying networks at all, including WAN, LAN and even host OS network. This can only be done by moving the perimeter to the app, using SW, with SDP and ABC. This should be open source so that anyone and everyone can do it. This must touch on all the pillars, as you mention, to reduce overall risk. 

Philip, I think what is missing is the requirement to provide a context for common Zero Trust scenarios, because one size does not fit all.  It bothers me that people want to be prescriptive of Zero Trust, because it is not a process rules based workflow. I think the NIST ZTA publication has set the stage scene, and they are quite humble in their descriptions, declining to be definitive, rather using language such as 'strategy' and 'tenets', which I think is smart.  You and I know that for resources to be properly secured, the perimeter is a movable fence.  I think a lot of people who don't have a network orientation are still thinking in concepts of wire and boxes with a fixed perimeter.  This requires definition.  Anything with an internet connection is part of a global network.  And that is where the real risk lies.  Defining network endpoints and securing them is a great start, but it is not infallible.  An SDP approach to networking attempts a set of security practices to secure a network. However SDP is in its infancy. Today, there is no such thing as a secure network perimeter, because cybersecurity depends on the quality of not only network interconnections, but also all the current practices of transport, session, and application in the OSI sense.  To think there is a  set of rules and definitions for Zero Trust is misguided. Most people are carrying baggage of past technical paradigms, and there are a lot of unconscious misconceptions relating to old concepts prior to virtualization and the cloud revolution.  The CSA Zero Trust initiative is no exception. So I don't think we need new definitions, I think we must recognize that to be too prescriptive is a case of reductio ad absurdum. I hope the IEEE initiative that is commencing takes a strategic architecture view rather than a process oriented engineering POV. And I agree. The reason I raised the need to write a paper on ZT with the old SDP group way back in 2019 is because so many suppliers are claiming ZT credentials without understanding the complex dependencies between Device, Network, Identity, Application Workflow and Data, and these fields of knowledge are categoric points of view, not siloes, of course one transaction, one packet, one message, triggered by an event, touches each capability..  I try to think through every cybersecurity scenario, from both build time and runtime, from a risk context perspective.    My view is to describe ICT/IOT security from a services view, information processing driven by complex event handling.  We inherited this approach from radio technologies developed during WW2 allied with encoding that is becoming increasingly cryptic.  I would like to go back to basics before we constrain the technology future to earlier models of compute, network and data capability. Particularly because it is clear that AI and ML are based on mathematical models that at root remain unchanged.  Now we can  run them in parallel with huge amounts of CPU, which provides more accuracy. However this is still behavioral conjecture that takes the past and projects it into the future.  We can do better than that, and we are rethinking computing in view of probability theory and quantum mechanics.  Interesting times ahead. Best, Nya.

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

------------------------------
Philip Griffiths
Head of Business Development
NetFoundry
------------------------------

Can we call it "Dynamic Trust" instead? There is no "zero trust" in Zero Trust. You are still making a dynamic decision whether to trust a connection / transaction as authenticated and authorized. 

The original definition should have mentioned "Zero Implicit Trust"

I was thinking recently about the CSA Zero Trust definition that no user or asset is implicitly trusted ... and that each user, device, app and transaction must be continually verified. I wonder to myself, should we update it, particularly to adopt some of the ideas in SDP, while taking it to its logical conclusion?

Specifically, I have recently worked with a few people in high-security use cases who have said "Most zero trust products/vendors are providing rubbish solutions". Instead, they have opted for technology that flips our technology, specifically networking, approaches on their head. In their words, this technology, which is open source, is the best implementation of NIST 800-207.

In my opinion, the root of the problem is that we have come to accept networking as being Authenticate/Authorise-After-Connect. I believe this is mad. When vendors have CVEs/zero days etc, or misconfiguration is made, businesses get exploited. Resources can be exploited from the network, for example, denial of service attacks. If we look at MOVEit, it took place as a SQL injection that could be done on resources exposed to the public internet. In tandem with insecurity, it also causes large complexity in managing FW rules, ACLs, black/whitelisting etc.

I believe, we need to take ZT and SDP to their logical conclusion - Authenticate/Authorise-Before-Connect (or ABC). Use certificate-based identity to authenticate endpoints to an overlay network (with potential secondary authentication checks). If these requirements are passed, we tell the endpoint what services/apps they can access. If not, the endpoint has absolutely no access to resources. 

It sounds simple, but it's a profound change. It's like making our resources invisible to attackers while massively reducing complexity - No more dependencies on IP addresses, public DNS, port forwarding, VPNs, complex FW rules, ACLs etc. Had MOVEit implemented ABC, then the SQL injection attack could not have done in the first place across the public internet.

Any thoughts on how we can differentiate fo this and if the definition would benefit from updating?

------------------------------
Philip Griffiths
Head of Business Development
NetFoundry
------------------------------