|
When it comes to IT security, my recommendation is to always choose the device or software that you deem provides the most effective product for the threat that you are trying to mitigate. When appraising potential devices, the cost of buying, installing and then maintaining them will nearly always be an important consideration. In the unlikely situation of having an unlimited budget, you would obviously choose the best tool available.
In the real world, however, it's important to weigh potential benefits of different options against their costs to ensure that you get the most out of a limited budget. Obviously, an open source product seems attractive if there's a restricted amount of money available to spend. Although if it doesn't meet the evaluation criteria, then the product probably isn't the correct choice. Also, if it is likely to lead to onerous support or administration issues, then these costs need to be taken into account as well. Let's look then at whether open source disk encryption software can provide an effective alternative to shrink-wrapped vendorware.
Firstly, I would never consider any software that uses a proprietary encryption algorithm. At the core of any product with cryptographic services will be its cryptographic module. A cryptographic module using a proprietary encryption algorithm will not have had adequate testing and validation against established standards to provide the necessary security assurance. Obviously with open source software, the cryptographic module is never going to be proprietary and can and will be pored over by security experts.
The ability to review how a cryptographic module and its cryptographic algorithms are implemented is vitally important. For any IT systems that include encryption products, there are legislative restrictions that require federal agencies to use only products tested and validated through the Cryptographic Module Validation Program, a product-accreditation program managed by the United States and Canada. This requirement helps ensure that government agencies have a minimum level of assurance that a product's stated security claim is valid. The Federal Information Processing Standard (FIPS)140, issued by the National Institute of Standards and Technology (NIST), covers government computer security standards for cryptographic modules including both hardware and software components.
Poor design or weak algorithms can render a product insecure and place highly sensitive information at risk. Interestingly, even FIPS 140 doesn't guarantee that a module conforming to its requirements is secure or that a system built using such modules is secure. It is this last point that makes many security purists argue that open source security is always more secure than proprietary security, as you can look at the full source and check whether the encryption algorithms are implemented correctly.
Just because you may opt for open source, though, doesn't mean that there's no need for caution. In my article on the recent Debian flaw, you can see how a good open source cryptographic module badly implemented can lead to a serious and far-reaching vulnerability. Similar failings to generate truly random values for keys have caused a number of similar problems, including vulnerabilities in Kerberos, the X Window System and the Network File System protocol.
More information:
Despite the tough economy, a recent survey shows companies are hesitant to broaden its use of open source security tools.
A SearchSecurity.com reader asks our expert panel, "What does the future of the endpoint encryption market look like?"
|
