While I personally consider packet captures and memory dumps more interesting than policy and standards documents, I have been on many professional engagements over the years where the root contributor to the chaos was a lack of clear direction, either because solid governance was missing for one reason or another. Decades into my career now, I view these as important parts of a sustainable information security program.
Unfortunately, policies and standards are not something one can download from the SANS or ISACA website, make a few changes and call it a day. I often joke, the only thing worse than having to read policies and standards is writing them. The operating constraints of the organization are can never be fully understood by the policy writers and these documents are meant to provide long standing direction many years past the date of authoring. In all fairness to those authors, (myself included on some occasions), there is an assumption those responsible for implementing the controls understand the intent and make intelligent adjustments when needed because thing can change quickly in unpredictable ways.
When the world turned upside down overnight with the pandemic quarantine most companies found their remote access solutions were running at full capacity yet usability was not there. My first office VPN solution was PCAnywhere over a dial up modem, when I compiled the PPTP patch into my RedHat kernel and connected via cable modem 300kbs felt like a rocket. This memory lane visit shows remote access is old and so is the security guidance around it. It has been well entrenched in the remote access policies of many companies that while connected to the organization’s VPN all traffic from the remote computer needs to be contained within that encrypted tunnel. This of course includes all traffic to the internet because the common believe was the company needs to monitor what it’s people are doing when connected to the internet.
Back in 2000 something, when most company services were internal and internet access was not even granted to every worker, avoiding split tunneling made sense. That road warrior connection from the hotel room should not be exposing the internal corporate network in anyway. Fast forward to SaaS based email and CRM being the norm, the mass migration to home offices meant most companies suddenly found themselves burning double the bandwidth overnight. Once to bring the worker in, then direct their request out to Office 365 or SAP in the cloud, bring all that data back, then send it out once more to the home office. In addition the the double tax on the bandwidth, the requirement for monitoring the user activity isn’t being fully realized either because the traffic is encrypted from the worker’s desktop right to the SaaS service. The state of the art firewall knows it’s TLS traffic and the source IP is assigned to someone inside the company but that is about it. Conversely, the SaaS provider knows exactly who it is because they authenticated both the worker and are decrypting the TLS communications.
Those that clung tightly to a policy statement like “VPN connections shall not permit split tunneling”, likely found themselves trying to block high bandwidth content requests at perimeter firewalls. Those that realized a service like Office 365 is secured at the transport layer and the authentication layer, ( just like a VPN connection), may have found a policy change that permitted trusted connections to take the least expensive route allowed work to get done and the firewall whack-a-mole game never even got started.
If there is a call to action here, it would be review the policies that are in place and consider what threat or threats were intended to be mitigated? Does the current language make that abundantly clear to the reader five years from now dealing with a situation no one would have predicted?