Practical Ways to Implement Identity-centric ZTNA

In a post-pandemic world, securing BYOD and addressing remote access requests from literally anywhere, while also quickly ensuring secure connectivity from endpoints to applications and services residing in campus, remote, and cloud environments proved just how inadequate most traditional enterprise architectures were at building the enhanced remote capabilities enterprises now require.

Recognizing the need to address this shortfall, NIST (the National Institute of Standards and Technology) introduced in August 2020 their final version of “Zero Trust Architecture,” or “ZTA,” an identity-centric security architecture that replaced the traditional network perimeter-based enterprise security model. ZTA placed human and machine identities at the heart of security policy creation and established enterprise access controls and policies based on identity and other assigned attributes. What are the implications of moving to this new model? What, specifically, is needed in practical, operational terms to support “identity-centric” ZTA and to move one’s entire architecture to the Zero Trust model?

Node-centric is a practical way to implement identity-centric Zero Trust architecture

A “Node” simply refers to a point that is connected both logically and physically to a given network. Once a device with a MAC address appears within an enterprise’s network environment, it is assigned an IP address and becomes known, generically, as a Node.

Now, a Node can come with various attributes, such as device fingerprinting data – as in, for example, a device platform name. Until now, we have mainly utilized SNMP MIB, OID, and Nmap to acquire a device name along with other general identifiers, such as whether the Node is a Windows Server, an Android phone, a D-Link wireless camera, and so on. However, this kind of generic name is ultimately not very helpful in identifying and classifying a complex, hybrid workforce. Rather, we really need to acquire more detail about the device platform name, such as “Microsoft Windows Server 2012 R2 x64,” “Samsung Galaxy S6 mobile phone,” and “D-Link DCS-933L Wireless Network Camera” to distinguish these devices clearly and to be able to establish more granular access control. Nodes, then, allow us to acquire a rich and meaningful set of attributes for all connected devices.

According to NIST SP 800-207, to step up authentication requirements and implement a risk-based approach to security, access policies should ideally consider other factors as well, such as when was the device last used, current asset status, and environmental factors. What then are these required factors?

Required factors needed to implement Zero Trust access policies

Once you have acquired fully accurate device platform names, you’ll need to focus on the contextual data related to key business and risk factors, such as the following:
Business-related context factorsRisk-related context factors
· End of life (EOL)
· End of support (EOS)
· Manufacturer Business Information
· Manufacturer Location (Country)
· Common Vulnerabilities and Exposures (CVE)
for Platforms and Manufacturers
· Manufacturer Mergers & Acquisitions
· Industry News
Most importantly, one should be able to correlate fingerprinting data with contextual factors to support more granular access policies, detect where vulnerabilities may exist, and mitigate compromised devices in real time. In this manner, security practices can be extended to include the entire range of information available across all nodes involved in the network at hand, thus allowing for a truly holistic, node-informed security approach.

Genians Node-centric Zero Trust Network Access

Genians deploys a layer 2-based network sensor to identify and classify in real time all IP-enabled devices. No special integration is needed with network switches and wireless controllers in order for this sensor to do its job and to allow management of all endpoints. Further, one can establish “Node groups” by obtaining the various characteristics of connected Nodes in conjunction with Genians Device Platform Intelligence (DPI).

For instance, you may want to see any devices affected by Ripple20 (CVE-2020-11896 ~ 11914) and used by employees (developers) or guests during working hours or weekends. With Genians, you can easily create a “Node group” to classify devices to operate according to pre-established policies and report instantly on their actual behavior. You can then take appropriate action (policy enforcement) in response, such as immediately blocking device access, or enabling certain devices to have only limited access to the internet – while also sending the necessary notifications to network SOC teams and managers.

Genians provides over 600 conditions with the attributes needed to create the various Node groups necessary to meet one’s set of business requirements. Genians’ dynamic node-grouping technology, which correlates device-centric with user-centric data, will help you implement the identity-centric approach of Zero Trust architecture in a highly-practical manner. Cybersecurity professionals can accordingly make major technology stack decisions based on node-centric intelligence to optimize their cybersecurity investment as well as control risks more proactively.

Scroll to Top

We use cookies to help improve this website and enhance your browsing experience You can change your cookie settings at any time. • Privacy • Terms