Where to Start Your Zero-Trust Journey
Zero-trust policy isn’t as easy as all those vendor emails in your spam folder would claim. This is due to organizational silos, the difficulty in identifying exactly what to protect, the fact that zero-trust must compete with other (sometimes higher) priorities, a lack of budget and the persistence of legacy technologies.
In a recent Optiv Security study, 100% of respondents said that zero-trust is a critical policy for mitigating risk, but less than a quarter of them have started adoption. This article is for that 100%.
What does the ideal “greenfield” use case look like—one that addresses each of those challenges?
● It addresses initiatives that are high priority and have monies already allocated
● It has a low chance of failure and high visibility
● It has clearly-defined parameters for what needs protection and who needs access
● It has a limited scope, which allows us to compartmentalize each use case
● It has compensating controls that readily deal with the limited legacy aspects
Starting With Third-Party Vendor Access
One of the most common use cases is third-party access. This is because, from the technology side, security architects and executives understand that poking holes in the perimeter and VPNs leaves the organization highly vulnerable to adversaries.
Technology is just one piece of the puzzle and represents the beginning of the process.
Contracting and Execution
Zero-trust should be treated as a policy that reflects specific relationships—and this principle applies to everything, not just vendor access. Organizations must pay as much attention to their access policies as infrastructure and implementation.
No user or device is inherently trustworthy, regardless of its location, history or status. And for external parties, you have even less control over devices and verifying identities. Job one is to incorporate zero-trust requirements into contracting and negotiation. Spell out all responsibilities, limitations and liabilities that let vendors do their job absent additional risk.
Include MFA, IAM and least-privilege access methods in the contract language. You may have the option for the cost of these technologies to be absorbed by your third-party partners. Remember that you need to plan for that capability as you select technology that allows these third parties to procure the technology individually while remaining under the umbrella of your project and security administration.
And since vendor contracts always include termination language, your contract must specify what data, devices, credentials, etc., will be destroyed or returned. Set the terms for completing and “certifying” those actions have been completed within a reasonable time.
Defining the Who, the What and How Much
Clearly defining the scope of vendor access is generally compartmentalized relatively easily–especially when compared to the complexities of your internal access policies. This is obvious but needs to be stated. Third-party access policies clearly define who has access, which specific resources they need access to, their responsibilities for protecting access and data and under what circumstances access is revoked.
“Who” means drilling down into the details. How many from their team will be accessing your data while under contract? Is it important to know who those employees are, their roles and the specific access each individual will need?
You’ve identified the activities your vendor will perform. Limiting the scope of your project to just third-party access makes the zero-trust framework easier to implement individual access. Best-in-breed technology allows you to:
● Deploy without making changes to your underlying network design
● Limit lateral movement (The simplest and most effective method is to make the devices invisible)
● Enforce “absolute least privilege” to users and devices (Tip: Mandate whitelisting versus blacklisting)
● Structure roles and rules so that configuration drift is kept to an absolute minimum
● Limit how and when specific ports and services are available
● Log management; both for users and system administrators
● Real-time device and user isolation/revocation/remediation without disabling or impacting underlying functions
Accountability to Standards and Best Practices
Holding third parties to the same level of security compliance as your organization may not always be realistic, if for no other reason than they may be smaller organizations without the resources and scale as you. That said, you don’t need to forsake the integrity of your security posture.
You’re likely already specifying audit requirements, authentication processes, update protocols and other controls. Adding the zero-trust “who/what/when/which” conditions to your contracts will not be met with much resistance given the increased awareness that cybersecurity has been given recently. Going back to how you structure licensing acquisition and selecting the right technology can go a long way toward minimizing the pushback you get from your supply chain.
Taking the First Step Toward Zero-Trust
The benefits of this approach will set you up for success. You are using an existing budgeted project for a high-priority need. At the same time, the narrow scope gives your team a baseline of experience that you can build upon as you expand zero-trust into other areas.
Your team wins. Your supplier-base wins. And your company wins.
