ISO 27002:2022, Control 8.28 – Secure Coding

Ownership of Control 8.28

Considering that 8.28 requires the design and implementation of organisation-wide secure coding principles and procedures, the chief information security officer should be responsible to take appropriate steps for compliance.

General Guidance on Compliance

Control 8.28 requires organisations to establish and implement organisation-wide processes for secure coding that applies to both software products obtained from external parties and to open source software components.

Furthermore, organisations should keep up to date with evolving real-world security threats and with the most recent information on known or potential software security vulnerabilities. This will enable organisations to improve, and implement robust secure software coding principles that are effective against evolving cyber threats.

Supplementary Guidance on Planning

Secure software coding principles should be followed both for new coding projects and for software reuse operations.

These principles should be adhered to both for in-house software development activities and for the transfer of the organisation’s software products or services to third parties.

When establishing a plan for secure coding principles and determining the prerequisites for secure coding, organisations should comply with the following:

• Organisations should determine security expectations tailored to their needs and establish approved principles for secure software coding that will apply to both in-house software development and outsourced software components.
• Organisations should detect and document the most prevalent and historical poor coding design practices and mistakes that result in compromise of information security.
• Organisations should put in place and configure software development tools to ensure the security of all code created. One example of such tools is integrated development environments (IDE).
• Organisations should achieve compliance with the guidance and instructions provided by software development tools.
• Organisations should review, maintain, and securely use development tools such as compilers.

Supplementary Guidance on Security During Coding

Secure coding practices and procedures should take into account the following for the coding process:

• Secure software coding principles should be tailored to each programming language and techniques used.
• Deployment of secure programming techniques and methods such as test-driven development and pair programming.
• Use of structured programming methods.
• Proper code documentation and removal of code defects.
• Prohibition on the use of insecure software coding methods such as unapproved code samples or hard-coded passwords.

Supplementary Guidance also notes that security testing should be performed both during and after the development in accordance with Control 8.29.

Before putting the software into actual use in the live application environment, organisations should consider the following:

• What is the attack surface?
• Is the principle of least privilege followed?
• Carrying out an analysis of the most prevalent programming mistakes and documenting that these risks have been eliminated.

Supplementary Guidance on Review Process

After the Code Is Put Into Use in the Production Environment

• Updates should be applied in a secure manner.
• Security vulnerabilities reported in line with Control 8.8 should be addressed.
• Suspected attacks on information systems and errors should be recorded and these records should be reviewed on regular intervals so that appropriate changes to code can be made.
• Unauthorised access to, use of, or changes to source code should be prevented via mechanisms such as management tools.

When Organisations Use External Tools, They Should Take Into Account the Following

• External libraries should be monitored and updated at regular intervals based on their release cycles.
• Software components should be carefully vetted, selected, and authorised especially cryptography and authentication components.
• Licensing of external components and ensuring their security.
• Software should be tracked and maintained. Furthermore, it must be ensured that it comes from a trustworthy source.
• Development resources should be available for the long term.

When Making Changes to a Software Package, the Following Should Be Considered

• Risks that may arise out of built-in controls or compromise of integrity processes.
• Whether the vendor gives consent to changes.
• Whether it is possible to get consent from the software vendor for regular updates.
• The likely impact of carrying on the maintenance of the software that arises out of changes.
• Whether the changes would be compatible with other software components used by the organisation.

Additional Guidance on Control 8.28

Organisations should ensure that security-relevant code is used when it is necessary and is resistant to tampering.

Control 8.28 also lists the following recommendations for security-relevant code:

• While programs installed via binary code include security-relevant code, this is limited to the data stored within the application itself.
• Concept of security-relevant code is only useful when code is run on a server that is not accessible to the user and it is segregated from the processes that use it and its data is kept securely in another database. For instance, you can run an interpreted code on a cloud service and access to code can be restricted to privileged administrators. It is recommended that you protect these access rights via methods such as just-in-time administrator privileges and robust authentication mechanisms.
• Appropriate configurations on web servers should be implemented to prevent unauthorised access to and browsing of the directory.
• When designing application code, you should start with the assumption that the code is vulnerable to attacks due to coding errors and actions by malicious actors. You should design critical applications in a way that they are not vulnerable to internal faults. For instance, the output produced by an algorithm can be reviewed to ensure that it complies with security requirements before it can be used in critical applications such as finance-related applications.
• Certain web applications are highly vulnerable to security threats due to poor coding practices such as database injection and cross-site scripting attacks.
• Organisations should refer to ISO/IEC 15408 series for more information about IT security evaluation.

Changes and Differences from ISO 27002:2013

27002:2022/8.28 is a new type of control.

How ISMS.online Helps

Our platform has been developed specifically for those who are new to information security or need an easy way to learn about ISO 27002 without having to spend time learning from scratch or reading through lengthy documents.

ISMS.Online comes equipped with all the tools needed for achieving compliance including document templates, checklists and policies which can be customised according to your needs.

Want to see how it works?

Get in touch today to book a demo.