Evan Schuman's StorefrontBacktalk

In another sign that investing in security isn’t enough, three customers of security vendor Bit9 ended up with malware in their systems. This happened after a digital code-signing certificate was stolen from the vendor—and that, in turn, happened because Bit9 failed to use its own product on some of its systems.

Never mind the physician-heal-thyself aspect of this incident (which is a little tough for us because, well, Bit9 did do exactly what it tells its customers not to). More to the point, it’s another sign that retailers need to stop trusting security and start thinking securely.

On February 8, Bit9 notified its customers that it neglected to install its product on some computers in its internal network. The result: Cyberthieves broke in and got access to code-signing certificates, which were then used by the thieves to create signed malware. That malware was then injected into the systems of the three publicly unidentified Bit9 customers. Bit9 revoked the certificate and has since sent customers a patch to block any software signed with it.

It’s not clear whether Bit9 or the infected customers discovered the problem first, and Bit9 didn’t respond when we asked. What is clear is that Bit9 was targeted to get access to those certificates. The vendor says its investigation shows nothing else in its systems was touched. And the Bit9 breach was only an end to a means—getting into the systems of those customers. In effect, the thieves got around Bit9’s very sturdy locks by breaking into the locksmith’s shop and stealing the keys.

It’s a problem unnervingly reminiscent of the 2011 breach at EMC’s (NYSE:EMC) RSA subsidiary that raised questions about how secure RSA customers would be. Once again, the basic security technology was solid. And yet thieves broke into the vendor to get what they needed to attack customers.

That signals the need for a different way of thinking about security products. You can do all the product vetting you want, and you could still be at risk if the security product doesn’t fail but the vendor’s security does. And that, in turn, is out of your hands.

Add to that new reality the fact that your systems are constantly being automatically probed by the bad guys—and so are the systems of your vendors—and a new flow chart for attacks becomes pretty clear. Is there a vulnerability? If so, use it. If not, what security products are being used? Is there a vulnerability at any of those vendors? If so, use it to steal something to use in attacking the original target. If not, you’re safe—this week.

All of which means you still need those security products. You just can’t trust them, at least not by themselves and without supervision. Layering multiple security products always makes attacks harder, but even defense-in-depth isn’t enough under that constant probing. You need to have security admins reviewing logs more frequently, looking for patterns that automated filters won’t catch.

You also need to assume that there will be failures, and that you need plans in place for dealing with them, even if they appear to be unsuccessful. Attackers are so far ahead of the security game from even a decade ago that you must expect your security products to fail. You can’t count on them anymore—a shift in thinking that, going forward, will make security a lot more challenging.

By which we mean “miserable and expensive,” but you already knew that.