Three Key Areas of Failure and What to Look Out For
There’s a lot of talk right now about the current state of endpoint protection solutions. Which technology has a future? Which technology should you be looking at? It’s good information to know, but more valuable is knowing which solution would work best for you and your specific environment. Unfortunately, to answer that question, most people still have to spend time and effort going through the POC/POV process and evaluating which solutions may meet their goals.
Because DirectDefense comes from the offensive, or “Red Team” side, a client recently asked us to perform a solution evaluation to identify each solutions effectiveness at protecting against determining attacks, and the more traditional attacks we’re all exposed to daily—such as spam, phishing, silly user and admin errors. There were more than a dozen vendors representing signature-based, whitelisting-based and next-gen solutions, and we evaluated each in both their default states and in their “protect” or “blocking” mode.
Whenever a solution failed a series of test cases, we analyzed the problem, looking for the root cause. While there were common failures due to technology weaknesses within the vendor solutions, most failures were due to basic challenges—or not AV technology-specific—that often get overlooked by companies evaluating these endpoint security solutions.
It is due to our ability to review endpoint protection solutions to this level that allows us to predict where and how your endpoint protection solution will fail you.
Installation of the “Management Servers” was the first key area of failure we encountered for many “On Premise” solutions. While some vendors do an exceptional job with automated installers, great documentation and even narrated videos, most management server installations can be best be described as dis-jointed. This issue is compounded with poorly-written documentation and sizing recommendations. Some solutions even require 3 or 4 components to be individually installed and configured outside of the server build, which leaves the door open for errors. Because of this, it is no wonder some vendors require professional services to install their solution.
So why is all this relevant? During testing, and in the real world, when solutions failed a series of test cases it was due to a disconnect or misconfiguration within the solutions’ various services. When this occured, we had to work with the vendor and the client’s support team to fix the underlying technology before testing could continue.
- What to look out for:Make sure the client/agent is properly configured and communicating with its management solution, and is on the policy you wish to enforce. We see this time and time again during incident response engagements, as well as in this lab environment.
- Make sure the management solution is properly housed on the correct-sized hardware.
- Make sure when using monitoring or incident response supporting solutions that you have fast storage, as these solutions do many read and writes. It’s easier to think of them as a SIEM for your endpoints—so your SAN better be fast.
Agent and solution maintenance was the second area we identified challenges with failed test cases. We’re talking about good old patch management here. In short, it’s surprising today to see how many solutions execute maintenance so poorly. While most vendor solutions do patch maintenance quite well, there are some in need of improved maintenance automation.
What to look out for:
- Agent Software Management: Let’s be simple here. It’s 2017. If the solution you are looking at does not provide some form of built-in automated agent maintenance mechanism, we strongly recommend you move on to the next solution. We’ve successfully broken into numerous companies over the years simply because an endpoint missed an update or the vendor requires you to send updates over your patch management solution. The automation of this process should be a major requirement for any solution you are evaluating.
- Management Server Maintenance: Aside from the typical product enhancement releases, there will be bug fix releases for your solution. We found plenty during our testing. When evaluating a solution, go through the process of conducting a patch release update and test to see what state your endpoints are in before, during, and after the patching process. Keep in mind that all solutions will have hiccups from time to time. This exercise ensures you’re aware of the state of your endpoint systems will be in when these issues occur.
Policy management was the most common area in which we found consistent failure, accounting for most of the failed test cases. Some vendors make policy management easy, and most newer cloud-delivered solutions make this even better through the use of simplified policies (IE—no more than 13-18 total options to select). However, other solutions have more than 70 settings for detection and just as many setting options for blocking attacks. While these solutions are highlighted as versatile, the assumption can be made that errors can occur—and commonly do.
What to look out for:
- Not Testing Your Policy: Just because it looks correct in your solution’s console does not mean it is properly implemented on your client. You must test each policy change to make sure the new settings are working properly and you did not lose older settings. Bugs happen, and this is how you find them—before the bad guy does.
- Not Reviewing Policy Group Assignments: Most failed test cases occurred because the agent was not running the correct policy at the time. Either our auto policy assignment did not work properly, or the agent was in the wrong group. Ideally, policy assignments should be reviewed after initial roll-out of your solution and after every major policy change or software update. At a minimum, they should be reviewed on a quarterly basis.
Not only do we see incorrect policies running in a lab scenario, but in the real world as well— and almost daily in our MSP practice. There is nothing worse than feeling secure, only to find out you got hit with malware because the infected system was running the wrong policy.
DirectDefense would be happy to contribute our opinion to the discussion about which endpoint protection technology is better and why; however, we want to highlight that regardless of what technology you choose or which vendor you select, there will still be challenges to overcome.
It is commonly stated that attackers are smarter—we’d argue that we just have more time to read the manuals and test the default settings and limitations of the solutions you’re trying to utilize to keep us out. So regardless of the solution you go with, make sure you test your solution—before we do—on your next penetration test.
Learn more about our security services by contacting firstname.lastname@example.org.