Management Network Integrity Protection - The Management Software Server-to-Client network must be secured
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.
The Management Software server-to-Client network must be secured
SecureDoc Enterprise Server has security features built into itself to protect against Denial of Service attacks against the server, as follows: All communication between endpoint devices and the SES server are encrypted and protected with a mutually-held Certificate. Where uncertified-source communications occur against the ports used, the SecureDoc communication components are designed to intelligently deflect and ignore these requests - even to the point of blocking/ignoring further communications from the originating IP address(es).
Since all communication is so protected, it is not possible (without a correctly-formatted, encrypted and certificate-assured communication) for the SecureDoc client agent to mistakenly accept information or instructions (e.g. from a "man in the middle" server). As a result, it is not possible to fool a user into mistakenly believing his device has been secured. There is a separate article in this series that covers how users can validate that their SecureDoc client installation is complete and communicating with the server.
SecureDoc Client agents do not do "network advertising"; Client devices do not "call for, recieve and install" the software, they will normally either have the software pushed onto them (e.g. through SCCM, Tivoli, GPO or work-alikes) under Administrator command, or a technician will install the product from a secure network share or other media.
Once installed, each client knows very specifically only those SDConnex servers with which it can communicate, and as mentioned above, all communication is encrypted and certificate-assured.
Man in the Middle configuration attacks are not possible with SecureDoc since all configuration information required by the device during installation is made available through a set of configuration files bundled with the installer. It is recommended that these files be made read-only, for additional security.
All installation-related messages that might pass between the client and server are encrypted and certificate-assured, and neither end will accept or process any information that is not correctly-formatted, encrypted and certificate-assured.
Device Encryption Keys (DEKs) cannot be intercepted or discovered through network sniffing or other network attacks, since all information exchanged between the Server and the client will be accepted or processed if it is not correctly-formatted, encrypted and certificate-assured.
For greatest protection, all communications should ideally be performed on trusted/protected networks connections during initial installation of the SecureDoc client software, so that the DEK can be sent to the server rapidly and securely. Similarly, though it may not always be practical to do so, in an ideal world each device should be kept away from untrusted networks until after initial encryption has completed.
WinMagic recommends that (at least during device provisioning) the network should be protected and accredited to at least the highest classification of the data stored on all machines.
WinMagic also recommends for the sake of greatest security that where SDConnex servers have multiple network interface cards (NICs) AND those servers perform other functionality (e.g. print serving), the Administrator specified which Network Interface Cards addresses are used for SecureDoc communications, and that other non-SecureDoc services performed by the server use only the server's other Network Interfaces - i.e. those that are not used for SDConnex traffic.