Hardware Security Modules
In this final stretch of security month, what hopefully has been a helpful serving of security content concludes with a look at some of the technologies that support our integrated solutions. In this article, we’ll cover the hardware security modules (HSM.) An HSM is a crypto management device that generates and stores keys locally, protects that key material from leaving the device as well as enforces policy over key material usage, and secures cryptographic operations. Back before I had the privilege to work for F5, my first exposure to HSM was working on a DoD contract. The web application infrastructure I was responsible for was subject to the FIPS requirements mandating key material be kept under hardware lock and, ahem, key. For years this was under the hood of your BIG-IP appliance (on select models ordered with FIPS cards,) and is still available in that configuration. The need for crypto offload Locking away the keys in a custom hardware module in your BIG-IP is all well and good, and still applicable in many situations, but with the advent of hybrid and completely virtualized infrastructures, the need for network-based HSMs, or netHSMs (and now cloudHSMs for that matter,) arose. F5’s integration points with netHSM technologies were developed specifically for this need, allowing VE, vCMP, Viprion chassis, as well as any other BIG-IP appliance without FIPS hardware to be utilized with FIPS deployments. In the fall, John covered some of the crypto offload options available to F5, FIPS compliant HSMs and otherwise in this Lightboard Lesson if you haven’t checked it out. The Fine Print With a netHSM deployment, there are considerations on both the client and server side. For BIG-IP, a separate license is required to use a netHSM. On the netHSM, depending on the number of clients (i.e., BIG-IP devices) you use, you might need additional licenses from the netHSM vendor. Just like your infrastructure and application servers, redundancy and scale should be considerations as well, so understanding your SSL traffic needs is important. The netHSM configurations require installation of the client software on BIG-IP, so that should be included not just as part of the initial deployment, but considered in future hotfix and upgrade plans as well, as the client software will not be carried forward and will need to be reinstalled. For vCMP and Viprion systems, please note that client software will need to be installed for each guest needing FIPS validation. For further questions on the deployment scenarios and nuances with regard to either the Thales (née SafeNet) or nCipher (née Thales) solution, drop a comment below, ask a question in Q&A , or reach out to your sales team. Resources Configuring one of our partner netHSMs on BIG-IP is a more complex scenario than most deployments. The install guides for Thales (née SafeNet) and nCipher (née Thales) are below in this list of resources. BIG-IP System and Safeness Luna SA HSM: Implementation BIG-IP System and Thales HSM: Implementation Top 10 Hardcore F5 Security Features in 11.5 (good BIG-IP FIPS/nCipher/Thales comparison chart here) US Federal: CCRI Season Lessons Learned
SafeNet vs Thales (FIPS) with F5 Advice?
Doesanybody have any advice or pros and cons of Thales vs. Safenet? I know both are good but have a customer that is looking to decide between the two. Any advice on which should be used or certain environments, what should be the determining factor, etc... would be most helpful. Again, I know both are good products that F5 partners with but looking for scenarios on when to use one vs the other. ThanksImplementing THALES netHSM to our F5 LTM VE edition
Hello I’m in the beginning steps of implementing THALES netHSM to our F5 LTM VE……and wanted to know if IOS 11.5.1 with Hotfix 4 ok to implement with THALES……also looking for any best practices for this implementation, lesson learned, or things to watch out for?.......I see three different implementation manuals (11.5) (11.6) (12.0) wanted to know does it really matter which IOS version? Thanks.
