AI2.10:
AI 2.10 Application Software Maintenance
Control Objective:
Develop a strategy and plan for the maintenance and release of software applications. Issues to consider include release planning and control, resource planning, bug fixing and error correction, minor enhancements, maintenance of documentation, emergency changes, interdependencies with other applications and infrastructure, upgrade strategies, contractual conditions such as support issues and upgrades, periodic review against business needs, risks and security requirements.
Applicability:
- Sarbanes-Oxley
- HIPAA
- GLBA
- PCI
- FISMA
- NIST SP 800-66
- Ditscap
- Control Exception
- User Defined
Risk Association Control Activities:
- 1. Risk: In-House and or Package applications may not meet all business and application control requirements.
- a. SOX.4.3.1 The organization acquires and or develops systems software in accordance with its acquisition, development and planning process.
- a. SOX.4.3.1 The organization acquires and or develops systems software in accordance with its acquisition, development and planning process.
- 1. Risk: In-House and or Package applications may not meet all business and application control requirements.
- 2. Risk: Controls provide reasonable assurance that the systems are appropriately tested and validated prior to being placed into production processes, and associated controls operate as intended and support financial reporting requirements.
- a. SOX.5.4 A testing strategy is developed and followed for all significant changes in applications and infrastructure technology, which addresses unit, system, integration and user-acceptance-level testing so that deployed systems operate as intended.
- a. SOX.5.4 A testing strategy is developed and followed for all significant changes in applications and infrastructure technology, which addresses unit, system, integration and user-acceptance-level testing so that deployed systems operate as intended.
- 2. Risk: Controls provide reasonable assurance that the systems are appropriately tested and validated prior to being placed into production processes, and associated controls operate as intended and support financial reporting requirements.
- 3. Risk: The impact of application system changes (e.g., hardware and software) should be evaluated and adjusted to ensure ongoing availability, performance and resilience requirements.
- a. SOX.6.1.1 The impact of application system changes (e.g., hardware and software) should be evaluated and adjusted to ensure ongoing availability performance and resilience requirements.
- a. SOX.6.1.1 The impact of application system changes (e.g., hardware and software) should be evaluated and adjusted to ensure ongoing availability performance and resilience requirements.
- 3. Risk: The impact of application system changes (e.g., hardware and software) should be evaluated and adjusted to ensure ongoing availability, performance and resilience requirements.
Implementation Guide:
Process Narrative
Insert a description of the process narration that is applicable to the existing control statement this narrative refers to.
Process Illustration
Insert a process diagram, flowchart or other visual representation here to illustrate the process narrative.
File:Someimage.jpg
Control Commentary
Insert a description of the control that is applicable to the existing control statement this commentary refers to.
Control Exception Commentary
Insert a description of the control exception that is applicable to the existing control statement this commentary refers to.
Evidence Archive Location
Insert Evidence Description Here.
Control Status and Auditors Commentary
Describe the condition of the applicable control and its effectiveness. Set the color icon to a redlock.jpg, yellowlock.jpg or greenlock.jpg.
File:Redlock.jpg
Remediation Plan
Insert remediation plan, applicability, or any information that indicates what needs to be done.
Supplemental Information:
ISO 17799 12.1: Security requirements of information systems.
- Objective: To ensure that security is an integral part of information systems.
- Objective: To ensure that security is an integral part of information systems.
- Information systems include operating systems, infrastructure, business applications, off-the-shelf products, services, and user-developed applications. The design and implementation of the information system supporting the business process can be crucial for security. Security requirements should be identified and agreed prior to the development and/or implementation of information systems.
- Information systems include operating systems, infrastructure, business applications, off-the-shelf products, services, and user-developed applications. The design and implementation of the information system supporting the business process can be crucial for security. Security requirements should be identified and agreed prior to the development and/or implementation of information systems.
- All security requirements should be identified at the requirements phase of a project and justified, agreed, and documented as part of the overall business case for an information system.
- All security requirements should be identified at the requirements phase of a project and justified, agreed, and documented as part of the overall business case for an information system.
ISO 12.1.1: Statements of business requirements for new information systems, or enhancements to existing information systems should specify the requirements for security controls.
- Implementation guidance:
- Implementation guidance:
- Specifications for the requirements for controls should consider the automated controls to be incorporated in the information system, and the need for supporting manual controls. Similar considerations should be applied when evaluating software packages, developed or purchased, for business applications.
- Specifications for the requirements for controls should consider the automated controls to be incorporated in the information system, and the need for supporting manual controls. Similar considerations should be applied when evaluating software packages, developed or purchased, for business applications.
- Security requirements and controls should reflect the business value of the information assets involved (see also 7.2), and the potential business damage, which might result from a failure or absence of security.
- Security requirements and controls should reflect the business value of the information assets involved (see also 7.2), and the potential business damage, which might result from a failure or absence of security.
- System requirements for information security and processes for implementing security should be integrated in the early stages of information system projects. Controls introduced at the design stage are significantly cheaper to implement and maintain than those included during or after implementation.
- System requirements for information security and processes for implementing security should be integrated in the early stages of information system projects. Controls introduced at the design stage are significantly cheaper to implement and maintain than those included during or after implementation.
- If products are purchased, 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 then the risk introduced and associated controls should be reconsidered prior to purchasing the product. Where additional functionality is supplied and causes a security risk, this should be disabled or the proposed control structure should be reviewed to determine if advantage can be taken of the enhanced functionality available.
- If products are purchased, 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 then the risk introduced and associated controls should be reconsidered prior to purchasing the product. Where additional functionality is supplied and causes a security risk, this should be disabled or the proposed control structure should be reviewed to determine if advantage can be taken of the enhanced functionality available.
- Other information:
- Other information:
- If considered appropriate, for example for cost reasons, management may wish to make use of independently evaluated and certified products. Further information about evaluation criteria for IT security products can be found in ISO/IEC 15408 or other evaluation or certification standards, as appropriate.
- If considered appropriate, for example for cost reasons, management may wish to make use of independently evaluated and certified products. Further information about evaluation criteria for IT security products can be found in ISO/IEC 15408 or other evaluation or certification standards, as appropriate.
ISO/IEC TR 13335-3 provides guidance on the use of risk management processes to identify requirements for security controls.
Implementation guidance
Insert guidance in this section if it helps to elaborate upon the subject matter. Examples of evidence that would help guide the end user is desirable.
--Mdpeters 08:02, 23 June 2006 (EDT)