Five Common Misconceptions in Enterprise Security Organizations – Part Two
In my previous blog post (part 1), I talked about common misconceptions in Enterprise security organizations as they relate to IT security skills challenges along with the disadvantages of counting on log-based solutions for stopping advanced attacks. This week I’d like to focus on three other common misconceptions in IT security organizations. I’ll be talking about why bigger isn’t necessarily better, why User and Entity Behavior Analytics on its own is not enough, and why “zero-configuration” solutions will let you down.
MISCONCEPTION #3: Focusing on covering as many sources and services as possible
Having a solution that covers as many sources (logs and API-based) and services as possible doesn’t necessarily keep you safe. A recent blog on Telltale Signs You Don’t Understand Big Data by Big Data Expert Bernard Marr, highlights this. There is a strong possibility that attackers won’t waste time breaking into your proprietary systems or exploit your services directly. Instead, they will focus on acquiring more and more privileges by owning more and more computers. And as you try to protect many services, you will find yourself overwhelmed by irrelevant information and false-positives that you won’t be able to handle efficiently.
Because Active Directory (AD) is an essential platform for an APT to spread around the network, having a solution strongly focused on the AD is essential. And you may even want to invest in a product that does solely that. This is true even if a company is web-based. Generally speaking, instead of focusing on one solution that does an ok job protecting many services, you would be better served looking for a few products that protect your priority services really well.
MISCONCEPTION #4: User and Entity Behavior Analytics on its own to identify attacks
Many would say, User and Entity Behavior Analytics (UEBA) can help catch attackers. Well, that is true, technically speaking. But in reality, even if you see alerts or users have high-risk scores, there is such a vast amount of users and alerts, you probably won’t notice. Reducing the false positives in this approach to a negligible level is very difficult. I think false positive is far worse than true negatives! You will have an exhausted team if you try to check each of them.
It is technically a very hard problem, even for a sophisticated machine learning system, to identify correctly suspicious behavior of an uncertain kind, rather than a slightly different behavior of a regular user. So, this is generally not an efficient detection method on its own.
To be more effective, you need to combine UEBA with an adaptive response to can mitigate the problem. For example, adding an automated identity verification step with something like multi-factor authentication when there is a suspicious action can confirm the authenticity of actions without requiring a security analyst to get involved. This allows them to focus on the really suspicious events, ones where the authenticity of the users can’t be confirmed, thus balancing and reducing the workload overall.
Alternative mitigation to that problem might be to apply deterministic rules that are only triggered when a specific event occurs. Typically these rules are set to detect a certain type of events that suggests an attacker in high certainty, even if they don’t necessarily occur. This is done to avoid false-positives as much as possible. An event could be a known attack like Pass The Ticket or Skeleton Key. Each has a unique signature in the traffic. The event could also be a deviation from an organization’s predetermined policies. For example, a policy might say that a File Server cannot do any action in a worker’s workstation. Or, another example could be that the European division of the company cannot query a database in the United States.
MISCONCEPTION #5: Expecting security products to work out of the box
“Zero-configuration” products aren’t going to do you any favors. You invest a lot of money into security products. Spending the time to configure it (for things like the security policy of the network, and on what to alert on, whitelisting, blacklisting, etc) is cheap compared to the price you might pay if you skip it as this might dramatically reduce the number of false-positives. Don’t want to spend the time? Then plan on spending an hour or so every week sifting through false positives. As a result, your trust in the solution will be lower. The three hours you spend setting configurations could eliminate many of them.
For automated products to be really effective, it needs to know something about the network. For example, knowing the remote management policy (ie, how the IT team manages workstations remotely). Understanding policies can be valuable in spotting attacks. Since an attacker might not know what the acceptable practices are in an organization they may try to do something that ends up being a policy exception using one of their accounts. I believe the “zero-configuration” concept comes at the price of false positives and incredible alerts, which is just not worth it.
To be sure, while not every misconception here may apply to every organization and some may be perceived as controversial, I think we can all agree that It is beneficial to scrutinize our assumptions and beliefs from time to time. Having a thoughtful and solid approach to your security strategy is key to successfully mitigate threats.
Posted by Roman Blachman on August 3, 2016 8:00 AM