Principles for Engineering
Secure Systems
ISO/IEC 27701 Toolkit: Version 2
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 describes the security engineering principles the organization has adopted to ensure that its systems are secure.
Areas of the standard addressed
The following areas of the ISO/IEC 27701 standard are addressed by this document:
• A.3 Security considerations for PII controllers and processors
o A.3.29 Secure system architecture and engineering principles
General guidance
The intention of this control is to provide a set of general rules when creating or evaluating systems to ensure that they are as secure as possible from the outset. The standard is not specific about what these should be or the level of detail that is required. This document suggests a number of such principles that may be used, some of which are part of the wider concept of zero-trust.
Other documents are available that set out such principles, often in significant detail, including NIST Special Publication 800-160 which is available free of charge and without copyright restrictions from nist.gov.
Review frequency
We would recommend that this document is reviewed annually.
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.
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.
Principles for Engineering Secure Systems [Insert classification]
Principles for Engineering Secure Systems
Version 1
DOCUMENT CLASSIFICATION [Insert classification]
DOCUMENT REF PIMS-DOC-A3-29-1
VERSION 1
DATED [Insert date]
DOCUMENT AUTHOR [Insert name]
DOCUMENT OWNER [Insert name/role]
5 of 10 [Insert date]
Revision history
Distribution
NAME
Approval
NAME
1 Introduction
The purpose of this document is to present a list of system-level security principles to be considered in the design, development, and operation of an information system within [Organization Name]
The principles presented here must be adopted from the onset of a program (at the beginning of, or during the initiation phase) and then employed throughout the system’s lifecycle. However, these principles are also helpful in affirming and confirming the security posture of already deployed information systems. The principles are relatively short and concise and may be used to develop more detailed system life-cycle policies.
This document should be read in conjunction with the following documents which give more detail in specific areas:
• Secure Development policy
• Secure Coding Policy
2 Principles for engineering secure systems
The following principles should be used as guidance when designing or evaluating information technology infrastructure and applications within [Organization Name].
2.1 Least privilege
The principle of least privilege states that each component of a system (such as a process, user or supplier) should be allocated sufficient privileges to accomplish its specified functions, but no more. This will require an exact specification of the tasks to be performed by a component so that a precise level of authority may be granted in each case. Situations where a generic set of permissions are provided by default must be avoided.
2.2 Defence in depth
Defence in depth involves the application of multiple mechanisms to create a series of barriers to prevent, delay, or deter an attack by an adversary. This adds strength to the defences of the organization by avoiding a situation where a breach of a single control exposes assets to compromise.
2.3 Security by design
Security must be considered at the outset of the creation of an information system, and an appropriate design defined and implemented as a key part of the development. This design should consider all aspects of the system (for example people, process and technology) and make use of the other principles described in this document throughout. The situation where security controls are bolted onto a system as an afterthought must be avoided. Independent guidance (such as the OWASP Top 10 for web applications) should be considered.
2.4 Secure by default
This principle dictates that security should be an underlying foundation in all components of an information system and should be designed in (often by third party suppliers) without affecting usability. Components should not need to be configured to become secure but should be so “out of the box”.
2.5 Default deny
The principle of default deny states that if a request is not specifically allowed, then it must be denied. This avoids a situation where access is granted on the basis that no rules state that it should not be, so potentially allowing a loophole to be exploited.
2.6 Fail securely
If an unexpected error occurs in a system, the resulting state of that system must be a secure one. This may involve defining logic that returns the system to a known, secure state without exposing unauthorised functions or disclosing additional information that may be useful to an attacker.
2.7 Security in deployment
In addition to designing and creating systems in a secure way, this principle states that the security and integrity of developed applications must not be compromised during deployment. This may involve the use of automated techniques to minimise the risk of human error, verify the integrity of components (such as software applications) and perform additional security checks.
2.8 Assume breach
Related to the general concept of zero trust, the principle of assume breach dictates that all components in an information system must be treated as if they have already been compromised. This requires that appropriate security checks are performed between components before processing requests, even when both parties are within the same internal environment.
2.9 Least functionality
The principle of least functionality requires that components only support those features that are needed for them to fulfil their role. For example, in system hardening un-needed software may be removed, non-essential ports closed and network services disabled.