The harbinger of things to come for software developers came earlier this spring when CISA Director Jen Easterly singled out the private sector during a speech at Carnegie Mellon University for the continued flood of data breaches plaguing the U.S.
In her view, the private sector has become too comfortable shifting the safety burden for products to consumers -- which has subjected them to endless patches, updates and privacy risks -- rather than making sure the products are safe when they hit the market.
“The situation is not a sustainable one,” Easterly says. “We need a new model where consumer safety is front and center in all phases of the technology product lifecycle — with security designed in from the beginning — and strong safety features enabled right out of the box, without added costs,” Easterly says.
This was followed by the release of Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default -- joint guidance urges software manufacturers to take urgent steps necessary to ship products that are secure-by-design and -default.
Easterly acknowledged this effort will require a “significant shift” in how technology is produced, including the code used to develop software. But she argues adopting the guidelines will help both organizations and technology providers.
“It will mean less time fixing problems, more time focusing on innovation and growth, and importantly, it will make life much harder for our adversaries,” Easterly says.
Senior Execs Called Out
CISA’s new guidelines were developed with recommendations from the National Security Agency (NSA), Federal Bureau of Investigation (FBI) and international partners in Australia, United Kingdom, Canada, Germany, New Zealand and the Netherlands.
“Secure-by-Design” means technology products are built in a way that reasonably protects against malicious cyber actors successfully gaining access to devices, data and connected infrastructure. Software manufacturers should perform a risk assessment, CISA says, to identify and enumerate prevalent cyber threats to critical systems, and then include protections in product blueprints that account for the evolving cyber threat landscape.
“Secure-by-Default” means products are resilient against prevalent exploitation techniques out-of-the-box without additional charge. These products protect against the most prevalent threats and vulnerabilities without end users having to take additional steps to secure them.
Among other things, CISA’s directive calls on companies to “embrace radical transparency and accountability. Software manufacturers should pride themselves in delivering safe and secure products, as well as differentiating themselves among the rest of the manufacturer community based on their ability to do so.”
CISA also called on manufacturers to build organizational structure and leadership to achieve these cyber goals, including senior executives prioritizing security as a critical element of product development.
What is ‘Secure Enough?’
There has been a mixed reaction to the guidelines in the cybersecurity industry. Some have criticized the document for being too vague or aspirational, while others believe the guidelines are just what is needed to move the needle on product safety.
Henrik Plate, security research for Endor Labs, says it’s surprising that CISA’s document goes into detail on SQL injection while it stays high-level in other areas. “Comparable to the approach taken by the authors of the OWASP Top 10, for example, it would have been possible to speak more broadly of injection vulnerabilities rather than specifically highlighting SQL injection attacks,” he says.
Plate says the document already refers repeatedly to the Secure Software Development Framework (SSDF), which is also known as National Institute of Standards and Technology’s (NIST) SP 800-218. So he sees the CISA document as being “clearly linked” to other regulatory efforts following President Biden’s executive order requiring software suppliers of federal agencies to provide self-attestations regarding their secure software development practices.
“We appreciate that the (CISA) document explicitly refers to the necessity to, “acquire and maintain well-secured software components from verified commercial, open source, and other third-party developers” -- which has been the root cause of numerous high-profile supply chain attacks observed in the past few years, including the vulnerabilities included in Apache Log4j or Apache Struts,” Plate says.
More broadly, Plate says the core principles for secure software development, such as security by design and default, don’t change regularly because they have been formulated in abstract terms to apply to a wide range of domains “and remain agnostic of specific technologies.”
But the CISA guidelines are still valuable, he notes, due to the shared effort and joint communication of international government agencies, “which shows broad alignment and agreement on the principles.”
The fine print on safe products could prove to be tricky because it could be hard to prove.
“Software security differs from other software features and qualities because it’s difficult to measure the level of security provided by a given software product or service,” Plate explains. “This makes it hard for developers and consumers to understand whether a given product or service is secure ‘enough’ or more secure than that of another provider. Also, given enough time, effort and motivation, adversaries can compromise most of today’s software.
“In other words, claims that a given software or service is secure and does not have any vulnerabilities can hardly be proven by their developers, and cannot be verified by software consumers.”
Plate says adds developers can only prove the presence of defects during testing once they’ve found a bug, but not their absence.
“This particular feature of security can impact developers’ motivation to work on security – as opposed to developing tangible features that can be appreciated more directly by customers -- and customers’ willingness to spend more for secure products that might have less features,” he says.
Chuck Brooks, president of Brooks Consulting International and a globally recognized expert in cybersecurity and emerging technologies, agrees the tenets for Secure By Design/Default have been around for a while, but the onus on the private sector to implement them has been lacking.
“Moreover, the threat landscape has changed,” Brooks notes. “Sophisticated actors, including state-sponsored, have enhanced their capabilities to exploit and breach via artificial intelligence and machine learning and sharing of threat tools, and because of geopolitical motivations.
“Also, it’s not only software developers that must their game, but also hardware developers -- as the Internet of Things has become a major launching point by criminal hackers into supply chains and for DDos attacks.”
Learning Curve for Congress
Brooks doesn’t agree the document is too aspirational, noting that much of the critical infrastructure in the U.S. is being modernized, “and there is an opportunity to put security as a priority in the renovations.
Because much of the critical infrastructure is owned and operated by the private sector, Brooks says it makes sense for CISA to push hard to get that sector to make investments.
“In the long run, it will take a close collaboration that includes cooperative R&D, and technology and threat sharing between the public and private sectors to better mitigate the cyber and physical threats from adversaries,” he says.
“Passing laws will eventually come into play, especially if there is a catastrophic breach that harms national security. There is a learning curve in Congress on what the prudent path for both cybersecurity and emerging technologies entails. Some of these directives by CISA are certainly spurring some cyber awareness among legislators and industry.”
Driving Down Risk
Some observers question whether the new guidelines will be enough to motivate software and hardware vendors to drive down risk.
Plate says those decisions should not be taken by individual developers. Secure software must have buy-in from top management, be part of organizations’ core values and be reflected in corresponding policies and guidance, he notes.
“Secure development activities across the software development lifecycle consume developer resources and impact the flow of features and functionality. The time spent by developers to implement security features or run security tests cannot be used for developing the next fancy product feature,” Plate says.
“Again, the nature of security, and the difficulty in measuring the level of security, makes it hard to estimate whether a developer has done enough, or whether another security test case or threat model will bring up a higher severity of vulnerability.”
Brooks believes a renewed focus on security in the development phase could slow down innovation a bit, “but for others, particularly those involved in operating and protecting critical infrastructure, it will make business sense,” he says.
“Colonial Pipeline and Solar Winds, along with a whole host of recent visible breaches, show that security needs to be operational and not just a revenue cost for corporations and organizations -- or they may not stay in business or at least operate with tarnished reputations,” Brooks says.
Coding Challenges
Another challenge facing CISA’s security guidelines is that code is constantly changing, as are the users, attacks and technologies available, Plate says.
Software engineering is often compared to other engineering disciplines like civil engineering, he says -- but one important difference is the threat landscape in software development evolves constantly, “while the risks stemming from, for example, weather conditions that threaten the products of civil engineers such as bridges or buildings, are generally more stable over time. Moreover, attackers of IT infrastructure act intelligently.”
Brooks believes there are solutions to that.
“Artificial intelligence and machine learning have a significant role in enhancing threat modeling capabilities, especially with automation,” he says. “ In addition, sharing lessons learned on a global basis can help bring best practices to coding, including with Open Source.”
