Zero-trust (ZT) a cyber security paradigm that moves the line of defense from a static, network-based perimeters to remote users, bring your own device (BYOD), and cloud-based assets that are not located within an enterprise-owned network boundary.
What is ZTA?
Traditionally, agencies and enterprise networks have focused on perimeter defense and authenticated users/identities were given access to a broad collection of resources, once authenticated. As a result, unauthorized “lateral” access within the environment became one of the biggest threats. A zero-trust architecture (ZTA) is an enterprise cybersecurity architecture designed to provide an end-to-end approach to resource and data security that encompasses identity (person and no-person entities), credentials, access management, operations, endpoints, hosting environments, and interconnecting infrastructure.
How Niyam implements ZTA?
We believe that ZTA implementation should be integrated with an IT modernization plan that blends incremental ZT principles, process changes and technology upgrades. Migrating an existing workflow to a ZTA will likely require a partial redesign. Enterprises may take this opportunity to modernize their legacy systems.
Steps to Implementing ZTA:
- Understand the full attack surface: The entities involved in ZTA could be person entities as well nonperson entities like service accounts that interact with the systems.
- Identify assets owned by the enterprise: We build the capability to quickly identify, categorize and assess all assets on enterprise-owned infrastructure. This also includes configuration management and monitoring to keep observe the current state of an asset.
- Identify Key Processes and Evaluate Risks: This involves creating a catalog of business processes, data flows and their relationships. Business processes that utilize cloud-based resources or are used by remote users are good candidates and would be a good measure of success for ZTA. Risks to consider are tradeoffs in performance, user experience and workflow fragility that may occur when implementing ZTA for a given business process.
- Formulating policies for ZTA candidate: After the process is identified, we identify all upstream resources (e.g. Identity management systems, databases, microservices), downstream resources (e.g. logging, security monitoring), and entities (e.g. person/non-person, service accounts) that are used or affected by the workflow. Then, in collaboration with the enterprise administrators, we determine the set of criteria or confidence level weights for resources used in the candidate business process. We adjust or tune this criteria to ensure that policies are effective but do not hinder access to resources.
- Identifying candidate solutions: Some deployment models are better suited for particular workflows, while some vendor solutions are better suited to some use cases than others. Here is a list of factors we consider:
- Does the solution require installation on client assets?
- Does the solution work entirely on premise?
- Does the solution provide means to log interactions for analysis?
- Does the solution provide support for different applications, services and protocols (e.g. web, secure shell (SSH) etc.) and transports (IPv4 and IPv6)?
- Does the solution require changes to subject behavior?
- Initial deployment and monitoring: Once the candidate workflow and ZTA components are chosen, then we implement the policies by using the selected components in an observation and monitoring mode at first. There may be instances where ZTA workflows coexist with non-ZTA workflows. This allows us to gain understanding of baseline asset and resource access requests, behavior and communication patterns. Once the baseline activity patterns for the workflow has been established, anomalous behavior can be more easily detected.
- Expanding the ZTA: As we gain more confidence with the refined workflow policy set, we enter the steady operational phase where network and assets are still monitored, traffic is logged, but responses and policy notifications are less frequent. At this stage we begin planning the next phase of ZT deployment, i.e., identify a candidate workflow and solution set. If a change occurs to the workflow, the operating ZTA should be reevaluated. Significant changes to the system like new devices, major updates to software and shifts in organizational structure may result in change to the workflow or policies.
For more information on our ZTA capabilities and how we can implement ZTA for your agency, please contact us at info@niyamit.com