7 Deadly Sins of Website Vulnerability Disclosure

Someone you don’t know, never met, and didn’t give permission to informs you of a vulnerability in your website. What should you do? Or often just as important, what should you NOT do? Having security issues pointed out, “for free,” happens to everyone eventually (some more than others). People unfamiliar with the process often make poor judgment calls causing themselves more harm than good. We witness these missteps regularly, even amongst security vendors who should know better. I figured that if we document some of these mistakes, maybe we’d start learning from them. Then again, the original seven deadly sins certainly haven’t vanished. :)

Note: The content below should not be considered a substitute for an incident response plan.

Pride
It’s been said many times, all software has bugs. And as long as software has bugs it will contain vulnerabilities. It’s time we faced this fact. If you receive an email from a stranger declaring the discovery of a Cross-Site Scripting, SQL Injection, Cross-Site Request Forgery, Response Splitting, Content Spoofing, Information Disclosure, Predictable Resource Location, or some other esoterically named vulnerability in your website, there’s no need to get defensive. Even if you’ve never heard of or don't understand the type of attack, it doesn’t mean you’re dumb or your baby/code is ugly. It also doesn’t mean that it’s not a real issue with serious consequences undeserving of attention. Investigate each disclosure thoroughly, communicate openly, and fix issues promptly.

Wrath
Depending on the nature of the disclosure, some are tempted to fight back against the person disclosing a vulnerability by informing law enforcement and/or their attorney. While it’s not a bad idea to seek their counsel, only in cases of fraud, extortion, or other malice is taking the next step typically warranted. Investigations are difficult to open unless the financial or data loss is substantial. And, nasty legal threats only lend credence to the fact that something major has taken place. Criminal and civil actions have been known to backfire when the news breaks. Negative PR due to a “security issue” is not something any business owner desires, especially headline news about an issue that could have been quietly resolved with little to no media attention.

Desertion
A fresh security event is no time to start polishing the resume for Monster, CareerBuilder, or Craigslist. This is when your presence is critical and where you can end up learning the most. A vulnerability disclosure is not the end of the world (instead painfully common). Then again maybe a “free” vulnerability assessment reveals you’ve been severely negligent in your duties. It’s much more advantageous to take advantage of an outside vulnerability disclosure because it clearly demonstrates what might have happened “IF” exploited by someone with malicious intent. This should provide management with the motivation to prioritize initiatives previously suggested by the security team.

Blame

Your website, your responsibility. That’s how customers see it and that’s how any respectable business owner should treat the security of their website. No one appreciates when people point the finger at others or saying it was only *cough* honeypot when an event takes place. These excuses are transparent, unbecoming and do nothing to build or rebuild customer confidence. When an organization acknowledges an issue (publicly or privately) and resolves the matter quickly, it says a lot about that their integrity. Try not to shoot he messenger. Despite how you might feel at the time, when someone privately discloses a vulnerability in your website, in their mind they’re doing you a favor. Next time you might not get the chance to handle the incident proactively.

Arrogance
Dismissing or reprioritizing a vulnerability disclosure because a website uses SSL, is PCI compliant, or sports a HackerSafe logo is absurd. Compliance != Security. These credentials will not ward off the bad guys or prevent an incident from occurring. In fact, it might attract new attackers because it represents an interesting challenge. Compliance standards are typically a minimum baseline, and the skill of the average hacker (good, bad, or gray) easily outpaces the required security measures. Mandating security throughout the SDLC does not result in perfect code. Protecting a website is very difficult as you have to defend against all issues all the time. Someone on the outside only needs to find ONE issue to place the odds in their favor.

Sloth
Ignoring or flat-out denying that a vulnerability exists will not cause a disclosure to go away. In fact, it is more likely that the discloser will become annoyed and post the issue publicly, thereby alerting the media, a competitor, and perhaps a bad guy or two. The guys on sla.ckers.org have no problem full disclosing a website vulnerability and making you the subject of ridicule. Make sure that when you fix a disclosed issue, you take the time to hunt for others just like it, because where there is one there is likely another. It’s embarrassing to have someone point out a flaw and have the same issue pop up again and again.

Uncommunicative
When a disclosee fails to communicate adequately with the discloser, the media, or customers - one thing people do very well is assume the worst. The disclosure may believe they are being ignored and proper action is not taking place, which forces them to consider full-disclosure. A reporter receiving zero responses to press inquiries might assume they’ve uncovered the next TJX and raise a large FUD flag over the company/website. Should customers catch wind of the matter and not feel properly informed, panic and revolt could easily cross their mind. Striking the right balance between open communication and discretion is difficult, but also crucial.