Securing SSL Keys on your BIG-IP
Losing your keys is a real problem While losing your car keys is indeed a pain, I mean losing your Web Server Keys. Lost keys can expose your website to a Man in The Middle (MiTM) Attack.While in the middle, an attacker can use those keys to decrypt the traffic between your clients and your servers. All of the data is open to be read by the hacker. How can we help make sure you're not the poor soul in the picture? Let's start with a little Crypto background. What is a Cryptographic key? A cryptographic key is pretty much like any other key.It unlocks a door; in this case, the door is a ciphered piece of text. I'll save the mechanics for what enciphering and deciphering are for another time, but suffice to say when traffic is encrypted, we need to encrypt it in such a way that it cannot be easily decrypted. In asymmetric encryption, there are two files – one is a certificate (the lock on the door—also known as the “public key”), and the other one is the key (the, uh, key?--also known as the “private key”). The certificate is the public part anybody can have.We share that readily, possibly through infrastructure that automatically transfers the info or delivers the certificate over a handshake or an email. An example of an RSA certificate file … slightly obfuscated because I am somewhat paranoid. The key itself is what stores the secret component, and it is the file we need to protect. An example of an RSA key file. Storing Cryptographic Files We can protect our key by storing it somewhere securely and ensuring that access is extremely limited. There are tools, like hardware security modules (HSM) that do this for us, and there are standards like Federal Information Processing Standard (FIPS) 140 (https://csrc.nist.gov/publications/detail/fips/140/3/final) which define many of the specifications around storing keys, including access and retention.When there are 1000s of keys to manage, it makes sense to invest in these tools. For others, we might just want to store them in a secure location, and there are several ways to do that. File Storage Indeed, the first is file access controls.We can limit access to these files using ACLs and read/write protection, and we definitely should do that.By default, on Linux distributions, you haveto correctly set the file permissions for some applications to even use your keys. Properly setting the file permissions is necessary, but with this mechanism alone, anyone who is able to get the necessary access to any of the systems storing the key can copy the key—it is just a small string of text--and do whatever they want with it. While gaining access to a BIGIP is not simple, there are many ways this can be done such as a disgruntled administrator, a vulnerability, a weak access password, and so on. Further, OpenSSL (www.openssl.org) provides a means to add a passphrase to this file so that instead of storing the file data as plain text, the file itself is enciphered with a passphrase even to read it. Shown here is a file – the same "key" even – without and then with a passphrase: Plaintext key file. You will notice that in the image above, we can read the key's text is displayed right after the header – that is THE KEY itself. Key file protected with an OpenSSL Passphrase enciphered with AES256. However, in the next image, there's a "Proc-Type:" and "DEK-Info:" header.The text of the file is NOT the actual key but an enciphered version of the key. Doing this means that, even with file access, an attacker would still need to get the Passphrase to use the key.It adds an extra factor of authentication to use the file.It is not as secure as a Hardware Security Module, but it is at least another layer of protection from unwanted access toyour keys. Now, note that the key itself has not changed.The file is the only change.Once you read the file with the proper access, the resulting key string remains the same. Passphrases and TMOS Within the BIG-IP configuration, these files are stored in an unencrypted version or an encrypted version depending on whether or not a Passphrase was supplied when they were loaded.To protect the Passphrase-protected files, TMOS includes Secure Vault (https://support.f5.com/csp/article/K73034260), which uses a "Master Key" which encrypts the file passphrases into the BIG-IP configuration.TMOS stores the OpenSSL Passphrase, but the Passphrase itself is stored in an encrypted format in the configuration files.To access the keys, you now need both the required TMOS access permissions and the Passphrase to read the contents. So, merely gaining access to the system is not enough to steal the key and use it to decrypt confidential data! Neat, huh? But Security is HARD!!! Yup, security is hard, and I would say moderately annoying, and a lot of people skip this step of adding the Passphrase to their keys. It is easier to store them as plain text, which allows loading them into TMOS without a Passphrase. When the keys are used in a Client or Server SSL profile, that pesky Passphrase isn't required. More comfortable, sure, but this isn't a smart or secure way to work. Plaintext keys came up recently with a customer.The customer had conducted a thorough security audit and determined that having keys available in plaintext on the file system was a possible threat to customer data integrity.This finding led to a requirement that all keys across the organization need to use a Passphrase. Great idea, but how could they retrofit the 100s of keys already loaded without a Passphrase? Luckily, OpenSSL provides a mechanism for managing the Passphrase associated with a key.You can change, add, or remove the Passphrase with a simple command. Here's the command if you want to copy it: openssl rsa -aes256 -in devcentral-example-key-open -out devcentral-key-protected Using this command, OpenSSL takes the "in" file and adds a Passphrase to the "out" file, enciphering it in the desired format specified (AES256). Fortunately, this is possible using the BIG-IP RESTful API and a few shell calls to manage the underlying files.The steps are: Copy the keys. Run the OpenSSL command to add a passphrase and encipher a copy of the file. Load the new, enciphered version of the key onto the BIG-IP. Get a list of the SSL Client and Server profiles using the plaintext key. Update these profiles with the new name of the encrypted key and Passphrase. Optionally remove the plaintext version of the key. I have built a sample script that does all this for you! I've posted it on my Github here https://github.com/pmscheffler/securekey, and you're welcome to take a copy and give it a try. Since it uses your keys, I would suggest thorough testing and making sure you're not using it in Production the first time out! Protecting the Keys to Your Door If you haven't adopted Passphrases on your keys because you thought it was too much effort to maintain, I hope you take a moment to check out the script and see that it isn't a lot to manage them in this manner. If you find the script useful or have another method you use – please let me know in the comments below. Hopefully, you never have a case where your customer data is exposed in a Man in the Middle breach because you lost your keys.
F5 Anti-Fraud Solutions: Frictionless Protection for the Masses
Anti-Fraud Solutions: Why F5? In 2013, F5 Networks grew its security portfolio to include advanced Anti-Fraud services with the acquisition of the Israeli-based security company Versafe. At the RSA Conference in San Francisco this week, we have a section of our F5 booth dedicated to the Anti-Fraud solution where we are talking about the technology, answering questions and demonstrating the capabilities all week. If you cannot make it to the conference or even if you attended but missed us at our booth, that’s not a problem. I’ll fill you in on some of the details. First, just walking around the RSA Conference, it’s clear that there is no shortage of anti-fraud solutions on the market. The number is mind blowing and continuously growing. As new threats emerge, new technologies are introduced to combat them. But if you look at the approaches each company takes, they are often quite different. So that begs the question: why F5? Well, from a feature and function standpoint, we cover a wide range of web-based fraud detection and protection capabilities. The WebSafe solution, which protects web-based applications, safeguards against various forms of malicious activity including phishing attacks, Man-In-The-Middle, Man-In-The-Browser and Trojan activity such as web injections, form hijacking, page modifications and transaction modification. But what makes the solution unique is that it enables 100% coverage of the user base in a completely clientless manner, without impacting the user experience. We inject our obfuscated code via an iRule, into the web application code as part of the response data. In other words, the solution is completely frictionless, which is key differentiator number one. And because the solution leverages common browser-based technologies, we protect users who are navigating from all types of devices: laptops, PCs, tablets, smart TVs, mobile devices, etc. As long as the user is navigating with a standard web browser, they will be protected. This is key differentiator number two. From a deployment standpoint, today the WebSafe solution is implemented via an iRule on an F5 device (either physical or virtual), so there is no need to introduce changes to the web applications our customers are looking to protect from online fraud. This saves time when deploying the solution because there is no need to engage web development resources which are often outsourced or already engaged in critical projects. Our ability to deploy without these web application changes equates to savings and is key value proposition number three. As a matter of fact, many F5 customers can leverage their current F5 investment and deploy the Anti-Fraud services on their existing infrastructure, requiring no additional hardware investment: differentiator number four. Lastly, WebSafe provides protection against online fraud without a client install and with no change in the online users’ experience. Introducing CAPTCHAs, popups, etc is often too intrusive to the end user, so we are looking to protect the users without introducing friction in the process. Summary If you are at the RSA Conference, stop by booth 1801. We would be happy to demonstrate our Anti-Fraud solution and help to enhance your fraud protection capabilities. If you are not at RSA, look for further details here. We will be posting more details about F5’s Anti-Fraud solutions throughout the coming weeks.Encryption Basics: How RSA Works
The RSA Conference starts today in San Francisco, CA and we wanted to start off this week with a video that shows how RSA works. RSA is a public key cryptosystem that absolutely rocked the world of cryptography back in the 1970s. Maybe you've heard about RSA but you've never really understood how it works. Check out today's video to learn more about this amazing cryptosystem. Enjoy! Related Resources: Elliptic Curve Cryptography Ciphers Supported on BIG-IPCloudy with a Chance of Security
We found all manner of interesting practices and trends as it relates to cloud and security in our State of Application Delivery 2015 report. One of the more fascinating data points was a relationship between security posture and cloud adoption. That is, it appears that the more applications an organization migrates to the cloud, the less strict its security posture becomes. Really. I was a bit disturbed by that, too. At least at first. The reality is that simply asking about "applications in the cloud" isn't enough. It's perfectly reasonable to expect an organization that pays careful attention to application security (securing all three Cs) in the data center might not appear to be as careful if those applications move to a SaaS offering. Not because the attitude toward security has changed, mind you, but because there's no means for an organization to apply that level of scrutiny to a SaaS. They can't deploy a WAF inspect inbound requests and outbound responses, after all. But if those apps are migrating to an IaaS environment, where services like web application firewalls and application aware services can be deployed, then we're looking at a very different story. After all, if you can and choose not to, then you're purposefully degrading your security posture; hedging your bets that "in the cloud" is somehow safer than "in the data center." I'd guess that in the case of our results with respect to cloud and security practices, that there's some of both these scenarios (and probably some other ones, too) that explain the abandonment in security practices with increases in cloud presence that the data shows. Lesson learned: don't just ask about migration to "the cloud"; specifically dig in and ask whether an app is migrating to SaaS* or to IaaS or even to PaaS. That's important, because it has an impact on the amount and type of attention paid to securing that app. SaaS is more likely to be governed by an identity federation architecture that enables corporate oversight over access. IaaS is more likely to be protected by application layer security services but not traditional network security services (in the sense that the organization deploys and manages these services, of course cloud providers include these services, making them not only redundant but unnecessary). What we can, say, however, is that thanks to the migration of applications to cloud environments organizations certainly have less control over access to and security of those applications, whether intentional or not. The movement of apps toward the cloud has introduced fewer security practices on the part of the organization, and that might be a wee bit problematic. "Out of sight, out of mind" is not an appropriate attitude for information security, after all. I'll leave you with this infographic full of data related to cloud and security (and cloud security, I suppose) and a reminder that we have plenty more security-related (and application service-related, of course) data in the full report, which you can get here , along with archives of webinars exploring the data and concepts in more depth. If you're at RSA this week, feel free to stop by the F5 booth (it's the one with the big red ball ) and find out more about our full-stack approach to security, including apps "in the cloud". * I still maintain SaaS isn't really cloud computing, it's a hyper-scaled application on the Internet. We usually call those "apps", not "cloud". Call me Lori Quixote. It's my windmill, I'll tip at it if I want to.The RSA Conference: What Do You Want To Learn?
RSA is not just a public-key cryptosystem, it’s also the premier security conference in the world. Let’s face it…Rivest, Shamir, and Adleman know how to take a great thing and expand it into a really great thing! The RSA Conference mission is to connect you with the people and insights that will empower you to stay ahead of cyber threats. As you probably know, RSA will be hosting one of it’s two 2015 conferences in San Francisco next month (April 20-24). This year’s conference theme is “Change: Challenge today’s security thinking”. I just checked the website for this event, and they literally have 540 speakers planning to attend this year! In addition, they have what’s called “crowdsourced sessions” where mere mortals like you and I can go online and vote for their favorite session. The top 12 vote-getters will show up at the conference to present their topic. Pretty cool stuff. I say all this for two reasons: 1) I have the fortunate opportunity to attend the conference in San Francisco this year, and I want to be the “voice of DevCentral” at the conference. My goal is to attend as many cool sessions as I can and then tell all about it here on DevCentral so that we can all start/continue discussions around security-relevant topics that come up at this conference. I know it’s not feasible for all of you to attend, but if you have a chance to go this year, look me up at the F5 booth in the exhibit hall. I’d love to meet you and chat about all kinds of stuff. If you won’t be attending this year’s conference, please feel free to add comments at the end of this article and tell me what you’d like to hear about. I’ll do my best to attend sessions related to your interests, and I might even have a chance to interview some of the speakers and ask them directly. I’ll try my best to get a video of myself asking the speakers questions on your behalf…then I could post them here on DevCentral…wouldn’t that be awesome?!? 2) The second reason I mentioned the conference and great speakers is that one of F5’s own is in the running for two of the “crowdsourced” sessions. You’ve seen him here on DevCentral, you’ve read his infinitely wise articles about all things security, and you’ve probably named your first-born after him (no one would blame you). That’s right, I’m talking about none other than the man, the myth, the legend…David Holmes. If you don’t mind, do us all a favor and go online to vote for David’s sessions at RSA. I know he will appreciate it, and quite honestly, the rest of the world simply needs to hear more of what this man has to say. Here are the direct links to vote for David: DDoS True Stories - Mitigation Strategies through the Lens of Motivation: https://www.rsaconference.com/events/us15/crowdsourced-voting/114-ddos-true-stories-mitigation-strategies How the Skills Shortage Ushered in the Security as a Service Era: https://www.rsaconference.com/events/us15/crowdsourced-voting/123-how-the-skills-shortage-ushered-in-the I look forward to hearing from you in the comments section below…let me know what you want to hear from RSA this year!RSA Here We Come
#RSAC #F5 #infosec #sdas #webperf Security and performance can coexist. Security is an integral part of what F5 is all about. It's our mission to deliver secure, reliable and fast applications to anyone, anywhere at any time and we take all three of those goals very seriously. From hardened virtual, appliance and chassis-based platforms to FIPS compliance to supporting the latest protocols and ciphers (like Perfect Forward Secrecy), F5 is committed to security of its platforms, of the applications and data it delivers, and the consumers (and their devices) who interact with them. Our recent announcement of F5 Synthesis 1.5 includes security-related enhancements, services, and new capabilites designed not just to improve security of devices, networks and applications but to make sure organizations don't have to sacrifice performance for security. Too often the introduction of new SSL-related services, like Perfect Forward Secrecy, can degrade performance due to increases in key sizes or demands on resources from cryptographic processing. DDoS protection, too, is compute intensive, requiring inspection and analysis of traffic from layer 2 through layer 7 to ensure the most complete detection of attacks possible. That's one of the reasons we moved 15 new DDoS attack vectors into hardware, and spent a lot of time tweaking how we support Perfect Forward Secrecy; to ensure the best possible performance of the platforms that comprise the F5 Synthesis High Performance Service Fabric while making security stronger. We also added a new service, a Secure Web Gateway (SWG), to help organizations defend against inbound malware and malicious content in external sites that make their way into the network and systems through outbound activities. Our Secure Web Gateway Service, one of F5 Synthesis' Software Defined Application Services, helps organizations secure outbound traffic through URL filtering, dynamic content filtering and real-time content inspection. At RSA this year, we'll be demonstrating these services, and more. You can also check out our integration with Sourcefire as well as our new Websafe web anti-fraud service. Because protecting devices and users is as important to corporate data security as protecting the data and applications that live within the data center walls. You can stop by the booth (#1801) and chat about any of these services (or any other F5 related topic for that matter) or plan to be there for one of the live demonstrations. We know you're busy and your phone is your own personal scheduling assistant, so clicking on a demo time will enable you to easily add the demo (and location) to your calendar. DATE DDoS Secure Web Gateway Websafe Sourcefire 24-Feb 6:00 PM 6:30PM 7:00PM 7:30PM 25-Feb 11:30AM 12:00PM 1:00PM 4:00PM 5:30PM 5:00PM 26-Feb 1:30PM 2:00PM 11:30AM 3:00PM 5:30PM 5:00PM 27-Feb 1:30PM 2:00PM 11:30AM If you aren't attending the conference (and even if you are) you can follow the action on Twitter (#RSAC) and follow F5 (@F5networks) for more information and real-time opportunities, and be sure to check DevCentral during the week for blogs and videos from the show floor.Today’s Target: Corporate Secrets
Intellectual Property is one of a company’s most precious assets and includes things like patents, inventions, designs, source code, trademarks, trade secrets and more. These formulas, processes, practices and other inside information can differentiate your brand and give a competitive edge in the marketplace. An often cited example is Coca-Cola’s formula or KFC’s 11 herbs and spices. For technology companies it can be their software, hardware design, development process, roadmaps, patents and others pertinent to the company. In F5’s case, we own the patent for Cookie Persistence technology and have had to lawfully protect that valuable intellectual property. A new study from Forrester in conjunction with RSA and Microsoft entitled The Value of Corporate Secrets (pdf) concludes that while companies do focus and invest in compliance driven data security programs like PCI-DSS, they miss the mark on protecting corporate secrets and valuable intellectual property. "Nearly 90% of enterprises we surveyed agreed that compliance with PCI-DSS, data privacy laws, data breach regulations, and existing data security policies is the primary driver of their data security programs. Significant percentages of enterprise budgets (39%) are devoted to compliance-related data security programs," according to Forrester Consulting's study. "But secrets comprise 62% of the overall information portfolio's total value while compliance- related custodial data comprises just 38%, a much smaller proportion. This strongly suggests that investments are overweighed toward compliance." (from the RSA press release) Companies spend enormous amounts of time and money protecting the Custodial Data; things like medical & card payment information along with sensitive customer data, as they should and are required to do, yet losing Intellectual Property or Trade Secrets can have long lasting ramifications. The study indicated that loss of sensitive information from employee theft is 10 times more costly to a company than a single accidental loss – ‘hundreds of thousands verses tens of thousands’, the study says. Also, companies are targeted and attacked more frequently the more valuable their information. From the study, the key findings are: Secrets comprise two-thirds of the value of firms’ information portfolios. Compliance, not security, drives security budgets. Firms focus on preventing accidents, but theft is where the money is. The more valuable a firm’s information, the more incidents it will have. CISOs do not know how effective their security controls actually are. The study’s Key Recommendations: Identify the most valuable information assets in your portfolio. Create a “risk register” of data security risks. Assess your program’s balance between compliance and protecting secrets. and Reprioritize enterprise security investments. Increase vigilance of external and third-party business relationships. Measure effectiveness of your data security program. psDan Kaminsky Interview Part I
Peter Silva of F5 sits down with IOActive's Dan Kaminsky. In this extremely informative and lively discussion, the Domain Name System is the topic. DNS infrastructure, DNS vulnerabilities including DNS Cache Poisoning, DNSSEC and what's happened since the discovery of the flaw are all discussed. In 3-10 minute segments.
