AI2.7:: Difference between revisions
No edit summary |
No edit summary |
||
| Line 103: | Line 103: | ||
'''Implementation guidance'''<br> | '''Implementation guidance'''<br> | ||
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.<br> | 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.<br> | ||
--[[User:Mdpeters|Mdpeters]] 08:14, 23 June 2006 (EDT) | |||
Latest revision as of 12:14, 23 June 2006
AI 2.7 Development of Application Software
Control Objective:
Ensure that automated functionality is developed in accordance with design specifications, development and documentation standards and quality requirements. Approve and sign off on each key stage of the application software development process following successful completion of functionality, performance and quality reviews. Issues to be considered include approval that design specifications meet business, functional and technical requirements; approval of change requests; and confirmation that application software is compatible with production and ready for migration. In addition, ensure that all legal and contractual aspects are identified and addressed for application software developed by third parties.
Applicability:
- Sarbanes-Oxley
- HIPAA
- GLBA
- PCI
- FISMA
- NIST SP 800-66
- Ditscap
- Control Exception
- User Defined
Risk Association Control Activities:
- 1. Risk: Information security and business requirements may be compromised. Inaccurate results are produced.
- a. SOX.1.1 A formal, documented systems development methodology should be established and implemented by management. This systems development life cycle (SDLC) describes the stages involved in information system development projects, from an initial feasibility study through maintenance of the completed application. Verify that security, availability, and process integrity requirements are included.
- a. SOX.1.1 A formal, documented systems development methodology should be established and implemented by management. This systems development life cycle (SDLC) describes the stages involved in information system development projects, from an initial feasibility study through maintenance of the completed application. Verify that security, availability, and process integrity requirements are included.
- 1. Risk: Information security and business requirements may be compromised. Inaccurate results are produced.
- 2. Risk: Controls provide reasonable assurance that policies and procedures that define required acquisition and maintenance processes have been developed and are maintained, and that they define the documentation needed to support the proper use of the applications and the technological solutions put in place.
- a. SOX.1.4 The organization has policies and procedures regarding program development, program change, access to programs and data, and computer operations, which are periodically reviewed, updated and approved by management.
- a. SOX.1.4 The organization has policies and procedures regarding program development, program change, access to programs and data, and computer operations, which are periodically reviewed, updated and approved by management.
- 2. Risk: Controls provide reasonable assurance that policies and procedures that define required acquisition and maintenance processes have been developed and are maintained, and that they define the documentation needed to support the proper use of the applications and the technological solutions put in place.
- 3. Risk: Development and maintenance of system with potential impact to financial reporting bypass processes for identifying business requirements, risks, and for designing needed controls.
- a. SOX.1.14 Controls provide reasonable assurance that systems with potential impact to financial reporting are developed and maintained in a controlled manner through the use of a development methodology.
- a. SOX.1.14 Controls provide reasonable assurance that systems with potential impact to financial reporting are developed and maintained in a controlled manner through the use of a development methodology.
- 3. Risk: Development and maintenance of system with potential impact to financial reporting bypass processes for identifying business requirements, risks, and for designing needed controls.
- 4. Risk: Business requirements are not met or third parties have inappropriate access to business data stores and business processes.
- a. SOX.2.0.6 Roles and responsibilities of third parties are clearly defined in the contractual relationship.
- a. SOX.2.0.6 Roles and responsibilities of third parties are clearly defined in the contractual relationship.
- 4. Risk: Business requirements are not met or third parties have inappropriate access to business data stores and business processes.
- 5. Risk: Third party entities have inappropriate access to critical business processes and data.
- a. SOX.2.0.7 Third party (outsourced) processors have established an acceptable level of control procedures in their operations.
- a. SOX.2.0.7 Third party (outsourced) processors have established an acceptable level of control procedures in their operations.
- 5. Risk: Third party entities have inappropriate access to critical business processes and data.
- PCI-6.3.1 Testing of all security patches and system and software configuration changes before deployment.
- PCI-6.3.1 Testing of all security patches and system and software configuration changes before deployment.
- PCI-6.3.2 Separate development/test and production environments.
- PCI-6.3.2 Separate development/test and production environments.
- PCI-6.3.3 Separation of duties between development/test and production environments.
- PCI-6.3.3 Separation of duties between development/test and production environments.
- PCI-6.3.4 Production data (real credit card numbers) are not used for testing or development.
- PCI-6.3.4 Production data (real credit card numbers) are not used for testing or development.
- PCI-6.3.5 Removal of test data and accounts before production systems become active.
- PCI-6.3.5 Removal of test data and accounts before production systems become active.
- PCI-6.3.6 Removal of custom application accounts, usernames, and passwords before applications become active or are released to customers.
- PCI-6.3.6 Removal of custom application accounts, usernames, and passwords before applications become active or are released to customers.
- PCI-6.3.7 Review of custom code prior to release to production or customers, to identify any potential coding vulnerability.
- PCI-6.3.7 Review of custom code prior to release to production or customers, to identify any potential coding vulnerability.
- PCI-6.5.1 Invalidated input.
- PCI-6.5.1 Invalidated input.
- PCI-6.5.2 Broken access control (e.g., malicious use of user IDs).
- PCI-6.5.2 Broken access control (e.g., malicious use of user IDs).
- PCI-6.5.3 Broken authentication/session management (use of account credentials and session cookies).
- PCI-6.5.3 Broken authentication/session management (use of account credentials and session cookies).
- PCI-6.5.4 Cross-site scripting (XSS) attacks.
- PCI-6.5.4 Cross-site scripting (XSS) attacks.
- PCI-6.5.5 Buffer overflows.
- PCI-6.5.5 Buffer overflows.
- PCI-6.5.6 Injection flaws (e.g., SQL injection).
- PCI-6.5.6 Injection flaws (e.g., SQL injection).
- PCI-6.5.7 Improper error handling.
- PCI-6.5.7 Improper error handling.
- PCI-6.5.8 Insecure storage.
- PCI-6.5.8 Insecure storage.
- PCI-6.5.9 Denial of service.
- PCI-6.5.9 Denial of service.
- PCI-6.5.10 configuration management.
- PCI-6.5.10 configuration management.
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:
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:14, 23 June 2006 (EDT)