I’ve written, co-written, edited, and ghostwrote numerous security disclosures in the past. I wanted to share my thoughts on security, marketing, and security marketing so that others in the software space, security space, and marketing space can get some insights on how important communication is when patching software.
Involving marketing in security disclosure
Security is much more than patching bugs, intrusion detection, and intrusion prevention. Security is also very much about communication and the preservation of trust. In many cases, informing stakeholders — your customers, your team, and your leadership — is more important than anything else.
As such, marketing should be intimately involved in all steps of software security patching and disclosure to ensure that the communication effectively meets user needs. If not, your software runs the risk of eroding trust with your user base. There’s nothing worse than users that are in the dark about issues, whether they are security or otherwise. Communication is so important to fostering trust. Your users put their trust in you, and that’s never something to take for granted.
I’ve written before about how important it is to align marketing with product & development. And communication about security vulnerabilities underscores how critical it is to the success of your product to have marketing involved when user trust is in the balance.
If you are a developer and you’re in the midst of patching a security vulnerability, loop marketing in early to help them prepare documentation and disclosure. Marketing understands the language of your customer, and communication about vulnerabilities should be shared with as much honesty and clarity as possible in a way that your customers understand.
Vulnerabilities are celebrity bugs
No one is perfect, and sometimes you don’t know what you don’t know. Security is always evolving, no matter if you are running offense as an ethical hacker or defense as a security operations professional. Vulnerabilities happen. Patching is normal. It is not something about which to be ashamed or something that should be downplayed.
In fact, by being very clear about your process and transparent about your fixes, you actually do more good for your business and your brand than anything else.
The temptation of brushing off vulnerability disclosure
If you watch how celebrities or politicians handle negative press, you might note that they frame the conversation or distract away from negative attention. It might be tempting for software marketing to brush off a significant security issue or downplay its impact. Of course, most marketers want to elevate their brand and protect its integrity. The temptation to hide or downplay vulnerabilities can be obvious. However, in software marketing, ensuring that your customers have the data and understanding they need in order to protect their digital assets should be your number one priority.
In WordPress, your users have trusted you with their digital home on the web. In return for that trust, you owe them clear communication.
When to publish disclosure
You’ll want to ensure they have enough clarity on impact and technical details so that they can prepare communication as quickly as possible. Ideally, the patch goes out prior to communication. But the communication should go out as soon as possible.
Choosing a proper timeframe is dependent on a number of factors.
Is the vulnerability a zero-day? Is it actively exploited in the wild? Has it been identified by hackers? If so, communicate swiftly. The faster you can get ahead of the online conversations, the better off you will be.
Did your team or a responsible security researcher discover the vulnerability? Is it unknown and patched before anyone else knew? You have some time. Still, you’ll want to communicate clearly in the changelog and then publish a vulnerability report as quickly as possible. Thank your friendly neighborhood security researcher for doing the (sometimes) hard work of finding bugs and responsibly disclosing to you.
Make it super easy for security researchers to find you and establish a secure line of communication to your lead developer.
Monitor the number of installations of your patch to ensure that the majority of your users are patched prior to any publication of vulnerability details. If even a small number of users would be affected by public disclosure, it makes sense to withhold any Proof of Concept (POC).
However, publication of a POC is helpful for the greater community. A POC helps security researchers find and responsibly disclose other similar coding issues so that we lift all software to better more secure coding practices.
Obfuscating Patches Erodes Trust
I’ve seen organizations get this wrong (sometimes VERY wrong) where they obfuscate* patches with vague language in their changelogs or try to make a patch seem like it wasn’t actually a vulnerability patch. I’ve seen other vendors state that a patch is “no big deal.”
Or, I’ve seen vendors try to drop disclosure during times when they think no one is paying attention, like the LastPass breach last year where they dropped details of the extent of the breach 2 days before Christmas to miss the news cycle.
Security marketing is an opportunity
If you know me by now, you’ve figured out that my view on marketing is to be clear about what you offer users and what you want users to do. In so doing, you have to act with integrity. You’re establishing a relationship with your users and customers, and being honest and transparent with them goes a long way towards establishing a long-term relationship that focuses on mutual benefit.
As such, security events are an opportunity to either win big by establishing trust with clear communication… or an opportunity to show your true colors as someone who is just in it for the money.
Your users will judge you based on the decisions you make when the cards are on the table. Which route will you choose?
