Security or Functionality: The Dilemma

Today I want to talk about a very common problem when managing our IT systems: what to do when we have to choose between functionality and security.

Many of you will think “well, security, of course!”, but when it comes to managing thousands of computers that depend on certain protocols, ports, or services, it's not that simple. The more security we add, the more functionality we lose, and there's a point at which certain recommendations stop making sense.

Maximum security, no connection

Let's say, for example, that a secret service wants to build its hyper-secure environment with activated and fully updated Windows systems running the latest version. But inside the “bunker” there's no internet connection or any kind of communication with the outside world. How do we activate and update those machines? There has to be at least a phone available to activate the licenses, and the updates will have to be downloaded from the internet at some point. Not every machine needs an internet connection, but at least our internal update server does.

This is a very basic, simple example, but there are many others that come up in everyday IT work. For instance, in this article Ned Pyle explains many of the consequences of requiring authentication for RPC communications: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/restrictions-for-unauthenticated-rpc-clients-the-group-policy/ba-p/399128

In that piece, the author closes with a message I couldn't agree with more, which basically boils down to: “a security consultancy will tell you to remove this and add that, but when push comes to shove, they won't be there to help you once you've broken your environment because of all those changes.”

Filtering to only strong TLS ciphers

A typical example is when these security consultancies suggest their clients drop support for any TLS cipher considered “weak.” Great suggestion, but if a server's certificate is encrypted with TLS_RSA_WITH_AES_256_GCM_SHA384, what do we do? Do we block all communication with that server? We'll have to allow some exceptions, always keeping in mind a future removal of the weak TLS cipher. But let's explore the example a bit further: https://ciphersuite.info/cs/TLS_RSA_WITH_AES_256_GCM_SHA384/

The information for this cipher mentions that it doesn't support PFS (forward secrecy). In other words: if someone gets hold of that certificate's private key, all past or future communication with that server could be decrypted. But to actually exploit this vulnerability, someone first has to have “sniffed” network traffic between our clients and that server, and then obtained the certificate's private key. If the method for obtaining that key is “brute force,” attackers will need a lot of resources and time (years) to get what they want. The server's certificate will most likely be renewed before that happens. And that's just for one certificate.

Of course, deciding one way or another will depend on how critical the information we send to that server is. Needless to say, if the server is ours, we can avoid a bigger problem by issuing a new, more secure certificate. But otherwise, our Windows client can always fall back on Windows' default behavior, which uses a list of TLS ciphers ordered from most to least secure for communications that go through schannel. Here's that list for Windows 11 22H2: https://learn.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suites-in-windows-11-v22h2

What does this mean? That if the server accepts a “strong” cipher in addition to the “weak” one, Windows will always pick the strong one by default. Our communication with servers will always be possible using the strongest common TLS cipher we have.

With this, we can do a lot of testing: apply a GPO to a single test machine, configuring only a handful of very secure TLS ciphers, to see if any day-to-day connectivity issues come up. We can also capture a network trace with Wireshark, which will show us which TLS ciphers the servers we connect to are using.

I know some people won't be satisfied with this explanation — “I want maximum security, whatever the cost” — and that's a legitimate way to think. But let me ask another question: do all your clients run Windows 11, and all your servers Windows Server 2022? Because if not, they won't be able to communicate over TLS 1.3, the most advanced and secure version of that protocol.

The problem with account lockouts

A similar case is when the lockout threshold is enabled to block user accounts after multiple failed credential attempts. Some applications can trigger these failures by design, and a low threshold — 3 or 5 attempts — can very easily cause a denial of service. People usually don't want to raise the threshold “for security reasons,” even when the recommendation is only to raise it to 50.

“Ah, but if I set it to 50, it'll be much easier for someone to compromise the account.” True, the odds go from about 1 in a trillion down to about 1 in a hundred billion. But if we add just one more character to our password policy's minimum length, security improves just as much. Microsoft's public documentation mentions that account lockout can be removed if you have strong passwords and a solid auditing system in place: https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/account-lockout-threshold

On top of that, account lockouts are a bad practice in themselves (they make DDoS attacks easier); continuing to rely on passwords at all is a much bigger security problem than allowing a few wrong password attempts. The ideal solution here is to have a passwordless authentication system in place, such as Windows Hello for Business, and require your organization's users to use it. The password would only be used once, to enroll the user's device, and from then on smart card logon would be enforced.

“Oh, but how can a 6-digit PIN be more secure than a password?” The PIN only ever works on our own machine — it never travels over the network, and that's exactly where its security comes from. It can also be longer, include letters, or you can opt for biometric authentication or MFA instead. In the end, what WHFB uses for communications is a certificate (tied to our PIN, fingerprint, etc.), which is far more secure than a password. And it's all stored in a TPM chip — no passwords sitting in memory.

This second solution probably won't be well received either, since it takes several hours to implement and comes with a small cost. And that's where we hit the contradiction: the first solution (raising the threshold) isn't good enough because it's insecure, but the second one, which is more secure, isn't good enough either because it takes too much time.

Old, unpatched software

Another curious case is when we run into the opposite situation: system administrators who want to keep Windows Server 2003 running eight years after it received its last security updates. Or old third-party systems that don't use RPC sealing, or can only use Kerberos tickets encrypted with RC4. The November 2022 updates brought these problems to a head.

The first case in particular is genuinely concerning: how can a systems administrator want to keep a server running a highly insecure operating system? Going eight years without update support is no joke; thousands of vulnerabilities could be used to steal information or take control of the domain. Not to mention the enormous legal liability that could fall on us if a breach happens. The first thing an IT administrator should do in these situations is tell their superiors that certain operating systems need to be retired immediately. If the worst does happen, at least it won't be without our superiors having been properly informed.

Honestly, I wouldn't want to find myself in that situation. Whoever orders that highly insecure, unsupported software keep running is exposing themselves to a possible fine or, in the worst cases, prison.

Required protocols and ports

Fortunately, the more common (and reasonable) situation is the opposite: a company insisting on using the most up-to-date, secure software. As I mentioned above, this sometimes gets taken to absurd extremes: some people want to block all NTLM communications and still have everything work normally. Or block port 389 so that all LDAP communications use a certificate (LDAPS and 636) — but operating systems aren't built that way: they're designed for maximum compatibility and offer maximum security whenever possible.

Among Windows' requirements is being able to use both Kerberos and NTLM, and having the necessary ports open for the services we use, regardless of whether we only want to use the most secure methods. This is a good moment to revisit all those required ports: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements

Some people, wanting to lock down their environment as much as possible, want all administrative tasks for an on-premises domain to be carried out only from machines joined to Microsoft Entra ID with hybrid users. Starting from the fact that those hybrid accounts would need special privileges — which isn't really recommended — we run into the issue that Microsoft Entra machine authentication doesn't exist on-premises, so it's expected that some utilities requiring that authentication will fail.

Security matters most, but are we focusing on the right things?

To wrap up (the rant), I just want to leave you with a few more questions, which I think are worth asking before deciding whether we should really care so much about a change that will only marginally improve security in exchange for a loss of functionality. We wouldn't want to be paying too little attention to other things that actually do matter, and that in some cases won't cost us any functionality at all:

• Are there any machines running an unsupported OS?

• Do I have all my machines updated to the latest version?

• How many domain admins do I have?

• Do I fully trust the people who administer my systems?

• Is there a room reserved just for administrators? Is it locked? Are there security cameras?

• Do my employees lock their screens every time they step away from their desk?

• Do users connect to the corporate network over VPN?

• Do my users use passwordless authentication (WHFB)?

• Do my services use gMSA accounts? Delegation or impersonation?

• Do I use a different account for each service?

• What information do I share with the security consultancy?

• Do I use a tiered model to limit access to servers?

• Are my disks encrypted with BitLocker?

• Do my client machines use Credential Guard to protect passwords?

• Is Windows Defender running across my entire domain?

• Do I use an auditing system like Microsoft Sentinel to stay on top of the threats in my domain?

• Am I keeping up with the latest security news?

I'm sure I'm forgetting dozens of important questions, but as an example I think this gets the point across pretty well. I hope you enjoyed it!