Is zero trust security an approach, architecture or new tech?
Yes—and how to unravel it for your organization
Lately, the topic of zero-trust Security (ZTS) is one that we at CyberMSI have been discussing quite a bit with CIO/CISOs. In case you’re not familiar with ZTS, you can reference how the industry—and Microsoft in particular—defines ZTS here.
Like so many of the other major shifts in tech before, this too comes in different flavors:
- Architecture-centric using design principles such as defense-in-depth, least-privilege, separation of concerns, etc.
- Tech-centric driven by newer or revamped cybersecurity products, especially ones using AI, to address environments with significant legacy infrastructures operating in tandem with cloud
- User-centric relying on a combination of policy management, user-training and governance to address weak links in cyber defenses
With this common understanding in place, let’s review some prevalent misconceptions about ZTS:
- ZTS is an IT/cybersecurity initiative and you don’t need to secure C-suite and business sponsorship
- Conversely, ZTS is overly difficult, time consuming, and probably expensive, so there’s no point in making a case for it
- Achieving zero trust security for every device, identity, app and data store should be the target
- ZTS is an out-of-the-box solution with one-size fits all
Below are the key lessons we’ve learned in working with customers on ZTS implementations during the last 18 months that you need to be mindful of as well.
1. ZTS reduces business risk:
Failing to position ZTS as a strategy to reduce business risk means lack of executive sponsorship, which is critical to any large-scale change at an organization. You can align business and cybersecurity priorities by developing business threat models to show the expected improvements in both qualitative and quantitative measures of risk management by adopting ZTS. Refer to Microsoft Security Development Lifecycle if you need to jump start this exercise.
You also need to develop a realistic enablement roadmap/plan to achieve both short and long-term wins over a period of 3-12 months. Remember that ZTS requires strong stakeholder expectation and change management, so invest the time upfront to launch the planning phase.
2. Operating cybersecurity controls in dual mode:
Prioritizing cloud apps and infrastructure while opportunistically enabling legacy IT as part of overall cloud adoption for ZTS will ensure that you can show quick wins while minimizing complexity and potential business disruptions.
3. Federating identity protection and governance:
Most organizations typically use an app-based approach to governing identities, which doesn’t work with ZTS. Instead you should federate your identity protection and governance in an organization-wide identity platform for capabilities such as single sign-on (SSO), multi-factor authentication (MFA), role-based access control (RBAC), just-in-time (JIT) access via explicit approval (“4-eyes principle”) to name a few controls while allowing individual apps to manage user’s actions at a granular level within the app.
4. Policy-driven, risk-based controls:
If there’s a killer use case for AI in cyber, this is it. You need to ensure that your ZTS solution enables defining and enforcing cyber policies when risky user sign-in or anomalous behavior is detected. Essentially you define—often declaratively—the various conditions such as user groups, actions (e.g. accessing an app with sensitive data), and type of devices to determine the different cyber controls that the ZTS solution will enforce at any given point in time (e.g. requiring password reset or blocking access all together).
5. Sensitive data labeling and protection:
Data protection takes on a whole new meaning in the context of ZTS because it’s truly your last line of defense. Data classification and labeling is either missing or very immature especially at small and midsize organizations, so this is one area that you’ll want to adequately address when adopting ZTS. Good news is that you can automatically classify and label a vast portion of sensitive information using products like Microsoft 365.
6. Mobile app and device management:
Device-based risk evaluation is a key feature of ZTS. However, you need to focus not only on whether a user has a company or personal device. You need to manage access to your cloud services and data from applications running on these devices as well. As such, your ZTS solution needs to vary the stringency level of cyber controls in runtime beyond the common ones such as anti-virus/malware/etc. This is known as using risk-adapted controls.
7. Threat analytics and automated response:
Your ZTS product needs to provide both activity-level (e.g. which users took what actions when) and resource-level (e.g. a Windows endpoint launched an unknown process) visibility and the ability to automate incident response using threat analytics.
8. Software-defined, policy-driven network segmentation:
One of the biggest flaws in traditional network-based security has been lack of segmentation and the inability to prevent lateral movement. As a result, some proponents of ZTS believe in minimal reliance on network security controls. However, these controls are required for many cyber threats (think DDoS) that simply can’t be mitigated by an identity-based perimeter or elsewhere for that matter. That’s the reality. Effective ZTS solutions implement SW-defined network segmentation by using policies based on workload, data, and threat types.
In closing, consider these three questions as you reflect on how best to approach ZTS at your organization:
- Have you been educating your business executives and end users on how ZTS can help to lower business risk posed by cybersecurity attacks?
- Have you created the business threat models, defined enablement plans, developed a solution blueprint, and conducted a pilot to enable ZTS and validate the business case?
- Have you formalized the executive sponsorship and governance model to effectively manage ZTS because it takes time to implement?