Do you notice when you buy things online or log into your bank’s website, your address bar says “https://” instead of “http://,” or you get a pop-up with a closed lock icon? That means your web pages are going through TCP/IP port 443 instead of port 80. HTTPS is just like HTTP, the internet protocol that serves most web pages, but it goes through an encryption layer, to make your web session more secure. Secure Sockets Layer evolved into Transport Layer Security, and the most widely used open source version of that it OpenSSL. There are also TLS/SSL versions of FTP (file transfer protocol), among some other TCP/IP internet services. So, TLS/SSL doesn’t only pertain to the web. It’s absolutely vital that sensitive web data, like online shopping (your credit card numbers!) and banking goes through a layer of encryption. Some of us like to go beyond that and we install plug-ins or add-ons to our web browsers that make sure that our all of our web data goes through port 443 whenever the web server we’re engaged with has it available. Those plug-ins and add-ons aren’t even necessary in the latest stable versions of Google Chrome on both desktops and on mobile devices, because recent versions of Chrome and some other web browsers now do that automatically. In the wake of the Heartbleed vulnerability, even with my many years of web development and IT security expertise, I was surprised to learn how many entities have been using OpenSSL. I’m usually a passionate advocate of open source software. When source code is readily available to anyone, there are a couple of major benefits. One is that we can examine how the code works and if there are any vulnerabilities or bugs in it. Pretty much any code longer than a dozen lines will have bugs, because code is usually written by humans and humans make mistakes. Even software that writes its own code was coded by human beings, so the same applies. The second benefit is that people with programming expertise can make changes to open source code without having to worry about intellectual property rights. Well, as long as the open source license, such as GPL, remains intact. That OpenSSL is open source code and the vulnerability was unpatched for so long surprises me even further. Do you use the web most days? Chances are, you’re affected. Google, Facebook, Dropbox, and many government and commercial websites are amongst those definitely or probably affected. Check out this scan log, posted at GitHub, for an extensive list: https://github.com/musalbas/heartbleed-masstest/blob/master/top10000.txt Make an inventory of the web services you use, especially those you have usernames and passwords for, and use your browser’s search function to see if they’re among those affected. For the web services you have accounts with that are on that domain list, do what I did and change your passwords for them. Dropbox and many of the other affected services have said they are working on security patching their OpenSSL configurations, or replacing their OpenSSL configurations with other TLS/SSL programs. But even with all of their security patching behind the scenes, you won’t be properly hardened until you change your passwords. It’s your login credentials that give you access to encrypted data transfer on those websites. Do you operate your own web services, or operate web services for your employer? Here’s some of what you must know. The affected versions of OpenSSL are versions 1.0.1 through 1.0.1f. 1.0.0, 0.9.8 and 1.0.1g are not affected. If your OpenSSL configuration is one of the unaffected versions, assure your customers and clientele of that. If your OpenSSL configuration is affected, upgrade to 1.0.1g or switch to another TLS vendor. Let your customers and clientele know about that. Transparency and proactivity are key to mitigating the potential for litigation, and to maintain the confidence of your customers and clientele. Whichever version of OpenSSL, or TLS in general that you’re using, it’s best to still do a vulnerability scan. A web based domain scanning service can be found here: https://filippo.io/Heartbleed/ From there, you can also contact the developer for further assistance. I really hope Heartbleed has woken the right people up. Corporations and organizations of all sizes that operate web services must understand that security is an everyday process. I’m baffled by the number of people in IT and development I’ve met over the years who think that security isn’t everyday work. That attitude will always come back to haunt them. It’s never a waste of money to hire penetration testing services. Your pen testers must be a third party, because your in-house IT and development staff know too much about your computing systems to be able to explore them like a blackhat. And a third party playing blackhat is always the best way to learn about your vulnerabilities. Hire pen testing services whenever major changes are made to your networks of computing systems or at least once ayear, whichever is more frequent. Do you have more than a dozen IT staff? If so, you should hire a full time IT security practioner. A security-minded network administrator is great, but medium to large organizations and corporations should also have in-house, dedicated IT security. It’s a lot more expensive to correct security flaws after-the-fact than to be proactive about security at all times. And the one factor that accountants will always miss, because it can’t be exactly quantified, is the affects of damage to your corporation and brand’s reputation due to publicized security problems. Take my word for it, if and when your corporation has a major security problem, the odds are good that it will be publicized, the question is only when. As for myself, I host a lot of my own data in the data center space I share with my husband. I have complete control of its security, and I scan and harden our servers frequently. I also store gigabytes of documents, stuff that I don’t mind Google seeing, in my Google Drive account. I have about the same amount of data stored in my Dropbox. But now that I believe they’ve been lax about security, I’m going to migrate from Dropbox, close my account, and therefore Dropbox will no longer be profitting from me. Don’t let that be you. Oh, and folks… Open source code is very easy to scan, debug and patch! Hopefully, Heartbleed has encouraged you to be proactive about that. Because all of the damage done by Heartbleed will all be for naught if we don’t learn from it. History that we don’t learn from will repeat itself. References Heartbleed.com http://heartbleed.com Heartbleed Domain-based Vulnerability Scan Log https://github.com/musalbas/heartbleed-masstest/blob/master/top10000.txt Heartbleed Test https://filippo.io/Heartbleed/ Websites affected by Heartbleed http://m.tech.firstpost.com/news-analysis/websites-affected-by-heartbleed-change-your-gmail-facebook-and-yahoo-passwords-today-221526.html The NSA’s Heartbleed problem is a problem with the NSA http://www.theguardian.com/commentisfree/2014/apr/12/the-nsas-heartbleed-problem-is-the-problem-with-the-nsa
