The System Acquisition, Development and Maintenance clause covers controls for identification, analyses and specification of information security requirements, securing application services in development and support processes, technical review restrictions on changes to software packages, secure system engineering principles, secure development environment, outsourced development, system security testing, system acceptance testing and protection of test data. This can be thought of as a control that not only governs procurement processes for new systems, but that also sets criteria for new systems that can be tested before go-live. We will take a look and how ISO 27001 defines this control, and how organizations can demonstrate compliance with it through their business as usual (BAU) processes. So firstly what does security requirements of information systems actually mean? Well, in short this control aims to ensure that security requirements for new systems are assessed, defined and measured. When an organization identifies the requirement for a new system, the requirements of the system are often captured in the form of functional and non-functional requirements. This sets the bar for what the organization expects the system to be able to look like and feature. The organization can then measure the system against these requirements to ensure it is fit for purpose before procuring or building it. It is during this process that security requirements should be identified.
To be most effective, information security must be integrated into the system lifecycle from system inception through system disposal. Regardless of the formal or informal lifecycle methodology employed, security can be incorporated into information systems acquisition, development and maintenance by implementing effective security practices in the following areas.
• Security requirements for information systems
• Security in development and support processes
• Test data
Information systems security begins with incorporating security into the requirements process for any new application or system enhancement whether that application is purchased from a vendor or internally developed. Designing security requirements in systems is most effective at the early stages of system development. Similarly, security requirements are presented to the vendor during the requirements phase of a product or cloud service purchase. Formal testing should be done to determine whether the product meets the required security specifications prior to purchasing the product or moving the application to production.
Security in development and support processes is an essential part of a comprehensive quality assurance and production control process and usually involves training and continuous oversight by the most experienced staff. Rules for system and software development should be developed. These rules should incorporate secure software development techniques such as user authentication, session control, logging, and data validation and sanitization. Unit, system, integration and regression testing should include testing of security requirements prior to deployment. Changes to the system as well as its operating environments should be managed, tested and approved. Support processes are closely related to A.12. Operations Security. As system maintenance occurs secure operational processes with regard to change control, separation of development, test and production environments as well as other operational controls provide many of the post implementation support processes and control. System and acceptance testing usually requires Test data that is as close as possible to production data. Using production data for test data should be avoided unless mechanisms for removing or masking personally identifiable information or other sensitive information in test data is developed.
A.14.1 Security requirements of information systems
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.
A.14.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.
Information security requirements should be identified using various methods such as deriving compliance requirements from policies and regulations, threat modelling, incident reviews, or use of vulnerability thresholds. Results of the identification should be documented and reviewed by all stakeholders. Information security requirements and controls should reflect the business value of the information involved and the potential negative business impact which might result from lack of adequate security. Identification and management of information security requirements and associated processes should be integrated in early stages of information systems projects. Early consideration of information security requirements, e.g. at the design stage can lead to more effective and cost efficient solutions. Information security requirements should also consider:
a) the level of confidence required towards the claimed identity of users, in order to derive user authentication requirements;
b) access provisioning and authorization processes, for business users as well as for privileged or technical users;
c) informing users and operators of their duties and responsibilities;
d) the required protection needs of the assets involved, in particular regarding availability, confidentiality, integrity;
e) requirements derived from business processes, such as transaction logging and monitoring, nonrepudiation requirements;
f) requirements mandated by other security controls, e.g. interfaces to logging and monitoring or data leakage detection systems.
For applications that provide services over public networks or which implement transactions, the dedicated controls 14.1.2 and 14.1.3 should be considered. If products are acquired, a formal testing and acquisition process should be followed. Contracts with
the supplier should address the identified security requirements. Where the security functionality in a proposed product does not satisfy the specified requirement, the risk introduced and associated controls should be reconsidered prior to purchasing the product. Available guidance for security configuration of the product aligned with the final software / service stack of that system should be evaluated and implemented. Criteria for accepting products should be defined e.g. in terms of their functionality, which will give assurance that the identified security requirements are met. Products should be evaluated against these criteria before acquisition. Additional functionality should be reviewed to ensure it does not introduce unacceptable additional risks.
A.A14.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.
Information security considerations for application services passing over public networks should include the following:
a) the level of confidence each party requires in each other’s claimed identity, e.g. through authentication;
b) authorization processes associated with who may approve contents of, issue or sign key transactional documents;
c) ensuring that communicating partners are fully informed of their authorizations for provision or use of the service;
d) determining and meeting requirements for confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation of contracts, e.g. associated with tendering and contract processes;
e) the level of trust required in the integrity of key documents;
f) the protection requirements of any confidential information;
g) the confidentiality and integrity of any order transactions, payment information, delivery address details and confirmation of receipts;
h) the degree of verification appropriate to verify payment information supplied by a customer;
i) selecting the most appropriate settlement form of payment to guard against fraud;
j) the level of protection required to maintain the confidentiality and integrity of order information;
k) avoidance of loss or duplication of transaction information;
l) liability associated with any fraudulent transactions;
m) insurance requirements.
Many of the above considerations can be addressed by the application of cryptographic controls, taking into account compliance with legal requirements especially for cryptography legislation.
Application service arrangements between partners should be supported by a documented agreement which commits both parties to the agreed terms of services, including details of authorization. Resilience requirements against attacks should be considered, which can include requirements for protecting the involved application servers or ensuring the availability of network interconnections required to deliver the service.
Applications accessible via public networks are subject to a range of network related threats, such as fraudulent activities, contract disputes or disclosure of information to the public. Therefore, detailed risk assessments and proper selection of controls are indispensable. Controls required often include cryptographic methods for authentication and securing data transfer. 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.
A. 14.1.3 Protecting application services transactions
Information involved in application service transactions should be protected to prevent incomplete transmission, mis-routing, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication or replay.
Information security considerations for application service transactions should include the following:
a) the use of electronic signatures by each of the parties involved in the transaction;
b) all aspects of the transaction, i.e. ensuring that:
- user’s secret authentication information of all parties are valid and verified;
- the transaction remains confidential;
- privacy associated with all parties involved is retained;
c) communications path between all involved parties is encrypted;
d) protocols used to communicate between all involved parties are secured;
e) ensuring that the storage of the transaction details is located outside of any publicly accessible environment, e.g. on a storage platform existing on the organizational intranet, and not retained and exposed on a storage medium directly accessible from the Internet;
f) 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.
The extent of the controls adopted needs to be commensurate with the level of the risk associated with each form of application service transaction. Transactions may need to comply with legal and regulatory requirements in the jurisdiction which the transaction is generated from, processed via, completed at or stored in.
The acquisition of a system or application often includes a Request for Proposals (RFP), which is a formal procurement process. During this process, security requirements need to be identified. It can include both a security review and a security questionnaire as part of the RFP process. Learn more about this effective practice by viewing Building Security into the RFP Process. The organization can develop a procurement process for evaluating whether an electronic service is considered to be low-risk, and potentially eligible for purchase using a P-Card. The criteria can include in Purchasing Software and Electronic Services with a P-Card. Many organizations are looking to the cloud for information system solutions. Cloud Computing Security considerations are essential. Organizations need to perform due diligence to assess the security of cloud service providers. The Cloud Controls Matrix may prove particularly beneficial to those who are evaluating services prior to purchase. The Organization can share experience, lessons learned, and recommendations for creating a cloud policy, contracted solutions, and security assessments in Bring Your Own Cloud.
As electronic commerce and online transactions become more prevalent, controls should be implemented to protect the information involved in this activity from various threats associated with this way of doing business. A review of potential information security controls that can be implemented for risk reduction should be considered, such as encryption, authorization processes, segregation of duties, network security controls, checks and balances to verify transactions, non-repudiation, etc. Care should also be taken to verify the validity and integrity of publicly available information provided over the internet, and protect this information from unauthorized access and compromises.
• Conducting Internal PCI DSS Assessments
• PCI DSS (Payment Card Industry Data Security Standard) Library Page
• Leading the Way to PCI Compliance: It’s All About Planning and Collaboration
As applications are developed for mobile computing, security requirements need to be included from the beginning. Applications often include data bases for backend processing.
System Development–For systems developed by the organization:
1. Investigate and review how your organization manages software development for release to the campus community.
2. Revise the process to ensure the security team is involved at key points in your organization’s software development life cycle (SDLC). Having security “at the table” early and throughout the SDLC ensures that security requirements are designed, tested and implemented when they are the least costly. It is particularly critical to be involved in defining security requirements at the beginning of a development project and prior to implementation to validate security requirements are met.
3. Review Microsoft’s Security Development Lifecycle that parallels the system development lifecycle and can be used to assist in developing the role of security in each of the SDLC phases.
System Acquisition–For systems purchased by the organization:
1. Investigate and review how your organization acquires new software. Understand the procurement processes in place when selecting vendors; particularly for cloud services.
2. Determine whether processes encourage proper assessment of vendor relationships and cloud environments before contracting. For example, Northwestern University has a clearly defined process for assessing vendors–Service Provider Security Assessment.
3. Verify that processes include acceptance criteria which will give assurances that security requirements are met.
4. Review and evaluate previous vendor contractual agreements for security protections. Helpful documents:
a. Data Protection Contractual Language contains sample contractual language for contracts.
b. Legal and Quasi-Legal Issues in Cloud Computing Contracts contains information that may be useful in specifying security requirements.
5. Develop a plan, if needed, for improving the contracting process with campus procurement and/or other sta
A.14.1.1 Information Security Requirements Analysis & Specification
Information security related requirements need to be included in any requirements for new information systems or enhancements to existing information systems. This can happen alongside A.6.1.5 as part of the information security in projects and should take into account the value of the information at risk which could align with the information classification scheme in A.8.2.1.In any new system development or change to existing systems, it is important to understand what the business requirements for security controls are by doing a risk assessment. This should be done prior to the selection of or commencement of the development of a solution. Security considerations should happen from the earliest possible opportunity to ensure that the correct requirements are identified before solution selection commences. The security requirements should be documented and agreed so that they can be referenced as the solution is procured or developed. It is not good practice to select or develop a solution and then assess the level of security capability afterwards. This often leads to higher risks and costs and may also cause problems in applicable legislation such as GDPR which encourages a secure by design philosophy and techniques such as Data Protection Privacy Impact Assessments (DPIA). There are also numerous websites advocating secure development practices and key principles for consideration. ISO 27002 also includes implementation guidance. Any of the principles being followed should be documented. The auditor will be looking to see that security is being considered at all stages of a project lifecycle, for a new system or changes to an existing system. They will also expect to see consideration for confidentiality, integrity and availability at a minimum prior to the selection or development process commencing.
A.14.1.2 Securing Application Services on Public Networks
The information involved in application services passing over public networks need to be protected from fraudulent activity, contract dispute and unauthorized disclosure and modification. For services being provided over a public network, like the internet, it is important to understand the risk levels involved and the business requirements for protecting information. Once again, it is important to consider confidentiality, integrity and availability. When financial transactions or sensitive personal information form part of the service, it is especially important to consider security to minimize the risk of fraudulent activity where GDPR requirements for encryption and other safeguards need to be the minimum requirements. Once operational, it is important to ensure that such services are constantly monitored for attack or undesired activity. The auditor will expect to see the consideration for “how secure” application services over public networks need to be, with decisions based on risk assessment and other legal, regulatory and contractual requirements.
A.14.1.3 Protecting Application Services Transactions
Information involved in application service transactions must be protected to prevent incomplete transmission, mis-routing, unauthorised message alteration, unauthorised disclosure, unauthorised message duplication or replay. Additional protection is likely to secure application service transactions (not necessarily just financial transactions). These may include; Use of electronic signatures, Use of encryption; and Use of secure protocols. The ongoing monitoring of such transactions in as near to real-time manner is also likely to be required.
A.14.2 Security in development and support processes
To ensure that information security is designed and implemented within the development lifecycle of information systems.
14.2.1 Secure development policy
Rules for the development of software and systems should be established and applied to developments within the organization.
Secure development is a requirement to build up a secure service, architecture, software and system. Within a secure development policy, the following aspects should be put under consideration:
a) security of the development environment;
b) guidance on the security in the software development lifecycle:
- security in the software development methodology;
- 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.
Secure programming techniques should be used both for new developments and in code re-use scenarios where the standards applied to development may not be known or were not consistent with current best practices. Secure coding standards should be considered and where relevant mandated for use. Developers should be trained in their use and testing and code review should verify their use. If development is outsourced, the organization should obtain assurance that the external party complies with these rules for secure development
Development may also take place inside applications, such as office applications, scripting, browsers and databases.
A.14.2.2 System change control procedures
Changes to systems within the development lifecycle should be controlled by the use of formal change control procedures.
Formal change control procedures should be documented and enforced to ensure the integrity of system, applications and products, from the early design stages through all subsequent maintenance efforts. Introduction of new systems and major changes to existing systems should follow a formal process of documentation, specification, testing, quality control and managed implementation. 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. Wherever practicable, application and operational change control procedures should be integrated. The change control procedures should include but not be limited to:
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 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.
Changing software can impact the operational environment and vice versa. Good practice includes the testing of new software in an environment segregated from both the production and development environments. This provides a means of having control over new software and allowing additional protection of operational information that is used for testing purposes. This should include patches, service packs and other updates.
Where automatic updates are considered, the risk to the integrity and availability of the system should be weighed against the benefit of speedy deployment of updates. Automated updates should not be used on critical systems as some updates can cause critical applications to fail.
A.14.2.3 Technical review of applications after operating platform changes
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.
This process should cover:
a) review of application control and integrity procedures to ensure that they have not been compromised by the operating platform changes;
b) ensuring that notification of operating platform changes is provided in time to allow appropriate tests and reviews to take place before implementation;
c) ensuring that appropriate changes are made to the business continuity plans.
Operating platforms include operating systems, databases and middleware platforms. The control should also be applied for changes of applications.
A.14.2.4 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 the following points should be considered:
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 the original software should be retained and the changes applied to a designated copy. A software update management process should be implemented to ensure the most up-to-date approved patches and application updates are installed for all authorized software. All changes should be fully tested and documented, so that they can be reapplied, if necessary, to future software upgrades. If required, the modifications should be tested and validated by an independent evaluation body.
A.14.2.5 Secure system engineering principles
Principles for engineering secure systems should be established, documented, maintained and applied to any information system implementation efforts.
Secure information system engineering procedures based on security engineering principles should be established, documented and applied to in-house information system engineering activities. Security should be designed into all architecture layers (business, data, applications and technology) balancing the need for information security with the need for accessibility. New technology should be analyzed for security risks and the design should be reviewed against known attack patterns. These principles and the established engineering procedures should be regularly reviewed to ensure that they are effectively contributing to enhanced standards of security within the engineering process. They should also be regularly reviewed to ensure that they remain up-to-date in terms of combating any new potential threats and in remaining applicable to advances in the technologies and solutions being applied. The established security engineering principles should be applied, where applicable, to outsourced information systems through the contracts and other binding agreements between the organization and the supplier to whom the organization outsources. The organization should confirm that the rigour of suppliers’ security engineering principles is comparable with its own.
Application development procedures should apply secure engineering techniques in the development of applications that have input and output interfaces. Secure engineering techniques provide guidance on user authentication techniques, secure session control and data validation, sanitization and elimination of debugging codes.
A. 14.2.6 Secure development environment
Organizations should establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle.
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;
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, organizations should document corresponding processes in secure development procedures and provide these to all individuals who need them.
A.14.2.7 Outsourced development
The organization should supervise and monitor the activity of outsourced system development.
Where system development is outsourced, the following points should be considered across the organization’s entire external supply chain:
a) licensing arrangements, code ownership and intellectual property rights related to the outsourced content;
b) contractual requirements for secure design, coding and testing practices;
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.
A.14.2.8 System security testing
Testing of security functionality should be carried out during development.
New and updated systems require thorough testing and verification during the development processes, including the preparation of a detailed schedule of activities and test inputs and expected outputs under a range of conditions. For in-house developments, such tests should initially be performed by the development team. Independent acceptance testing should then be undertaken (both for in-house and for outsourced developments) 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.
A.14.2.9 System acceptance testing
Acceptance testing programs and related criteria should be established for new information systems, upgrades and new versions.
System acceptance testing should include testing of information security requirements and adherence to secure system development practices. The testing should also be conducted on received components and integrated systems. Organizations can leverage automated tools, such as code analysis tools or vulnerability scanners, and should verify the remediation of security related defects. Testing should be performed 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.
One of the security layers that can expose serious vulnerabilities is the application layer. Inventorying and securing all applications, software interfaces, or integration points that “touch” sensitive data is crucial in any organization that handles personal identity data, HIPAA, PCI, or any data that can lead to identifying confidential information. Unfortunately, this layer is subject to extensive variations and stretches across many technologies, human competencies, and organizational controls, practices, and standards. As such, it is difficult to secure and sustain, usually requiring departments to re-evaluate much of their software development, acquisition, and production control organization, staffing, and practices. Moreover, since applications are enhanced to adapt to changing business needs relatively often, even while the technology they depend on may also be changing, a consistent and “routinized” approach to maintaining their security must be adopted. Fortunately, there are many excellent resources to help organizations get started. The Information Technology Infrastructure Library (ITIL) is one of the oldest and most mature frameworks for IT service management, and offers a wealth of best practice documents. JIRA is a project tracking tool that is very useful for bug tracking and change management. Jira workflows can be customized and used to formalize testing procedures.
A.14.2.1 Secure Development Policy
Rules for the development of software and systems should be established and applied to developments within the organization. A secure development policy is used to ensure that development environments are themselves secure and that the processes for developing and implementing systems and system changes encourage the use of secure coding and development practices. Such policies will include showing how security needs to be considered at all stages of the development lifecycle from design through to live implementation. Specific coding languages and development tools have different vulnerabilities and require different “hardening” techniques accordingly and it is important that these are identified and agreed and developers are made aware of their responsibilities to follow them. Compliant policies will address security checkpoints during development; secure repositories; security in version control; application security knowledge; and developers’ ability to avoid vulnerabilities, then find and fix them when they occur. The auditor will be looking here to see that security considerations are appropriate to the level of risk for the systems being developed or changed and that those doing the development understand the need to include security consideration throughout the development lifecycle. Strong initial screening in hiring for these skills, in life management and training of resources is essential and practices like pair programming, peer reviews and independent quality assurance, code reviews and testing are all positive attributes.
A.14.2.2 System Change Control Procedures
Changes to systems within the development lifecycle must be controlled by the use of formal change control procedures. System change control procedures should integrate with, be aligned to and support operational change control. Formal change management procedures are designed to reduce the risk of accidental or deliberate development of vulnerabilities that may allow systems to be compromised once the changes are put live. For system change control, it is important that the system owner understands what changes are being made to their system, why and by whom. It is their responsibility to ensure that their systems are not compromised through poor or malicious development. They should therefore be involved in setting the rules for authorization and pre-live testing and checking. Audit logs are required to provide evidence of the correct use of change procedures. ISO 27002 documents many aspects of change control that should be included, ranging from simple documentation of the changes through to consideration of the time for deployment to avoid negative business impact. This control like others in A.14 also aligns with documented procedures in A.12.1.2.
A.14.2.3 Technical Review of Applications After Operating Platform Changes
When operating platforms are changed, business critical applications need to be reviewed and tested to ensure there is no adverse impact on the organizational operations or security. When operating system platforms are changed it is commonplace that some applications may have compatibility problems. It is important therefore to test operating system changes in a development or test environment where critical business applications can be checked for compatibility with the changed OS. Procedures for control and testing of operating system changes should follow standard change management control.
A.14.2.4 Restrictions on Changes to Software Packages
Modifications to software packages need to be discouraged, limited to necessary changes and all changes should be strictly controlled. Vendor supplied software packages are designed for the mass-market and are not really designed for organizations making their own changes to them. In fact most of the time the ability to make such changes is locked out by the vendor and customization limited to within the package. Where open-source software is used, it is far more likely that changes can be made by the organization, however, this should be restricted and controlled to ensure that the changes made do not have an adverse impact on the internal integrity or security of the software.
A.14.2.5 Secure System Engineering Principles
Principles for engineering secure systems must be established, documented, maintained and applied to any information system implementation efforts. Secure software engineering principles exist at both general levels and specific to development platforms and coding languages. Wherever development is being carried out, consideration for the selection and application of such principles should be considered, assessed, formally documented and mandated. The auditor will want to see that as with many controls, the use of system engineering principles is considered against the risk levels identified and will be looking for evidence to support the choices made.
A.14.2.6 Secure Development Environment
Organizations need to establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle. Development environments need to be protected to ensure the malicious or accidental development and update of code that may create vulnerabilities or compromise confidentiality, integrity and availability. Protection requirements should be determined from risk assessment, business requirements and other internal and external requirements including legislation, regulation, contractual agreement or policies. In particular, if any form of live data is used in development environments it needs to be especially protected and controlled.
A.14.2.7 Outsourced Development
The organization must supervise and monitor the activity of outsourced system development. Where system and software development is outsourced either wholly or partly to external parties the security requirements must be specified in a contract or attached agreement. This is where Annex A 15.1 is important to have correct as well as A.13.2.4 for nondisclosure and confidentiality. It is also important to supervise and monitor development to gain assurance that organizational standards and requirements for security within systems is achieved. Depending on how embedded outsource partners are within the organization, especially if staff are located on organizational premises, it is important to include their staff in security awareness training and awareness programmed and communications. It is critical to ensure that the internal security practices of the outsource partner, e.g. staff vetting, at least meet assurance requirements relevant to the risk levels related to the developments they will be working on. The auditor will be looking to see that where outsourcing is used, there is evidence of due diligence before, during and after the engagement of the outsource partner has been conducted and includes consideration for information security provisions.
A.14.2.8 System Security Testing
Testing of security functionality needs to be carried out during development. Specific testing of security functionality for any development must be carried out and signed-off by an appropriate authority with security competency and responsibility. Security testing expected outcomes should be documented before testing commences and should be based on business requirements for security. The auditor will want to see that there is evidence that security specific testing has been carried out in any development that is security relevant.
A.14.2.9 System Acceptance Testing
Acceptance testing programs and related criteria must be established for new information systems, upgrades and new versions. For acceptance testing, the tests and the criteria for demonstrating a successful test should be designed and developed based on business requirements prior to tests being carried out. Acceptance testing should also include security testing. The auditor will be looking for evidence that shows acceptance testing criteria and methods were designed according to business requirements and include provisions for security acceptance testing.
A.14.3 Test data
To ensure the protection of data used for testing.
A.14.3.1 Protection of test data
Test data should be selected carefully, protected and controlled.
The use of operational data containing personally identifiable information or any other confidential information for testing purposes should be avoided. If personally identifiable information or otherwise confidential information is used for testing purposes, all sensitive details and content should be protected by removal or modification.
The following guidelines should be applied to protect operational data, when used for testing purposes:
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.
System and acceptance testing usually requires substantial volumes of test data that are as close as possible to operational data.
Data used in testing environments such as quality assurance, test and development must be protected against unauthorized access. For example, test environments may be firewalled to restricted to campus systems. Accounts may be disabled so that only a subset of accounts can be used for testing. Copying data between production and test environment should be approved. Where possible data used for testing should not contain personally identifiable information. Guidelines for Data De-Identification or Anonymization should be followed to remove sensitive information or to modify it beyond recognition when used for testing purposes. If production data is used unchanged for testing, the data should be protected with the same level of controls used for the production system. Test data must be selected carefully, protected and controlled. Test data should ideally be created in a generic form with no relation to live system data. However, it is recognized that often live data must be used to perform accurate testing. Where live data is used for testing it should be; Anonymized as far as possible; Carefully selected and secured for the period of testing; Securely deleted when testing is complete. Use of live data must be pre-authorized, logged and monitored. The auditor will expect to see robust procedures in place to protect data being used in test environments, especially if this is wholly or partly live data.
If you need assistance or have any doubt and need to ask any question contact me at firstname.lastname@example.org. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.