Application security is an essential part of application development and security activities within organizations that develop and maintain their own applications or produce applications for other organizations. Adversaries continue to discover and exploit vulnerabilities in applications at a pace that often exceeds the organization’s ability to remediate them or to implement compensating controls fast enough to protect themselves while they are taking corrective actions. With the emerging practices of continuous integration and continuous development/deployment (CI/CD) quickly becoming the norm for application development activities, the ability to apply reasonable and adequate security concepts, controls, and testing becomes more daunting.
The drive to what is termed “shift left,” or integrate quality assurance, functional and security testing, and practices into application development activities is quickly becoming an industry leading practice to enhance application security and a key component of successful application security programs. Shifting left for application security requires changes in philosophies, approaches and work practices for most organizations. It requires risk and security to be considered, integrated and tested at every step of the application development process and orchestrated into an application security program. Application security programs encompass all the tools, processes, functions and capabilities that support these efforts.
There are five key components of an application security program:
- Security by design—The most effective method to enhance the security of applications and application development activities is to consider security at the point of architecture and design, before any source code is written or compiled. Collaboration between application security professionals and developers at the onset of any new application development project is likely to result in more secure applications than the traditional approach of addressing security during or after the completion of application development. This collaboration should include a risk-based identification and specification of security control objectives and requirements that need to be integrated into the application to fit the organization’s risk appetite.
Once an application architecture and design are defined, security risk assessments should be performed that identify and categorize the inherent security risk of the planned application architecture and the application’s expected functional capabilities. These assessments should be inclusive of types of data, business processes, third-party systems and platforms, and/or information infrastructure with which the application will interact and/or to and from which it will store, process, and transmit data. By gaining insight into inherent security risk, appropriate security control objectives and associated security controls can be defined to manage risk appropriately within the applications. Controls can include, but are not limited to, the use of web application firewalls (WAFs) and application program interface (API) security gateways, encryption capabilities, authentication and secrets management, logging requirements, and other security controls.
The identification of security instrumentation requirements should also be included in the architecture and design stage of application development. The insights that security teams need to appropriately monitor the application and how the data should be interpreted must be identified and documented by the development staff. This information should be validated for comprehensiveness by security staff prior to being incorporated into application-coding activities.
It is important that the security-related insights and data feeds that are generated by the application are produced in such a manner that they can be ingested by and useful to application security monitoring tools used within the organization, such as security incident and event management (SIEM) capabilities or other security tools and analytics platforms. Generated alerts should also include categorization, explanations of intended meanings and the applicable level of concern. For example, if logging alerts are generated, they should follow a categorization taxonomy that can be interpreted by security controls as part of their assessments, analytics and reporting processes, and capabilities (e.g., Critical, High, Medium, Low, Informational).
- Secure code testing—Secure code testing should be conducted on an ongoing basis, not merely at the time of quality assurance or security testing. There are several primary types of security code testing that should be performed:
-
- Static application security testing (SAST) focuses on the identification of security flaws and weaknesses at the time of development and/or prior to compiling or running the code.
- Dynamic application security testing (DAST) examines applications for flaws and weaknesses in compiled applications that are operating.
Both techniques are useful in identifying security concerns in code that will need to be addressed. SAST testing has the advantage of being able to identify issues and concerns at the time of code development or soon after. When using SAST, approval gates should be implemented in the software development life cycle (SDLC). Ideally, code scanning should be implemented in an integrated development environment (IDE) where code can pass through gates prior to being part of the application build branch, ensuring that all identified security issues are addressed before the code is allowed to be merged into the larger code base that makes up the application. This minimizes the effort expended during corrective recoding activities and prevents deficiencies from becoming part of the larger code base that will be compiled into applications.
Penetration (pen) testing can also be integrated into the testing process. Pen testing can be accomplished using automated tools that operate autonomously as part of the testing pipeline (e.g., Burp Suite, portswigger.net) or through a combination of manual human-driven testing and automated testing prior to release of code to production environments. If a risk-based approach is followed, low-risk code can be scanned through automated testing alone, but high-risk applications should have human testing performed at least annually. This ensures that cause-and-effect pen testing is performed to compensate for weaknesses in automated testing. In this type of pen testing, pen testers can utilize and interpret data from multiple testing tools and try multiple attack methods and techniques based on how the application reacts to them. Cause-and-effect pen testing also comprehensively evaluates the effectiveness of security controls across multiple dimensions of attack techniques.
- Software bill of materials—Modern applications are often assembled from a combination of internally developed code and open-source code and libraries. Software composition analysis (SCA) creates a software bill of materials (SBOM) inventory of all open-source code libraries and capabilities that are used in an application’s particular code base. This is essential knowledge in light of the current state of application security. A notable incident during which this knowledge was extremely useful was in the case of the Apache Log4j open-source vulnerability that emerged in December 2021. This vulnerability was extremely concerning due to the ease of exploitation and the pervasive nature of the use of the Apache Log4j open-source library in many commercial and internally developed applications. It was important for organizations to have SBOMs available to understand their exposure and be able to make risk-based decisions about corrective action plans.
The SBOM should be paired with reputational analysis that provides insights about the viability and support history of open-source components and identifies any known security concerns or issues associated with the components identified in the SBOM. This insight allows organizations to make informed decisions about whether they should incorporate open-source libraries and capabilities into their applications. Security policies and standards should include criteria and guidance for developers concerning what open-source components and capabilities they are allowed to use based on the results of reputational analysis.
-
Security training and awareness—Application security training is key to the success of any application security program. All developers should be minimally trained on the Open Web Application Security Project Top 10 list (OWASP Top 10), a comprehensive list of the current most concerning and prolific security issues that are found in applications because of errors and/or oversights in the SDLC. Security issues identified in developed code should be cross-referenced with the OWASP Top 10 and individual and focused training should be provided to the developers who are identified as the source of the errors.
Developers should also be regularly provided threat and vulnerability intelligence related to common vulnerabilities in applications and current and emerging application attack techniques that are actively being used to attack such applications. This intelligence should include information about how attacks are being conducted, the level of effort required for the attacks and whether effective attack tools are available to low-skilled adversaries, which typically propagates the frequency of attacks. Insights into common vulnerabilities, how they are created in the coding process and how they can be avoided should also be provided.
-
WAFs and API security gateways and rule development—WAFs and API security gateways should be implemented as protective layers between external connections and applications that are considered material to business operations. WAF and API security gateways are designed to operate at the application layer of the Open System Interconnection (OSI) reference model. They provide protective layers against common security exploits and vulnerabilities and allow for the development of definitive rules that identify exactly what kind of commands, connections and data can interact with an application through a web interface or API.
A common mistake many organizations make is to delay the development of WAF and API application-specific rules until the applications they develop and/or implement are in production. When that is the case, typically a learning mode is enabled on the WAF and API gateways to allow them to dynamically develop rules for consideration as traffic passes through, though the gateways do not provide any actual protection during this time.
WAF and API rules should instead be considered at the point of architecture and design of an application. Once the application interfaces have been defined and the type, format, structure and attributes with which they will interact have been developed, WAF and API security gateway rules can be developed and evaluated for impact and effectiveness. Thus, the rules can be implemented immediately in blocking mode as part of the promotion of code to production environments. This provides immediate protection to the applications and is more efficient than defining, implementing and enabling rules after deployment.
A core component
Application security is a core component of any successful information risk and security program. Adversaries are regularly and consistently identifying and exploiting new application vulnerabilities. An effective application security program can significantly reduce the presence of these vulnerabilities, which, in turn, enhances the security of the developed applications. Application security can also reduce the time and effort exerted to perform any corrective actions taken to rectify security issues and vulnerabilities that are often both disruptive and challenging for organizations.
John P. Pironti, CISA, CRISC, CISM, CGEIT, CDPSE, CISSP, ISSAP, ISSMP
Is the president of IP Architects LLC.