Guidelines for Software Acceptance Flashcards
Software acceptance is
the life cycle process of officially or formally accepting new or modified software components, which when integrated form the information system.
Acceptance criteria must be predefined with respect to the following categories:
Functionality, Performance, Quality, Safety, Privacy, and Security
Objectives of software acceptance include
Verification that the software meets specified functional and assurance requirements; Verification that the software is operationally complete and secure
as expected; Obtaining the approvals from the system owner; Transference of responsibility from the development team or company (vendor) to the system owner, support staff, and operations personnel if the software is deployed internally.
Software accepted for deployment or release
must
be secure by design, default and deployment; complement existing defense in depth protection; run with least privilege; be irreversible and tamper-proof; isolate and protect administrative functionality and security management interfaces; and have non-technical protection mechanisms in place.
SD3
secure by design, default and deployment
EULA
End User Licensing Agreements - You shall not modify, translate, reverse engineer, decompile or disassemble
the Software.
DMCA
Digital Millennium Copyright Act
Reverse engineering protection is increased by
code obfuscation and anti-tampering techniques, which must be verified in the software before being accepted for release.
Benefits of Accepting Software Formally
Final checkpoint to discover the existence of missed and unforeseen security vulnerabilities and to validate the presence of security controls that will address
known threats; ensure that the software publisher or acquirer are protected.
Some of the major items to consider before accepting software that is built in-house for deployment/release are
Completion Criteria; Change Management; Approval to Deploy / Release; Risk Acceptance and Exception Policy; Documentation.
Security related milestones include, but are not limited to the following:
Generation of the of the requirements traceability matrix; completion of the threat model during the design phase; review and sign-off on the security architecture at the end of the design phase; review of code for security vulnerabilities after the development
phases; completion of security testing at the end of the application testing phase; and completion of documentation before the deployment phase
commences.
As part of the software acceptance process, the following must be verified as part of change management:
change requests are evaluated for impact on the overall security of the software; the asset management database is updated with the new/updated software information; and the change is requested formally, and evaluated and approved by appropriate signatory authorities.
Risk must be accepted by whom
The business owner and not by officials in the IT department.
RAID
Risk, Actions, Issues and Decisions
Risk transference can be achieved by
Transferring the risk to someone else, e.g., an insurance company.