This is part two of a two part series on Zero Trust Architecture.
Zero Trust Monitoring
In Part One of this series, we discussed in detail what Zero Trust Architecture is. We learned what it can and can’t do for us and the importance of securing our Zero Trust Architecture through strong security controls. We concluded that these controls should be proactively monitored to ensure our Zero Trust Architecture is operating as intended and as securely as possible. In part two, let’s take a closer look at what a “Zero Trust Monitoring” program might look like.
As part of Zero Trusting our Zero Trust, we shouldn’t assume our configurations and controls are secure even after applying them. We should instead “never trust, always verify” by continuously monitoring our environments to ensure that everything is working as intended. In fact, monitoring is recommended by CISA in their “Cloud Security Technical Reference Architecture” and includes notable benefits.
Verify Zero Trust controls
First of course, is a verification of our Zero Trust Architecture and associated controls. We may have implemented a secure access policy, but is it truly enforcing multi-factor and blocking insecure authentication protocols? Monitoring may show us that a control isn’t working as intended and enable us to take corrective action to improve our Zero Trust Architecture.
Threat detection and forensic investigations
Monitoring can identify threats that may not otherwise have been surfaced through traditional alerting. Something may simply just “not feel right” but did not itself trigger any obvious alarms. Monitoring enables investigations into suspicious or malicious activities. The collected data isn’t just useful for deep dives into security incidents, it can also be useful for troubleshooting and operational monitoring.
Compliance requirements
Many organizations, depending on size and industry, are required by law or other compliance standards to perform security monitoring. At the very least, most organizations are required to maintain audit logs for a defined period.
Starting from zero
If you’re just starting out with monitoring, you’ll want to prioritize what assets to monitor. While you may want to eventually monitor everything, it might not be feasible initially. With an asset inventory, you can assign criticality to each asset and then, based on your budget and team size, you can more effectively prioritize your efforts.
Despite what vendors would have you believe, you don’t need to buy the shiniest, most expensive product to achieve a Zero Trust Architecture and effective monitoring. There are low-cost options available for just about any part of a larger Zero Trust monitoring program. As you mature your program, you can scale up your monitoring as needed.
Aside from the technology components, having a team with strong technical backgrounds and a solid understanding of the business will help you get the most of your platforms. They’ll be able to optimally design, build, and engineer your Zero Trust Architecture with secure controls and your monitoring capabilities so as to provide visibility without introducing negative business impacts.
As with any project, you can decide to do it yourself or outsource some or all the effort. However, from experience, you won’t want to completely outsource everything, as you will know your environment the best and be able to provide the most accurate context when identifying issues and investigating alerts if you are involved in the monitoring. That said, it can be helpful to have an outside team get you started and avoid common pitfalls.
Nuts and bolts
So, what goes into Zero Trust monitoring? Is it a one-week project? One-month? The vendors tell me if I just buy their solution, it will magically implement Zero Trust Architecture and monitoring all for me. Would they lie?
Turns out, it’s a bit more involved in that. We’ll outline a few high-level steps that will guide you through the overall process. Note that each of these steps and their related tasks can easily become their own projects depending on your organization’s size and available resources.
Level 1: Asset Inventory
You can’t start monitoring if you don’t know what to monitor in the first place. Just as with implementing Zero Trust Architecture, having an accurate asset inventory is critical in determining what should be monitored for security incidents. Having an accurate asset inventory doesn’t just mean knowing what devices you have, it also means:
- Having an up-to-date infrastructure diagram that details core components.
- Identifying both enterprise-owned and non-enterprise-owned (BYOD) devices.
- Knowing where your critical files (PII, customer data, intellectual property) are stored.
Level 2: Logging
You’re likely already logging in some form, perhaps your firewalls or Windows event logs. If you want to know how your Zero Trust Architecture is performing, you’ll want logs that tell you what’s truly happening. Are you really enforcing multifactor everywhere? Are insecure authentication protocols actually blocked?
From experience, you’ll want to have logs from the following:
Firewalls and network devices
- Threats detected
- URLs visited
- Connection logs
- HTTPS decryption logs
- VPN logs
In the cloud-and-remote-first world we live in, collecting firewall and network device logs may seem less than useful. However, in many environments, employees continue to use a VPN, meaning a good amount of network traffic is still routed through corporate infrastructure and can be easily logged.
EPP / EDR
- Malware alerts
- File events
- Process events
- Network events
Endpoint protection, detection, and response platforms collect a wealth of information in addition to blocking malicious threats. With many employees now working on laptops from remote locations, the EPP/EDR solution often provides the most or only visibility into an employee’s computing activities. Thus, this is valuable data that is critical to any successful Zero Trust Architecture and monitoring program. File, process, and network events give us insight into possible malicious activity, regardless of the user’s location.
OS (Windows / macOS / Linux)
- Windows Event logs
- macOS Apple Unified logs
- Linux auditd logs
Don’t forget the traditional operating system logs that, when tuned and configured properly, can provide great insight into a system’s activities. This is especially helpful if you don’t already have an EPP / EDR platform. It works even better as a complement to EPP / EDR data, enabling you to correlate and contextualize event data.
Cloud / SaaS
- Microsoft 365
- Google Workspace
- Azure / AWS / GCP
- Website
Often forgotten are the variety of cloud systems that organizations now depend on. We generally think it’s the cloud provider’s responsibility to perform all the securing and monitoring for its customers. Typically, while the cloud provider is responsible for the security and monitoring of the underlying infrastructure, the customer is often responsible for the security or configuration of the application or service itself.
Due to this disconnect, many organizations don’t know or don’t realize that cloud platforms, whether it’s Microsoft 365 or AWS, generate detailed audit logs that can be used to effectively monitor and verify the Zero Trust controls that have already been implemented.
Custom applications
You may have custom applications that generate logs you’ll want to collect. These are especially important if these custom applications contain critical or sensitive data that you want to protect.
The larger your organization, the more challenging it becomes to not only enable logging for every system but to also ensure you’re enabling the right kind of logging. Turning everything on is almost always not a great idea, and conversely turning on too little is unhelpful when an incident inevitably occurs. Use the asset inventory from step 1 to help determine where to enable logging and what types of events you need to capture. You’ll also likely need to work with the administrators of each of these systems to configure and tune the logging output — be patient, each of these can easily become their own large project.
Level 3: SIEM
Once you have logging set up, you could simply search or export these logs out from each individual platform, system, or application and perform periodic queries or investigations on them as needed. However, this would be incredibly inefficient and ineffective and more reactive than proactive.
Instead, you’ll want to send those logs to a security information and event management (SIEM) platform that can centralize the collection, correlation, and contextualization of all your disparate logs. We won’t cover the specifics on evaluating and choosing a SIEM platform, as that is a talk in itself.
That said, at a high level, a SIEM helps to quickly identify suspicious behavior and enables you to respond to an incident more efficiently by having a single system to run queries and perform monitoring from. You can start with its built-in rules and as you mature, start adding your own custom queries, rules, and dashboards.
Years ago, SIEMs were often viewed as a luxury that only the largest of organizations needed and could even afford. Today, there are SIEMs available for just about any budget and with the amount of logging and telemetry generated even in small networks, they are no longer a nice-to-have when it comes to Zero Trust Architectures and monitoring.
Level 4: Threat intelligence
Finally, with your asset inventory, logging, and SIEM all set up, you’ll want to enhance your monitoring capabilities with threat intelligence. You’ll likely have access to some general form of threat intelligence with your network and security infrastructure, including firewalls and endpoint protection platforms. As you mature your Zero Trust monitoring program, the goal is to use threat intelligence that is specific for your industry or ideally, your organization.
Most organizations might start with widely available open-source threat feeds and then pay for a commercial threat intelligence service. More sophisticated programs might set up a dedicated honeypot network masquerading as critical infrastructure to gather organization-specific intelligence.
Anytime you identify malicious or suspicious activity on your networks, the artifacts of the subsequent investigation, including IPs, hashes, URLs, and domains, are forms of threat intelligence. Feed these back into your SIEM to identify similar malicious activity in the future.
Conclusion
In this two-part series, we learned what Zero Trust Architecture is and isn’t and that our Zero Trust controls should also apply to the Zero Trust Architecture itself — we shouldn’t blindly assume that it’s working exactly as we designed. Not only should we secure our assets, we should also secure our Zero Trust platforms. That means doing the basics of hardening, patching vulnerabilities, and auditing our Zero Trust systems. On top of this, we should implement a Zero Trust monitoring program that enables us to verify our Zero Trust controls, detect threats, perform in-depth forensic investigations, and meet compliance requirements. We can start small by first creating an asset inventory, then enabling logs, standing up a SIEM, and then finally adding threat intelligence. As we continue to mature, we can scale our monitoring as needed to ensure our Zero Trust Architecture continues to perform as expected.
We hope this talk inspires you to start or improve your own Zero Trust Architecture and Monitoring programs.
References
- Executive Order 14028 on Improving the Nation’s Cybersecurity https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
- NIST SP 800-207: Zero Trust Architecture https://csrc.nist.gov/publications/detail/sp/800-207/final
- M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
- CISA: Cloud Security Technical Reference Architecture https://www.cisa.gov/sites/default/files/publications/CISA%20Cloud%20Security%20Technical%20Reference%20Architecture_Version%201.pdf
