Application security requirements

What the requirement asks

Information security requirements are to be identified, specified and approved whenever applications are developed or acquired. Purpose: leave no security requirement unidentified or unaddressed when an application is built or bought. Guidance: identify and specify application security requirements, normally through risk assessment and with help from security specialists; their scope depends on the application's purpose. As applicable they include: the trust needed in entities' identities, for example through authentication (5.17, 8.2, 8.5); the kinds and classification of information the application will process; how far access to data and functions must be separated and at what level; resilience against attacks or accidental disruption, such as buffer overflow or SQL injection; legal and regulatory requirements where transactions originate, are processed, completed or stored; privacy needs of all parties; protection of confidential information; protection of data in processing, in transit and at rest; secure encryption of communications between parties; input controls including integrity checks and validation; automated controls such as approval limits or dual approval; output controls including who may access outputs; limits on free-text fields, which can accumulate uncontrolled confidential or personal data; process-driven requirements such as transaction logging, monitoring and non-repudiation; requirements set by other controls such as interfaces to logging, monitoring or leakage detection; and error message handling. For transactional services with partners, also consider the trust each party needs in the other's identity; trust in the integrity of exchanged information and ways of detecting integrity loss (checksums, hashing, signatures); who may approve, issue or sign key transactional documents; keeping key documents confidential and intact, proving they were sent and received, and preventing repudiation such as tendering contracts; confidentiality and integrity of transactions such as orders, delivery details and receipt confirmations; how long transactions stay confidential; and insurance and other contractual needs. For electronic ordering and payment, consider confidentiality and integrity of orders; the right degree of verification of customer payment information; avoiding loss or duplication of transactions; keeping transaction details off publicly accessible storage and on internal platforms instead; and, where a trusted authority issues signatures or certificates, building security into the whole end-to-end certificate or signature process. Cryptography (8.24) can meet several of these, with regard to legal requirements (5.31 to 5.36). Other information: networked applications face fraud, contract disputes, public disclosure, incomplete transmission, misrouting, unauthorized alteration, duplication or replay, so detailed risk assessment and careful control selection, often including cryptographic authentication and secure transfer, are essential; the ISO/IEC 27034 series covers application security. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Application security requirements belong in the backlog. The guidance asks for the requirement, the test, the defect and the release decision.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep approved application security requirements documents for new or acquired applications, derived from risk assessment with security specialist input and one live sample together.

Evidence an assessor asks for

• Application security requirementsApproved application security requirements documents for new or acquired applications, derived from risk assessment with security specialist input
• Application security requirementsRequirement checklists covering authentication, classification, access segregation, attack resilience, legal and privacy needs, data protection, encryption, input and output controls, logging and error handling
• Application security requirementsAdditional requirements for partner transactional services covering identity trust, integrity mechanisms, approval authority and non-repudiation
• Application security requirementsPayment and ordering application requirements covering verification, duplication prevention and storage away from public exposure
• Application security requirementsTraceability showing requirements were tested or verified before go-live
• Application security requirementsProcurement evaluations of acquired applications against the specified requirements

The question an assessor will ask

An assessor will ask for approved application security requirements documents for new or acquired applications, derived from risk assessment with security specialist input, then trace it to the system it protects. For A.8.26 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Applications are bought on functionality alone with security requirements never specified
• Requirements are generic and not derived from any risk assessment
• Free-text fields collect personal data that nobody planned to protect
• Verbose error messages disclose internal details to users

Before the next audit

Before the next audit, check one live sample for this gap: applications are bought on functionality alone with security requirements never specified.