|
|
1) Does your software meet minimum security requirements?
NIST offers the following guidance: “If encryption of stored information is employed as an access enforcement mechanism, the cryptography used is FIPS 140-2 compliant.” The key point here is that the encryption method must meet a widely accepted federal standard, such as FIPS140-2. This includes the control, distribution and management of encryption keys. If it does not meet an accepted federal standard, then the Compliance Checklist test fails. |
2) Was your software correctly installed?
The solution must be able to provide irrefutable evidence that the software was loaded on the machine. It is NOT enough for the user to simply report that they have loaded the software, or to send software to the user on a CD and ask them to install it. There has to be user-independent verification. Section 3 of the FIPS140-2 standard specifically requires that the encryption software “… employ and correctly implement the Approved security functions for the protection of sensitive information” and that it must “… provide indications of the operational state of the cryptographic module”. At the higher level, this means that the data security solution must be able to centrally detect devices that have installed software and store this information in a central auditable log. This log provides proof that the software was installed correctly. |
3) Was your software operating correctly?
The solution must be able to perform regular ‘health checks’ on the encryption software to ensure its correct operation and that no one has tried tampering with it. Evidence will be required in the form of audited logs. In addition to the NIST requirements mentioned above, the FTC ‘Safeguards’ document recognizes that in order to guarantee that software is operating correctly, companies must “…check with software vendors regularly to get and install patches that resolve software vulnerabilities”. Again, it is important that the data security solution is able to update the software on devices and to maintain an auditable progress log. If a device is stolen, it will be important to be able to prove that the security software was kept up-to-date. |
4) Was your operation of the software beyond the control of end users?
The encryption software should not allow any interaction with end users, apart from displaying warning messages and alerts. The user should not be able to modify any encryption parameters, or the way in which data encryption is applied to attached devices (handhelds, USB sticks, etc.). Furthermore, the user must not be able to uninstall the software using the Windows
Control Panel or by deleting program files. |
| The NIST FIPS140 document states the software must be able “…to protect a cryptographic module from unauthorized operation or use”. But this isn’t nearly enough – the end-user must be prevented from changing any aspect of the software’s behavior, not just the encryption module. |
5) Was the installation, operation, and management of the software controlled by qualified IT Security personnel?
If the functions of the encryption software can in any way be modified by anyone without the necessary security permissions, then your encryption compliance test will fail. This really follows on from the point in item 4: it is very unlikely that a non-qualifed person meets the standard required to implement and maintain an effective information security program. It is “reasonable and appropriate” for this responsibility be an IT function. |
|
|
|
|
