New security-by-design and security-by-default guidelines from a collection of federal agencies provide the first guidance of its type issued to urge manufacturers to ship devices with adequate security for the modern threat landscape.
While the guidance applies to all types of software, one of the central points of focus is in improving the inherent security of smart devices. New aspects of homes and businesses are rapidly becoming internet-connected with each passing day, but standard device security in this area continues to lag behind known threats and there is little in the way of existing regulation to force improvements across the market.
“Security by design” guidelines involve allied nations
CISA, the Federal Bureau of Investigation (FBI), and the National Security Agency (NSA) are the US-based point agencies for this guidance, but the recommendations have also been co-signed by the cybersecurity authorities of Australia, Canada, Germany, the Netherlands, New Zealand and the United Kingdom.
“Security by design” calls for threat consideration at the fundamental development level, before products hit the manufacturing line. Security for most existing devices, particularly cost-conscious smart devices, is reactive; an approach that is a particularly poor setup for devices that cannot have their firmware or software updated or that do not allow users to change passwords.
A security by design approach also takes the onus of securing devices off of the end user, who is often not trained for such things or fully aware of the threat landscape. The guidance calls for a “default baseline” that has the device configured to automatically implement appropriate security controls. Manufacturers are also asked to be more timely and transparent in their vulnerability disclosures and advisories when a security issue develops.
None of the security by design principles outlined in the guide are mandatory, and CISA Director Jen Easterly said that the main goal was to “start a conversation” about eliminating device vulnerabilities before they become the end user’s responsibility to deal with. Though it is not mandatory, the guidance is the first of its kind from a collection of international federal agencies.
Core “security by design” principles include default security controls, executive commitment, “radical transparency”
Some products come packed with user or “hardening” guides that instruct the purchaser in getting appropriate security controls and defenses in place. The security by design approach would essentially have the manufacturer implement these measures themselves before shipping the product.
The listed security by design principles do contain a number of specific recommendations for manufacturers. One is the use of “memory safe” programming languages. Easterly has called for manufacturers to avoid “leaky” languages like C and C++, instead using something like Rust, Python or Java (C# was also listed as a “safe” option).
The guidance also recommends implementation of vulnerability disclosure programs, regular code reviews, and the use of software bills of materials. SAST and DAST testing are also recommended for app code, as is the use of a secure hardware foundation and known secure software components.
What might “security by design” products look like for the end user? The likely most common change would be no more smart devices with default passwords or with the inability to implement a custom password, a problem that has plagued the industry since its inception. Manufacturers might also be pushed to support single sign-on solutions as a standard, or multi-factor authentication as a requirement of using the device. Smart devices would also likely sport more robust software that is able to update automatically, similar to how phones can receive security patches and OS updates.
On paper, the security by design approach looks like a crowd pleaser. But these examples show why it remains a hard sell for many organizations, and why there has not been much regulatory pressure to force the issue as of yet. More security requirements can mean more hassle and headache for users, who may turn away from the product. Consumers may also love the idea until they see what it adds to the price tag, with development costs almost certainly going up if these principles are implemented.
But the report notes the counter-argument that any initial trouble with higher prices or sign-in reticence could be offset by improvements to the brand’s reputation for security and reliability, as well as product longevity. The lack of regulatory requirements means that manufacturers might ease into this process with slow and gradual product changes, while gathering data on what consumers find both helpful and hard to deal with.
Jeff Williams, co-founder and CTO at Contrast Security, believes the spirit of the government effort is in the right place, but the actual advice is lackluster and perhaps reflects the fact that there are no binding requirements to push change: “It’s wonderful to see the multi-national cooperation on a document that so clearly focuses on the importance of software security and transparency. It demonstrates that the governments of the world recognize the importance of software to healthcare, finance, governments, elections, utilities, social media, education, and everything else important in life. This demonstrates that they are determined to ensure that market failures in the software industry don’t endanger consumers who rely on this software. Still, the guidance here feels a bit aspirational and often very dated. The discussion of secure-by-default and secure-by-design is straight out of 2000,”
“The list of secure-by-design tactics seems a little bit off. I would have expected design principles like the OWASP article on the topic (from 2006) discusses, such as “separation of duties”, “minimize complexity”, “minimize attack surface”, etc. It’s not that what’s there is necessarily wrong, but it seems to suggest some minor tactics rather than what I’d consider the fundamental practices that lead to secure-by-design,” noted Williams.
