What you need to know to build a solution to detect compromised credentials

Last updated at Fri, 21 Jul 2017 17:09:30 GMT

Once convinced of the need to detect compromised credentials, the focus shifts to building the right solution. Ultimately, the act of learning what it takes to build a solution informs whether the better return comes from building or buying. It sets the stage to consider the key elements and forms a strong evaluation criteria.

The fourth conversation in the Party Crashers series delved deeper into the specifics of how to build an effective solution - and some lessons learned along the way.

The foundation: the user attribution engine

Previous conversations revealed the near-universal concern over the length of time required for investigations. A chief element contributing to the delay is determining who was involved. The longer it takes, the more it costs. And the longer before the appropriate response is taken.

The foundation of a successful program relies on the ability to quickly attribute activity to individuals. While it may seem easy at first blush, the challenge is shifting from an asset to an account basis.

What happens when someone uses the VPN? What information is discernable at the level of an account, versus aggregate information about the authentication on the device?

The ability to detect a compromise requires a solid understanding of what normal is. The key is capturing the real normal, not just what the expected or desired version.

A proper user attribution engine draws on multiple sources of information to build a picture of what people do. Instead of storing all the data, the key is to grab what is needed to make accurate decisions. It combines the relevant insights from multiple points to provide a comprehensive picture of activity.

Capturing the right information: catch Metasploit

The conversation revealed the ‘catch Metasploit' project and the important role it played in developing the capabilities of UserInsight. The widespread success of the pen-testing team prompted the question, “what are sophisticated attackers doing that allows them to avoid detection?”

Answering the question created an opportunity.

By riding along and observing the methods and approach used by pen-testers (and attackers), it revealed the limitations of central logging. It also provided insights into where to look, what to look for, and how to pull the information together in a rapid, useful way.

A key finding was the realization that attackers work on local hosts as a means of avoiding detection. Knowing that means finding a way to determine when event logs are deleted and administrator privileges are elevated on local machines.

The solution requires understanding what is happening on each of the endpoints, and then coordinating the information. It means the ability to realize that the account used on a local machine is different than the account logging in remotely to another machine. Detecting the difference may be a sign of compromise.

Observing and testing the movements within an organization shapes the difference between capturing signal versus noise.

Gather all the (right) things

As a result of the ‘catch Metasploit' project, the UserInisght team realized a need to gather as much of the right information as possible. Broader than understanding the happening on endpoints, it required better visibility into the environment.

That means the introduction of honeypots and honeyusers.

Honeypots are not new. Making the honeypot work, however, requires a constant review to determine (and whitelist) known/acceptable activities from those that require additional investigation. Many are surprised and overwhelmed by the use of honeypots.

However, without a honeypot, it is hard to detect internal scans and related attack activity. That also means detecting normal and allowed activity and narrowing the focus to just what matters. Hence the challenge of successfully incorporating honeypots in the solution.

Equally compelling is the use of a “honeyuser.” The ‘catch Metasploit' project revealed that attackers often capture a list of user accounts, and then try each one once using likely password choices. A single failed attempt does not normally sound any alarms -- or even get logged. In the event the password guess worked, the attacker has access!

The honeyuser, then, looks real. Except no one uses it. It has one purpose: signal an alert when someone attempts to use it. It only requires a single attempt to sound the alarm. A clever way to gather the information necessary to determine when an attacker is in the process of compromising accounts.

Learn more about honeypots and honeyusers in UserInsight.

Make the choices that create useful insights

Building a solution to detect compromised accounts takes focused skillsets, dedication, and the willingness to test assumptions and solutions to focus on gathering the information necessary to provide useful insights.

As we approach the conclusion of the series, what questions remain? How can we help explain or aid in the ability of you and your team to embrace the changes and adopt the shifts necessary to detect compromised credentials?

The final conversation primer is available on September 9, 2014. The last conversation of the series happens on September 11th - save your spot now. We look forward to closing the series and celebrating your path to success.