By Craig Burland,CISO of Inversion6

The default mental image of a 1970’s Ford Pinto shows a car ablaze with the rear end mildly crumpled and the hapless driver nowhere in sight.  The Pinto came to epitomize the flaws in consumer safety regulations and the downside of callous cost benefit analysis.  Ford’s leadership had determined that redesigning the car’s fuel system was more costly than the legal impact of mass producing a dangerous vehicle.  They were wrong.  The Pinto spurred a revolution in product safety that saw manufacturers face dramatic changes in requirements to protect consumers.  Fast forward 50 years and we’re facing a similar dilemma in digital products, seemingly waiting for a virtual explosion and flaming wreckage before taking action.

The idea of Secure by Design has been around for decades.  One of the earliest references can be found in a paper called, “The Protection of Information in Computer Systems” by JEROME H. SALTZERAND MICHAEL D. SCHROEDER.  The authors called for attention to least privilege and data privacy in the new arena of multi-user systems.  In 2022, Microsoft celebrated the 20th anniversary of Bill Gates’ now-famous email announcing the creation of the Trustworthy Computing (TwC) initiative. The initiative sought to put customer security at the forefront, emphasizing the need for security over adding new features.

Inexplicably, adoption of these ideals remains aspirational rather than foundational.  Companies across the world continue to emphasize speed and efficiency in development, choosing to launch products and deliver features at pace with minimal attention paid to application or security.  It’s DevSecOps minus the Sec. Day in and day out, we read about product design flaws that expose customer data or reveal significant vulnerabilities.  The lack of commitment to security can be seen across the technology landscape from industrial control systems to cloud platforms.  Within the last month, CISA announced multiple issues with input validation flaws opening the door to compromise.  Input validation is one of the most basic checks a developer should perform.  Skipping this check is development malpractice.  It’s like strapping a gas tank to the back of a small car and hoping rear-end collisions won’t happen.

The good news is that adding security to the DevOps pipeline and moving toward Secure by Design doesn’t take innovative genius.  Organizations like OWASP and MITRE have done the hard work by building the components of a sound program.  All it takes is an awareness of risk, a focus on strategic prioritization, and a matter of will.

First, it’s essential to raise awareness with the development teams and leaders about why security warrants investment.  Developers don’t typically spend their mornings reading about the latest vulnerabilities and compromises.  Development leaders worry about release dates, price points, and key features.  In their minds, the only guaranteed way to fail is never to launch.  Injecting a cybersecurity perspective into the decision process is vital to reshaping the dialog.  Every product with technology faces threats.  Those threats may be large or small.  They may require a big response or a minor adjustment.  They may potentially impact the company’s reputation or affect a minor aspect of product data.  From a cyber perspective, the biggest mistake a company can make is choosing to remain ignorant of the risks.  Tools like threat assessments for the leaders and secure development training for the developers can spark a change and build buy-in for long-term, cultural change.

Next, it’s critical to establish cybersecurity as a stakeholder in product development.  By inserting cyber requirements alongside product features, security has a designated seat at the table and a voice in the outcome.  Too often, security is engaged just before a product launch shoved into the precarious situation of trying to stop the business or ignoring risk.  This is an unwinnable 11th hour trap.  Including security-centric elements at the start of the effort lets the process flow normally, allowing a genuine, unbiased dialog about risk and compliance happen.  Requirements may be broad like adoption of a secure development framework or narrow like insisting on static code analysis before every release.  Like most business requirements, these cyber elements should be negotiable.  It’s rare that a product feature doesn’t spawn a design discussion about different ways to meet the need.  If fully meeting a requirement would undermine the product or eliminate the business opportunity, other options or compensating controls should be considered.

With awareness and requirements in place, the final step is testing and validation.  In contrast to the 11th hour trap, security issues discovered during the development pipeline can be treated rationally, discussing time, cost, and scope – the core elements of project delivery – to find win-win scenarios.  Good requirements have tangible success criteria and named ownership.  Validation should be an objective, fact-based exercise rather than a contentious series of events.

Secure by Design will continue to grow in importance as the negative impacts of unsecure development practices drive headlines.  The Biden Administration recently announced a shift in liability for flawed technology products, intended to increase protections for customers.  CISA followed with more detailed guidance about how to meet this challenge.  In June, Google called for security-by-default as its 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 product becomes the Ford Pinto of the 2020s, engulfing the company’s reputation in lawsuits and flames.

About the Author

The Power of Policy: The Best Weapon in Your Defensive Arsenal Isn’t New TechCraig Burland is CISO of Inversion6. Craig brings decades of pertinent industry experience to Inversion6, including his most recent role leading information security operations for a Fortune 200 Company. He is also a former Technical Co-Chair of the Northeast Ohio Cyber Consortium and a former Customer Advisory Board Member for Solutionary MSSP, NTT Security, and Oracle Web Center. Craig can be reached online at LinkedIn and at our company website http://www.inversion6.com.

Source: www.cyberdefensemagazine.com