Everyone who works or has worked in a medium/big/large/huge/... company I am sure encountered a lot of occasions where the security measures set in place by the company were extremely annoying, a mix of intentional slow-downs, red-taping, bureaucracy and rituals.
This is no news, as a lot of regulations impose compliance against a number of frameworks, which often prescribe a bunch of security measures to be implemented. Security means controls, and controls can be implemented well and can be...just implemented.
The problem with compliance is that you often find yourself walking a fine line between useful security measures to mitigate risk and protecting people (and the organization) and complete bullshit security theater which is essentially meant to just tick a box during an audit. The more the latter is annoying to the end-user (the unlucky working class who just wants to get its job done to earn a salary to have money to spend in their free time to forget about work), the more “security” is providing.
Another problem is that to comply with many different regulations, a lot of policies are needed. A LOT. Each policy has tons of sections, subsections, sub-subsections, and so on. These are often accepted/reviewed once a year, during that beautiful process in which hundreds or thousands of employees essentially sign off company policies that they barely read and when they actually read, they barely understand (because of how the policies are written, not because of them), in the same way that we all accept EULA when signing up to Facebook or whatever cool new social network young people use.
Either way, I digress. What is the problem with many policies? Well, there are a few:
- Maintenance is hard. Reviewing policies is one of the most boring jobs ever, and when you have tons of them, keeping them all up-to-date to the point that they are relevant, is a challenge.
- Even harder is to maintain a framework of policies. This means that policies need to all go in the same direction, they need to live in harmony with each other, they should not contradict each other.
Enters Workstation Security
One of the largest battlefield in which compliance, security theater, security, marketing from security companies, pleasure to make people miserable and other components meet each other is the security of the workstations for the employees.
To be honest, the last year has seen a rise in attacks involving the compromise of engineers workstations, besides the usual phishing attacks (which are “on the rise” every year for the last 10 years according to prestigious security publications), so all of this is not completely unfounded.
Anyway, usually every company has an “Acceptable Use Policy” (AUP) which states what you can and cannot do with your company device(s). This includes things like watching porn, gambling, playing games but also things like installing new software.
Clearly the situation gets complicated when we are talking about workstations for engineers and tech workers in general: they generally need a lot of tools to get their job done or to do it in a more efficient way. However, this often conflicts with the common requirements of getting approval for every software installed.
Besides AUP, there is also another term that companies (mostly the ones that sell products to “prevent” it) love: DLP, Data Loss Prevention. This essentially means preventing you (the employee) from exfiltrating proprietary data of the company outside the company. Concretely this translates in things like blocking USB drives on workstations, blocking certain sites (like personal email, storage sites, etc.).
DLP is security theater. Here, I said it. In most companies DLP translates into a bunch of annoying rules that make the life of people working more annoying, without solving any problem at all, against even the slightly motivated and capable malicious user.
Let's not just make a rant though, let's make concrete examples. One of the most important DLP area is the network. To avoid that you (the bad employee) would go to Google drive and upload a beautiful zip with all the company data, organizations usually install a proxy in the corporate network. Alternatively, for those working remotely (but not only, of course), the company might enforce a VPN solution with DLP integrated.
What this means is that every single network packet that employees send to the network, first need to pass through this proxy, where it gets decrypted, analyzed, filtered and then sent to the destination.
This technique also inspects HTTPs (TLS) traffic, since companies install by default in every workstation a CA certificate issued by the VPN provider, that is trusted for everything. In other words, if you go to https://mysite.org from your company workstation and inspect the certificate in the browser, you will see that the certificate is actually issued by your VPN provider.
So far, this makes sense, right? It is reasonable that on a company workstation you have no expectation of privacy (and this is another reason why you should NEVER, EVER use your work devices for anything else than work), and that traffic is inspected. Unfortunately, usually the “controls” don't stop here. For a man with a big hammer, everything looks like a nail. Once you pay big money for this kind of product, you want to start using all the beautiful features it offers, and the first – I guarantee you – is the category block. We are not talking about porn, gambling, etc., we are talking about calendar, emails, etc.
Once this solution is in place, it's common to see things like “only [whatever email provider your company use, say gmail] is allowed”. Then, if you try to go to mail.proton.me, you get a big error message that tells you that the page is blocked as it's an email application. Same if you go to outlook.com (if for some reason you chose to keep your emails there), and so on. The same applies to calendars, storage applications etc.
What is the problem here? The problem is that this is bullshit. Not in the sense that it doesn't have a rationale, but in the sense that it is pretty much like trying to empty the sea with a bucket. The only achievement of this is that Sarah in accounting will have more trouble organizing her life because she can't access her work calendar from her personal devices (of course!) nor her personal calendar from her work device. Or that John from marketing will need to jump 25 hoops to access a site needed to share data with a customer (who doesn't happen to use the same system as his company), usually by requesting some manual, temporary whitelist, with lots of approvals and time wasted.
That's pretty much the only achievement, because there is just no way, NO WAY that whatever pricey solution you are buying, you are actually blocking all email, storage, calendar, etc. applications on earth (or better, on the Internet). It simply will not happen. Anybody can run a huge number of opensource or even custom software to do essentially whatever. You can host a pastebin service under your personal domain, you can access your personal Gitea instance, and a solution that works based on the domain alone to be in a list, especially a blocklist, is going to be extremely ineffective. You could achieve this only via an allow-list, but good luck figuring out a list of all the websites that everyone in the company requires to access.
In fact, usually there is always someone within a company that knows “something that works”, which they use to do their job better, and which technically violates a huge number of policies, but that “since it's not blocked” automatically feels like allowed (which makes sense, to some extent).
So here there are only 2 scenarios that matter:
- Your super expensive network DLP-blockchain-AI-web3 technology can block network traffic which contains suspicious sensitive data.
- Your super expensive network DLP-blockchain-AI-web3 technology cannot block network traffic which contains suspicious sensitive data.
If your solution falls in the first scenario: good job! You have a technical control that works and scales. At this point, there is no need anymore to block any site for anybody in the company, because if Sarah from accounting decided one day not to use her calendar to remember about her karate lesson, but to exfiltrate company data, this holy-grail of DLP would catch it and block it. It's unclear how this solution will work with things like code (that reasonably you will sometimes paste online for searches) or credit card data (when you are doing a legitimate purchase with your card, not exfiltrating credit cards), but I will leave this to the – I am sure – extremely expensive solutions.
If your solution falls into the second scenario, then you have no technical control. There is absolutely nothing you can do to prevent a user from doing cat | tar | nc IP port and sending whatever data she wants to whatever IP she controls. You also can't do anything if she can access a file upload service hosted at https://news.kitchen.cat, which likely won't be in any list. Or you can't do absolutely anything about one of the other millions of ways to exfiltrate data in a way to bypass a simple list of domains.
If you are in this situation, what benefits does it give to block a negligible part of the internet? The only benefit is to prevent people from doing mistakes likes sending accidentally an email from their personal account instead than from their work one. Is this kind of scenario worth the nuisance to all the users for everything that is blocked? Maybe it is, maybe it is not, but this is essentially what the decision should be based on. If someone starts mentioning the risk of DLP in accessing your personal email, you know that's bullshit. Some malicious insider will find another way, while the well-meaning users will just obey the rules and get annoyed in the process.
A small parenthesis is due at this point. Every security control has some gaps. It's very rare, if not impossible, to have something 100% effective. The problem is that in this context we are not talking about a bypass for a control, but rather about a few ways that the control cannot be bypassed. The efficacy is so low, that it's like claiming to have restricted access to a field by putting a door in the middle of it: you didn't help a little, you wasted the wood.
In whichever scenario your solution falls, you need to realize that as a company your main control is administrative: a policy that states that you can't share the data, and if you do so, you will have legal troubles and will get fired. Of course this will not prevent anything, but it's basically all you got. Even the most sophisticated solution won't anyway prevent anybody from taking pictures of their screen and OCR the data at scale, so it's a lost battle anyway, you might as well not annoy the users in the process.
The Virtualization Issue
When talking about DLP, and workstation security in general, another topic is virtualization. Usually the organization requires to run a bunch of tools on each workstations, agents that monitor files, processes and the network (as the one discussed before). Obviously, if you decide to run a VM on your workstation, all the tools and agents will not be present, and therefore there is a security and a DLP risk.
The security risk is that your VM can be compromised and potentially infect your workstation as well (hypervisor vulnerabilities are rare but they exist). The DLP risk is that...you guessed it, inside the VM there are not those kind of agents which we talked about before. So you could be accessing whatever site you want, for example (this mostly apply for people working remotely, and not sitting in their corporate network, where the filtering can happen outside your machine).
For these reasons, the AUP sometiems forbids the use of VMs. This is where the beauty of the bureaucracy comes into play: many new companies (especially the hip and techie ones) are now using Apple devices (Macs) as their workstations, using tools like Jamf & similar, to replace the very common Windows or (among techies) Linux workstations.
Unfortunately, modern development is also extremely tied to containers, and an engineer who can't use Docker locally nowadays is going to initiate a mutiny. Because of this reason, Docker usage is generally allowed and necessary.
The beautiful side of this is that on Mac Docker Desktop uses a Linux VM, even configured in a way which is way less isolated than a regular VM would be by default (unless explicitly made so).
I would like to conduct a survey of how many Mac shops ban VMs but allow Docker, because that's hilarious. If you want to run a VM with host-only network to run some tool that you are not allowed to install in full isolation, you can't do it. But if you want to run any Docker image you want, with similar (let's not say worse) isolation, you can do it.
The policy says so.
