By now everyone has heard of Heartbleed, a major new vulnerability that could let attackers gain access to users' passwords and fool people into using bogus versions of websites. But is your brokerage ready if Heartbleed strikes?
Heartbleed is a software flaw that can leave millions of servers on the Internet open to an attack, allowing sensitive data such as user passwords, to be stolen – or in the case of the Canada Revenue Agency, Social Insurance Numbers.
Anu Nayer, Deloitte Head of Security, Privacy and Resilience, stated the issue – which has been around for over two years but has only recently made headlines – cannot not be ignored.
“This is a major issue and it appears a significant portion of the Internet has been affected,” says Nayer. “Because this exploit leaves no trace in almost any system it is very difficult to determine the extent to which anyone has been compromised through this.”
At the CRA, approximately 900 SINs were reported stolen due to the Heartbleed encryption bug, The CRA says the data breach occurred about six hours before the agency shut down its web services last week. The RCMP is investigating the incident.
The heart of the problem lies in open-source software called OpenSSL that's widely used to encrypt Web communications. Nayer explained that a flaw in the programming on some versions (OpenSSL 1.0.1-1.0.1f) means attackers can view small portions of what is being stored in the server’s memory which includes data such as usernames, passwords, credit card numbers and any other sensitive information.
Grayson Milbourne, director of security intelligence at Webroot, added it is software vulnerability, not an infection. (continued.)
#pb#
“A vulnerability is a flaw in the code of an application which allows it to be exploited,” he says. “In the case of the OpenSSL Heartbleed vulnerability, researchers found a flaw in how the data was being encrypted and transmitted.”
Nayer said it is vital that the company’s technical team knows all the websites and web services the organisation has so they can check all the necessary sites. He recommends asking the IT department the following questions in addressing the issue:
• How have you determined whether each of our websites and web services have OpenSSL service enabled?
• What type of sensitive information do we have that is accessible from the internet? What type of information would have been at risk?
• Have we looked at our logs to determine if there have been any successful or unsuccessful attempts to exploit this issue? What did we find? Are we monitoring our network to look for indications of attacks?
• What steps have we taken to mitigate the issue?
• How have you confirmed that the fixes have been applied successfully?
• Have you gotten assurances from our vendors, external hosting providers and application cloud services that they have fixed any vulnerable systems?
Nayer said if the company’s website is internally hosted the organisation can run the command ‘openssl version’ on the server to find which if an affected version is being used. However, if it is hosted externally it is necessary to contact the hosting provider for more information.
“If your system uses a vulnerable version of OpenSSL (1.0.1-1.0.1f) you should immediately upgrade to OpenSSL 1.0.1g,” says Nayer. “If you are unable to immediately upgrade you can recompile the version of OpenSSL you have with ‘-DOPENSSL_NO_HEARTBEATS’ set.” (continued.)
#pb#
It would also pay to consider if it is appropriate to revoke any Certificates which were used while the organization ran exposed versions of OpenSSL.
“Even after a fix is applied,” he says, “the private cryptographic keys your systems are relying on to protect their communications could already have been compromised and this fix won’t address that compromise.”
Nayer recommends increasing monitoring for unexpected activity in your systems, and train call centre and client facing staff on how to respond to inquiries on the topic.
Additionally, Milbourne recommends changing passwords although this isn't a full-proof solution as it'll only help if the website in question has put in place required security patches.
“To be on the safe side,” he says, “I recommend changing passwords at least every three months and to make sure your personal email password is different from every other password.”
