Page Comparison

...

a) the risk of built-in controls and integrity processes being compromised;

a) licensing arrangements, code ownership and intellectual property rights related to the outsourced
content (see 18.1.2);
b) contractual requirements for secure design, coding and testing practices (see 14.2.1);
c) provision of the approved threat model to the external developer;
d) acceptance testing for the quality and accuracy of the deliverables;

development

processes and controls;
j) effective documentation of the build environment used to create deliverables;
k) the organization remains responsible for compliance with applicable laws and control efficiency
verification

.

ISO/IEC 27002:2013 Control

TSS-WEB

12.1.4 Separation of development, testing and operational environments

Control: Development, testing, and operational environments should be separated to reduce the risks of unauthorized access or changes to the operational environment.

Status

colour	Green
title	Yes

Control met by 3. Operational Requirements, “separation of environments”

14.2 Security in development and support processes

14.2.1 Secure development policy

Control: Rules for the development of software and systems should be established and applied to developments within the organization.

Expand

title	Implementation Guidance

a) security of the development environment;
b) guidance on the security in the software development lifecycle: (1) security in the software development methodology; (2) secure coding guidelines for each programming language used

c) security requirements in the design phase;
d) security checkpoints within the project milestones;
e) secure repositories;
f) security in the version control;
g) required application security knowledge;
h) developers’ capability of avoiding, finding and fixing vulnerabilities.

Status

colour	Green
title	Yes

TSS-WEB provides a template for such a policy:

a) See 4. Secure Development Environment

b)

5. Security within Development Process
Not covered, see our Security Guidelines for Confluence if you need them.

c) See 5. Security within Development Process

d) See 5. Security within Development Process, “security approvals”

e) See 4. Secure Development Environment

f) See 5. Security within Development Process , “Defect tracking”

g) See 1.4 Roles

h) See “developer tests” in 6. Security Tests

14.2.2 System change control procedures

Control: Changes to systems within the development lifecycle should be controlled by the use of formal change control procedures.

expand

title	Implementation Guidance

This process should include a risk assessment, analysis of the impacts of changes and specification of
security controls needed. This process should also ensure that existing security and control procedures
are not compromised, that support programmers are given access only to those parts of the system
necessary for their work and that formal agreement and approval for any change is obtained.

a) maintaining a record of agreed authorization levels;
b) ensuring changes are submitted by authorized users;
c) reviewing controls and integrity procedures to ensure that they will not be compromised by the changes;
d) identifying all software, information, database entities and hardware that require amendment;
e) identifying and checking security critical code to minimize the likelihood of known security weaknesses;
f) obtaining formal approval for detailed proposals before work commences;
g) ensuring authorized users accept changes prior to implementation;
h) ensuring that the system documentation set is updated on the completion of each change and that
old documentation is archived or disposed of;
i) maintaining a version control for all software updates;
j) maintaining an audit trail of all change requests;
k) ensuring that operating documentation (see 12.1.1) and user procedures are changed as necessary
to remain appropriate;
l) ensuring that the implementation of changes takes place at the right time and does not disturb the
business processes involved.

Status

colour	Green
title	Yes

Control met by 5. Security within Development Process, “Assessment of functional requirements and changes”.

14.2.3 Technical review of applications after operating platform changes

Control: When operating platforms are changed, business critical applications should be reviewed and tested to ensure there is no adverse impact on organizational operations or security.

Status

colour	Yellow
title	No

14.2.4 Restrictions on changes to software packages

Control: Modifications to software packages should be discouraged, limited to necessary changes and all changes should be strictly controlled.

Expand

title	Implementation Guidance

b) whether the consent of the vendor should be obtained;
c) the possibility of obtaining the required changes from the vendor as standard program updates;
d) the impact if the organization becomes responsible for the future maintenance of the software as a
result of changes;
e) compatibility with other software in use.
If changes are necessary the original software should

Status

colour	Yellow
title	No

TODO

14.2.5 Secure system engineering principles

Control: Principles for engineering secure systems should be established, documented, maintained and applied to any information system implementation efforts.

Status

colour	Green
title	Yes

See8.1 General Design Principles

14.2.6 Secure development environment

Control: Organizations should assess risks associated with individual system development efforts and establish secure development environments for specific system development efforts, considering:

Expand

title	Implementation Guidance

A secure development environment includes people, processes and technology associated with system
development and integration.
Organizations should assess risks associated with individual system development efforts and establish
secure development environments for specific system development efforts, considering:

a) sensitivity of data to be processed, stored and transmitted by the system;
b) applicable external and internal requirements, e.g. from regulations or policies;
c) security controls already implemented by the organization that support system development;
d) trustworthiness of personnel working in the environment (see 7.1.1);
e) the degree of outsourcing associated with system development;
f) the need for segregation between different development environments;
g) control of access to the development environment;
h) monitoring of change to the environment and code stored therein;
i) backups are stored at secure offsite locations;
j) control over movement of data from and to the environment.

Status

colour	Green
title	Yes

See https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Protection+of+Code+and+Secrets

14.2.7 Outsourced development

e) provision of evidence that security thresholds were used to establish minimum acceptable levels of
security and privacy quality;
f) provision of evidence that sufficient testing has been applied to guard against the absence of both
intentional and unintentional malicious content upon delivery;
g) provision of evidence that sufficient testing has been applied to guard against the presence of known
vulnerabilities;
h) escrow arrangements, e.g. if source code is no longer available;
i) contractual right to audit

Control: The organization should supervise and monitor the activity of outsourced system development.

Expand

title	Implementation Guidance

Status

colour	Green
title	Yes

See 7. Outsourced Development

14.2.8 System security testing

Control: Testing of security functionality should be carried out during development.

Status

colour	Green
title	Yes

See “custom security & developer tests” at 6. Security Tests

14.2.9 System acceptance testing

Control: Acceptance testing programs and related criteria should be established for new information systems, upgrades and new versions.

Status

colour	Green
title	Yes

See “custom security & developer tests” at 6. Security Tests

14.3 Test data

14.3.1 Protection of test data

a) the access control procedures, which apply to operational application systems, should also apply to test application systems;
b) there should be separate authorization each time operational information is copied to a test environment;
c) operational information should be erased from a test environment immediately after the testing is complete;
d) the copying and use of operational information should be logged to provide an audit trail

Control: Test data should be selected carefully, protected and controlled.

Expand

title	Implementation Guidance

Status

colour	Green
title	Yes

See “general requirement” at6. Security Tests

Versions Compared

Old Version 9

New Version 10

Key