What is ISO 27002:2022 Control 8.28 on Secure Coding?
Poor coding practices such as improper input validation and weak key generation can expose information systems to security vulnerabilities and result in cyber attacks and compromise of sensitive information assets.
For example, in the infamous Heartbleed bug incident, hackers exploited improper input validation in the code to gain access to more than 4 million patients’ data.
Therefore, organisations should ensure that secure coding principles are followed so that poor coding practices do not lead to security vulnerabilities.
Purpose of Control 8.28
Control 8.28 enables organisations to prevent security risks and vulnerabilities that may arise as a result of poor software coding practices by designing, implementing, and reviewing appropriate secure software coding principles.
Attributes Table of Control 8.28
Control 8.28 is a preventive type of control that helps organisations maintain the security of networks, systems, and applications by eliminating risks that may arise out of poorly-designed software code.
| Control Type | Information Security Properties | Cybersecurity Concepts | Operational Capabilities | Security Domains |
|---|---|---|---|---|
| #Preventive | #Confidentiality | #Protect | #Application Security | #Protection |
| #Integrity | #System and Network Security | |||
| #Availability |
Get an 81% headstart
We've done the hard work for you, giving you an 81% Headstart from the moment you log on.
All you have to do is fill in the blanks.
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.
Compliance doesn't have to be complicated.
We've done the hard work for you, giving you an 81% Headstart from the moment you log on.
All you have to do is fill in the blanks.
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.
Manage all your compliance in one place
ISMS.online supports over 100 standards
and regulations, giving you a single
platform for all your compliance needs.
Changes and Differences from ISO 27002:2013
27002:2022/8.28 is a new type of control.
New ISO 27002 Controls
New Controls
| ISO/IEC 27002:2022 Control Identifier | ISO/IEC 27002:2013 Control Identifier | Control Name |
|---|---|---|
| 5.7 | New | Threat intelligence |
| 5.23 | New | Information security for use of cloud services |
| 5.30 | New | ICT readiness for business continuity |
| 7.4 | New | Physical security monitoring |
| 8.9 | New | Configuration management |
| 8.10 | New | Information deletion |
| 8.11 | New | Data masking |
| 8.12 | New | Data leakage prevention |
| 8.16 | New | Monitoring activities |
| 8.23 | New | Web filtering |
| 8.28 | New | Secure coding |
Organisational Controls
People Controls
| ISO/IEC 27002:2022 Control Identifier | ISO/IEC 27002:2013 Control Identifier | Control Name |
|---|---|---|
| 6.1 | 07.1.1 | Screening |
| 6.2 | 07.1.2 | Terms and conditions of employment |
| 6.3 | 07.2.2 | Information security awareness, education and training |
| 6.4 | 07.2.3 | Disciplinary process |
| 6.5 | 07.3.1 | Responsibilities after termination or change of employment |
| 6.6 | 13.2.4 | Confidentiality or non-disclosure agreements |
| 6.7 | 06.2.2 | Remote working |
| 6.8 | 16.1.2, 16.1.3 | Information security event reporting |
Physical Controls
| ISO/IEC 27002:2022 Control Identifier | ISO/IEC 27002:2013 Control Identifier | Control Name |
|---|---|---|
| 7.1 | 11.1.1 | Physical security perimeters |
| 7.2 | 11.1.2, 11.1.6 | Physical entry |
| 7.3 | 11.1.3 | Securing offices, rooms and facilities |
| 7.4 | New | Physical security monitoring |
| 7.5 | 11.1.4 | Protecting against physical and environmental threats |
| 7.6 | 11.1.5 | Working in secure areas |
| 7.7 | 11.2.9 | Clear desk and clear screen |
| 7.8 | 11.2.1 | Equipment siting and protection |
| 7.9 | 11.2.6 | Security of assets off-premises |
| 7.10 | 08.3.1, 08.3.2, 08.3.3, 11.2.5 | Storage media |
| 7.11 | 11.2.2 | Supporting utilities |
| 7.12 | 11.2.3 | Cabling security |
| 7.13 | 11.2.4 | Equipment maintenance |
| 7.14 | 11.2.7 | Secure disposal or re-use of equipment |
Technological Controls
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.
Jump to topic
