(5) Risk Treatment Ch9

9. System acquisition, development and maintenance

9.1 Security requirements of information systems

Objective: To ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks.

9.1.1 Information security requirements analysis and specification

The information security related requirements should be included in the requirements for new information systems or enhancements to existing information systems.

Identify information security requirements using various methods such as deriving compliance requirements from policies and regulations, threat modelling and incident reviews. Information security requirements and controls should reflect the business value of the information involved and the potential negative business impact.
Early consideration of information security requirements, e.g. at the design stage can lead to more effective and cost efficient solutions.
Information security requirements include:
a) the required protection needs of the assets regarding their availability, confidentiality, integrity;
b) user authentication requirements;
c) access provisioning and authorization processes, for end users as well as for privileged technical users;
e) requirements derived from business processes, such as transaction logging and monitoring, non-repudiation requirements.
Identify security requirements in contracts with the supplier. Where the security functionality of the product does not satisfy the specified requirement, reconsider the risk introduced and associated controls. Additional functionality should be reviewed to ensure it does not introduce unacceptable additional risks.

9.1.2 Securing application services on public networks

Information involved in application services passing over public networks should be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification.

Applications accessible via public networks are subject to a range of threats and fraudulent activities such as unauthorized message alteration, incomplete transmission, mis-routing or disclosure of information to the public. Therefore, conduct detailed risk assessments and select proper controls like controls that include cryptographic methods for authentication and securing data transfer.
For application services passing over public networks:
a) establish the level of confidence among the parties through authentication;
b) establish authorization processes e.g. who may approve contents of, issue or sign key transactional documents;
c) determine and meet requirements for confidentiality and integrity of key documents, for proof of dispatch and receipt of key documents;
d) select the most appropriate settlement form of payment to guard against fraud to guarantee the confidentiality and integrity of any order transactions, payment information, confirmation of receipts etc.
Application services can make use of secure authentication methods, e.g. using public key cryptography and digital signatures to reduce the risks. Also, trusted third parties can be used, where such services are needed.
Protect all aspects of the application service transactions by ensuring:
a) the use of electronic signatures by each of the parties involved in the transaction;
b) authentication information of all parties are valid and verified;
c) the transaction remains confidential and privacy ofall parties involved is retained;
d) communications path between all involved parties is encrypted;
e) protocols used to communicate between parties are secured;
f) the transaction details are stored outside of any publicly accessible environment and not retained and exposed on a storage medium directly accessible from the Internet;
Where a trusted authority is used (e.g. for the purposes of issuing and maintaining digital signatures or digital certificates) security is integrated and embedded throughout the entire end-to-end certificate/signature management process.

9.2 Security in development and support processes

Objective: To ensure that information security is designed and implemented within the development lifecycle of information systems.

9.2.1 Secure development policy

Security rules for the development of software and systems should be established and applied to developments within the organization that cover the entire system development lifecycle.

To build up a secure service, architecture, software and system, ensure:
a) security of the development environment;
b) security in the software development methodology
c) secure coding guidelines for each programming language used;
d) security requirements in the design phase;
e) security checkpoints within the project milestones;
f) secure repositories;
g) security in the version control;
h) required application security knowledge;
i) developers’ capability of avoiding, finding and fixing vulnerabilities.
A secure development environment includes people, processes and technology associated with system development and integration. When establishing secure development environment, consider:
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;
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.
Once the level of protection is determined for a specific development environment, document corresponding processes in secure development procedures and provide these to all individuals who need them.

9.2.2 System change control procedures

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

Document and enforce formal change control procedures to ensure the integrity of system, applications and products. Changing software can impact the operational environment and vice versa. Introduction of new systems and major changes to existing systems should follow a formal process of documentation, specification, testing, quality control and managed implementation.
Formal change process ensures that existing security and control procedures are not compromised and 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.
Formal change control ensures:
a) that changes are submitted by authorized users following recorded authorization levels;
b) review of controls and integrity procedures to ensure that they will not be compromised by the changes;
c) identification of all software, information, database entities and hardware that require amendment;
d) identification and checking of security critical code to minimize the likelihood of known security weaknesses;
e) obtaining of formal approval for proposals before work commences;
f) that authorized users accept changes prior to implementation;
g) that the system documentation is updated on the completion of each change;
h) maintainance of a version control for all software updates;
i) maintainance of an audit trail of all change requests;
j) that operating documentation and user procedures are changed as necessary;
k) that the implementation of changes takes place at the right time and disturbance of the business processes involved is avoided.
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.

9.2.3 Restrictions on changes to software packages

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

As far as possible and practicable, vendor-supplied software packages should be used without modification.
Where a software package needs to be modified, consider:
a) the risk of built-in controls and integrity processes being compromised;
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, retain the original software and the changes like patches and updates applied to a designated copy. Test and document all changes, so that they can be reapplied, if necessary, to future software upgrades.

9.2.4 Outsourced development

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

Obtain assurance that the external party complies with rules for secure development (see 9.2.1) if development is outsourced.
Set contractual requirements for secure design, coding and testing practices - developers should be trained in the use of secure programming techniques and testing and code review should verify their use;
Conduct acceptance testing for the quality and accuracy of the deliverables;
Ask developer to provide evidence that security thresholds were used to establish minimum acceptable levels of security and privacy quality;
Ask developer to provide evidence that sufficient testing has been applied to guard against the presence of known vulnerabilities and against the absence of both intentional and unintentional malicious content upon delivery;
Set contractual right to audit development processes and controls, considering that the organization remains responsible for compliance with applicable laws and control efficiency verification;
Set contractual requirements for effective documentation of the build environment used to create deliverables.

9.2.5 System security testing

Testing of security functionality should be carried out during development. Test data should be selected carefully, protected and controlled.

New and updated IT systems require thorough testing and verification during and after the development processes, including:
a) the preparation of a detailed schedule of activities and
b) the preparation of test inputs and expected outputs under a range of conditions.
c) independent acceptance testing should then be undertaken to ensure that the system works as expected and only as expected.
The extent of testing should be in proportion to the importance and nature of the system. System and acceptance testing usually requires substantial volumes of test data that are as close as possible to operational data.
Avoid the use of operational data containing personally identifiable information or any other confidential information. If it is necessary to use confidential data, remove or modify all sensitive details and content.
When using operational data for testing purposes:
a) use the same access control procedures, which apply to operational application systems;
b) use authorization each time operational information is copied to a test environment;
c) erase operational information from a test environment immediately after the testing;
d) log the copying and use of operational information to provide an audit trail.
Establish acceptance testing criteria for new information systems, upgrades and new versions and include information security requirements in system acceptance testing. The testing should also be conducted on received components and integrated systems. If applicable, use automated tools, such as code analysis tools or vulnerability scanners, and verify the remediation of security-related defects.
Perform acceptance tests in a realistic test environment to ensure that the system will not introduce vulnerabilities to the organization’s environment and that the tests are reliable.