The most effective cyberattacks turn the tables on the security measures we take to ward off attacks. We\u2019re 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 \u2014 sending out attachments in emails that appear to come from the recipients\u2019 close co-workers. So then we warn employees to not open an attachment unless it was expected. All right, say the attackers; we\u2019ll 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\u2019ve all been warned to make sure that the sites we visit are the intended ones \u2014 not altered by a strategically placed typo \u2014 and those warnings are especially important when it comes to banking sites. Attackers, of course, know that we\u2019ve been trained to be wary. So the Brazilian thieves didn\u2019t attack the bank \u2014 well, they did, but only after they had attacked the bank\u2019s DNS provider. That allowed them to purchase valid digital certificates for the bank\u2019s domain.\u00a0Then\u00a0they attacked the bank, planting malware that disabled antivirus apps.A\u00a0story detailing this attack in Dark Reading\u00a0noted that \u201ccustomers accessing the bank\u2019s 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.\u201dThe bank and the DNS provider did apparently make some mistakes \u2014 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\u2019s 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\u2019t be resolved with Legal adding in a few extra clauses in your standard partner contract. It\u2019s no longer adequate to set security specifications for your partners. You must have mechanisms in place to periodically test them \u2014 unannounced, ideally \u2014 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 \u2014 as in two-factor authentication \u2014 take it up on it. The refusal by the bank won\u2019t 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\u2019s extra security offer without several levels of approval. In writing. Nothing makes employees take security more seriously than the threat of paperwork.