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. |
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 | ||
---|---|---|
| ||
a) security of the development environment; c) security requirements in the design phase; |
TSS-WEB provides a template for such a policy: a) See 4. Secure Development Environment b)
|
“Security approvals” e) See 4. Secure Development Environment f) See 5. Security within Software 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 | ||
---|---|---|
| ||
This process should include a risk assessment, analysis of the impacts of changes and specification of a) maintaining a record of agreed authorization levels; |
Control met by 5. Security within Software 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. |
Not relevant for web-based applications. | ||||||
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 |
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
. |
|
Not relevant for web-based applications. | |||||||
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. |
| ||||||
14.2.6 Secure development environment Control |
: |
title | Implementation Guidance |
---|
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.
See https://secodis.atlassian.net/wiki/spaces/TSSWEB/pages/65878/4.+Protection+of+Code+and+Secrets | ||||||
14.2.7 Outsourced development Control: The organization should supervise and monitor the activity of outsourced system development. |
title | Implementation Guidance |
---|
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;
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 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.
| |||||||
14.2.8 System security testing Control: Testing of security functionality should be carried out during development. |
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. |
See “custom security & developer tests” at 6. Security Tests | ||||||
14.3 Test data | |||||||
14.3.1 Protection of test data Control: Test data should be selected carefully, protected and controlled |
title | Implementation Guidance |
---|
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
. |
See “general requirement” at6. Security Tests |