alphaspirit - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

How can security vendor hacks affect enterprises?

Several security vendors and providers have been hacked over the last year. Expert Michael Cobb explains how enterprises should prepare for a vendor hack.

A number of cybersecurity firms this year have fallen victim to cyberattacks, including Kaspersky, LastPass and Bitdefender. What should enterprises do when their cybersecurity firms are hacked? Is there anything that can be done to prepare for a security vendor hack?

The recent string of successful cyberattacks against some high-profile cybersecurity firms certainly proves the maxim that there is no such thing as "100% secure." Victims of security vendor hacks include companies such as Bitdefender, Kaspersky Lab and cloud-based password manager LastPass. The controversial IT security company Hacking Team also became the victim of a cyberattack when hackers announced they were making its client files, contracts, financial documents and internal emails available for public download through Hacking Team's own Twitter account.

Security vendors are an obvious target for sophisticated hackers, as they have valuable information about their clients, many of whom will be the attackers' prime targets. Some of these clients may assume a security vendor's own security will be flawless, but nobody's perfect, and sadly, some of the vendor hack attacks have revealed some disappointing security practices. For example, Bitdefender's security defenses failed because a server was operating with an outdated software package that contained known flaws. More disappointing was that the last line of defense -- encryption -- was not used to protect its customers' most sensitive data, such as usernames and passwords. The hacker managed to use some of these stolen credentials in attacks against some of Bitdefender's clients, posting a screenshot showing he had access to at least one client's Bitdefender enterprise security software.

Enterprises should never assume the networks of any vendor, supplier or third-party contractor are secure, and they should plan accordingly for a vendor hack. Additional precautions should be taken with providers who have privileged access either to data or security systems. Passwords should be unique for each service, and should be rotated on a regular basis. Ideally, some form of two-factor authentication should be in place to make it more difficult for hackers to use stolen credentials to access resources as a valid user.

An incident response worksheet should be drawn up for each cybersecurity firm that includes key contact details and a list of services, devices or data that would be at risk if the firm's systems were compromised in the event of a vendor hack. Also an incident response plan should be created with the help of each provider to minimize the impact of any breach, such as instructions on how encryption keys and credentials can be changed, and how affected systems can be quarantined or taken offline. They should of course be kept up to date and periodically tested. Security teams should monitor relevant newsfeeds and sites to stay abreast of the latest hacking news, as the story may break before a cybersecurity firm has time to notify all its clients.

Finally, service-level agreements (SLA) with providers that will hold sensitive data should clearly state that classified data has to be encrypted and stored on well-protected network segments with strict access controls. And remember that publication of the SLA or contract itself could be damaging in certain situations. As greater amounts of data are being stored and handled by third parties, the task of validating their security is robust and compliant with best practices is becoming even more important if enterprise data is to remain secure at all times, in all places.

Next Steps

Learn about best practices for third-party risk management

Find out if enterprises should use an open certificate authority

Read about the security risks of third-party DNS providers

This was last published in January 2016

Dig Deeper on Information security policies, procedures and guidelines