View source for Information Systems Acquisition, Development and Maintenance:

==Security requirements of information systems==
The objective of this category is to ensure that security is an integral part of the organization's information systems, and of the business processes associated with those systems.<br>
<br>
===Security requirements analysis and specification===
Statements of business requirements for new information systems, or enhancements to existing information systems should include specification of the requirements for security controls.<br>
<br>
'''Control includes:'''<br>
<br>
* Consideration of business value of and legal-regulatory-certificatory standards for information assets affected by the new or changed system(s)
* Consideration of administrative, technical and physical controls available to support security for the system(s)
* Integration of  these controls early in system design and requirements specification
* A formal plan for testing and acceptance, including independent evaluation where appropriate
<br>
===Correct processing in applications===
This category aims to prevent errors, loss, unauthorized modification or misuse of information in applications.<br>
<br>
===Input data validation===
Data input in applications should be validated to ensure that the data is correct and appropriate.<br>
<br>
'''Control includes:'''<br>
<br>
* Use of both automatic and manual methods of data verification and cross-checking, as appropriate
* Defined responsibilities and processes for responding to detected errors<br>
<br>
===Control of internal processing===
Validation checks should be incorporated into applications to detect the corruption of of information through processing errors or deliberate acts.<br>
<br>
'''Control includes:'''<br>
<br>
* Use of both automatic and manual methods of data verification and cross-checking, as appropriate
* Defined responsibilities and processes for responding to detected errors<br>
<br>
===Message integrity===
Requirements for ensuring authenticity and protecting message integrity in applications should be identified, and appropriate controls identified and implemented.<br>
<br>
===Output data validation===
Data output from applications should be validated to ensure that the processing of stored information is correct and appropriate to the circumstances.<br>
<br>
'''Control includes:'''<br>
<br>
* Use of both automatic and manual methods of data verification and cross-checking, as appropriate
* Defined responsibilities and processes for responding to detected errors<br>
<br>
===Cryptographic controls===
This category aims to protect the confidentiality, integrity and authenticity of information by cryptographic means.<br>
<br>
===Policy on the use of cryptographic controls===
Policies on the use of cryptographic controls for protection of information should be developed and implemented.<br>
<br>
'''Control includes:'''<br>
<br>
* Statement of general principles and management approach to the use of cryptographic controls
* Specifications based on a thorough risk assessment, that considers appropriate algorithm selections, key management and other core features of cryptographic implementations
* Consideration of legal restrictions on technology deployments
* Application, as appropriate, to data at rest and fixed-location devices, data transported by mobile or removable media and embedded in mobile devices, and data transmitted over communications links
* Specification of roles and responsibilities for implementation of and the monitoring of compliance with the policy<br>
<br>
===Key management===
Key management policies and processes should be implemented to support an organization's use of cryptographic techniques.<br>
<br>
'''Control includes procedures for:'''<br>
<br>
* Distributing, storing, archiving and changing and or updating keys
* Recovering, revoking and or destroying and dealing with compromised keys
* Logging all transactions associated with keys<br>
<br>
==Security of System Files==
'''Control objective:'''<br>
<br>
To ensure the security of system files.

===Control of operational software===
Procedures should be implemented to control the installation of software on operational systems, to minimize the risk of interruptions in or corruption of information services.<br>
<br>
'''Control includes:'''<br>
<br>
* Updating performed only with appropriate management authorization
* Updating performed only by appropriately trained personnel
* Only appropriately tested and certified software deployed to operational systems
* Appropriate change management and configuration control processes for all stages of updating
* Appropriate documentation of the nature of the change and the processes used to implement it
* A rollback strategy in place, including retention of prior versions as a contingency measure
* Appropriate audit logs maintained to track changes<br> 
<br>
===Protection of system test data===
Test data should be selected carefully and appropriately logged, protected and controlled.<br>
<br>
===Access control for program source code===
Access to program source code should be restricted.<br>
<br>
'''Control includes:'''<br>
<br>
* Appropriate physical and technical safeguards for program source libraries, documentation, designs, specifications, verification and validation plans
* Maintenance and copying of these materials subject to strict change management and other controls<br>
<br>
===Security in development and support processes===
This category aims to maintain the security of application system software and information.<br>
<br>
'''Change control procedures'''<br>
<br>
The implementation of changes should be controlled by the use of formal change control procedures.<br>
<br>
'''Control includes:'''<br>
<br>
* A formal process of documentation, specification, testing, quality control and managed implementation
* A risk assessment, analysis of actual and potential impacts of changes, and specification of any security controls required
* A budgetary or other financial analysis to assess adequacy of resources formal agreement to and approval of changes by appropriate management
* Appropriate notification of all affected parties prior to implementation, on the nature, timing and likely impacts of the changes
* Scheduling of changes to minimize the adverse impact on business processes<br>
<br>
Technical review of applications after operating system changes===
When operating systems and processes are changed, critical business processes should be reviewed and tested to ensure that there has been no adverse impact.<br>
<br>
===Restrictions on changes to software packages===
Modifications to software packages should be discouraged, limited to necessary changes, and all changes shall be strictly controlled.<br>
<br>
===Information leakage===
Opportunities for information leakage should be appropriately minimized or prevented.<br>
<br>
'''Control includes:'''<br>
<br>
* Risk assessment of the probable and possible mechanisms for information leakage, and consideration of appropriate countermeasures
* Regular monitoring of likely information leak mechanisms and sources
* End-user awareness and training on preventive strategies (e.g., to remove meta-data in transferred files)<br>
<br>
===Outsourced software development===
Outsourced software development should be appropriately supervised and monitored by the organization.<br>
<br>
===Technical vulnerability management===
This category aims to reduce risks resulting from exploitation of published technical vulnerabilities.<br>
<br>
===Control of technical vulnerabilities===
Timely information about technical vulnerabilities of information systems used by the organization should be obtained, evaluated in terms of organizational exposure and risk, and appropriate countermeasures taken.<br>
<br>
'''Control includes:'''<br>
<br>
* A complete inventory of information assets sufficient to identify systems put at risk by a particular technical vulnerability
* Procedures to allow timely response to identification of technical vulnerabilities that present a risk to any of the organization's information assets, including a timeline based on the level of risk
* Defined roles and responsibilities for implementation of countermeasures and other mitigation procedures

==References==
ISO-27002:2005 12.1.1<br>
HIPAA 164.312(c)(1)<br>
ISO-27002:2005 12.2.1<br>
ISO-27002:2005 12.2.2<br>
ISO-27002:2005 12.2.3<br>
ISO-27002:2005 12.2.4<br>
ISO-27002:2005 12.3.1<br>
HIPAA 164.312(a)(2)(iv)<br>
HIPAA 164.312(e)(2)(ii)<br>
PCI-DSS:2005 3.4<br>
PCI-DSS:2005 4<br>
ISO-27002:2005 12.3.2<br>
PCI-DSS:2005 3.5<br>
ISO-27002:2005 12.4.1<br>
ISO-27002:2005 12.4.2<br>
ISO-27002:2005 12.4.3<br>
ISO-27002:2005 12.5.1<br>
ISO-27002:2005 12.5.2<br>
ISO-27002:2005 12.5.3<br>
ISO-27002:2005 12.5.4<br>
ISO-27002:2005 12.5.5<br>
ISO-27002:2005 12.6.1<br>

==See also==
* ISO 17799/27002 - Code of Practice for Information Security Management