Those who think that that technology can be made ‘unhackable’, don't comprehend the overall challenges and likely don't understand what 'hacked' means.
Trust is the currency of security. We all want our technology to be dependable, easy to use, and secure. It is important to understand both the benefits and risks as we embrace new features and capabilities. For product companies, there is a challenge to show how their wares are desirable and differentiated from others. However, marketing claims around security can potentially undermine customer confidence, enrage potential attackers, and be a source of embarrassment.
The latest 'unhackable' tech marketing claim, for a digital wallet no less, falls after just a week. Luckily, it was an ethical hacker who disclosed their findings and not a cybercriminal who would have concealed the capability until such time as they could victimize users for their financial gain. There are many lessons to be learned.
Here are my top 4 tips for avoiding the pitfalls of overstating product security.
- Never let marketing make promises (or guarantees) that products are "secure" "unbreakable" or 'unhackable" when talking about the security of products. These words are absolutes for a domain where it is not possible. If there is a security story to be told, be cautious, accurate, and specific. It is far too easy to self-sabotage customer trust by flagrantly throwing about promises that can’t be kept or worse, quickly disproven. It makes confidence look like arrogance, deceit, or ignorance. To put this into rational terms of how momentously bad this is, I am not aware of any digital technology ever deployed into the real world for widespread use that is ‘unbreakable’. Do you really believe yours is the first? Don’t let hubris be your downfall.
- It is important to understand how secure and resistant to attack your product is, but it requires a comprehensive evaluation and expert opinions. Security technologists (engineers, architects, coders, etc.) have different perspectives than security risk experts (threats, intelligence, methods, likelihood & impact calculations, etc.). Both are needed to understand the whole picture.
I would venture a guess, that in the case above, the security technologists likely stated all known vulnerabilities were closed, which was interpreted by marketing or management as their product was bullet-proof, while the security risk expert group was likely ignored or never engaged. Risk intelligence professionals would have outlined the types of threats most motivated, the objectives they would pursue, the likely methods employed, and what resources it would take to break the fundamental chains of trust.
Both disciplines, technical and intelligence, are needed when determining resistance, translating viewpoints, and comprehending risk. Don’t rely solely on a technical vulnerability scan or code audit to determine risk, as it is simply one facet of a complex model and only provides a partial overall outlook.
- Never ignore how technology will be used, by whom, and what dependencies exist (network, supply chain, endpoint configuration, etc.). Anything is fair game, including the technology, processes, and people involved in the development, implementation, use, and sustaining support. Attackers don't follow your product manual rules. They will be creative in finding the easiest way to exploit your products, likely in ways you didn’t consider.
- Be kind to the white-hat hackers (i.e. security researchers) as they will work with you to make your products better. Save your venom for the cybercriminals and black-hat hackers who are agreeable with making your customers, their victims.
Trust is key for adopting technology. As the saying goes: "Trust is earned in drips and lost in buckets". Choose your path, messages, and partners carefully.
Interested in more insights, rants, industry news and experiences? Follow me on your favorite social sites for insights and what is going on in cybersecurity: LinkedIn, Twitter (@Matt_Rosenquist), YouTube, Information Security Strategy blog, Medium, and Steemit