Device Integrity Protection - How users can validate that SecureDoc is being deployed to the correct device, and is actually protecting the device

While SecureDoc performs an invaluable service ensuring that data is protected by encryption, and that user access to SecureDoc-protected devices is locked down and governed by permitting only specific users to authenticate at Pre-Boot, there are other risks that any security-conscious organization should be aware of and include in its overall security design.

How users and Administrators can validate that SecureDoc is being deployed to the correct device, and is actually protecting the device

In order to protect against the risk of having SecureDoc installed on devices on which it should not be installed, as a "best practice" recommendation, technicians or other users that are to tasked with installing the SecureDoc client software  should validate that the device intended for installation is the correct one, and has not been somehow compromised prior to installation by checking identifiers such as

• asset tag numbers
• tamper label identifiers and label integrity
• device serial numbers (usually provided by device manufacturers)
• disk serial numbers and expected number of disks
• processor identifier

In the event that a user or technician detects an un-sanctioned/un-approved device or that the device may have been tampered with (see article on Tamper Labels), the IT Manager and SES Administrators should be notified and steps taken to determine how this device came to be mistaken or tampered with.

How to determine that SecureDoc is securely installed on a given endpoint device

In order to protect endpoint users against mistakenly believing their devices to be protected by SecureDoc when in fact it is not, here are some recommendations for IT or end users to use to assure themselves that SecureDoc is legitimately installed, and that it is protecting the device.

• Program: First, the user can check the Installed programs list to determine that WinMagic SecureDoc is installed.  
• Pre-Boot Authentication: The SecureDoc Pre-Boot Authentication (if enabled) will normally present a brief message on a black screen, to the effect "Press 'a' for alternate ... " following which will be a Pre-Boot Authentication panel that prompts the user to enter credentials (usually User Id + Password).
• Existence of Tool Tray Icon: Once in Windows there should be a small SecureDoc tool tray icon that looks like a tiny padlock in a circle (in the Windows lower-right tool tray area) unless it has been explicitly suppressed by the SES Administrator through Device Profile settings.  
• Test communication to SES Server: Right-click on the Tool Tray icon, and choose the "Communicate with Server" option.  Within a few moments a "balloon" pop-up message will appear, confirming either that the client was able to successfully communicate with the SDConnex server, or that it was not able (e.g. if there's no network link available between the two). In either case, this will indicate an attempt by the SecureDoc component(s) to communicate with the SDConnex server.  Since no device can successfully communicate with the SES server without the server-issued Certificate, this proves that the device is trusted by the SES server.
• Launch SecureDoc Control Center: Right-click on the Tool Tray Icon (or launch the client software from Start | All Programs | SecureDoc Disk Encryption | SecureDoc Control Center.  If the Logon splash screen appears, that will further prove that the SecureDoc client software is installed. The user can close this splash screen.
• Check device in SES Console:  Having got the user to force communication with the SES server, find the device in question in the SES server console, then validate the encrypted status.  The Audit Log history for the device should show that it has just communicated with the server, and when a legitimate SecureDoc-protected device has communicated with the server, it always communicates its encryption status.  This cannot be faked, due to the very strong protection built into both the communication channel, exchange of credentials, the proprietary compression of the data exchanged and the encryption of the information exchanged between the client device and the SES server.
• Check existence of escrowed device key in SES Console:In the SES Console, there will be a device record for the device in question.  Looking in the device details panel, near the top right there will be a reference to the Key used to encrypt each device.  
  • If desired, this Key can be validated against the Key list in the Keys tab of the SES console, though this is not necessary since the reference in the device record is tied to the actual key used through the key record's primary key in the database and can only display the key name that coincides with the primary key.