top of page

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?