Do you feel confident about the security of your corporate account access controls? Can you say the same about those of your partners and contractors? Time and again the achilles heel for breached organisations turns out to be one of their third-party providers. It’s the path of least resistance for the clued-up cyber criminal and it continues to be an area of concern, which more firms would do well to pay more attention to. This week, hot on the heels of revelations that US retailer Target was breached via a third party comes news that UK telco TalkTalk has also fallen victim.
It should be another warning shot across the bows of organisations everywhere to pay more attention to the security practices of contracted third parties – especially when it comes to access controls.
As usual in these cases, the details are still emerging. What we do know is that during the latter months of 2014, TalkTalk experienced a significant increase in customer complaints. Scammers pretending to be staff from the telco apparently called up these customers, quoting their names and account numbers, and tried to trick them into eliciting bank account information or downloading malware onto their PCs.
TalkTalk noted the following:
“After further investigation, we’ve become aware that some limited information we have about some of our customers could have been accessed in violation of our security procedures.”
The firm told the BBC that the information was lifted from internal systems “via a third party that also had access to its network”. Some reports claimed this firm is an Indian call centre outsourcer.
TalkTalk is said to have started legal action against the party in question – at yet more expense to the firm. But the legal fees, brand damage, industry fines and customer churn that often follow a data breach can be avoided if firms take a more proactive stance on auditing the security of their partners.
When it comes to passwords, they must remember that handing over credentials to Privileged Accounts results in a loss of control. You might be confident that your password policies are watertight, but can you say the same about your contractors? Their system administrators may act responsibly, but what about other users who have access to privileged accounts? Even if staff are trained to follow best practice it can be difficult to verify whether these policies are being faithfully followed. Run books or OpSheets can be a potential goldmine for hackers as they often contain log-in credentials for key client systems. Such is the sensitivity surrounding run books that some firms even go so far as to take them offline completely and store them as physical copies in secure operations centres. This isn’t the norm, however – in fact, some firms even store them as spreadsheets, which are notoriously easy to copy and distribute.
The truth is that in these situations, knowledge of a password or set of passwords tends to ripple out to more and more employees over time. Having them stored in spreadsheets accelerates the process even further.
We all know organisations outsource to reduce costs and improve flexibility. But in doing so they risk turning these third-party outsiders into trusted insiders, with too much access to key systems.
In short, it’s time to minimise your risk exposure by better policing the password security of third-party providers. Doing so might even have prevented one of the biggest breaches of its kind in history – when the records of 70 million Target customers were taken after hackers stole the firm’s network credentials from an air conditioning subcontractor.
Conduct a thorough review of third-party providers with technology which audits and controls who did what, where and when on systems. Ensure any partners or subcontractors operate rigorous user education policies with staff.
Make sure third parties also operate user access according to a principle of least privilege.
Consider technology like Osirium's Privileged Access Management (PAM) which creates system specific accounts, meaning access to one system doesn’t allow a user to bounce across to another. Further, minimise risk by isolating users from credentials – meaning they can’t access other systems.