HOW TO PIVOT YOUR SOC TO SUPPORT A REMOTE WORKFORCE
The world has changed and now many staff are working from home.
Very few people think this phenomenon is going to change anytime soon and everyone needs to adjust their security solutions and services to this new reality.
I have already been working on several situations where a home employee was connected to the corporate network and bad things happened. Here are just a few of them:
Malware spread from a remote computer into the corporate environment via the VPN
A home computer with a corporate mail account was taken over and used to send emails from inside the corporate environment with malicious attachments
Employees inappropriately moving data to unprotected home systems
The source code was leaked via an employee working at home
Split tunneling allowed surfing of inappropriate content during work hours on corporate systems and malware infected the user’s system
“Many corporations initially tried to force 100% of communications over VPN to ensure that security technology would have full visibility by security systems and the Security Incident Event Management (SIEM). However, several of those corporations had VPN bandwidth and license challenges with this approach.”
Corporations quickly solved these challenges by employing split tunneling (only allowing corporate-destined data into the VPN) but this caused SIEM blindness. When remote systems traffic does not pass by network devices (routers, network firewalls, data loss prevention gateways, etc.) due to split tunneling, the SIEM becomes blind.
Traditional Managed Security Service Providers (MSSPs) / Security Operations Centers
(SOCs) did not anticipate that they would become blind to most security-related activities taking place on remote systems. Much of SIEM logs are captured by network devices and systems located in the environment. Remote systems could not send logs in real time unless they were actively connected to the VPN. As a result of shifting to a remote workforce, MSSPs / SOCs experienced a significant drop in the quantity of logging being sent to the SIEM. This was very concerning for everyone as it limits the ability to monitor malicious activities.
Additionally, the use of encryption technology (SSL, SSL-VPN, TLS) is making it increasingly difficult to inspect traffic and further complicates the situation. Unless the security device is performing TLS Decryption, when encrypted data passes by, it cannot determine if it is appropriate. At best, it only sees source and destination addresses but that alone is not enough to make any risk determinations.
This is where Endpoint Detection & Response (EDR) technology comes in. If SIEM technology cannot acquire the needed logs, the industry needs technology running at the endpoints that can acquire and send security data to a centralized location. EDR technology lives at the endpoints, so it is running and reporting regardless of where the system is located. Make sure you are running EDR style protection with features like:
Malware, Trojans, Ransomware Protection
Detect highly sophisticated malware, memory exploits, script misuse, and other file-less attacks
Rollback for Microsoft Windows in the event of compromises
Device Control for plug-in devices such as USB device peripherals
Firewall Control for network connectivity to and from assets, including location awareness
Vulnerability Management for systems in remote locations
Full Remote Shell capability to enable incident responders and forensics personnel
Enterprise threat hunting
Most EDR technology was designed with location independence in mind. By using the cloud, EDR vendors can aggregate this information without needing corporate connectivity. EDR can protect a computer wherever it is located (coffee shops, airplanes, corporate networks). Since EDR technology can see data before it gets encrypted and after it gets decrypted, the logs can be full of rich information for making security determinations.
Should I send my EDR log data to my SIEM?
That is a good question. If you are not going to monitor your EDR 24x7, then the answer is yes. But this means you are going to pay for twice the log storage and twice the computing power. Additionally, your compliance obligations may require long-term log storage, whereas most EDR retro-hunt capabilities are limited to 7 or 14 days. When a corporation has a small EDR implementation this may make sense. That means that if an EDR alert is sent to a SIEM, the analyst will need to log in to the EDR to perform additional analysis and take action.
If a corporation has a large EDR implementation, then duplicating logs may be cost-prohibitive and not the smartest move. EDR has very rich data and response capabilities which the SIEM does not include. In this case, it may make more sense to monitor the EDR independently.
Now that we see the benefits of EDR technology, MSSPs / SOCs need to adapt to this change.
To support this new reality, MSSPs / SOCs need to start monitoring EDR technology in addition to the legacy SIEM environment. What does EDR monitoring require?
Monitoring comes in many levels. One of our EDR vendor partners offers an “EDR Monitoring” service. It sounds good on the surface since they say 24x7 but it may not be good enough. They set up the EDR portal and apply some basic EDR automated response actions to the tool. You may even get an email if the EDR tool fires off a response action. The real issue is that they only have access to that one tool, so performing any investigations is limited to only the data in one system that had an alert. Imagine trying to figure out how a forest caught on fire when you are only able to evaluate a single tree. That one tree may be part of the story, but it may not be enough to really understand how the fire started what just happened. The same is true with the EDR, the one alert may help us understand a piece of the puzzle, but it may not enough for us to fully complete an investigation. Correlating EDR events with Azure/O365 logs and email technology may help point to patient zero and completely eliminate an unauthorized individuals access into an environment.
Monitoring in an EDR world, in concert with the SIEM, requires embracing the “Response” components. For example, the 15 seconds before and after an EDR alert may be more valuable than the actual event identified. We want to understand what happened before and after an alert to see what caused the event and if other inappropriate actions were successful and not caught and blocked. This also may lead us back to the SIEM for further analysis. Using available information, we can piece together a fuller picture of the story.
Threat Analysis
Lateral Movement Detection
Pattern Recognition
Anomaly Detection
Observable Indicators of Compromise
Signals Detection
Respond & Rollback
Our SOC then finds that after an alert and automated responses, we may need to perform clean-up activities and EDR can support these activities:
Delete a file
Kill a process
Delete or modify Windows registry key or value
Put a file
Restart/Shutdown
Looking for the root cause of an alert is of critical importance. When systems are in a remote location, 24x7 EDR Monitoring & Response can really help protect your environment. Make sure you are seriously considering adding EDR technology to your security program and that your monitoring team is prepared to perform incident triage, remote forensics, threat analysis and provide advanced monitoring & remediation services.
Your future is at stake. It may only take one remote compromise to kill a corporation. Protect your future by contacting Emagined Security to discuss your needs in this New Remote World.