Automating the triage and incident response for account misuse alerts
Well, here we are. Our fourth and final installment of this blog series on use cases that can benefit most from security automation. In case you've missed the prior posts, we have already covered automating the investigation of and response to phishing
Today we wrap up this series by talking about how security automation
can be applied to account misuse alerts. These are the types of alerts that usually come in the form of failed logins, account logouts, domain groups added, and so on.
Why Account Misuse?
Alerts related to account misuse are ripe for automation because they meet three of our four criteria
Account misuse alerts require fast response particularly when they are actually caused by a malicious act and involve privileged accounts. Without quick action, you're at risk of unauthorized access and in turn, fraudulent activities or a real data breach.
It’s important to note that account misuse alerts can often be false positives. Yes, a failed login alert could be an indicator of a brute force attack, but it could also just be the result of a user forgetting or fat-fingering their password. Thus, it’s important to reach a conclusive diagnosis as soon as possible. Security automation can be a big help in that regard.
So, without further ado, let’s go over a typical account misuse alert process flow or playbook
and see which areas can be improved through security automation.
As in any type of investigation, this stage entails gathering data from various sources to get better context of the situation. For account misuse alerts, you would typically gather information about the user account and host/endpoint involved in the alert. It would also help to gather historical data of those entities for even greater context. All this can be quickly gathered through automation.
In addition, your SOC team might also want to look into GeoIP data (say for example in the case of a VPN alert) to check whether the IP address involved and its current location make sense from the context of your organization’s current operations. Again, this information can be collected automatically.
Automated Analysis and First-Level Determination
In the previous use case examples, the security analyst would typically retrieve information such as hashes, URLs, IPs, etc., from different security solutions as well as threat intelligence sources, and then make decisions off of the collected information. With account misuse alerts, the process usually entails a greater degree of user involvement.
Let’s say your SOC team receives a failed login alert due to someone attempting to log in to a machine 10 different times and failing in all of them. Once your SOC team identifies the owner of the user account in question - perhaps through Active Directory or whatever user management tool you’re using - one of the things they would likely do is communicate with that person and ask if he or she actually performed those login attempts.
The reply the SOC gets from that user would then help analysts decide whether the incident requires further investigation. That verification process of communicating with a user and getting the information needed can be incredibly time consuming, especially in organizations with a large number of users. Fortunately, it can easily be expedited through automation.
When security analysts conduct a deeper investigation on potential account misuse alerts, their usual tasks involve looking into the activities of the user as well as the activities of the host and network. What they’ll be looking for are signs indicating either normal or irregular user/host/network behavior. If they find anomalies indicative of malicious activity, they could proceed to escalation and response.
Again, these repetitive, detailed tasks of fetching activity data - mostly from application, sensor, server and device logs, as well as other sources, like WMI or AD - can be automated to save precious time. Of course, the deep analysis of the aggregated information ultimately requires the hands-on expertise of a security analyst.
At this stage, after studying all the information and context gathered through automation, the analyst would have been able to reach a conclusion with a high degree of certainty. The analyst would then move on and carry out the appropriate response activities.
- Imposing restrictions on the user account or even suspending/disabling it to prevent it from inflicting damage further in the organization
- Notifying the user of the impending restrictions/suspensions
- Notifying the user’s manager - as well as the user himself/herself - of any impending investigation
- If the account misuse is deemed to be already in an advanced/high-risk stage, escalating the case to an incident response process
To minimize the risk of such incidents from happening again, the analyst would then update any relevant security policies.
We've said it before and it can't be stated enough - security automation doesn't replace the need for critical thinking by security analysts. What it offers is faster, better decision making by ensuring the right information is readily available in its most logical, usable form. This results in your team being able to increase its caseload capacity and reduce mean time to respond.
In closing out our series, we would like to remind you of our five rules of the road for any security operations team:
- Always automate data collection and enrichment
- Automate triage activities when possible
- Automation empowers (not replaces) human decision making
- Sensitive actions should be analyst assisted
- Embrace consistency...its value to security operations can't be overstated
The increasing sophistication and frequency of cyber attacks, paired with the shortage of skilled security talent, makes it imperative for you to maximize your existing threat investigation and response capabilities. Security automation can be a powerful tool in your security operations arsenal to drive greater process efficiency and effectiveness so your organization stays a step ahead of cyberthreats.