Finish Or Start New?

What’s better for security: finishing the deployment of a functional product or start fresh with the modern product? It seems like it really depends on circumstances.

I had an alright MSSP. There were some problems though. Picking a new MSSP allowed me to fix some configuration issues I couldn’t resolve due to organizational inertia.

On the other hand, I had hardware for network segmentation and additional hardware would have been pretty affordable. My issue was a lack of FTE’s. When leadership buy-in was available, we had to use a hot new product and start over. I’m not sure we were any better off after the replacement. The new product wasn’t really doing anything that much better. It had the potential, but we lacked the FTE’s to make it happen.

Similarly, I went from an integrated IDS/IPS that wasn’t managed to a newer modern profiling stand-alone IDS/IPS. Given the previous product was integrated, I’d argue we’d clearly lost effectiveness since the FTE cost was higher with this stand-alone product.

On to Monitoring.

I’ve got a SIEM type product. It’s not fully deployed, but who can say their SIEM is really fully deployed and tuned? I’m looking at UEBA and analytics platforms, but I suspect my time would be better spent focused on a well tuned SIEM than 3 partially deployed platforms. The vendors mostly agree/admit that the platforms all have steep FTE requirements for success.

Microsoft ATA is extremely affordable and claims to be a UEBA type product. It’s ignoring the non-Microsoft user realms, but can an attacker get in and get data out of an environment without touching anything Active Directory?

I couldn’t begin to write anything close to comparable to Anton Chuvakin’s blog post on the subject of security analytics.

It seems like money and FTE effort would be better devoted to furthering a SIEM deployment completeness / maturity. 

More Than The Team Can Handle

Anton Chavukin at Gartner has a recent post about security monitoring on the Garter blog.  I don’t have access to Gartner papers anymore, but he published a couple key quotes.

The first was about layering controls.  I think most leadership groups understand that at this point.  It has been a while since I’ve heard of anyone thinking a single control is sufficient to stop 100% of all security threats.

The remaining quotes all seem focused around poorly responding to a security incident(s).

Clients often approach security monitoring from a specific driver, rather than from a larger perspective. This is no surprise, because they are generally trying to address a specific regulation, risk pain point or deal with an incident that just happened, and focus on what is the best and most cost-effective solution for that alone. But this path is dangerous, because it can lead to leaving large gaps in some areas and overspending in others — in part due to a focus on differences, rather than commonalities, in threats and attacks.

Do not buy more monitoring than you need — or can handle. Automated monitoring and response systems can be deployed widely, but many require investment in time and expertise. […] Gartner research consistently demonstrates that organizations procure much more security control functionality than they can absorb, deploy or and operationalize (this challenge applies to all controls but is rampant for SIEM and DLP, in particular).

How do you handle that?  If the business unit is behaving 100% reactionary and wanting to over reach the organization limitations, what do you do?  From my experience, it is typically the security person/people battling the business, the resellers, the vendors, and the outside consulting.  You can try your best to make positive of the situation given the available resources, but:

  • Management is assuming they have a fully polished security posture.  A lot of money was spent on the fancy SIEM or DLP solution.  The consultants, resellers, and the vendors are all claiming the security team has extremely powerful tools to do extremely advanced security work.
  • There will be another incident in the future.  There will be information in the logs in the fancy SIEM or DLP solution.  Is this new environment not configured to alert or generating more alerts than the team can handle?  In either case, the root cause is going to include that the information was available in the tool.
  • What happens to the morale of the security team?  They either have a product they don’t have time to properly manage or they don’t have time to respond to alerts.  Either situation is going to dramatically increase burnout of the team members.