Spoiler alert: Alert Pathways toward Success
Spoiler Alert: We made visible improvements in median time which is required to report 75 per cent of suspicious login activities after an investigation from October 2019 to March 2020.
Firstly, we reviewed all the investigating patterns of SOC analysts. Then, we deployed thousands of automation techniques to respond to questions quickly with accuracy.
We endeavoured our utmost efforts to boost investigation time for suspicious logins. Due to these efforts, the long procedure of six months has been turned into a matter of minutes and seconds.
That’s how we are showcasing the 75th percentile and median.
The more time you spend, the higher the TLDR line goes. Have you observed the line down? It’s time for the investigation of suspicious login alerts.
Do you wonder how repetitive tasks have been changed into SOC efficiency?
Well! You need to understand key metrics and SOC operations to get to know the reason for handing over the time-taking analyst tasks to robots.
Before discussing this, we will glance at the deployment ways of decision support for the reduction of challenging suspicious login alerts. It is a very vital step that can be very painful if ignored. Is it?
What’s decision support?
Decision support is a process of how technology is used to answer security questions correctly by enabling SOC analysts.
In this step, we lower the phenomenon of cognitive loading by handing off repetitive tasks to AKA robots for automation.
This is the essential component through which we ensure that our analysts are properly subscribed.
NOTE: The sticky notes without passwords you might have seen on the SOC tours are opposite to decision support.
The following are the main four components of which Excel decision support is made:
- Contextual Enrichment ( important for cloud automation)
- Orchestrated Investigation
- User Interface Attributes
- Automation
How do you build decision support?
The bottom line for the establishment of a decision support program is a proper understanding of why your team needs help. It means that the team can figure out all the suspicious alerts after proper investigation.
Have you ever seen the patterns opted by the team? Are they asking meaningful questions? To know the answer to these questions, you need metrics deployment. Qiside works on the vision that the more quality questions you ask, the more effective investigation takes place.
For instance, analysts often ask questions about the times usually user log in and the location from where the account was previously logged in by the user. And you know what is good about machines. They can ask all these questions continuously without any break.
Having excellent instrumentation and SOC metrics are very helpful in the initiation of a path down the project. You need to opt for effective strategies by taking into account your destination. Keep a glance at all the metrics and establish a cadence in the surroundings.
Remember that it’s not complicated to find out SOC metrics. All you need is a team to get an in-depth understanding of all the circumstances happening around you. This teamwork and discussion will help you in reaching the state where you can decide which steps are effective for investigation.
Qoside SOC system diagram
It is recommended that we resist the urge to automate things and do it manually before concluding any metrics. The following are some main points you need to know about SOC diagram interpretation.
- It comprises six paths. Every path has a capacity utilization monthly percentage record.
Robots: Just like the robot Josie, we inculcate security signals into the system via detection engines of different processes and technologies. - Triage: Whenever a security event matches with particular criteria, you need to generate an alert. Then all these alerts are passed over to SOC analysts for better judgment and decision by manpower. In the SOC diagram, almost 50 per cent capacity is used for this purpose.
There are three main paths that an alert can take:
Close: There is nothing to see in this alert as it is a false positive. You can mark down when you need to turn on alerts here.
- Incident: As it is a true positive alert, you should go here and respond.
- Investigate: for this alert, there is a need for additional data before dialling a call. It’s because investigations can take place either by Close path or by Notify ones.
- Close: This alert is also proved to be a false positive one after investigation.
- Notify: Additional investigation takes place to this alert where there is a need to know about the customer response to all the suspicious activities.
All of the phases have some metrics. Some are suspicious, while others are usual suspects. One of these usual alerts is the time required to fire an alert when our analyst figures it out. In terms of decision support opportunities, you will see two major metrics:
1- Firstly, you need to know the percentage of alerts depending upon their type and movement to investigate the bucket. As mentioned above in the SOC diagram, we usually figure out the alert pathways. Do we pass out 50 percent of “suspicious login alerts” in the investigation bucket? If so, you have incomplete information about alerts for making a call. At this stage, you might be thinking about what information is needed then.
Well, you need to know whether it’s possible to utilize data from different vendors for decorating alerts. Doing so has been made possible through the triage bucket. An alternative to this is to use an orchestration investigation to bring out a piece of evidence before you dial a call. All this takes a lot of time, and you need to optimize the accuracy, speed, and efficiency of triage. This is a key source of lowering cognitive loading on SOC analysts.
2- Secondly, you must have an idea about the time SOC will take to complete the investigation bucket process of alert. By the time, we mean all the time required to cover all the phases of the investigation cycle. Moreover, you can take some basic steps the improvement time. But the step to be taken by analysts is based upon the review of the alert investigation. After spotting the right pattern, the process is handed over to robots.
Noteworthy is that we don’t waste our time on analysts. We usually complete all the steps of the investigation of activity in an hour. Then, we account for data usage for spotting the suspects and improving times of the cycle by incorporating technology. After such hard proceedings, we can review weekly metrics for highlighting and monitoring progress on the spots in need of advanced technical improvement.
Case Study: Suspicious Logins
Now it’s time to put all the understanding and knowledge into practice.
Always keep in mind the two main metrics, such as time taken for investigation and likelihood to step toward an investigation.
We figured out some suspicious logins on the cloud applications like the AWS and O365 console authentication. Every security analyst knows how painful this particular class of alerts is.
Now the question is what makes a login suspicious. Well, there is a simple class of alerts to flag the authentication of content provided by customers (For example, location and login time are of great importance).
Besides this, we also make sure whether all the things happening are from suspicious regions or under VPN assessment.
This is of prime importance because our analysts review alerts depending on our willingness to unlock an aperture. Opening such apertures usually make login more suspicious than those tossing alerts our customers often face at the fence (This is opposite to Qoside).
For pre-optimization of suspicious Qoside login alerts, we need to collect basic data from observations. Whether your observed collection points out any peculiarity or not? If not, let’s have a look at questions based upon the alert evidence of class activity.
Here are some key questions usually asked based on alerts. Can you answer these
| Key question | Able to answer just based on the alert? |
|---|---|
| 1. Where has this user previously logged in from? | |
| 2. What other accounts has this IP logged into? Were they successful? | |
| 3. Is this user based out of Aruba? Did they forget to authenticate to the corporate VPN before logging into O365? |
We can’t answer all the questions simply by looking at the alert.
It is not surprising that a major percentage of suspicious login activity alerts make their route to our in-depth investigation bucket.
As a result of the examination of the alerts of suspicious login pathway metrics, we found that our analysts spend ample time querying.
This time is usually spent in inquiring SIEM logs for the performance of other steps of answering crucial questions. Here are some alert pathway interests from Suspicious Login Alerts of May 2019.
| Alert pathway | % of alerts following pathway (pre automation) |
|---|---|
| Alert-to-close | 61% |
| Pursue as investigations | 39% |
In the next step, we look at the patterns of investigation of suspicious logins. Another basic question that people often want to get answered is: What steps do you take when forwarding a suspicious login alert in the investigation?
By this, you can estimate how much time we spend in the investigation of querying logs in SIEM. After getting answers to the same questions again and again, things get visible.
Deep analyses have proved that we are investing most of our time in getting the answer to these questions:
From where did the user log in the last time?
- At which time does the user log in to the account normally?
- Which type or source of IP address did the user use?
- What have other successful IP addresses logged into this account previously?
- Did the same user agent was observed for the last time?
- What role is played by users? Whether they have any association with travel groups or not?
- Did users use VPN for assessing data? If yes, which VPN was common?
Concluding the above discussion, I would like to say that it’s better to use automated alerts to answer all these questions to arrive at the right decision in less time.
When robotic investigation orchestration is in use, our robot will grab the alert as soon as it is generated to be presented in decision support. The thing our SOC analyst focuses on is making less-time grepping judgment calls via SIEM
Qoside alert for suspicious login post-optimization
What work do we automate?
In this section, we will highlight the post-optimization activity of Qoside for suspicious login alerts. After firing a suspicious login alert, our robot picks it up, and the process takes place as follows:
Map of user login activity to elaborate the geolocation of all previous logins, including both successful and unsuccessful. It also includes the current login details of users over the past 30 days in the form of a weighted bubble map.
User authentication histogram to showcase the usual time of user login to account in the previous 30 days.
A summary of both successful and unsuccessful attempts from the IP address suspected in the alert.
Login summary to show the frequency of users logging in from different locations or IP addresses.
A user agent summary to have a view of the previous one-month record.
Robots grab all the user details from MFA, O365, or G-Suite device activity to warn our analysts about the observance of sensitive context.
It shows that suspicious login alerts can be resolved in just a few minutes by asking wise questions and passing the workload to robots. Here are the main stats of the post automation alert of May 2020.
Percentage of Alerts Following Pathways (Post automation)
Pursue as investigations
| Alert pathway | % of alerts following pathway (post automation) |
|---|---|
| Alert-to-close | 86% (+25%) |
| Pursue as investigations | 14% (-25%) |
We have gained efficiency in handling the painful class of alerts conveniently. This is the main fruitful outcome for our customers and SOC analysts.
Parting Encouragement
Achieve the desired successful result by asking the right questions. This is the basic reason for which we established decision support.
Decision support makes it super convenient to answer questions accurately.
Keep in mind that decision support is not a piece of sticky notes. It begins with a team that discusses the happening and understands the things needed for adjustment.
It is effective in having amazing SOC metrics even before moving down the path. Picture the whole plot and zoom in on the areas where you want your team to struggle.
