In cybersecurity, having a proper security control set is mandatory due to complex external obligations and the high dependence on information and communication technology (ICT) services provided by ICT infrastructure to one or more internal or external users. In essence, an ICT infrastructure is a complex ecosystem comprising software, hardware, firmware, and network elements. Regardless of whether we consider them individually or as working together collectively, these elements must fulfil the organisational cybersecurity requirements, applying the proper preventive, detective, corrective, deterrent, and compensating security controls.

As per TechTarget [1], an application, also referred to as an application program or application software, is a computer software package that performs a specific function directly for an end user or, in some cases, for another application. An application can be self-contained or a group of programs, each program representing a set of operations that runs the application for the user. As an essential part of the ICT infrastructure, applications, including out-of-the-box and custom-developed ones, must fit into the given organisation’s cybersecurity operational environment, realising the technical safeguards (or countermeasures) that protect the confidentiality, integrity, and availability of the system and its processed data.

According to the balanced operational constraints, security controls that hinder or even prevent achieving business goals are not acceptable [2]. On the other hand, the administrative, physical, and logical security controls must be well-designed and maintained according to the principles of defence in depth and diversity of defence, and the concept of principles of Least Privilege and Separation of Duties. The appropriate combination of deterrent, preventive, corrective, recovery, detective, and compensating controls should be used to manage the risks while complying with internal standards.

To fulfil this objective, the previously mentioned security frameworks help organisations to set up, operate, and maintain the proper set of security controls to which applications must conform.

If we delve into NIST Special Publication (SP) 800-53 Revision 5 [3], an application’s security is directly involved in the following control groups:

• AC - The Access Control family contains controls that cover access to systems, networks, and devices, providing guidance on the implementation of access policies, account management, and user privileges.
• AU - The Audit and Accountability family of controls provides guidance on procedures for managing event logging and auditing, covering the baseline content of audit logs, storage capacity, and the process for monitoring and reviewing logs.
• CM - The Configuration Management family provides guidance for the configuration of software, operating systems, and devices, the creation of a configuration policy and baseline configuration of the systems, and the management of unauthorised configuration or devices.
• IA - The Identification and Authentication family contains controls for the identification and authentication of users and devices, including user management policies.
• MA - The Maintenance family of controls is about all elements of system maintenance, including software updates.
• PT - The Personally Identifiable Information (PII) Processing and Transparency family of controls provide guidance to safeguard personal (sensitive) data, focusing on consent and privacy. By default, organisations should ensure that personal data is processed with the highest privacy protection.
• SC - The System and Communications Protection family of controls guide the creation and ongoing management of systems, including network access, boundaries, partitions, etc.
• SI - The System and Information Integrity family of controls focuses on maintaining the integrity of the information system, including protection from malicious code.

The OWASP Application Security Verification Standard (ASVS) [4] is a framework of security requirements and controls, containing security requirements of web application technical security controls for testers, developers, security staff, and consumers. It differentiates three levels: (1) ASVS Level 1 Basic, (2) ASVS Level 2 Standard, and (3) ASVS Level 3 Advanced.

ASVS Level 1 Basic is for applications that don’t deal with sensitive information and are less susceptible to attacks, and it must be designed to safeguard against known vulnerabilities. This level is suited for small and medium-sized organisations facing no major security risks. ASVS Level 2 Standard is generally recommended for safeguarding most applications, e.g., against injection flaws, validation and authentication errors, and illegitimate access, requiring reviewing source code, documentation, and configuration. ASVS Level 3 Advanced Applications deal with applications working with highly sensitive information, in industries such as healthcare, defence, and finance, requiring a complex security layer embedded into the application.

The OWASP ASVS contains 14 sets of security requirements:

• V1: Architecture, Design and Threat Modeling Requirements cover the primary aspects of security architecture, such as availability, confidentiality, processing integrity, non-repudiation, and privacy, principles which must be built into each application. It provides a checklist for securely designing any application.
• V2: Authentication and Verification Requirements cover several aspects of authentication, such as single- and multi-factor authentication, password requirements, FIDO, credential storage, etc.
• V3: Session Management Verification Requirements contain important session management features in order to ensure that sessions are handled securely, are unique for each individual, and are suspended if there has been no action/input for a considerable amount of time.
• V4: Access Control Verification Requirements provide user authorisation, specific privileges and roles, and secure storage of the relevant information preventing theft and tampering.
• V5: Validation, Sanitation and Encoding Verification Requirements focus on requirements such as establishing a secure pipeline for input validation and output encoding to prevent injection attacks.
• V6: Stored Cryptography Verification Requirements provide a set of requirements for secure error handling mechanisms, the application of fail-safe cryptographic modules, choosing and using a suitable random number generator, and secure management of cryptographic keys.
• V7: Error Handling and Logging Verification Requirements deal with logging containing the appropriate contents, log storage and protection, etc.) and error handling. Applications should avoid collecting sensitive user information unless it is essential.
• V8: Data Protection Verification Requirements are for providing confidentiality, availability, and integrity for processed data, including personal data, generally and on the client side.
• V9: Communication Verification Requirements ensure proper use of encryption and transport layer security for network communication through the application of advanced algorithms, rather than continuing to rely on weak and outdated computational procedures.
• V10: Malicious Code Verification Requirements ensure the integrity of the application and the prevention of any negative effects that might arise from malicious codes.
• V11: Business Logic Verification Requirements are for ensuring business logic and mechanisms are followed, to prevent malevolent actors from evading security flaws by tampering, for example.
• V12: File and Resources Verification Requirements contain guides for implementing secure and compliant mechanisms for purposes such as managing files’ integrity, handling uploads, downloads, and file execution.
• V13: API and Web Service Verification Requirements ensure proper authentication, authorisation, session management, and input validation for web services.
• V14: Configuration and Verification Requirements contain requirements for a secure, repeatable, and automatable build; furthermore, they prescribe hardening of third-party libraries and implement a configuration and dependency management system to remove components that pose a risk to application security.

 The mentioned security controls of both frameworks are helpful, and it is needless to say that there are more frameworks helping elevate the security level of applications. However, one should comply with internal and customer requirements and requests, which may need more special controls to comply with. Furthermore, there should be requirements for the process of application development, with which the next blog post will deal.

References

[1]   A. S. Gillis, “Application,” TechTarget. https://www.techtarget.com/searchsoftwarequality/definition/application (accessed Aug. 27, 2022).

[2]   E. Wheeler, Security Risk Management. Syngress, 2011.

[3]   “Security and Privacy Controls for Information Systems and Organizations,” Gaithersburg, MD, Sep. 2020. doi: 10.6028/NIST.SP.800-53r5.

[4]   OWASP, “Application Security Verification Standard 4.0.3,” 2021. https://raw.githubusercontent.com/OWASP/ASVS/v4.0.3/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0.3-en.pdf (accessed Aug. 27, 2022).