ISMS-DOC-A08-28-1 Secure Coding Policy

Coding Policy

Secure Coding Policy

classification]

Implementation guidance

The header page and this section, up to and including Disclaimer, must be removed from the final version of the document. For more details on replacing the logo, yellow highlighted text and certain generic terms, see the Completion Instructions document.

Purpose of this document

This document sets out the principles that will be used when developing secure code.

Areas of the standard addressed

The following areas of the ISO/IEC 27001 standard are addressed by this document:

• A.5 Organizational controls

o A.5.1 Policies for information security

• A.8 Technological controls

o A.8.28 Secure coding

General guidance

Writing secure code is difficult and can be highly dependent on the techniques and languages used. An approach of continuous improvement over time will probably be most appropriate, based on the kinds of general principles set out in this document and elsewhere. There are some effective tools available for security testing particularly in a cloud environment and the use of these will encourage the creation of more secure code from the outset. Common advice is also to place security firmly on the agenda of all development related meetings and reviews so that a clear focus is maintained on secure coding.

Review frequency

We would recommend that this document is reviewed annually and upon significant change to the organization.

Secure Coding Policy

[Insert classification]

Document fields

This document may contain fields which need to be updated with your own information, including a field for Organization Name that is linked to the custom document property “Organization Name”.

To update this field (and any others that may exist in this document):

1. Update the custom document property “Organization Name” by clicking File > Info > Properties > Advanced Properties > Custom > Organization Name.

2. Press Ctrl A on the keyboard to select all text in the document (or use Select, Select All via the Editing header on the Home tab).

3. Press F9 on the keyboard to update all fields.

4. When prompted, choose the option to just update TOC page numbers.

If you wish to permanently convert the fields in this document to text, for instance, so that they are no longer updateable, you will need to click into each occurrence of the field and press Ctrl Shift F9.

If you would like to make all fields in the document visible, go to File > Options > Advanced > Show document content > Field shading and set this to “Always”. This can be useful to check you have updated all fields correctly.

Further detail on the above procedure can be found in the toolkit Completion Instructions. This document also contains guidance on working with the toolkit documents with an Apple Mac, and in Google Docs/Sheets.

Copyright notice

Except for any specifically identified third party works included, this document has been authored by CertiKit, and is ©CertiKit except as stated below. CertiKit is a company registered in England and Wales with company number 6432088.

Licence terms

This document is licensed on and subject to the standard licence terms of CertiKit, available on request, or by download from our website. All other rights are reserved. Unless you have purchased this product you only have an evaluation licence.

If this product was purchased, a full licence is granted to the person identified as the licensee in the relevant purchase order. The standard licence terms include special terms relating to any third party copyright included in this document.

Secure Coding Policy

classification]

Disclaimer

Please Note: Your use of and reliance on this document template is at your sole risk. Document templates are intended to be used as a starting point only from which you will create your own document and to which you will apply all reasonable quality checks before use.

Therefore, please note that it is your responsibility to ensure that the content of any document you create that is based on our templates is correct and appropriate for your needs and complies with relevant laws in your country.

You should take all reasonable and proper legal and other professional advice before using this document.

CertiKit makes no claims, promises, or guarantees about the accuracy, completeness or adequacy of our document templates; assumes no duty of care to any person with respect its document templates or their contents; and expressly excludes and disclaims liability for any cost, expense, loss or damage suffered or incurred in reliance on our document templates, or in expectation of our document templates meeting your needs, including (without limitation) as a result of misstatements, errors and omissions in their contents.

Secure Coding Policy

classification]

Secure Coding Policy

Secure Coding Policy

classification]

Revision history

VERSION

Distribution

Approval

SUMMARY

Secure Coding Policy

Secure Coding Policy

classification]

1 Introduction

Developing bespoke software provides a level of flexibility and functionality that is not always possible to reproduce using commercial off the shelf systems. [Organization Name] dedicates a significant amount of its resources to designing, coding, testing, releasing and maintaining its software according to industry best practice standards. As part of this, we have a responsibility to ensure that the computer code we produce is as secure as it reasonably can be. Insecure software allows vulnerabilities to be found which can provide a way in for malicious actors and requires our time to create and distribute patches.

In order to write software that minimises such vulnerabilities, there are a number of guiding principles that must be followed, in addition to the more detailed programming techniques that apply with specific languages. This policy defines these high level principles as a starting point for the definition of lower level procedures for the creation of secure code, as part of an effective, managed approach.

This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access to [Organization Name] systems.

The following policies and procedures are relevant to this document:

• Secure Development Environment Guidelines

• Secure Development Policy

• Principles for Engineering Secure Systems

Secure Coding Policy

classification]

2 Secure coding policy

It is the policy of [Organization Name] to write software in such a way that the number of potential vulnerabilities in the code is minimised.

Secure coding within [Organization Name] will be based on the principles established by best practice organizations including (but not limited to) the following:

• OWASP (The Open Web Application Security Project®)

• SEI CERT (Software Engineering Institute Computer Emergency Response Team)

• UK NCSC (National Cyber Security Centre)

• USA NIST (National Institute of Standards and Technology)

• [Add further sources of best practice as applicable]

Secure coding practices in use within the organization will cover as a minimum the following topics (based on OWASP Secure Coding Practices V2.0):

• Input validation

Output encoding

Authentication and password management

Session management

Access control

Cryptographic practices

Error handling and logging

Data protection

Communication security

System configuration

Database security

File management

Memory management

General coding practices

These general principles will be supplemented by technology specific advice and guidance produced by the vendors of the technology in use, and third parties with particular expertise in them.

Secure coding practices will be established and documented for each development project, and will be communicated to third parties that create software on [Organization Name]’s behalf. Account will be taken of available threat intelligence and existing known vulnerabilities when defining these practices.

Good practice in writing code will be followed at all times including, where appropriate:

• The use of structured programming techniques

Clear documentation and commenting of code

Consistent naming of items such as classes, methods and variables

Avoiding hard coding of credentials

Secure Coding Policy

classification]

• Correct handling of errors

Appropriate software testing will be carried out to confirm that the documented coding techniques have been properly implemented prior to the release of the software to production.

Where possible, the use of secure coding techniques will be mandated via settings and automation within development tools, such as integrated development environments (IDE).

External software libraries used as part of the development process must be examined to assess them against the secure coding practices adopted for the relevant project.

A process must be in place for the management of vulnerabilities discovered after the release of the software into production.

Software fixes and updates must be subject to the same secure coding practices as the original development.