Introducing the Dynamic AccessIDTM Network & Toolkit
Zero Trust is a catchphrase that is growing in use and is employed by cybersecurity product and service vendors to promote their offerings. Zero Trust, as the concept implies, requires that users aren’t allowed any access to anything until they authenticate who they are Attaching the moniker “Zero Trust” usually misleads buyers into a false sense of security (no pun intended). True Zero Trust requires that no one is allowed into the network without rigorous authentication at the machine and user level along with the use of true multi-factor authentication.
Using VPNs and Firewalls to establish Zero Trust allows the user to connect to services (e.g., a mail server). Firewalls can be set up to ban IPs and services can be set up to figure out which IP addresses are good or bad. Connections can be vetted with existing authentication schemes (eg. Active Directory etc.) IT teams believe they achieve “Zero Trust” by implementing a VPN set up to only let the users on the network who have the authorized VPN client and the appropriate keys using protocols that are vetted at the firewall. However, unauthorized users who clone the VPN client and steal the keys, using key-stroke recording malware and the like, are already in the network so they can access the mail server and then determine other user names and passwords to perform malicious acts such as DDoS, credential theft, etc. The extorted user names and passwords allow one to access other services (eg. SharePoint) that are not on the mail server network segment. Unauthorized users that gain access to the network can access other shared services using hacking techniques. With the VPN and Firewall approach exposure is unlimited, that is to say, that allowing network access BEFORE rigorous authentication enables users (good and bad) to have access to all the services; not login, but actual access.
Allowing access to the network changes with real “Zero Trust”; as the concept implies that users aren’t allowed any access to anything until they authenticate who they are. Today’s “Zero Trust” implementations are like putting up a wall with multiple doors and allowing people to come and pick a lock on the door. We are then just relying on the locks. It is much better to put up a fence around and authenticate people before they get to the doors. One does want to see who is knocking, but one doesn’t want the threat to do bad things – like pick the locks. Authentication BEFORE access is the essence of real ”Zero Trust.”
The problem is exasperated in the cloud where the responsibility is shared between the cloud provider and the cloud user. Cloud users typically want to use their own identity provider that users authenticate to which means that all the traffic is backhauled from the cloud to the network that the identity provider is on. Users want to use their own devices and vetting the devices is complicated with no control over network operations. Business owners now have the added headache of not having much visibility into the security of connections to their applications but still carry all the responsibility.
Zero Trust Orchestration Case Study
The Dynamic AccessIDTM Network & Toolkit funded by DHS is designed to provide more than a “Zero Trust” network. It adds the dynamic capability to BOYD (bring your own device) and BYOC (bring your own credential). The Dynamic AccessIDTM Network is designed to be much like the bank’s ATM Network, and to onboard systems, users and devices dynamically and only set up for the particular crisis that is led by – presumably – an Incident or Emergency Manager.
The de-centralization and devolution of 3rd party access control to the system owners, device control to IT and identity control to the user is a key aspect of the dynamic approach. Another key aspect of for the dynamic approach is to minimize the efforts to engage during a crisis.
Securing information sharing among First Responders (Just like banks do statically)
Elements of Dynamic Federation for First Responders
Benefit to DHS
DHS could work with GSA to create a program similar to FIPS 140-2 or FedRAMP to encourage systems (eg. physical systems) to participate in preparation for national, state and local incidents.
To learn, more check out Waverley Labs who worked closely with the Cloud Security Alliance to develop the commercial SDP specification and has since delivered the industry’s first open source SDP. .