A.8.26
Application security requirements
Technological controlsCheckpoints 6Evidence 6Cases 6
Control objective
This control identifies and approves application security requirements according to information sensitivity, exposure, access/authentication characteristics, and transaction needs, then carries them into design and verification. Early specification reduces design gaps and rework. Apply confidentiality, integrity, and duplicate/replay protections to public-network communication and electronic transactions according to risk; where proof of an action is needed, define additional signature and audit-trail requirements.
Key checkpoints
- Is there a procedure to identify, document, and approve security requirements for application development/acquisition according to the sensitivity of the information processed and the exposure environment (internal/public network)?
- Are requirements for authentication/authorization/session management/access control specifically reflected in the requirements specification?
- Are requirements for addressing application vulnerabilities (input validation, output encoding, safe error handling, protection against injection/tampering) defined?
- Are encryption, integrity, missing/duplicate/replayed/misrouted-message controls, and any required proof of actions specified according to the nature and risk of public-network communications/transactions?
- Are legal/contractual requirements (for personal data, payment data, and so on) and logging/audit-trail requirements reflected?
- Are the defined security requirements verified/tested during the design/implementation/testing stages and approved before release?
Implementation guidance
- Establish a security requirements catalog/checklist keyed to application type (web/mobile/API/electronic transaction, and so on), data classification, and exposure environment, and select requirements based on the risk assessment at project initiation.
- Specify requirements for authentication (including multi-factor), authorization and least privilege, session management, and access control, and define control requirements for interactions between users/systems of differing trust levels.
- Define requirements for addressing known vulnerabilities, such as input validation, output encoding/escaping, safe error handling, and protection against injection/XSS/CSRF/insecure deserialization, linked to the secure coding standard (A.8.28).
- Apply suitable transport protection to public-network communication and specify integrity, duplicate/replay prevention, and payment validation according to transaction needs. Where non-repudiation evidence is needed, design verifiable signatures, linkage between actors and transactions, protected audit records, and time evidence together. A timestamp alone does not establish who acted.
- Where personal data and payment data are processed, reflect applicable laws/standards (data protection law such as Korea's Personal Information Protection Act, PCI DSS, and so on) together with data retention/disposal and logging/audit-trail requirements.
- Maintain traceability (requirement IDs) for the defined security requirements so they can be verified in design/implementation/testing (A.8.29), and for acquired (purchased/SaaS) products, assess and approve whether the supplier's security features meet the requirements.
Evidence
- Application security requirements specification/checklist and approval records
- Risk assessment and data classification results underpinning the requirements
- Authentication/authorization/access control/session management design documents
- Specification and applied records for public-network/electronic-transaction requirements (transport encryption, transaction integrity, non-repudiation, and so on)
- Test/verification results for security requirements (design reviews, security test reports)
- Supplier security requirement conformance assessment and approval documents for acquired applications
Nonconformity examples
- Applications are developed/acquired using only functional requirements, without separately defining security requirements.
- Required transport protection, integrity, or proof-of-action requirements are missing because public-network transaction risks and obligations were not assessed.
- Vulnerability-handling requirements such as input validation/injection prevention are absent, so the same class of vulnerability recurs.
- Legal requirements for processing personal data/payment data are not reflected in the security requirements.
- The product is released without the defined security requirements being confirmed during the testing/verification stage.
- An acquired (purchased/SaaS) application is adopted without its security features being assessed for conformance to requirements.