In the early 2000s, a courageous security initiative saved a major software company. At the time, this company was beleaguered with security vulnerabilities. Their products were being regularly hacked and ridiculed in the marketplace. It seemed like they had become a poster child for insecurity, and it was damaging their business. How did they respond? Did they start legal action against hackers? Did they attempt to blame victims? Did they suppress the bad press?
No. This company made the choice to do better. They made security their “highest priority” — a fight they knew they could win. They stopped development on all their products, fixed weaknesses and put their developers through security training. They designed new security controls, set new standards, created new processes and even wrote their own security tools. And it seems to have worked.
That company was Microsoft, and their “Trustworthy Computing” initiative was a huge success. Over the ensuing decade, I saw them reclaim their reputation, take back the market and reestablish their industry leadership. As Bill Gates said in 2002: “all those great features won’t matter unless customers trust our software. So now, when we face a choice between adding features and resolving security issues, we need to choose security.”
Today, the fight is on your doorstep.
Today, your company faces an existential challenge. You’ve turned everything distinctive about your company into code. Meanwhile, the hacking game has moved up the stack — from the operating system to your application layer. Hackers may be able to easily access your web applications and web APIs, which are likely full of valuable data and capabilities and rife with vulnerabilities. Many organizations simply don’t include software risk in their decision process — this is the dangerous seduction of automation.
If you’re like the typical Fortune 1000 financial, insurance or health care company, you have thousands of these web applications and web APIs, both “internal” and “external” (as if that distinction means anything anymore). Web applications can include millions of lines of custom code, open source libraries and configuration files, and I’ve seen that web flaws are a common cause of breaches. We’re not talking about super-complex, unique vulnerabilities that require specialized hacking skills to discover. Instead, they’re basic “blocking and tackling” problems that we’ve understood for many years, such as SQL injection, path traversal, cross-site scripting, weak access control and using libraries with known vulnerabilities.
Given all this, it’s not surprising that we have so many breaches. And remember, we may not hear about the vast majority of breaches — breach disclosure laws only apply in very narrow circumstances.
Are you abusing your customers’ trust?
Consider the trust that you put in the websites you use every day. Why do you trust these websites? What evidence do you have that they are safe? Relying on something without evidence is simply blind trust. Many organizations have the same myopia about their own software. They’ve convinced themselves that they are doing good security despite decades of vulnerabilities and breaches.
As Michal Zalewski said in The Tangled Web, “[Risk management] introduces a dangerous fallacy: that structured inadequacy is almost as good as adequacy and that underfunded security efforts plus risk management are about as good as properly funded security work.”
You can make a conscious choice, as Bill Gates did in 2002, to build trust with consumers over time. This isn’t about cost, as practicing strong security is likely to save you money over time. The challenge is moving your culture away from compliance, risk management, and “structured inadequacy” and toward continuous, transparent and convincing assurance.
If you think your company can’t produce a compelling argument that its applications are secure, consider whether abusing the trust of your customers is a good long-term business strategy.
Which company will step up?
Which company in your sector is going to dominate your market by creating trust? Which of your competitors is going to justify the trust people put in their web applications and APIs? Which will share the evidence showing how their code defends against the threats that matter?
One powerful way to share your security argument is in the form of a story. This is a structured approach that shows:
• You understand your application’s threat model
• You have the right security controls to counter your threats
• Your security controls are correct and effective
• You monitor your software for attacks and prevent vulnerabilities from being exploited (something my company helps with but that organizations can do independently)
The top half of your argument should be a set of claims you structure around your threat model. You can probably reverse-engineer it by simply asking “why” about the defenses you already have in place. The bottom half provides evidence justifying those claims. Your evidence can come from a variety of sources, but direct evidence that you generate from the running application is often the most compelling. Use this approach to focus on what matters so you can streamline your security work and avoid the tremendous potential for waste in the traditional “managing insecurity” approach. Ideally, you can generate the evidence to support your story by using a security as code approach.
Note that achieving trustworthy software doesn’t imply any particular organizational structure or engineering method. I believe the focus should be on achieving outcomes, not on trying to force your organization to follow a maturity model. Perhaps a team of experts does the work, or maybe it is fully automated, done once a year or outsourced entirely. The method you choose should match your engineering culture. Still, beware of “shifting left” by simply dumping security tools and activities on development.
This article is shared by www.itechscripts.com | A leading resource of inspired clone scripts. It offers hundreds of popular scripts that are used by thousands of small and medium enterprises.
