Secure Coding - Challenges in Information Security

• Security vulnerabilities in code
• Open source code and supply chain attacks
• Information security control 8.28 secure coding
• Principles of secure coding
• Conclusion
• Revision of ISO 27001: What does the update mean for your certification?
• DQS - Simply leveraging Security.

Security vulnerabilities in code

Operating system software, application software or firmware in an embedded system are elementary components of any digital infrastructure. However, increasing acceleration and deadline pressure in digitization projects often lead to a neglect of imperative information security aspects. The development requirements for software are usually function-centric 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 also lack a structured and sharpened view of cybersecurity.

Under these conditions, development teams have a hard time continuously reviewing and consistently securing the coding of their software, as evidenced by the many vulnerabilities that the non-profit MITRE Corporation publishes each year in its CVE (Common Vulnerabilities and Exposures) list. The regular security patches of even well-known software manufacturers are an indicator of the Sisyphean task of closing security-relevant bugs, let alone identifying them before they are even launched on the market.

Open source code - a special case

When coding self-developed software, programmers like to resort to open source libraries and modules. The practical advantages are obvious: If you don't have to reinvent the wheel over and over again, you benefit from this technology boost, speedy development, lower development costs, more transparency through open source code, and higher interoperability through open standards and interfaces.

It is also often said that code from open source offers a high degree of security because the code has been validated by many users and the swarm intelligence of the open source community enables fast and efficient bug fixing.

In practice, this trust must now be evaluated in a differentiated and critical manner. The most serious example is the zero-day security vulnerability Log4Shell in the widely used logging library Log4J for Java applications, which was 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 reliably functioning quasi-standard via the Apache Foundation, has established itself in many systems since 2013 - including well-known web services such as Amazon AWS.

The complexity of these well-developed and also maintained libraries implicitly provides powerful functionalities of which an importing developer is often unaware in his own combined new development, but which can be exploited by attackers.

Another insecurity factor of open source components are so-called supply chain attacks, i.e., intended built-in vulnerabilities by malicious actors who pose as part of the open source community and assist in code development. Such a vulnerability is an extremely efficient way for hackers to attack a large number of downstream user organizations. No wonder, then, that this attack vector is growing rapidly: a Sonatype study diagnosed a 650% increase when comparing 2020 and 2021.

Information security control 8.28 secure coding

In order to safeguard the software development process in a timely manner, the International Organization for Standardization (ISO - committee ISO/IEC JTC 1/SC 27) has included "Secure Coding" as a new control 8.28 in the new ISO/IEC 27002 and ISO/IEC 27001:2022, Annex A standards. The purpose of the technical measure for secure coding is the preventive protection of software.

A minimum level of security is created as early as the writing stage on the basis of procedural regulations, thus minimizing the number of potential security vulnerabilities in the software. The regulatory framework for secure code generation is to be applied holistically both to the company's own program code and to software from third parties and open source sources. Notable principles for implementation are Security by Design and Least Privilege, which must also be considered in coding.

Principles of secure coding

Measure 8.28 addresses so-called principles of secure coding several times. Guidance on what these might be is provided by numerous organizations and institutes that regularly issue guides and best practices for secure coding. These include, for example, the Secure Coding Practices of the OWASP Foundation, the Secure Coding Standards of the Computer Emergency Response Team (CERT) of the Software Engineering Institute (SEI), and the German BSI's catalog of measures for the security of web applications. Despite the different sources, the elaborations show many parallels, for example with regard to the following points:

• Validation of data input
• Securing authentication and password management
• Secure access control
• Simple, transparent code
• Sustainably tested cryptographic measures and components
• Error handling and logging
• Data protection
• Threat modeling

In the ISO/ISO 27002:2022 standard, the recommended actions for Control 8.28 are divided into three sections, "Planning and precoding," "During coding," and "Verification and maintenance," the core contents of which are outlined below.

Planning and precoding

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 for external products and services. This requires the evaluation of the organization-specific expectations and definition of recognized principles in advance. In addition, recommended actions for planning and precoding take into account known common and historical coding practices and errors that could lead to vulnerabilities.

The configuration of development tools, such as rule-based in integrated development environments (IDE), should enforce the creation of secure code. Quite critical is the qualification of developers and their familiarity with secure architectures and programming standards. The inclusion of information security expertise in the development team goes without saying.

During the coding 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 - for example, hard-coded passwords - should be consistently prohibited. Code should be adequately documented and reviewed to best eliminate security-related bugs. Code review should take place both during and after development, via static application security testing (SAST) or similar. Static testing methods support the shift left approach ("test early and often") by shifting left in the lifecycle by testing visible code for rule conformance early.

This allows early identification of tainted code, connections to files or specific object classes, or application-level gaps that can be abused for unnoticed interaction with third-party programs as exploitable vulnerabilities. Before the software is put into operation, Control 8.28 requires an evaluation of attack surfaces and the implementation of the least privilege principle. The analysis performed of the most common programming errors and documentation of their correction should be evaluated.

Verification and maintenance

Even after the software has gone live, the topic of secure coding remains relevant. This includes secure updates as well as checks for known vulnerabilities in one's code. In addition, errors and suspected attacks must be documented so that necessary adjustments can be made promptly. In any case, unauthorized access to the source code must be reliably prevented by suitable tools.

Open source code

In the area of verification and maintenance, Measure 8.28 additionally lists explicit instructions for the use of external tools and libraries, such as open source software. These code components should be managed, updated and maintained in inventories. This can be done, for example, via a Software Bill of Material (SBOM). An SBOM is a formal, structured record of a software's packages and libraries and their relationships to each other and within the supply chain, in particular to keep track of reused code and open source components. The SBOM supports software maintainability and targeted security updates.

Conclusion

Secure code is an elementary foundation for putting a stop to potential attacks. The new Control 8.28 takes this long-suffering insight into account and upgrades the key role of secure coding in its importance for information security. However, since the measure comprises a large number of detailed recommendations for action and is technically demanding, its implementation will involve a comparatively high level of effort - this should be taken into account as early as the planning stage.

With the professional view of our experienced auditors, we support you in the compliant implementation of the measure. With our audit and certification expertise of more than 35 years, we are your ideal contact partner and will be happy to assist you with the topic of information security and certification in accordance with the ISO/IEC 27001:2022 standards.

Revision of ISO 27001: What does the update mean for your certification?

ISO/IEC 27001:2022 was published on October 25, 2022. This results in the following deadlines and timeframes for users to transition:

ISO/IEC 27001:2022 certification readiness

• Expected from May 2023 (depending on the German Accreditation Body GmbH (DAkkS)).

Last date for initial/re-certification audits according to the "old" ISO 27001:2013

• After October 31, 2023, DQS will perform initial and recertification audits only according to the new standard ISO/IEC 27001:2022

Transition of all existing certificates from the "old" ISO/IEC 27001:2013 to the new ISO/IEC 27001:2022

• There is a three-year transition period from October 31, 2022
• Certificates issued according to ISO/IEC 27001:2013 or DIN EN ISO/IEC 27001:2017 will continue to be valid until October 31, 2025 at the latest, or must be withdrawn on this date.

DQS: Simply leveraging Security.

Due to the transition periods, companies have sufficient time to adapt their ISMS in accordance with the new requirements and have it certified. However, the duration and effort of the entire change process should not be underestimated - especially if you do not have sufficient specialized personnel. If you want to be on the safe side, you should deal with the issue sooner rather than later and call on experienced specialists if necessary.

As audit and certification experts with more than 35 years of expertise, we are happy to support you in evaluating your current status, maybe as part of a delta audit. Find out from our numerous experienced auditors about the most important changes and their relevance for your organization. Together we will discuss your potential for improvement and support you until you receive your new certificate. Take advantage of our competence in information security! We look forward to hearing from you.