The World According to Mitch

I came across a quote I love sometime over the last year: Security should cause healthy friction. It should not impede your users – it should hardly even cause them delays. It is a quote that I love, and which I have shared with my students every time I teach.

Sometimes I get caught in my own web.

I try to keep my systems secure using many of the same tools that I talk about in my class. For example, my main system is Entra ID (formerly Azure AD) joined, and it is protected with Microsoft Intune Configuration Policies. I have a number of policies for different purposes, ranging from Wi-Fi to Security Baselines to… BitLocker.

I have loved BitLocker since I was first introduced to it nineteen years ago. The Full-Disk Encryption (FDE) that Microsoft introduced in Windows Vista has been protecting my mobile devices (as well as my less-than-mobile devices) since January, 2007. It has bit me in the bottom once or twice (each was my fault), but I continue to swear by it.

One of the policies I have applied to my machines is that any external drive connected via USB port (or, I suppose, any other port… if I had any) needs to be BitLocker encrypted in order to write to it. If a drive is not encrypted, then it is automatically set to Read Only. This is usually not a problem… the rare time I need to share files with someone, I simply create a USB key with a password that I can share with them.

This morning I came across 40gb of files that I had saved for a buddy when I helped him with his smart phone. I asked if he still needs them and he shouted YES! No problem, I’ll put them onto a USB key for him.

Unfortunately my buddy is a Mac guy… and I know full well that Mac and BitLocker do not work together. How was I going to do this? Oh right… I encrypt the drive, copy the files over, and then remove the encryption! Simple enough…

…but slow. The encryption of an empty drive is very quick. The decryption of a drive with nearly 40gb of files on it is not… and to slow it down even further, the USB key that I chose is not a high performance key, but a relatively cheap USB 2.0 key that is not going to win any races. It took nearly two hours to copy the files over… and it took nearly two more hours to remove the encryption.

That is not what I would call healthy friction.

To be fair, the situation that I described is not an everyday one. If it were, then I would either transmit those files onto another computer on my network that does not have that restriction, or I would do away with the restriction. Were this a policy that affected many users (or any, other than myself) then I would revisit this (and likely several other) policy because I would want my users working, not fighting with drive encryption/decryption… and so much more.

There is a site that I have been advocating for years called The Center for Internet Security Workbench (https://workbench.cisecurity.org/). It provides benchmarks for myriad platforms – recommendations on how to best secure your environment. As an example (one that is relevant to this discussion), the CIS Microsoft Intune for Windows 11 Benchmark v4.0.0 is dated April 25, 2025 and includes an overview, target technology details, intended audience, consensus guidance, typographical conventions, recommendation definitions, and then about 1,070 pages of recommendations… followed by a 50-page checklist (Summary Table), and then a section on Change History. It would take an organization several weeks of full-time effort to review and then implement all of the recommendations contained in the benchmark to ensure that you have done it all correctly.

…But should you? I am not saying that you should not harden your systems. Far from it. Should you implement every single recommendation? That is a different story… and the answer is what I call the Universal Consultants Answer (UCA): It depends.

Should you harden your systems? Absolutely. Should you implement every single possible security measure? That would depend on what you are protecting… but probably not. Should you review the document and determine which recommendations are important to your organization, and which would be superfluous? Yes you should.

The following story is about a company that I once worked for. I want to clarify at this point that during my tenure with the company I never discussed any of this with anyone, so if you do happen to glean what company it is, know that I will not be revealing any insider or protected information. While I do not believe my NDA is still in force, I nevertheless will not break it.

I spent a year working for a major motion picture studio that had been compromised a few years earlier by cyber threat actors. It was an extremely embarrassing experience for the studio, and one that they vowed they would never need to go through again. When I arrived for my first day of work, I was told that I would need to meet with a senior cybersecurity manager… and that I would not get along with him because nobody did. I met with him, and to everyone’s shock I got along with him quite well. Why? Because I understood cybersecurity. At no point did I say to him ‘Isn’t that going a bit overboard?’ I knew why the security measures were in place, and I respected them.

Before and since that job I have worked with many organizations that require the absolute highest level of security, including governments and militaries. My recollection is that the security at that company was as secure if not moreso than those organizations. Were they going overboard? Possibly… but they had been hit before and they were not going to take a chance that it might happen again.

That company probably went overboard on their security… but they knew firsthand the cost of an unsecure environment. For most organizations, the best advice I can give is to balance security with usability… and to supplement their cybersecurity policy with regular User Awareness Training. This should be designed to help the users understand why cybersecurity is important, but also how to navigate it properly.

As an example of this, let’s discuss password complexity. Imagine your organization has a policy that requires passwords be twenty-two characters long, with upper- and lower-case letters, numbers, and special characters. The technical policy would be backed up by an administrative policy that bars users from writing their passwords down. Most users would balk at this… or they would follow the technical policy while ignoring the administrative one.

Now let’s go into the training! You show users the consequences of compromised passwords, and how easily cyber threat actors can break short and non-complex passwords. You remind them that people walking around the office may have clearance, but they should not have access to your files – and that a yellow sticky note with your password on it would give them everything. You then show them how to take their favourite songs and turn them into easy to remember complex passwords. “Heartbreak Hotel” is neither long enough, nor is it sufficiently complex. Indeed, the space is a special character, but that brings it to sixteen characters… and there are no numbers. However… knowing the song was published in January of 1956, we could use that – Heartbreak 1956 Hotel is 21 characters long and complex.

Conclusion

Our systems need to be secured using both technical and administrative policies… and periodic user awareness training will help your users to navigate the security hurdles you install. However, remember that if you are protecting a bag of candy you do not buy a vault and install a hundred thousand dollar security system. Implement the security appropriate to what you are protecting, and do not change the policy for a single case. I began this article discussing my frustration with a technical policy that I implemented; the day this arose was the first time the policy had every stymied me. Did I reverse the policy? I did not. Instead, I found a way to accomplish my goal without needing to do that. Is this a workaround that could compromise my security? It is not because end users would not be able to decrypt the drive, and even if they tried to the effort would show up in my audit logs.

Healthy friction should be your goal. We may not like lining up at airport security to have our carry-on bags inspected… but we know we have to arrive at the airport two hours before our flight because this will be required. It is not prohibitive friction… even though it is indeed a pain in the heinie. So are passwords and Intrusion Prevention Systems (IPSs) and Access Control Lists (ACLs) and so many of the security measures we implement to keep our organizations safe. They may initially be a pain… but if implemented properly they will protect your systems from cyber threat actors getting in.