Bank gets lesson in the security failings of third parties

The most effective cyberattacks turn the tables on the security measures we take to ward off attacks. We’re always countering the attacks that have worked in the past, rarely thinking about the opportunities our countermeasures might open up.

And opportunities always abound. If malware is being delivered via attachments, we put out memos forbidding employees from opening attachments from strangers. Cybercriminals see this, and they come up with phishing — sending out attachments in emails that appear to come from the recipients’ close co-workers. So then we warn employees to not open an attachment unless it was expected. All right, say the attackers; we’ll just wait for an attachment heads up and then launch our attack.

What brings this to mind is a recent attack on a Brazilian bank. We’ve all been warned to make sure that the sites we visit are the intended ones — not altered by a strategically placed typo — and those warnings are especially important when it comes to banking sites. Attackers, of course, know that we’ve been trained to be wary. So the Brazilian thieves didn’t attack the bank — well, they did, but only after they had attacked the bank’s DNS provider. That allowed them to purchase valid digital certificates for the bank’s domain. Then they attacked the bank, planting malware that disabled antivirus apps.

A story detailing this attack in Dark Reading noted that “customers accessing the bank’s online services were hit with malware posing as a Trusteer banking security plug-in application. The malware harvested login credentials, email contact lists, and email and FTP credentials.”

The bank and the DNS provider did apparently make some mistakes — and mistakes are a great way to learn, especially if they are made by someone else. First, the bank had declined to use the DNS provider’s two-factor authentication. Had it done so, the attack might have never worked.

Second, the DNS provider, according to Kaspersky Labs, had patched a cross-site request forgery flaw on its site, Dark Reading said. That flaw, coupled with an email phishing attack of the DNS firm, may have provided the initial access prior to the patching.

This is a reminder of how dependent companies are on their business partners. You can secure your systems and your people brilliantly, but if a supplier, distributor, DNS provider, cloud provider or contractor is compromised, so are you.

Unfortunately, this huge hole in your security strategy can’t be resolved with Legal adding in a few extra clauses in your standard partner contract. It’s no longer adequate to set security specifications for your partners. You must have mechanisms in place to periodically test them — unannounced, ideally — and dole out severe punishments if holes are found.

The intent is not to be punitive. The goal is to force all partners to take their security as seriously as you do.

Oh, one other thing. If a partner offers you better security — as in two-factor authentication — take it up on it. The refusal by the bank won’t play well in a courtroom if lawsuits result from this attack.

Given that we are talking policy, you might want to consider a rule that no one can decline a partner’s extra security offer without several levels of approval. In writing. Nothing makes employees take security more seriously than the threat of paperwork.