Symantec source code stolen: What Went Wrong?

A little while ago some (allegedly) Indian based hackers (ref:, announced that they got their hands on some of Symantec’s source code (SEP 11 and AV 10.2 respectively).

Don’t worry though, according to Symantec it’s all cool because they weren’t breached (it was a third party/one-armed man) and only “older code” was exposed. This is an example of a vendor’s glaring ignorance about its client base and a sort of arrogance about their own product. Let’s examine some of their arguments.

The Third Party Issue

We hear this one a lot. “This is our vendor” or “We can’t fix this, it’s some third party’s problem.” This is purely an attitude problem and I wish this one would just go away. You have to take control of your supply chain and your vendors.

Surely a company of Symantec’s size has some sway over their suppliers and vendors? You would think so at least. I have customers who have larger upstream clients that demand they receive regular audits and tests to assure some level of security standard is being followed. It isn’t perfect but it’s better than nothing.

The bottom line is: When it’s your stuff you don’t get to blame a third party, it really is your problem and you need to own up to it. Complete disclosure of the breach is the only way to maintain your integrity at this point.  

Older Code? Not Our Problem!

The problem with this argument is that (and I’m PURELY guessing here) a lot of their customers, even enterprise users, haven’t upgraded lately. I know, I know, security evolves fast, etc.

But a lot of larger, more conservative places have a “stay one version behind” policy for all their critical or possibly production-killing software. This is for any sort of software, not just security products. If their defense for this is, “well it was just older stuff and everyone should be upgraded anyway,” and it appears it is, then they are not living in reality.

Upgrades, even with security software we like to think is critical, are neither automatic nor pervasive. In light of this release though, I would encourage clients to upgrade if this is software you are reliant upon.

Seeya Later Source Code

This is always where the rubber meets the road. I am a firm believer that security systems should be able to hold up to open scrutiny but often I’m alone in that. If this code leak really makes Symantec’s software useless for securing systems I would contend they’re doing it wrong.

That being said here’s a little homework, go Google “antivirus evasion techniques” and see what you find. The “bad guys” don’t actually need the source code to evade much of it so I doubt this leak really increases that risk much. I know this seems snarky and pessimistic but that’s the point I’m at with AV vendors.

I just don’t think most of it is quality code and liken much of it to snake oil. Obviously that’s my opinion but I’m sticking to it.  

Okay smarty-pants, what do I do now?

Obviously if you’re relying on this software for even an illusion of protection you should upgrade as soon as possible. At this point though I think you should start examining the levels of protection you have in place for malware/virus/phishing threats.

Do you have an internal honeypot that can help to detect an early outbreak? No? You should. Are you making effective use of DNS blackholes and other blacklisting methods? No? You should be.

Do you have a testable, useful user security awareness program in place? No? Why not? As the Google search hopefully convinced you, A/V by itself is no longer enough, you need layers to help protect you when something fails.