Stories from the SOC is a blog series that describes recent real-world security incident investigations conducted and reported by the AT&T SOC analyst team for AT&T Managed Extended Detection and Response customers.
Executive summary
As we move towards more automation, we should remember the risk of over-automating, or at least make a conscious decision to accept the risks. This is especially important in automating response actions, which left unchecked could wreak havoc with day-to-day business operations.
Investigation
The alarm
One evening after normal business hours, an alarm came in indicating a software package attempting to execute on a server was auto-mitigated by SentinelOne. The software package was behaving in a way that was taken as attempting to evade detection by the SentinelOne agent and therefore rated as “Malicious” by the SentinelOne Artificial Intelligence logic. Since the server on which the software package was attempting to execute had a “Protect” policy applied, the auto-mitigation steps for a dynamically detected “Malicious” rating included killing and quarantining the process.
A “policy” setting in SentinelOne is the defined level of automated response activity the endpoint detection and response tool (EDR) has permission to perform for each grouping of assets. Whereas a “Detect” policy will create an alert that can be managed for post-investigation response actions, a policy setting of “Protect” will take automated response actions. The intrusion level of those automated response actions can be customized, but they all perform an automated action without a person looking at the situation first.
The below image is for an alarm for malware which ended up being process automation software
but nonetheless was automitigated (process killed) by SentinelOne as shown in the log excerpt below.
The business impact
The next morning, with business hours back in full swing, the customer reached out to us concerned about the result of the automated response action. The customer stated that the software package is a critical part of their business infrastructure and should never be stopped from executing. The software had been running on that same server the prior several months, since entering SOC monitoring.
The customer questioned why after several months with the SentinelOne agent running on the server did the agent suddenly believe the software package was malicious. We were not able the answer the question specifically since the decision-making behind identifying and rating a process as “Malicious” versus “Suspicious” or benign is a proprietary logic.
What we could state is that any EDR solution worth its price will continually update indicator of compromise (IOC) signatures. Any worthwhile EDR solution will also include not only static detection but also behavior-based dynamic detection. In the case of SentinelOne, there is the pre-execution behavior analysis that allows for process termination pre-execution as well. And of course, any software package run on a server is subject to updates for security, efficiency, or product feature upgrades.
Taken as a whole, it means any endpoint being protected is a very dynamic battleground with the potential for an updated software package that did not trigger IOC rules yesterday triggering tehm today. Or a non-updated software package may suddenly be identified as potently malicious due to updated machine learning IOC behavior analysis. Remember when JNDI calls were considered benign?
Lessons learned
Just as we learn the CIA security triad is a balancing act between confidentiality, integrity and availability, there is a balance to be struck between the use of immediate automated response actions and the slower reasoning of human evaluation prior to response actions. An EDR solution will immediately and infallibly carry out the policy which it has been programmed to implement, but in a ruthless fashion. A human evaluation will take longer, but it can consider prior history, the validity of the triggering IOCs in context, and the nuances of how selecting one response action over another might impact your overall business.
Automation, machine learning, artificial intelligence, and the like have their place. Their benefits will no doubt increase as technology develops. But the human component will always be necessary. The MXDR SOC and our customers (being the humans that we are) must work together to define the critical assets and business processes that should never be touched by automated intrusion. We must also work together to find the space in your environment where those swift and ruthless automated response actions are an advantage. And it is a very human decision to conclude how much risk we can tolerate in each implementation.
The post Stories from the SOC – The case for human response actions appeared first on Cybersecurity Insiders.
February 23, 2023 at 09:09PM
0 comments:
Post a Comment