Safer Coding
Welcome
How long have we been told that cybersecurity starts with the programmer? And what does that mean exactly? What can we do about it?
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:
- The burden of security should not fall solely on the customer.
- Embrace radical transparency and accountability.
- 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
Infos
- "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default": https://www.cisa.gov/sites/default/files/2023-04/principles_approaches_for_security-by-design-default_508_0.pdf
- Software Memory Safety: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
elementary OS 7.1 Now Available for Download
The team behind elementary OS has released the latest version of its operating system with a focus on personalization, inclusivity, accessibility, and privacy.
-
The GNU Project Celebrates Its 40th Birthday
September 27 marks the 40th anniversary of the GNU Project, and it was celebrated with a hacker meeting in Biel/Bienne, Switzerland.
-
Linux Kernel Reducing Long-Term Support
LTS support for the Linux kernel is about to undergo some serious changes that will have a considerable impact on the future.
-
Fedora 39 Beta Now Available for Testing
For fans and users of Fedora Linux, the first beta of release 39 is now available, which is a minor upgrade but does include GNOME 45.
-
Fedora Linux 40 to Drop X11 for KDE Plasma
When Fedora 40 arrives in 2024, there will be a few big changes coming, especially for the KDE Plasma option.
-
Real-Time Ubuntu Available in AWS Marketplace
Anyone looking for a Linux distribution for real-time processing could do a whole lot worse than Real-Time Ubuntu.
-
KSMBD Finally Reaches a Stable State
For those who've been looking forward to the first release of KSMBD, after two years it's no longer considered experimental.
-
Nitrux 3.0.0 Has Been Released
The latest version of Nitrux brings plenty of innovation and fresh apps to the table.
-
Linux From Scratch 12.0 Now Available
If you're looking to roll your own Linux distribution, the latest version of Linux From Scratch is now available with plenty of updates.
-
Linux Kernel 6.5 Has Been Released
The newest Linux kernel, version 6.5, now includes initial support for two very exciting features.