CSA CCM UEM-06
Automatic Lock Screen | Plerion

As our digital lives become increasingly intertwined with our physical ones, it's critical that we take steps to secure our devices from unauthorized access. One simple yet effective measure is to configure automatic lock screens on all endpoints used for interactive purposes. In this article, we'll explore what this control entails, why it matters, and how to implement it in your environment.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full matrix here. The Cloud Controls Matrix (CCM) is a cybersecurity control framework for cloud computing. It lists a set of controls designed to help organizations assess and manage cybersecurity risks related to their cloud environments.

Who should care?

  • IT administrators responsible for endpoint security configuration
  • Information security professionals tasked with reducing risk of unauthorized access to devices and data
  • Compliance officers who need to ensure adherence to security standards and regulations
  • End users who want to protect sensitive information on their work devices

What is the risk?

The main risk that automatic lock screens help mitigate is unauthorized physical access to a device. If a laptop or desktop is left unattended and unlocked, anyone who gains physical access to it could view sensitive information, install malware, or make malicious configuration changes.

Potential adverse events include:

  • Data breaches from a lost/stolen unlocked device
  • Malware infections spread to the corporate network from a compromised endpoint
  • Insider threats abusing an unlocked, unattended workstation
  • Compliance violations if regulated data is exposed

While automatic lock screens alone cannot completely prevent these risks, they serve as an important first line of defense. The likelihood and impact of an incident is reduced if devices auto-lock after a period of inactivity.

What's the care factor?

Implementing automatic lock screens should be considered a high priority, baseline security control for any organization. It is a relatively low effort, high impact measure that significantly reduces risk, especially for portable endpoints like laptops that are more likely to be lost or stolen.

While there are always higher-sophistication attacks to defend against, do not underestimate the importance of preventing simple physical access to devices and data. Many costly data breaches have occurred because a misplaced unlocked laptop fell into the wrong hands.

When is it relevant?

Automatic lock screens should be configured for all interactive-use endpoints, which typically include:

  • Corporate-issued laptops, desktops, and workstations
  • Personal devices used for work purposes (BYOD)
  • Privileged access workstations used by admins
  • Servers and jump hosts that support interactive logins

Exceptions may include:

  • Kiosk devices and shared terminals in public areas
  • Devices dedicated to presenting dashboards or alerts
  • Appliances and IoT devices not designed for interactive use

What are the trade offs?

The main downsides to automatic lock screens are convenience and productivity impacts to end users. Frequently having to unlock the screen can be seen as annoyance, especially for devices that rarely leave secure office environments.

Some users like developers and admins may complain that constant locking interrupts their workflow and concentration. Workarounds like using a mouse jiggler to prevent the lock screen are not uncommon.

There are also some technical considerations and limitations:

  • Older devices may not support robust auto-lock functionality
  • Lock screen settings may need testing to ensure they don't interfere with legitimate applications
  • Care must be taken not to lockout remote users or block unattended processes

Overall though, these are minor inconveniences compared to the risks of leaving devices unlocked. The trade offs weigh heavily in favor of auto-lock being enforced in the vast majority of cases.

How to make it happen?

The specific steps to require automatic lock screens depends on your endpoint OS and management tools, but the general process is:

  1. Define your auto-lock policy specifying:
    • Idle timeout before screen locks (e.g. 15 minutes)
    • If a password is required on wake (typically yes)
    • Any devices or users that are exempt
  2. Configure the relevant settings via Group Policy (Windows), Configuration Profile (macOS), or MDM policy (mobile)
    • For Windows, enable the policy "Interactive logon: Machine inactivity limit"
    • For macOS, set the "Login window idle time slider"
    • For iOS and Android, look for "Auto-Lock" options in the passcode settings
  3. Push the config to a test group of devices and verify it works as expected
  4. Communicate the upcoming change to end users
  5. Roll out the config to remaining in-scope devices
  6. Monitor for failed deployments or users trying to bypass the policy

Most UEM tools like Microsoft Intune and VMware Workspace ONE provide a streamlined way to consistently enforce these settings across Windows, macOS, and mobile devices. Where UEM isn't available, using native OS management features is perfectly adequate.

What are some gotchas?

A few things to watch out for when implementing auto lock screens:

  • Lock screen settings are not always 100% effective against a determined insider threat. For high-risk situations, consider disabling USB ports and requiring BitLocker.
  • Locking the UI does not necessarily disconnect remote sessions. Be sure to define an idle timeout for SSH, RDP, etc.
  • Applications that simulate user activity can extend the auto-lock time. Consider blocking tools like Caffeine that are easily abused.
  • Laptops should still auto-lock when closed, in case this happens before the idle timeout is reached.
  • The lock screen itself should be hardened to hide sensitive info like usernames, email notifications, etc.

Work with your endpoint engineering team to determine the right auto-lock behavior for your environment. Document any necessary exceptions or compensating controls.

What are the alternatives?

Auto-locking the screen after a timeout is the most common approach to meeting this control, but some alternatives include:

  • Requiring a lock action (e.g. Win+L) before walking away, enforced by policy and user training
  • Automatically locking the screen based on physical presence using a proximity sensor or camera
  • Locking the screen when a paired Bluetooth device like a smartwatch goes out of range
  • Remotely locking a lost device using MDM commands

In high-security environments, auto-lock may be combined with session termination, where the user is fully logged out after a longer period of inactivity. This clears memory and network connections in case the lock screen is bypassed.

Explore further

For more background on designing an effective endpoint security strategy, refer to:

  • CIS Benchmarks for Windows, macOS, iOS and Android
  • NIST Special Publication 800-124 on Guidelines for Managing the Security of Mobile Devices
  • Your device / MDM vendor's hardening guides for turning security recommendations into implemented technical controls

Some specific controls that complement UEM-06 include:

  • CIS Control 13.11: Restrict Access to Locked Machines (Windows)
  • macOS Benchmark 4.4: Enable a timed screen saver
  • Android Benchmark 4.3: Enable the lock screen with a strong PIN or passphrase

Let me know if you have any other questions! Securing endpoints is a complex topic but hopefully this gives you a solid foundation to build your auto-lock strategy.

Blog

Learn cloud security with our research blog