AI2.7:

From HORSE - Holistic Operational Readiness Security Evaluation.
Revision as of 16:21, 3 May 2006 by Mdpeters (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.


2. Risk: Ongoing operations, problem resolution, an future application maintenance may not be adequately supported and users may not receive appropriate application change training.
a. SOX.1.4: Documentation should be adequate to support ongoing operations, problem resolution, and future application maintenance. Technical documentation should be updated to reflect program changes.


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.


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.


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.


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:
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.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.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.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.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.4 Cross-site scripting (XSS) attacks.

PCI-6.5.5 Buffer overflows.

PCI-6.5.6 Injection flaws (e.g., SQL injection).

PCI-6.5.7 Improper error handling.

PCI-6.5.8 Insecure storage.

PCI-6.5.9 Denial of service.

PCI-6.5.10 configuration management.


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.