No data and information processing can be done without software. Software development focuses primarily on the specific functioning of algorithms. However, it is now known that improperly written program code often also causes security issues, such as incorrect access control, SQL injection, incorrect session management and authentication, cross-site scripting, etc.
Cybersecurity Planning and Secure Coding Practices
A robust cybersecurity plan must include measures that ensure software is developed with security in mind. The great importance of secure coding practices is highlighted in the updated information security standards ISO/IEC 27002 and ISO/IEC 27001:2022. Cybersecurity planning should incorporate these standards to address vulnerabilities that arise from poorly written code, as security threats can originate at the software development stage.
As part of an organization’s cybersecurity strategy, adopting secure coding principles is essential to mitigate risks. These principles, now recognized as a new information security measure (control), are included in the catalog of measures in Annex A of ISO/IEC 27001. This integration of secure coding practices into cybersecurity planning helps businesses prepare for future audits and strengthens their overall security posture.To learn more about the importance of this information security measure and what it means for future audits, read our blog post.
Security vulnerabilities in the code
Operating system software, application software or the firmware of an embedded system are basic components of any digital infrastructure. However, the increasing acceleration and deadline pressure in digitization projects often lead to the neglect of imperative aspects of information security. Development requirements for software are usually function-focused and emphasize constructive aspects, so that the destructive view of potential security vulnerabilities is mostly diametrically opposed to the actual development goals: Many programmers simply lack even a structured and sharp vision of cybersecurity.
Under these conditions, development teams have difficulty continuously reviewing and securing the coding of their software, as demonstrated by the numerous vulnerabilities that the non-profit organization MITRE Corporation publishes every year in its list.CVE(Common Vulnerabilities and Exposures). Regular security patches from even well-known software vendors are an indicator of the Sisyphean task of closing security-relevant bugs, not to mention identifying such bugs before they are even released to the market.
Open Source Code: A Special Case
When coding their own software, programmers like to use open source libraries and modules. The practical benefits are obvious: if you don’t have to reinvent the wheel over and over again, you benefit from a technological boost, faster development, lower development costs, greater transparency thanks to open source code, and greater interoperability thanks to open standards and interfaces.
It is also often said that open source code offers a high degree of security, because the code has been validated by many users and the swarm intelligence of the open source community allows for quick and efficient bug fixing.
In practice, this trust must be assessed differently and critically. The most serious example is the zero-day security vulnerability Log4Shell in the widely used logging library Log4J for Java applications, discovered in November 2021. You may have heard about the red alert level issued by the German Federal Office for Information Security (BSI) for Log4Shell. The Log4J library, distributed as a reliable quasi-standard by the Apache Foundation, has been established in many systems since 2013, including well-known web services such as Amazon AWS.
The complexity of these libraries, well developed and also maintained, implicitly provides powerful functionality that an importing developer is often unaware of in his new combined development, but which can be exploited by attackers.
Another factor that makes open source components insecure is so-called supply chain attacks, which are vulnerabilities embedded by malicious actors who pretend to be part of the open source community and contribute to the development of the code. Such a vulnerability is an extremely effective way for hackers to attack a large number of downstream user organizations.
Information Security Control 8.28 Secure Encryption
In order to safeguard the software development process in a timely manner, the International Organization for Standardization (ISO – ISO/IEC JTC 1/SC 27 committee) has included “Secure Coding” as a new control 8.28 in the new ISO/IEC 27002 standards andISO/IEC 27001:2022, Appendix A. The purpose of the technical measure for secure encryption is the preventive protection of the software.
A minimum level of security is created already at the writing stage based on procedural rules, thus minimizing the number of potential security vulnerabilities in the software. The regulatory framework for generating secure code must be applied holistically to both the company’s own program code and third-party software and open source sources. The most important implementation principles areSecurity by Design And Least Privilege, which must also be considered in coding.
Secure Coding Principles
Measure 8.28 addresses the so-called principles of secure coding several times. Indications on what these might be are provided by numerous organizations and institutes that regularly publish guides and best practices for secure coding. These include, for example, theSecure Coding Practices of theOWASP Foundation, theSecure Coding Standards Of the Computer Emergency Response Team (CERT) of the Software Engineering Institute (SEI) and the catalog of measures for web application security of the German BSI.
Planning and pre-coding
Both new code development and code reuse require the application of secure coding principles, regardless of whether the code is written for internal software or external products and services. This requires assessing the organization’s specific expectations and establishing recognized principles up front. Additionally, recommended actions for planning and precoding take into account common and historical coding practices and errors that could lead to vulnerabilities.
The configuration of development tools, such as rules-based ones in integrated development environments (IDEs), should enforce the creation of secure code. Very important is the qualification of developers and their familiarity with secure programming standards and architectures. The inclusion of information security expertise in the development team goes without saying.
During the encoding process
During the coding process, coding practices and structured programming techniques play a primary role, taking into account the specific use case and its security needs. Insecure design techniques, such as hard-coded passwords, must be consistently prohibited. Code must be properly documented and reviewed to eliminate security bugs as best as possible. Code review must occur both during and after development, through static application security testing (SAST) or similar. Static testing methods support the shift left approach (“test early and often”) by moving left in the lifecycle and checking visible code for compliance with the rules early.
This allows for the early identification of contaminated code, connections to specific file or object classes, or application-level loopholes that can be exploited for unnoticed interaction with third-party programs as exploitable vulnerabilities. Before the software is put into operation, Control 8.28 requires an assessment of the attack surfaces and the implementation of the principle of least privilege. The analysis of the most common programming errors and the documentation of their correction must be evaluated.
Check and maintenance
Even after the software has gone live, the topic of secure coding remains relevant. This includes secure updates and checks for known code vulnerabilities. In addition, errors and suspected attacks must be documented so that necessary changes can be made promptly. In any case, unauthorized access to the source code must be reliably prevented with appropriate tools.
Open source code
In the area of verification and maintenance, Measure 8.28 also lists explicit instructions for the use of external tools and libraries, such as open source software. These code components must be managed, updated and maintained in inventories. This can be done, for example, via a software bill of materials (SBOM). An SBOM is a formal and structured record of software packages and libraries and their relationships to each other and within the supply chain, in particular to track reused code and open source components. The SBOM supports software maintainability and targeted security updates.
Conclusion
Secure coding is a basic basis for stopping potential attacks. The new Control 8.28 takes this long-suffering insight into account and highlights the key role of secure coding in its importance for information security. However, as the measure includes a large number of detailed recommendations for actions to be taken and is technically demanding, its implementation will involve a relatively high level of effort, which should be taken into account already in the planning phase.