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 such as validation and integrity checks; 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.
This control maps to 86 controls across 30 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
ISO 27002:2022 8.26 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 86 it maps to, and the evidence behind each claim, over MCP and REST.