DeviceLock Overview : Managed Access Control
  
Managed Access Control
Access control for devices works in the following way: Every time the user wants to access a device, DeviceLock intercepts this request at the kernel level of the OS. Depending on the device’s type and the connection interface (e.g. USB), DeviceLock checks the user rights in the appropriate Access Control List (ACL). If the user does not have the right to access this device, an “access denied” error is returned.
Access checking can occur at three levels: the interface (port) level, the type level and the file content level. Some devices are checked at all three levels, while others only at one level - either interface (port) or type.
Consider the case of a user connecting a USB flash drive to the USB port. Here DeviceLock would first check whether the USB port is open or locked at the interface level. Next, because Windows recognizes a USB flash drive as a removable storage device, DeviceLock will also check permissions at the type level (Removable). Finally, DeviceLock will also check permissions at the file content level (Content-Aware Rules).
In contrast, a USB scanner would only be checked at the interface level (USB port), as DeviceLock doesn’t distinguish scanners at the type level.
There are additional security settings (see Security Settings (Regular Profile)) that can turn off access control for classes of devices (for example, all USB printers) while others remain under control. In the case of a device belonging to a class for which control is disabled, DeviceLock allows all requests to connect this device at the interface (port) level.
Also, DeviceLock supports the white listing of specific devices (see USB Devices White List (Regular Profile)); in other words, you can turn off access control for only specific devices (for example, certain USB printer).
 
Note: If access to a device is denied at the interface (port) level, DeviceLock does not check permissions at the type level. However, if access is granted at the interface (port) level, DeviceLock also checks permissions at the type level. Only when access is granted at both levels, the user can connect the device.
Access control for protocols works in the following way: Every time the user wants to access a remote network resource, DeviceLock intercepts this connection request at the kernel level of the OS and checks the user rights in the appropriate Access Control List (ACL). If the user does not have the right to access this protocol, an “access denied” error is returned.
 
Note: Access control settings for Social Networks, File Sharing and Web Mail override access control settings for HTTP. For example, if users are allowed to access Gmail, but disallowed to use HTTP, they nevertheless can access the service.
Access checking can occur at two levels: the protocol level and the data content level. All network connections are checked at both levels, except for connections using Telegram, Telnet, Torrent, and WhatsApp, which are checked at the protocol level only.
For example, suppose a user attempts to connect to a remote host. In this case, DeviceLock would first check whether the user is allowed the connection at the protocol level, and then it would check permissions at the data content level (Content-Aware Rules).
For another example, consider the case of a user connecting to a social networking site. Here DeviceLock would first check whether Social Networks are open or locked at the protocol level. Next, DeviceLock will also check permissions at the data content level (Content-Aware Rules).
Also, DeviceLock supports the white listing of protocols (see Managing Protocols White List). With the Protocols White List, you can turn off access control for connections with specific parameters (for example, HTTP connections to specific hosts and ports).