#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.