Does the world really need one more white paper? Do we need more of some watered-down version of a product instruction manual and specification guide devised of other people’s quotes about other things and tied together with sales pitchiness? Do we?
Why do we call them white papers? Well, like absurd holy grail humor, wizard orphan fiction, and romanticizing historically murderous monarchy, we have the British to blame for it.
Apparently the 1922 Churchill white paper in response to the Jaffe Riots is the best well-known example starting this trend of IT product vendors passing off positive opinions of their own products as factual, decision-making guidance. Which is why this white paper is a response to Churchill dressing raccoons in school children’s outfits and raising them as his own children. <Editor please don’t bother with fact-checking that as this is now officially a white paper.>
Since I have now called this article a white paper, I can fill it with whatever opinion I want to pass off as fact. I can use whatever statistics I want to sell my opinion. I can take any sentence out of any context to bolster my claims. And in the end, you’ll make a business decision off of it and I’ll get rich.
So here’s my stab at a white paper:
The Glory that is Patch Management
Patching vulnerabilities should be your first line of defense. CSO shows that 80% of... exploits have patches. According to NIST SP 800-40r3 (PDF), “Organizations should implement the following (patching) recommendations to improve the effectiveness and efficiency of their enterprise…”
Patching not only protects your network greater than any other security devices can, it also promotes feelings of security to employees and customers.
Famed explorer Sir Edmund Hillary agrees, “I still get the same thrill out of glimpsing a tiny patch…” Even Jane Goodall, authority on the psychology and sociology of human-like beings, the primary science of which social engineering as a cybersecurity threat is derived, says, (cybersecurity protections) “...are isolated in a very tiny patch….”
Good stuff, ain’t it? Anyone who wants me to write their white papers can now line up. Seriously, does your white paper have quotes from Jane Goodall and Sir Edmund Hillary? I doubt it. Mine does. Therefore, vis-a-vis, in conclusion, not withstanding, mine is better.
But me showing off how great I am isn’t the point. It’s probably not even the reason why you’re reading this (but winky emoji we both know it secretly is though).
Let me tell you what I want to learn from a white paper, especially a cybersecurity product white paper, is whether or not a product or service is right for me. Your white paper can be pleasing to the eye and give the illusion of authority if you want. I don’t care. But it better actually tell me something about the product.
You can even tell me why I need it. Maybe there’re people out there who aren’t me that have no idea why they’d need encrypted shoelaces for their Zips brand sneakers. I totally get it. But there are people who don’t so go ahead and say why. But for the luvva Odin, it had better have realistic use cases or I’ll bring the thunder down on you myself. At least metaphorically. And in words. And to myself in my head. I’m not very confrontational….
But of all things, this is what I expect from your cybersecurity white paper:
- Explain to me how your product works. Showing me with pictures is even better. And not just high-level overview. If your secret sauce is how it works, you’re in for a rude awakening a week after your competitor buys one. So show me. I don’t need to know your algorithms and all the calculus or if-then statements, just what it’s actually doing to protect my stuff.
- Show me how I integrate your product into a typical system or network. That will tell me if it’s a situation or environment I’m familiar with. But many of you are pushing white papers to sell snow tires that never mention snow. You just push safety statistics over “normal” tires without once showing me that they operate on mountain roads covered in snow.
- Tell me what I’m physically getting when I buy your thing. Is it software I can install and then archive a copy for next time I need to install it? Is it a cloud service and I get a handful of nuthin’? Is it server hardware or a sweet-looking gadget that I get to keep? Is that all of it? What is it? What am I getting?
- Tell me if it’s running in any real environments successfully. Or tell me it’s running in a lab somewhere, so I know where your statistics come from and how realistic they are.
- Tell me if it’s a product I install or something my developers or IT team needs to integrate into our operations. Tell me how long that usually takes.
- Show me what it looks like when it’s running. An artist’s rendition is okay too if it’s something abstract or a piece of code to integrate. I just want to know what I can expect. As you know, meeting expectations is up there with being on time, being dressed appropriately, and not slurping coffee, as how you keep a customer.
- I need to know if I’ll need to buy anything else with this product. What does this require to work? I don’t care if it’s another RJ46 Ethernet cable, if your product comes and I have to take the cable out of our break room TV to connect it because you didn’t include the cable then we’ll have a problem. And why didn’t you include the cable? Seriously, you charge $20,000 and don’t give me a fifty-cent cable?
- I also don’t need to know what pseudo-research lobbying organization put you in their ‘hotshot’ category. That only tells me you’re wasteful trying to buy your way to the top. I’d rather know you spent that money on better research, better developers, better snacks, I don’t care as long as it’s not trying to get some pundit to look at you, so you can sell your product to one of those eight big companies that you falsely think matter. Instead, give me quotes from your real customers. Or better, a use case from a real customer.
- Tell me what problems I might encounter. Tell me why sometimes your product doesn’t work. Even if the problem is customers installing it wrong I want to know. Because I want to make sure I have the right people who can do the installation right then, even if I have to pay your team to do it.
- And while I know I said finally before, I needed to add that you should include where I can get more details, contact info, or find you on social media. So, this is more an addendum to the finally above. Back off, I’m the writer so I can do that if I want.
- Finally, tell me something about your support channels. I don’t wanna have to hunt you down to get an answer. Tell me where I can find how you do security advisories, bug bounties, regular updates, and customer relations. It’s not okay that you don’t have those things so if it’s not in there then I’m out. Because no matter how shnizzle your dizzle is it’ll break for someone at some point, and that someone will become your worst enemy if you can’t effectively and efficiently provide support.
In conclusion, because all white papers that have conclusions are stupid unless they’re articles made to look like white papers, follow the above points, and me and about 90% of your potential buyers won’t have a problem with you. You’ll make white papers great again. Winston would want that.
