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
F5 and SafeNet HSM integration
As f5 doc suggest we can use fipskey.nethsm to create key/CSR/certificate as below: Generating a key/certificate using the fipskey.nethsm utilityBefore you generate a key/certificate, make sure that the SafeNet Luna SA client is running on the BIG-IP® system.You can use the fipskey.nethsm utility to generate private keys and self-signed certificates on the BIG-IP system.Display the available options.fipskey.nethsm --helpGenerate the key, using any options you need.fipskey.nethsm --genkey -o This example generates the three files that follow: fipskey.nethsm --genkey -o siterequest /config/ssl/ssl.key/siterequest.key /config/ssl/ssl.csr/siterequest.csr /config/ssl/ssl.crt/siterequest.crt The key is saved in /config/ssl/ssl.key/.key. The certificate request is saved in /config/ssl/ssl.csr/.csr. The self-signed certificate is saved in /config/ssl/ssl.crt/.crt. After you generate keys and certificates, you need to add the local key to the BIG-IP configuration using tmsh. The local key points to the HSM key, which resides in the HSM. I am a bit of confused with the above. My question is: is "siterequest.key" local key which is used by F5 LTM to access the real private key stored on HSM.
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. ThanksStrong Authentication
It’s authentication, people! Only, wait for it….STRONGER (yes i did use the strong html tag for that.) Strong authentication is a nebulous term. Many will interchange strong authentication with two-factor authentication (2FA), but that is only one method for strong authentication, not necessarily a requirement. You could have a series of “something you know” challenges that makes the authentication process more in depth and thus stronger, but doesn’t require one or more of the other multi-factor pillars in “something you have” or “something you are." So what strong authentication solutions does F5 support? The Access Policy Manager actually shines here, because it is vendor agnostic. You can plug and play a myriad of authentication systems into the process and off you go. Some of the different authentication methods include: LDAP/S HTTP/S RADIUS TACACS+ If your authentication services can talk one or more of these protocols, APM will support it. We’ve posted solutions on DevCentral with Google Authenticator (LTM via ldap and APM,)Yubico Yubikey(LTM and APM,) as well asRSA SecurIDover the years. There are some nuanced differences between all the solutions, but this diagram from Brett Smith’s APM and Yubikey article linked previously shows the general process for APM’s support of multi-factor authentication. This directory server could be Active Directory, LDAP, or RADIUS to a cloud service like Thales' (née SafeNet’s) Authentication Services as discussed in this solution brief. Beyond just authenticating local services, these strong authentication services can be utilized with federation as well, using APM’s SAML support for SP and iDP deployments. Thales (née SafeNet) has quality write-ups for their APM-integrated enterprise and cloudiDP strong authentication services available on their site. For more information about how these authentication services plug in to the larger SAML federation services, take a look at John’s lightboard Lesson on the topic. Additional Resources APM Authentication and Single Sign-On Agility 2015 APM 101 Supporting Infrastructure Lab Documents Thales Authentication
