Dear Reader,

How long have we been told that cybersecurity starts with the programmer? And what does that mean exactly? What can we do about it? An official document released in April by the cybersecurity agencies of several tech-savvy nations attempts to answer these questions. "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default" is an attempt to distill some practical principles and guidelines for safer coding. The document, which is jointly sponsored by the US, Australia, Canada, New Zealand, United Kingdom, Germany, and the Netherlands, is an effort to codify some of the best practices often discussed at coding conferences and in publications like this one. The guidelines are quite general (they all fit on a 15-page PDF [1]), but the document is still an encouraging effort by national governments to define what the terms "secure by design" and "secure by default" really mean.

According to the authors, products that are secure-by-design "are those where the security of the customers is a core business goal, not just a technical feature." Secure-by-default refers to the practice of making the software secure "out of the box," without the need for additional security configuration and with all security features available in the basic package – without additional cost.

The three core principles guiding the approach are:

1. The burden of security should not fall solely on the customer.
2. Embrace radical transparency and accountability.
3. Build an organizational structure and leadership to achieve these goals.

Recommendations for secure-by-design include objectives such as:

• Use memory-safe programming languages [2], like C#, Rust, Ruby, Java, Go, and Swift.
• Incorporate secure hardware features that enable fine-grained memory protection.
• Use web template frameworks that implement automatic escaping of user input to avoid web attacks such as cross-site scripting.
• Use parameterized queries to avoid SQL injection attacks.
• Include peer review of the code by other developers.
• Design infrastructure so that the compromise of a single security control does not result in compromise of the entire system.

Guidelines for secure-by-default include eliminating default passwords, implementing single sign-on via Security Assertion Markup Language (SAML) or OpenID Connect, and ensuring secure logging. Another recommendation is to prioritize forward-looking security over backwards compatibility – in other words, don't cut corners on security in pursuit of backwards compatibility. The paper emphasizes the need to consider the user experience consequences of security settings. "Each new setting increases the cognitive burden on end users and should be assessed in conjunction with the business benefit it derives. Ideally, a security setting should not exist; instead, the most secure setting should be integrated into the product by default. When configuration is necessary, the default option should be broadly secure against common threats." The authors give the example of the "hardening guides" included with many software products that describe ways to tighten up security. According to the paper, a hardening guide implies that the software isn't as secure as it should be in the first place. Not only that, but the hardening guide gives the attacker a sort of roadmap showing where to look for vulnerabilities. An alternative favored by the authors is to deliver the software with all these hardening steps already in place and then provide a "loosening guide" describing possible ways to reduce the security with an accompanying description of possible risks.

It is worth noting that there is no enforcement mechanism tied to these guidelines to make them mandatory. No doubt the sponsoring governments will build this approach into their own contracts, but for the industry in general, this document is best considered informational. Still, in codifying what good programming looks like, the document will benefit developers who want to play it smart but aren't sure how to begin. But as the document points out, it is the customers who will ultimately drive adoption of these principles by insisting that software providers adopt secure-by-design and secure-by-default practices. One point that is very clear as you read through the document is that it will require more time and effort to develop software using these secure principles (at least on the front end – developers might ultimately discover they save money on later security patches and updates). The need to dial up the effort will require diligent demands from the customers, as well as a broad understanding from the industry itself that this problem is worth fixing.

Joe Casad, Editor in Chief