From my Gartner Blog - The Security Monitoring Use Cases Paper is Here!

I’m very happy to announce that our paper on “How to Develop and Maintain Security Monitoring Use Cases” has just been published! This is the result of our work to provide a structured approach for organizations that need to operate their security monitoring infrastructure in an integrated and coordinated way, aligning their monitoring activities with the overall security planning efforts.

Some interesting pieces from the paper:

“Use cases can be created from three different sources: compliance, threat detection and asset oriented.”

“Monitoring use cases are generally seen as SIEM content, but also can be implemented with other technologies, including user and entity behavior analytics (UEBA), data loss prevention (DLP) and others.”

“An organization can have too much process overhead in this area — agility and predictability are both needed.”

“Many organizations focus on implementing canned vendor UC content, and that approach is workable, as long as the content is tuned and further steps are taken.”

“Given all those security problems to solve, which ones should the organization do first? For example, some security architects claim that SIEM use cases must always be selected by order of importance, but that is a big mistake. Gartner research indicates that organizations should not undertake a complex and hard to develop use case as a first phase, unless absolutely necessary and unless all precautions (such as moving in small steps) are taken. On the other hand, “do only what is easy” will not yield the desired results either. A much better order is a balance of importance with “feasibility” (that is, ease of implementation).”

“The organization beginning its journey into security monitoring and use-case development should start implementing use cases one by one, using the experience to improve the processes and putting together the basic technology components that will form the core of the security monitoring infrastructure. In a “walk, then run” way, it can expand the cycles to implement multiple use cases simultaneously later, especially when the use cases share similarities on chosen technology, data sources and objectives. “

“Use cases almost never operate under static conditions; the IT and threat environments are very dynamic and could affect the use-case value, relevance and performance. Situations not identified by change management or security intelligence processes, or cases of undetected slow changes, could be identified during a periodic review of the use cases. These reviews can be built as general periodic cycles where all existing use cases are reviewed or based on a “use-case schedule” and each has its own review date based on when it was originally implemented or last reviewed. This approach requires more work on maintaining the review schedule, but also avoids accumulating too much review work on a single task. It also requires just a few reviews happening frequently instead of a big batch of work that ends up creating an audit like “use-case review season.” “

 

Now, as mentioned before, we’re full speed ahead with EDR. Stay tuned!

The post The Security Monitoring Use Cases Paper is Here! appeared first on Augusto Barros.

from Augusto Barros http://ift.tt/1TlYX9J
via IFTTT

From my Gartner Blog - The D in EDR

The research on EDR tools and practices renders some very interesting discussions on tools capabilities. While many EDR vendors will focus on their fast searching and automated IOC checking capabilities, the “Detection” piece is always a fun piece to talk about. Especially when you discard the basic “blacklist” approach which, by the way, may not be as simple as we think (malware polymorphism makes it far more challenging than most people think it is).

What would you expect from an EDR tool regarding “Detection”, considering we are not including there the basic IOC matching? Write down you answer, then look at it. Isn’t that something you would expect, for example, from your antivirus (or “Endpoint Protection Platform”, the grown-up name)? What kind of detection capabilities should we expect from an EDR tool but not from an EPP?

Most EDR tools trying to do something beyond EPP are taking a “behavior” based approach. Identifying exactly what the vendors refer to as “behavior based detection” is another interesting challenge. If you hard code on your tool something considered a malicious behavior (something like “disabling AV”, “setting up hidden persistence”, “establishing contact with C&C server” or “search for data files or memory pages containing credit card numbers”), is it “behavior based” detection or just a fancy signature (or “rule”)?

There are no strong definitions and descriptions for capabilities such as “behavior based detection”, “anomaly detection” (isn’t it funny that some tools doing that define what an “anomaly” is just like a…signature?), etc. Add to it the claims about Machine Learning, AI, etc, and we have the perfect storm of inflated claims and, unfortunately, expectations.  It also makes the lives of those comparing solutions a big nightmare.

To be fair with all those tools, identifying malicious activity, or just malware (malware as the main vehicle for malicious activity is so big now that we often forget that it is not a requirement), is very hard. Computers can do anything and it’s hard to understand when some instructions are part of malicious activities and when they are not. Some powershell use, for example, would be expected from system administrators and power users, but is often a good indication of malicious activity when done by a “regular” user. Only the context (that sometimes is only different from a human point of view) will tell if it’s good or bad. A malware dropper behaves almost exactly like an installer or auto-update component of regular software.

Removing the inflated claims, the existing capabilities for detection are not that bad. If it’s so hard to identify what is malicious and what is not, we may need to keep explaining that to the tools. The real risk of not meeting expectations is in believing that the tool doesn’t need to learn, or when you don’t fully understand who has the role of teacher. It might be primarily the vendor, but you still need to be able to assess if they are doing that appropriately.

What does that mean? It means tools need to be tested before buying and constantly after implemented too. Understanding how the existing and emerging threats behave and how the tools would react to them is crucial to ensure they will keep detecting bad stuff. If you have resources that can obtain that information (here’s where that “other” Threat Intelligence comes into play) and translate it into the right questions (or test scenarios) to the vendors, you’ll be able stay aware of your tools capabilities and limitations. And of course, identify the snake oil when you see it in that booth at RSA

The post The D in EDR appeared first on Augusto Barros.

from Augusto Barros http://ift.tt/1TQSMLh
via IFTTT

From my Gartner Blog - SIEM Architecture and Operational Processes UPDATE!

My favorite Gartner GTP research document has just been updated:

Security Information and Event Management Architecture and Operational Processes

Using security information and event management requires more than just buying the right technology. Security architects must understand how to properly design and operate SIEM; this is critical to avoiding the costly mistake of an ineffective or failed deployment.

This document is a full guide to organizations planning to buy or implement a SIEM. It also has lots of content for those that have a SIEM in place but are struggling with getting the full value from it. It was published by Anton Chuvakin back in 2013, updated in 2014 and again now – with the addition of a co-author

Enjoy!

The post SIEM Architecture and Operational Processes UPDATE! appeared first on Augusto Barros.

from Augusto Barros http://ift.tt/1SGSHca
via IFTTT