There’s a pervasive, false perception in contemporary politics. The candidate that advocates spending the most on something cares most about solving the problem. Today’s endpoint protection suites are similarly ranked. Those with the longer list of features are ranked higher. Similarly, like features are seldom compared one-to-one but are presumed little different among different suites. The breadth and price of the package carries too much weight. Actual results bear too little, including level of effort. And ultimately, the features checklists have usurped the overarching mission of endpoint protection suites, preventing compromises.
The Theory of the Endpoint Security Suite
Roughly a decade ago, the term best of breed characterized the state of endpoint protection. There seemed an ever growing number of agents with separate management systems and no common data model or reporting. Each agent required compatibility testing. Each management system required supporting infrastructure. Individual administrators had to log in to multiple, separate systems. Fusing data from different sources and generating reports was too costly. Consolidating all separate agents into one of many features, as well as, consolidating central management to a “single pane of glass” would save the enterprise mightily. The theory ultimately asserts that the cost of separate best of breed agents does not sufficiently outweigh the benefits of consolidation.
What the All-in-One Suite Did and Did Not Deliver
Consolidation undoubtedly reduced economic agency costs: less agent testing, less infrastructure, and easier reporting. So what’s the problem? A decade later, the enterprise is routinely compromised via endpoints and the cost of IT/Sec operations has never been higher.
Problem - The Ranking and Evaluation of the Suites Devolved into a Features Arms Race
The enterprise values the recommendations of the market analysts. These clever people struggle to get objective, quantitative information from the suites customers they interview. Their inferences are made from diverse, subjective opinions. They have done an admirable job creating a structure to contain and order these inputs. However, the information they get is not enough. For each protection feature, they need labor hour data as well as protection efficacy data. Instead, the analysts are forced to make recommendations from anecdotes and questionnaires consisting mostly of checklists and multiple choice answers.
The analysts went too far in prescribing features to treat problems instead of emphasizing the problems that features should treat. Fortunately, Gartner recently made a course correction last fall redefining their evaluation criteria. If you are unfamiliar with Gartner’s changes, I recommend reading them. They have shifted away from prescribing specific remedies toward emphasizing the problems the vendors must remedy. This will change matters for the better. One positive example concerns application exploits. Rather than prescribing patch management as THE remedy, other mitigations are valued, such as anti-exploit, HIPS, and host-based sandboxing. Yes, I don’t care for these remedies.
And, the old adage of ‘garbage in, garbage out’ aptly frames my concern. The existence of features overshadows the purpose and results of having them. The concept of what a protection feature does theoretically weighs heavily. Feature XYZ does ‘this’ to block ‘that’. To this day, analysts place great value on paper tigers such as anti-exploit technology, HIPS, and host-based sandboxing because the suite customers have little to say about what individual features block what. Even a simpler metric is under-reported. Little is reported as to what extent individual features are utilized or not by suites customers. Similarly, the same is true of the public bake-offs where the ‘block’ or ‘detection’ of something is attributed to the whole, not the individual cyber control. Without such insights, too much of the enterprise’s selection of initial candidate suites is based too much on the perceptions and features checklists of the analysts.
Consider analyst ‘perceptions’. If you were an analyst, how might your perceptions be shaped if interviews with a vendor’s customers mirrored and extolled the carefully crafted messaging of the vendor’s cool stuff? Analysts know and resist this. But they are just as human as the enterprise personnel selecting vendor products. BTW, this is one reason why marketing best practices prescribe content for a post-sales stage of the buyer journey. So many non-protection matters, such as features on paper, and perceptions, greatly influence the ranking and evaluation of endpoint protection suites.
Problem - Too Little Emphasis on Endpoint Compromise Prevention
In the last two years, market analysts have increasingly factored public bake-off results into their analyses. This is a positive development and may grow more so as this evolves. Presently, the bake-off findings are not yet contributing mightily to what the analysts can report because of differences and ambiguities in their frameworks and how well the respective frameworks fit the cyber controls tested.
That said, the last decade of analyst publications has had far more to do with the present shape of today’s suites. Some analysts have published scorecards, showing relative weights for different criteria. I strongly commend those that did so. Without these, few of us would know that in one influential analyst firms evaluations weighed the existence of patch management the same as protection. The two combined weighed less than a third overall. Others weighed protection similarly despite featuring the word protection in the title or subtitle of their respective publications.
Problem - More Features per Agent, More Potential Vulnerabilities
Vendor tools are made by humans, who make programming mistakes. If none were made, there’d be no application exploits and few if any security patches. If you browse the National Vulnerability Database, and type a vendor name and the word ‘endpoint’, you’ll find a variety of reported vulnerabilities over the years. Note that I wrote ‘reported’. Many vendors use their licensing and licensing terms to restrict testing by independent researchers. Software vulnerability volumes are EXTREMELY dependent on the attention they receive from independent testers.
Quick digression: many people mistakenly equate the security confidence of one application versus another based on the number of software vulnerabilities reported. This is simply wrong. Thorough statistical analyses have repeatedly shown that volume corresponds to attention from independent testers.
Bottom line, there have literally been successful enterprise attacks whereby adversaries exploited a vulnerability in an endpoint protection agent, sometimes via a seemingly insignificant feature. So, more features, more potential for exploits.
Last point, the all-in-one agent represents a single point of catastrophic failure. This was a trade-off made in the transition to all-in-one.
Problem - More Features, More Administration, and More Operations
While there are notable exceptions, generally, any all-in-one agent with say 10 features based on formerly separate agents, requires 10 different sets of configuration and updates. Little is published about the level of effort required of these all-in-one-plus-the-kitchen-sink approaches. How many times have you read an analyst report where a feature is mentioned as potentially mitigating this or that without a word of the required effort to do so? For example, to mitigate an application vulnerability, analysts oft say that anti-exploit or HIPS ‘can’ mitigate the risks. Clearly, the more specific the respective tool’s mitigation to the risk is, the more effective it is likely to be. However, the more specific it is, the more a specialist is required to specify it as well as the more compatibility testing is required. After preventing endpoint compromises, this is where the suites have failed the most.
A Brief Digression about AppGuard’s Practices Regarding Features
Ideally, any one cyber control should simplify the administration and operations of one or more other cyber controls. This is a design principle with AppGuard. With its patented adaptive process conformance cyber control preventing alterations and unauthorized additions to system-space (e.g., Windows, Program Files directories), AppGuard need not whitelist executables in system-space. Similarly, this obviates the need for application-specific memory rules. AppGuard doesn’t need to ‘guess’ what memory action to allow whenever there is uncertainty because this control ensures that any newly spawned fileless process, for example, cannot do harmful actions. This means no application-specific whitelist/blacklist child process rules. Its trusted enclaves cyber control is another example. AppGuard avoids yet more application-specific rules that regulate access to the Windows lsass.exe process to block pass-the-hash/ticket attacks in real-time. This last example may not be so great a comparison because so few if any other tools have such a capability at all. Again, this is an AppGuard design philosophy. Another one dictates whether a candidate feature is added or not. The rule is simple: the value of the new control must greatly outweigh the administration and operations of having it.
Problem - “Detect & React” Feature Create Too Much Work
The analysts have been quite brutal at times with their assessments of endpoint suites, noting the frequent and pervasive protection failures. Like many enterprises, they’ve lost faith in host-based agents blocking malware attacks. Consequently, they have increasingly advocated adding “detect & react” features to the suites, such as endpoint detection and response (EDR). Likewise, they have advocated integrations with cloud or network sandboxes and various “detect & react” tools not resident on the endpoints.
Conceptually, defense in depth sounds great. But, the enterprise has to pay the compensation for all of those people using those other elements. More needs to be reported about the incident volumes of all of the different elements and how the correspond with one another. How would a major improvement in endpoint compromise prevention, for example, impact each of those different elements? More needs to be reported on labor actuals. How could one quantify that improved endpoint compromise prevention if there’s no labor breakdown structure to show the impact on the single greatest enterprise cost: labor? Qualitatively, one can say that the labor for most of the other elements depends greatly on what happens at the endpoint.
Remedy - Some Analysts say ‘Don’t Rely Solely on your Vendor’s Endpoint Suite’
Alright, you’re currently licensing something for the next year or more, or whatever. But, you need better protection. And, your IT/Sec-Ops are overwhelmed. You need relief now! The answer is simple. Add another agent that demonstrable adds far better protection that requires very little overhead in terms of footprint, administration, and overall operations. Some analysts have been advocating for years that the enterprise not wait for the endpoint suites to catch up to next-generation protection tools. BTW, since the consolidation of endpoint tools into all-in-one agents, cloud-based administration and security information event management (SIEM) have altered the dynamics considerably. Adding another agent isn’t the headache it was.
AppGuard is just such a tool. Check out this blog post “Endpoint Protection: Operations Impact is just as Important as Blocking Malware”. Once deployed, ‘listen for what to leave out’. How many different and tedious endpoint suite features can be disabled? What other tools can be removed? What personnel groups are freed to work other problems? All this becomes possible because AppGuard blocks all types of malware attacks in real-time, at the endpoint, without needing any help from analysts in a security operations center. It’s as close to ‘set and forget’ endpoint protection as one dare hope to see in the real world where endpoints change weekly.
Final thought
Apathy throughout the electorate explains why so many voters equate ‘caring more’ with ‘spending more’ or that ‘more is better’. Enterprise Sec-Ops costs have been growing every year for a decade. The status quo is a quagmire. CISO’s must be afforded the flexibility to experiment and explore different approaches. Focus on tools upstream from other layers. A tool such as AppGuard can enable an enterprise to scale back many of the different investments/layers that have accumulated over the years.