{"id":14945,"date":"2014-04-14T20:46:23","date_gmt":"2014-04-14T20:46:23","guid":{"rendered":"http:\/\/kasperskydaily.com\/b2b\/?p=1680"},"modified":"2020-02-26T18:41:08","modified_gmt":"2020-02-26T16:41:08","slug":"addressing-the-heartbleed-panic-advice-for-small-business-owners-2","status":"publish","type":"post","link":"https:\/\/www.kaspersky.co.za\/blog\/addressing-the-heartbleed-panic-advice-for-small-business-owners-2\/14945\/","title":{"rendered":"Addressing the #heartbleed panic: advice for small business owners"},"content":{"rendered":"

The Heartbleed bug was huge news<\/a> last week and still is. As a hobbyist programmer, I am saddened that attention to the art of software-making was brought on as a result of this alarming situation rather than by something positive. In our previous blog posts<\/a> on the topic we received a number of questions and comments about how to reduce the risk of a possible attack using this vulnerability. Obviously we are not alone in sharing advice (almost everyone does nowadays), but I keep noticing that the majority of blog posts and articles are more or less devoted to an explanation of technical matters. Of course, this story is highly technical in nature, but when you run your own business you don\u2019t think about it like SSL, Heartbeat, memory dumps and the like. You think about lost profits, the compromise of customer data or the unavailability of your website. Is my company affected? Were my passwords compromised and where? What is the right thing to do right now? These are the topics that I will discuss today.<\/p>\n

Summary<\/b><\/p>\n

    \n
  1. Make sure your website is unaffected. Or fix it.<\/li>\n
  2. Change the password for your online bank account.<\/li>\n
  3. Change all other passwords just to be sure. Make sure your employees do the same.<\/li>\n<\/ol>\n

    Things to discuss with the IT guy<\/b><\/p>\n

    There is always an IT guy: your full-time employee, a freelance specialist or just a support team from a company that provides you with a web service, virtual infrastructure, etc. This is a person who will eventually clean all the mess and make sure that your data stays safe. In most cases what you have to do is just to ask the right questions.<\/p>\n

    Did they steal our passwords? <\/i><\/p>\n

    This is not the right question. IT people don\u2019t know (no one does), due to the specifics of the bug. The vulnerability can be exploited without leaving any trace of an attack. This one is correct:<\/p>\n

    Is our infrastructure vulnerable? <\/i><\/p>\n

    By \u2018infrastructure\u2019 I mean almost anything with an internet connection, apart from your laptops and desktops (I will talk about them later). Website? Yes, certainly. File server? Office Internet router? In some cases, they might not be vulnerable, or, even if they are, the vulnerable protocol might not be utilized. But it is a good idea to double-check anyway: the IT Pros will then narrow the list down to services and hardware running Linux or Unix-based systems with OpenSSL installed. We won\u2019t talk too technically here, but it is useful to know the exact vulnerable versions of the OpenSSL library. Everything from 1.0.1 to 1.0.1f is prone to this bug. All versions below or above these are okay.<\/p>\n

    So my website was (is) vulnerable. What should I do?<\/b><\/p>\n

    \"wide1\"<\/a><\/p>\n

    Let the IT guys do their work. Or insist on a solution from a company that handles your website. Sometimes upgrading software on a production server is a tricky process, but hey, if major internet giants like Google managed to solve the problem in a few hours after the vulnerability disclosure, on a much more complicated infrastructure, everything else should not be a big problem.<\/p>\n

    So, closing the vulnerability on the services or infrastructure you are directly responsible<\/b> for (like your company website), is the first priority<\/b>. For example, if your website is hosted by GoDaddy, you might start by reading this<\/a> statement from their website. Next you might want to contact their support and clarify, if your website was affected. The following procedure may require additional steps from your side as well.<\/p>\n

    The passwords problem<\/b><\/p>\n

    \"wide3640\"<\/a><\/p>\n

    Now we can proceed with the \u201cdid they steal our passwords\u201d question. Once again, it is impossible to tell. Is it possible to steal a password from a vulnerable website? Yes. What other passwords could be stolen? Do you have to change passwords at the cloud service of your choice? Was Dropbox vulnerable? GMail? Yahoo? Your bank?<\/p>\n

    Closing the vulnerability on the services or infrastructure you are directly responsible for (like your company website), is the first priority.<\/div>\n

    There are two ways to evaluate the risk. First is to conduct the research: lots of companies disclosed a lot of information on the potential vulnerability of their services. Let\u2019s name a few:<\/p>\n