#iso27002/2022/EN ## 8.26 Application security requirements | Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains | | ------------ | ----------------------------------------- | ---------------------- | -------------------------------------------------- | -------------------- | | #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection #Defence | #### Control Information security requirements should be identified, specified and approved when developing or acquiring applications. #### Purpose To ensure all information security requirements are identified and addressed when developing or acquiring applications. #### Guidance General Application security requirements should be identified and specified. These requirements are usually determined through a risk assessment. The requirements should be developed with the support of information security specialists. Application security requirements can cover a wide range of topics, depending on the purpose of the application. Application security requirements should include, as applicable: a\) level of trust in identity of entities \[e.g. through authentication (see [5.17](a-5.17-Authentication-information.md), [8.2](a-8.2-Privileged-access-rights.md) and [8.5](a-8.5-Secure-authentication.md))]; b\) identifying the type of information and classification level to be processed by the application; c\) need for segregation of access and level of access to data and functions in the application; d\) resilience against malicious attacks or unintentional disruptions \[e.g. protection against buffer overflow or structured query language (SQL) injections\]; e\) legal, statutory and regulatory requirements in the jurisdiction where the transaction is generated, processed, completed or stored; f\) need for privacy associated with all parties involved; g\) the protection requirements of any confidential information; h\) protection of data while being processed, in transit and at rest; i\) need to securely encrypt communications between all involved parties; j\) input controls, including integrity checks and input validation; k\) automated controls (e.g. approval limits or dual approvals); l\) output controls, also considering who can access outputs and its authorization; m\) restrictions around content of "free-text" fields, as these can lead to uncontrolled storage of confidential data (e.g. personal data); n\) requirements derived from the business process, such as transaction logging and monitoring, nonrepudiation requirements; o\) requirements mandated by other security controls (e.g. interfaces to logging and monitoring or data leakage detection systems); p) error message handling. Transactional services Additionally, for applications offering transactional services between the organization and a partner, the following should be considered when identifying information security requirements: a\) the level of trust each party requires in each other’s claimed identity; b\) the level of trust required in the integrity of information exchanged or processed and the mechanisms for identification of lack of integrity (e.g. cyclic redundancy check, hashing, digital signatures); c\) authorization processes associated with who can approve contents of, issue or sign key transactional documents; d\) confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation (e.g. contracts associated with tendering and contract processes); e\) the confidentiality and integrity of any transactions (e.g. orders, delivery address details and confirmation of receipts); f\) requirements on how long to maintain a transaction confidential; g\) insurance and other contractual requirements. Electronic ordering and payment applications Additionally, for applications involving electronic ordering and payment, the following should be considered: a\) requirements for maintaining the confidentiality and integrity of order information; b\) the degree of verification appropriate to verify payment information supplied by a customer; c\) avoidance of loss or duplication of transaction information; d\) storing transaction details outside of any publicly accessible environment (e.g. on a storage platform existing on the organizational intranet, and not retained and exposed on electronic storage media directly accessible from the internet); e\) where a trusted authority is used (e.g. for the purposes of issuing and maintaining digital signatures or digital certificates) security is integrated and embedded throughout the entire end-to-end certificate or signature management process. Several of the above considerations can be addressed by the application of cryptography (see [[8.24]]), taking into consideration legal requirements (see [[5.31]], [[5.36]], especially see [[5.31]] for cryptography legislation). **Other information** Applications accessible via networks are subject to a range of network related threats, such as fraudulent activities, contract disputes or disclosure of information to the public; incomplete transmission, mis- routing, unauthorized message alteration, duplication or replay. Therefore, detailed risk assessments and careful determination of controls are indispensable. Controls required often include cryptographic methods for authentication and securing data transfer.