The default mental image of a 1970’s Ford Pinto is that of a car engulfed in flames, with its rear end crumpled and the driver nowhere to be found. This unfortunate image has come to represent the flaws in consumer safety regulations and the consequences of callous cost-benefit analysis. Back then, Ford’s leadership made the misguided decision to prioritize cost over human safety by not redesigning the car’s fuel system. They believed that the cost of redesigning the system would be greater than the legal repercussions of mass-producing a dangerous vehicle. However, they were proven wrong. The Pinto’s flaws sparked a revolution in product safety, leading to significant changes in regulations to protect consumers. Now, 50 years later, we find ourselves facing a similar dilemma in the realm of digital products, seemingly waiting for a virtual explosion and a catastrophic aftermath before taking any action.
The concept of Secure by Design has been around for decades. It can be traced back to a groundbreaking paper titled “The Protection of Information in Computer Systems” by Jerome H. Saltzer and Michael D. Schroeder. In this paper, the authors called for attention to the principles of least privilege and data privacy in the emerging field of multi-user computer systems. Fast forward to 2022, when Microsoft celebrated the 20th anniversary of the Trustworthy Computing (TwC) initiative, which was announced by Bill Gates in an influential email. The TwC initiative aimed to prioritize customer security over the addition of new features.
Despite the long-standing existence of these ideals, their adoption remains more of an aspiration than a foundation in many companies worldwide. The prevailing focus in product development is still on speed and efficiency, with minimal attention given to application and security. It’s like practicing DevSecOps without the “Sec” part. Every day, we come across news stories about product design flaws that expose customer data or reveal significant vulnerabilities. The lack of commitment to security is evident across various technological sectors, from industrial control systems to cloud platforms. Recently, the Cybersecurity and Infrastructure Security Agency (CISA) reported multiple issues with input validation flaws, which have potentially opened the door to compromise. Input validation is one of the most basic checks that developers should perform, and neglecting this step is akin to strapping a gas tank to the back of a small car and hoping that rear-end collisions won’t happen.
The good news is that incorporating security into the DevOps pipeline and moving towards a Secure by Design approach doesn’t require innovative genius. Organizations like OWASP and MITRE have already done the hard work of building the components of a solid security program. All it takes is an awareness of the risks, a focus on strategic prioritization, and the will to make a change.
First and foremost, it is crucial to raise awareness among development teams and leaders about the importance of investing in security. Developers typically don’t spend their mornings reading about the latest vulnerabilities and compromises. Development leaders are more concerned about meeting release dates, price points, and adding key features. In their minds, the only way to fail is by never launching a product. Injecting a cybersecurity perspective into the decision-making process is vital in reshaping the conversation. Every product that relies on technology faces threats, whether they are significant or minor, require a major response or just a minor adjustment, or potentially impact the company’s reputation or only a small aspect of product data. Failing to acknowledge these risks is the biggest mistake a company can make from a cybersecurity standpoint. Tools such as threat assessments for leaders and secure development training for developers can ignite a change and generate buy-in for long-term cultural transformation.
Next, it is critical to establish cybersecurity as a stakeholder in product development. By including cyber requirements alongside product features, security is given a designated seat at the table and a voice in the final outcome. Too often, security is only considered at the eleventh hour before a product launch, which puts it in a challenging position of either trying to halt the business or turning a blind eye to risks. This is an unwinnable situation. By incorporating security-centric elements from the beginning of the development effort, the process can flow naturally, allowing for an unbiased dialogue about risk and compliance. Cybersecurity requirements can be broad, such as adopting a secure development framework, or narrow, such as insisting on static code analysis before every release. Like any other business requirement, these cybersecurity elements should be open to negotiation. It is rare for a product feature not to prompt a design discussion about different ways to meet the need. If fully meeting a requirement would undermine the product or eliminate a business opportunity, alternative options or compensating controls should be considered.
With awareness and requirements in place, the final step is testing and validation. Unlike the eleventh-hour scenario mentioned earlier, security issues discovered during the development pipeline can be addressed rationally. Time, cost, and scope, the core elements of project delivery, can be discussed to find win-win scenarios. Effective requirements should have tangible success criteria and designated ownership. Validation should be an objective, fact-based exercise instead of a contentious series of events.
Secure by Design is only going to become increasingly important as the negative consequences of insecure development practices continue to make headlines. The Biden Administration recently announced a shift in liability for flawed technology products, aiming to enhance protections for customers. Following this, CISA provided detailed guidance on how to meet this challenge. In June, Google called for security-by-default as the first element of responsible AI development. As the famous saying goes, “Those who fail to learn from history are doomed to repeat it.” Smart companies will heed this advice and embrace secure development before their products become the Ford Pintos of the 2020s, engulfing their reputations in lawsuits and flames.
About the Author:
Craig Burland, the CISO of Inversion6, brings decades of relevant industry experience to the company. He previously led information security operations for a Fortune 200 company. Craig has also served as the Technical Co-Chair of the Northeast Ohio Cyber Consortium and as a Customer Advisory Board Member for Solutionary MSSP, NTT Security, and Oracle Web Center. He can be reached on LinkedIn and at the Inversion6 website.