PO8.3:: Difference between revisions
No edit summary |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 19: | Line 19: | ||
'''Risk Association Control Activities:'''<br> | '''Risk Association Control Activities:'''<br> | ||
<br> | <br> | ||
[[Image:Key- | [[Image:Key-control.jpg]]<br> | ||
::'''1. Risk: Information security and business requirements may be compromised. Inaccurate results are produced.'''<br> | ::'''1. Risk: Information security and business requirements may be compromised. Inaccurate results are produced.'''<br> | ||
:::a. [[SOX | :::a. [[SOX.1.1:|'''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.<br> | ||
<br> | <br> | ||
::'''2. Risk: Development and maintenance of system with potential impact to financial reporting bypass processes for identifying business requirements, risks, and for designing needed controls.'''<br> | ::'''2. Risk: Development and maintenance of system with potential impact to financial reporting bypass processes for identifying business requirements, risks, and for designing needed controls.'''<br> | ||
:::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.<br> | :::a. [[SOX.1.14:|'''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.<br> | ||
<br> | |||
[[Image:Key-control.jpg]]<br> | |||
::'''3. 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.'''<br> | |||
:::a. [[SOX.5.4:|'''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.<br> | |||
<br> | <br> | ||
'''Implementation Guide:'''<br> | '''Implementation Guide:'''<br> | ||
| Line 84: | Line 88: | ||
'''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]] 09:12, 23 June 2006 (EDT) | |||
Latest revision as of 13:12, 23 June 2006
PO 8.3 Development and Acquisition Standards
Control Objective:
Adopt and maintain standards for all development and acquisition that follow the life cycle of the ultimate deliverable and include sign-off at key milestones based on agreed sign-off criteria. Issues to consider include software coding standards; naming conventions; file formats; schema and data dictionary design standards; user interface standards; interoperability; system performance efficiency; scalability; standards for development and testing; validation against requirements; test plans; and unit, regression and integration testing.
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: 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.
- 2. Risk: Development and maintenance of system with potential impact to financial reporting bypass processes for identifying business requirements, risks, and for designing needed controls.
- 3. 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.
- 3. 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.
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.
Image:Processimage.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 10.1.4 Development, test, and operational facilities should be separated to reduce the risks of unauthorized access or changes to the operational system.
- Implementation guidance:.
- The level of separation between operational, test, and development environments that is necessary to prevent operational problems should be identified and appropriate controls implemented.
- Implementation guidance:.
- The following items should be considered:
- a. Rules for the transfer of software from development to operational status should be defined and documented.
- a. Rules for the transfer of software from development to operational status should be defined and documented.
- b. Development and operational software should run on different systems or computer processors and in different domains or directories.
- b. Development and operational software should run on different systems or computer processors and in different domains or directories.
- c. Compilers, editors, and other development tools or system utilities should not be accessible from operational systems when not required.
- c. Compilers, editors, and other development tools or system utilities should not be accessible from operational systems when not required.
- d. The test system environment should emulate the operational system environment as closely as possible.
- d. The test system environment should emulate the operational system environment as closely as possible.
- e. Users should use different user profiles for operational and test systems, and menus should display appropriate identification messages to reduce the risk of error.
- e. Users should use different user profiles for operational and test systems, and menus should display appropriate identification messages to reduce the risk of error.
- f. Sensitive data should not be copied into the test system environment (see 12.4.2).
- f. Sensitive data should not be copied into the test system environment (see 12.4.2).
- Other information:
- Development and test activities can cause serious problems, e.g. unwanted modification of files or system environment, or system failure. In this case, there is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access. Where development and test personnel have access to the operational system and its information, they may be able to introduce unauthorized and untested code or alter operational data. On some systems this capability could be misused to commit fraud, or introduce untested or malicious code, which can cause serious operational problems.
- Development and test activities can cause serious problems, e.g. unwanted modification of files or system environment, or system failure. In this case, there is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access. Where development and test personnel have access to the operational system and its information, they may be able to introduce unauthorized and untested code or alter operational data. On some systems this capability could be misused to commit fraud, or introduce untested or malicious code, which can cause serious operational problems.
- Developers and testers also pose a threat to the confidentiality of operational information.
- Developers and testers also pose a threat to the confidentiality of operational information.
- Development and testing activities may cause unintended changes to software or information if they share the same computing environment. Separating development, test, and operational facilities is therefore desirable to reduce the risk of accidental change or unauthorized access to operational software and business data (see also 12.4.2 for the protection of test data).
- Development and testing activities may cause unintended changes to software or information if they share the same computing environment. Separating development, test, and operational facilities is therefore desirable to reduce the risk of accidental change or unauthorized access to operational software and business data (see also 12.4.2 for the protection of test data).
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 09:12, 23 June 2006 (EDT)