CISA sees elimination of ‘bad practices’ as next secure-by-design step

HERSHEY, Pa. — A year-and-a-half after launching its global secure-by-design initiative, the Cybersecurity and Infrastructure Security Agency is “thrilled” by the progress it’s made in getting vendors on board and now turning its focus to a new program aimed at drawing more attention to especially risky software-building practices.

Rina Rakipi, who leads strategic partnerships and vulnerability program development at CISA, said Monday during ACT-IAC’s Imagine Nation ELC 2024 conference that the cyber agency has secured more than 230 voluntary commitments from software manufacturers under the campaign. Signing on to the secure-by-design initiative means that those vendors pledge to meet within a year a variety of cybersecurity goals — covering everything from the reduction of default passwords across products to increasing the use of multi-factor authentication and eliminating entire classes of vulnerabilities.

“We are thrilled at the fact that we have over 230 software manufacturers that have voluntarily committed to this pledge,” Rakipi said. “Looking to the future, we look forward to seeing within the next year the progress that all 230 companies make.”

As software manufacturers push forward on honoring those pledges, CISA and the FBI this month released a document that serves as a natural follow-up to secure by design that is intended to stamp out exceptionally problematic issues before getting to production. 

The agencies’ Product Security Bad Practices publication touches specifically on three trouble areas for manufacturers: product properties, which covers the inclusion in software of default passwords, memory unsafe languages, user-provided input in SQL query and operating system command strings, and known exploitable vulnerabilities; security features, which includes lack of MFA and an inability to collect evidence of intrusions; and organizational processes and policies, which points to failures to publish timely CVEs and vulnerability disclosure policies.

The overarching goal of the document, Rakipi said, is to highlight for vendors “what are these bad practices” and “what should we not do.” The document is posted to the Federal Register and open for public comment until Dec. 2. 

Keelan Sweeney, section chief for IT sector management at CISA, said during a separate panel Monday that having memory-safe languages in products is especially “inherent to our secure-by-design mission at CISA.” Sweeney cited a stat that roughly 60% to 70% of vulnerabilities can be attributed to memory-unsafe languages. For manufacturers, simply prioritizing the inclusion of memory-safe languages in product development could have a truly significant effect on security.  

“What I tell developers all the time is, don’t let the perfect be the enemy of the good, right?” said Sweeney, who pointed to a Google case study that highlighted a substantial reduction in observed vulnerabilities thanks to the prioritization of memory-safe languages. “That kind of improvement, I think, is still worth celebrating.”

There’s also a push from CISA for software companies to not only bake into their products features like MFA but to make it so customers are “heavily dissuaded to remove” such protections from their security settings, Rakipi said. That could take the form of “security alerts saying, ‘Hey, are you sure you want to remove that security feature?’” Calling out that “risky behavior” would go a long way toward making the customer “really aware of what they are removing from their system,” Rakipi added.

But ultimately, CISA is fully in the mode now of putting the security burden on the software makers, pushing manufacturers to ensure that their products are secure from the start so that customers aren’t left in the dark on protecting their systems.

“If you got a car on the road and it didn’t have an airbag, it’s pretty impossible to … slap it on after the fact,” Rakipi said. “And so we don’t want to do that with our software.”