When we think about encryption for a Microsoft-based network, what generally first springs to mind is BitLocker, Microsoft’s native fixed-drive encryption software. But that highlights a tendency to forget that in a network there are many locations where encryption decisions are made.
These decisions are important but not always obvious, especially when they’re made by application or software vendors that recommend certain settings during the software installation process. I can’t tell you how many times a vendor has recommended settings that have given me pause and even made me question their stance on security.
Modern businesses manage many types of encryption across their sometimes vast networks. I’d argue that, on balance, cybersecurity teams do a decent job managing encryption on mobile workstations. It’s relatively straightforward to enable BitLocker with a PIN during Autopilot deployment — in Autopilot configuration, a template can be set in Intune’s endpoint protection. In addition, with Windows 11 machines that meet certain hardware configurations, such as devices that meet modern standby or meet the Hardware Security Testability Specification (HSTI), encryption happens by default during the out-of-box experience and encryption keys are backed up either to a Microsoft account or an Entra ID account by default.
Additional options can strengthen BitLocker encryption
If the user needs a recovery key, should it be necessary to reset a workstation back to default settings, or should a device ask for a BitLocker key during patching, the recovery key will be stored in a location that the help desk can refer them to. Autopilot allows the configuration of additional options, such as strengthening the Bitlocker encryption algorithm. On the Bitlocker CSP in Intune, you can specify a stronger algorithm such as XTS-AES 256-bit. You can configure this in Endpoint Security > Disk Encryption > Create Policy > Platform > Windows 10 and later and then choose the BitLocker profile type.
Ultimately, companies will want to measure compliance with policy — to review device encryption status across a firm and options for monitoring and reporting. In a given domain, there may be scripting or third-party management tools that may be used to identify those drives that are encrypted. Where there is Intune licensing, reports can be pulled using the Intune encryption status report console.
Log in to the Intune portal, then go to Devices, then Monitor and click on the encryption report. From there you’ll get a status report of computers, what TPM version they have, if they are ready for encryption and most importantly, if they are encrypted. It will also identify who has the username assigned to that computer device name so you can identify the “owner” of the computer.
Susan Bradley
BitLocker still relies on a degree of physical security
There have been many real-life examples of BitLocker vulnerabilities and it’s clear that with a lot of time, energy and staging of systems, it can be bypassed. The reality is that the security of Bitlocker ultimately relies on the physical security of individual computers. It’s essential to maintain good communication with users on the secure handling and storage of computers under their control.
Bitlocker is most effective on a system where the device is turned off, not on standby and able to be physically secure. Even when someone is travelling, consider deploying mobile locks to allow the users to physically secure the device when they are not monitoring their locations.
You may wish to set a policy to ensure that “Allow standby states (S1-S3) when sleeping (on battery) is set to ‘Disabled’. As CIS Security benchmarks indicate, “System sleep states (S1-S3) keep power to the RAM which may contain secrets, such as the BitLocker volume encryption key. An attacker finding a computer in sleep states (S1-S3) could directly attack the memory of the computer and gain access to the secrets through techniques such as RAM reminisce and direct memory access (DMA).”
Security settings beyond BitLocker
There is more than BitLocker in an operating system that will allow control over encryption settings. Often you are mandated in a firm to ensure that all sensitive data at rest is kept secure. Older operating systems may not natively provide the necessary internal encryption of application-layer encryption. Specific group policies are included in Windows that target how passwords are stored.
A case in point is the setting “Store passwords using reversible encryption”. This policy, if enabled, would lower the security posture of your firm. Older protocols being used in such locations as web servers and IIS may mandate that you enable these settings. Thus, you may want to audit your web servers to see if any developer mandate has indicated that you must have lesser protections in place.
For example, if you use challenge handshake authentication protocol (CHAP) through remote access or internet authentication services (IAS), you must enable this policy setting. CHAP is an authentication protocol used by remote access and network connections. Digest authentication in internet information services (IIS) also requires that you enable this policy setting. If you must use this setting, ensure that it’s in a very limited capacity and any workstation using it is isolated from the remainder of the network. As Microsoft itself notes, this policy setting should not be enabled unless business requirements outweigh the need to protect password information.
Phasing out NTLM in favor of Kerberos
A longer-term project in Microsoft is to phase out New Technology LAN Manager (NTLM) and push for more use of Kerberos. One of the first enhancements will be IAKerb, which will allow fixing some of the limitations with the current implementation of Kerberos. This will allow the Windows authentication stack to leverage and proxy Kerberos requests without requiring access to a domain controller. Messages are encrypted and secured in transit, which helps for remote authentication networks.
In the meantime, you’ll want to see if other protocols can be enabled, such as setting “Ensure Network Security: Configure encryption types allowed for Kerberos” to “AES128_HMAC_SHA1, AES256_HMAC_SHA1, Future encryption types (automated).” Other related settings in group policy can be enforced in your on-premises domains. As CIS Security benchmark policies indicate, “Some legacy applications and OSes may still require RC4_HMAC_MD5 — we recommend you test in your environment and verify whether you can safely remove it.”
Protecting an indexing location
Do you allow searching and indexing to be performed on sensitive or classified data? If you allow an index to be built using sensitive information and then do not protect that indexing location either in terms of ensuring proper authentication or the use of BitLocker where appropriate you could expose confidential information stored within the encrypted data. Ensure that all indexes of confidential data are just as protected as the data itself.
I’d argue it’s these other encryption settings in our networks that need much more review and examination. The next time you have to make an adjustment to an encryption setting on a web server during software installation that gives you pause, ensure you fully understand the consequences and push back to the vendor to justify their settings — encryption settings throughout or networks need to be managed and increased wherever possible.