How IT leaders can assess “secure-by-design” software claims

It’s no secret cyberthreats are increasing. The cost of reported cybercrime in the US jumped 22% last year to more than $12.5 billion, according to the FBI’s Internet Crime Complaint Center.¹ One issue is weaknesses that have been preserved in software by traditional approaches to coding and security. To combat these risks, there is now a concerted effort to create software that is secure by design. For example, the US Cybersecurity and Infrastructure Security Agency (CISA) has outlined a set of actions vendors can take to prove they are adopting secure by design the principles.²

But without enforceable standards and metrics, it’s difficult for IT and security leaders to assess whether and how vendors are carrying out this secure by design approach. Here are some steps you can take.

Incorporate secure by design practices into risk assessments

Vendor risk assessment is a standard process by which enterprises identify and evaluate the potential hazards associated with a vendor’s products and operations. IT and security leaders can use this process to focus on secure by design principles and practices, says Michael Riemer, Field Chief Information Security Officer, for Ivanti.

“For us, as a software vendor, it means taking full responsibility for our own products,” Riemer says. “You look at the solution’s entire architecture and consider security in all areas, such as architecture design, storage, connectivity, usage, and so on.”

As part of the risk assessment, enterprises should also consider requiring a SOC 2 Type 2 report. This type of assessment provides more assurance about how a vendor protects customer data and information. It entails a third-party cybersecurity audit that assesses how the vendor’s internal security controls and practices work over an extended period of time.

Here are some key questions every vendor should be able to answer:

• How often do you do penetration testing?
• What types of penetration testing are done?
• Do you perform both static and dynamic code analysis?

Evaluate coding practices

Traditional coding practices are sequential: one team works on a module, then hands it off to the next team and so on. But this preserves weaknesses that are introduced to the code base, says Ivanti’s Riemer.  By restructuring teams into “pods” or groups, each with a dedicated security architect, weaknesses can be weeded out from the start. This was a major change for Ivanti, says Riemer. Suppliers should be able to demonstrate these organizational changes and new practices.

Assess the secure by design transparency

Vendors should be able to publicly disclose their secure by design goals, and show that they are or will be reporting metrics on a regular basis. Customers should also be able to track the vendor’s progress through its software modules.

“We’ve created specific goals, established a baseline and metrics, and will publish quarterly updates of these metrics starting in October 2024,” says Riemer. “We’re holding ourselves accountable for our secure by design progress. These metrics will show what software modules we’ve analyzed and how deep the analyses have gone in identifying and rectifying weak coding practices.”

The bottom line

Business and IT leaders can use the principles of secure by design to assess the progress made of their software suppliers in creating code that is inherently more secure. Secure by design enables these leaders to minimize business risks.

Click here to find out more about Ivanti’s commitment to secure product design.

¹ 2023_IC3Report.pdf

² Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software (cisa.gov)