There are many pedantic frameworks about applying zero trust principles to rein in exorbitant cyber defense costs. The zero trust concept can be simpler than you might realize. Consider the use of devices (PCs, servers), networks, and cloud infrastructure: for every action allowed, something could go terribly wrong that requires somebody to respond when it does. Again, every action allowed! Apply to this the mantra that made Tesla and SpaceX billions of dollars: “the best part is no part”. The most practical outcome from applying zero trust is reducing the volume of allowed activities to make protecting the enterprise easier.
Consider the Costs of Searching for Bad
The frequency and sophistication of cyber-attacks continue to grow annually. Enterprises spend much on many different tools and teams of specialists to combat cyber risks. That means monitoring vast amounts of activities for anomalies, mining numerous data systems in real-time, staffing experts to investigate what automated systems cannot handle, hiring more people to tune and maintain the tools, and then responding to incidents, if and when they are detected, using inevitably complex workflows. Volume and complexity beget chaos that makes scaling to the challenge require yet more staff and tools. More allowed activities, more cost; less allowed, reduces cost. That’s the more pragmatic gist of Zero Trust.
Zero Trust Frameworks Help Systematically Reduce Activities to Monitor
Different zero trust frameworks consist of at least five elements: Identity, Device, Network, Application Workload, and Data. Each element represents different means to reduce the volume of allowed enterprise activities that must be monitored for “bad”.
Imagine a server that anyone can interact with regardless of identity. Restricting such interactions to only those with the right identity reduces the number of activities to monitor. Limiting access to users passing a two-factor authentication challenge can reduce the volume even more by eliminating access to those with stolen credentials. We’re using controls to reduce activities volume and exposure.
The Network element restricts what communications are allowed based on origin, destination, and type, blocking all others. The more restrictions an ecosystem can impose, the more it can reduce activity volumes and resource exposures that require monitoring.
We can also restrict activities by what Data and what Application Workloads can be accessed by what Identities, Devices, Networks, and combinations of them.
Admission into networks or access to resources can be prohibited to Devices lacking specified compliance criteria (e.g., missing vulnerability patches, required security software, weak security settings, etc.).
The theme is simple. Fewer allowed activities and exposures means less to monitor with all those different tools run by teams of skilled personnel operating within layers of management trying to overcome the ensuing chaos to counter cyber attacks growing in sophistication and volume.
Most Zero Trust Frameworks have a Gaping Hole: The Apps within the Devices
Each Device (or endpoint) consists of numerous applications, which consist of one or more running computing processes. Any one process in any endpoint can be malicious. Most frameworks do not apply zero trust principles to those computing processes in each endpoint. Yet, enterprises spend considerable budgets on AV, EDR, NDR, XDR, SIEM, SOAR, and many others to mitigate risks ultimately originating from these computing processes within enterprise endpoints. For example, a user clicks something from an email, one or more malicious process result, the endpoint gets altered, credentials get stolen, malicious communications to other endpoints compromises others, the Windows domain gets compromised, data is stolen from cloud resources, and finally something eventually detects the intrusion and cyber teams respond. Such incidents can be avoided if zero trust principles are applied down to the computing processes within endpoints.
Instead, enterprises rely too heavily on detection technologies. AV and EDR are trying to tell bad from good files. EDR is also trying to tell bad from good behavior patterns. NDR analyzes network traffic to detect intruders. XDR is mining and fusing other data sources to detect what the other tools did not detect individually.
Most of these monitored activities originate at the endpoint. Snuffing them out at the beginning nullifies much downstream from where they began. Applying zero trust principles within each endpoint (i.e., device) does this. In other words, applying controls as to what is allowed and not allowed within endpoints reduces the volume of activities that need to be monitored within the endpoint, within the network surrounding the endpoint, as well as the monitoring for anomalies of the Identity, Application Workload, and Data elements (i.e., the rest of the enterprise cyber stack).
Zero Trust within Endpoints makes Detection Layers Better
Most of the activities that enterprise cyber defenses monitor ultimately originate from Windows platforms. No one cyber tool can retroactively make Windows platforms perfectly secure. The underlying Windows architecture was not designed with sufficient compartmentalization, among other things. AV/EDR are essential layers. But, they are not enough as malware headlines and enterprise cyber budgets suggest.
Linux is arguably more secure but its controls can be aptly described as access control list quagmires. Complexity is its own security risk. Thus, Linux endpoints contribute to what must be monitored.
Fortunately, the enterprise doesn’t need “perfect” nearly as much as it needs “better”, which means to have less to monitor. AV, EDR, XDR, and other detection-based tools are overwhelming cyber defenders with alerts that require investigation and response. Applying zero trust principles within endpoints can reduce all of that considerably.
Tools that Apply Zero Trust Principles within Endpoints
You are looking for tools that apply some form of application control and/or containment. Some restrict what applications can operate (pre-execution), and some of these restrict what applications can do (peri-execution). These tools protect the enterprise from its own applications as well as those maliciously secreted onto endpoints.
Some vendors of pre-execution application control tools provide the “allow” lists for what applications can launch, sparing users from doing so. These vendor provided “allow lists” work well for OS and mainstream applications but struggle with non-mainstream applications.
Few application control tools include peri-execution features. Most vendors do not enable these features by default. Few vendors provide “allow” rules for what applications can do. Most of their subscribers do not actually use the peri-execution controls. They are too complex and policies must change too frequently to avoid “friction” with users and workflows.
AppGuard Uses Both Pre- and Peri-Execution Controls by Default, Used by All Subscribers
From the beginning, AppGuard avoided the complexities of other vendors and embraced simplifying abstractions. AppGuard combines three fundamental controls:
- Launch: Prohibit launches from risky folders or of dangerous OS utilities
- Containment: Prevent harm by restricting what risky applications may do
- Isolation: Only specific Apps may access or change critical data or settings
Combined, these three controls stop the activities necessary for hundreds of malware techniques. Consequently, AppGuard defeats malware attacks without having to recognize the malware itself, making it an essential complement to AV, EDR, XDR, and other detection-based tools. AppGuard blocks what the others miss or detect too late. Learn more about how AppGuard works and why AppGuard is the solution for your needs.