Technology—Application Security Practices
Overview
Application security is now a must in application development. An application is the primary means for a company to interact with its customers and sell its products or services. Online access to services, shops and banks has become a standard requirement for most businesses. However, application vulnerabilities are widespread, as are malicious attacks on these vulnerabilities. Fortunately, application security technologies have evolved significantly over the past few decades to counteract the growing number of threats.
Many organizations are evolving their security programs such that security deployment and testing are done throughout the software development lifecycle. This approach is known as DevSecOps and is characterized by the incorporation of application security testing and protection tools into the continuous integration/continuous delivery (CI/CD) pipeline.
- Application security technology covers the following practices:
- Static Application Security Testing (SAST)
- Open Source Analysis (OSA)
- Software Composition Analysis (SCA)
- Dynamic Application Security Testing (DAST)
- API Security Testing (API ST)
- Interactive Application Security Testing (IAST)
- Behavioral Application Security Testing (BAST)
- Byte Code Analysis (BCA)
- Container and Kubernetes Security (CKS)
- Penetration Testing (Pen Test)
- Application Security Orchestration and Correlation (ASOC)
- Runtime Application Self-Protection (RASP)
- Web Application Firewall (WAF)
Most of these practices are related to Application Security Testing (AST). ASOC practice integrates AST tools across a Software Development Life Cycle (SDLC) and performs correlation analysis of the security issues found by AST tools. Two practices (RASP and WAF) provide an additional level of application protection.
Let’s consider all of these practices, shortly, one by one. For each of the practices, we will try to cover several topics, including practice description, provided results and the corresponding phase of SDLC.
Application Security Testing Practices
SAST: Static Application Security Testing
SAST checks the application source code to find vulnerabilities that can be exploited to attack the application.
SAST is a white-box (with source code access) testing method based on static analysis of application source code. SAST tools are aimed at detecting potential security vulnerabilities in code, for example, when validating input, working with pointers and links, etc. SAST tools provide very good code coverage. At the same time, the source code is analyzed outside the context of its execution, which is a significant drawback for the accuracy of the analysis. Because of this, SAST generates a large number of false positives. It should also be taken into account that some types of security vulnerabilities are, in principle, difficult to find in static analysis, for example, problems with authentication, incorrect cryptography, access control, etc.
SAST can be used to identify source code vulnerabilities early in SDLC – during merge requests or during the build process. This allows the next generation SAST tools to be part of an Integrated Development Environment (IDE), enabling developers to work efficiently in the tools that they already know (see detailssee details). Thus, the development team can conduct SAST testing of the application code and fix problems during the development phase. Vulnerabilities discovered by SAST during the development phase can be fixed before the code is pushed into the deployment pipeline.
SAST protects an application against a number of well-known security flaws in the source code, such as application security risks described in OWASP Top Ten.
OSA: Open Source Analysis
The active adoption of DevOps and container technologies has contributed to the intensive use of Open Source Software (OSS) during application development. Over 90% of respondents to a July 2019 Gartner survey indicate they use open source software (see detailssee details).
Vulnerabilities in open source software can be discovered in several ways. The safest method is when the creator of the software finds and fixes the security defects. Another way is for ethical hackers to find vulnerabilities, who can report them to the organization before these defects become public. Each detected security flaw is logged in the Common Vulnerability and Exposure (CVE) database. Each CVE entry has an identification number and issue description for known security flaws. Checking applications against the CVE database and mitigating the risks caused by the use of vulnerable components is an important part of application security.
OSA protects the software engineering perimeter at the company level from vulnerable components at the early stage. OSA is applied to check the security of all new open source software code libraries and components before adding them to the company's repository. OSA shall be applied to any new source code libraries and components which are checked for security before being included in the company's internal repository. All open source software code libraries and components stored in the company repository are considered as secure after the OSA check and can be used by all development teams in the company. OSA uses public issue trackers for open source components to define a list of vulnerabilities. OSA supports analysis of the maximum number of libraries, package managers, and Docker images.
Practical measures exist that help organize the work with open source components. Creation of the so-called “quarantine” zone for the new software components enables a detailed examination of susceptible components as well as corresponding decisions and follow-up measures from the security team.
SCA: Software Composition Analysis
SCA is based on application source code analysis. SCA is applied to check security of all open source code libraries and components included in the application development project. The use of OSA does not guarantee the absence of vulnerable open source code. Developers can take a library not from the secure repository of the company. SCA of open source libraries and components used by an application is performed in terms of known security vulnerabilities and license issues. SCA determines a list of open source code libraries and components used by an application based on an application build file and performs analysis of open source components that fit into the software engineering cycle. With a list of components, SCA uses publicly available open source issue trackers to determine the list of application vulnerabilities. SCA tools check all open source components and libraries for correct license usage. This aspect is very important when creating an application from an intellectual property perspective.
SCA can be applied starting from the early phases of SDLC and until the deployment and maintenance stages. Built using SCA tools, the DevSecOps process monitors the production environment for known vulnerabilities in open source CVE-based software. It is important to note that when new security defects are added to the CVE database, any open source component can turn from safe to unsafe. This is why it is so important to regularly scan applications deployed in production with SCA tools.
Businesses sometimes need to make exception for vulnerable legacy open source libraries that have been used for decades. Custom security policies allow you to be flexible and use such legacy libraries.
DAST: Dynamic Application Security Testing
DAST is performed using a black box (without source code access) testing technique. With this approach, the tester does not know the structure of the application being tested and does not have access to the source code.
DAST is performed over the user interface. It tests an application from the user’s point of view. You can use DAST tools to create situations in which a vulnerability is detected in a running application. DAST tools allow detecting different types of problems – with authentication, data injection, requests and responses, and so on. DAST uses fuzzing as one of its testing methods. It sends invalid and unexpected test data and inappropriate commands to the application to force the application to perform unsecure actions.
DAST requires test automation. Correspondingly, the test engineers implementing DAST shall be experienced and have good test automation skills.
Since DAST requires a running application, it finds vulnerabilities in the later stages of the SDLC (starting from the testing phase). DAST can also be used to test applications deployed in a pre-production environment.
DAST conducts attacks on an application that can be performed by a hacker. Thus, a DAST test that ends up finding a potential security issue in the application is highly likely to indicate a vulnerability. This is why DAST produces a small number of false positives.
API ST: Application Programming Interface Security Testing
Some analysts consider API ST as a part of DAST because these two types of testing use the same testing technique. The quality of testing using DAST is determined by the amount and parameters of communication between the web client and other services, which results in the exchange of messages between application frontend and backend. The same statement is true for API ST.
However, there is a difference between these two types of testing. API ST tests application backend, while DAST tests application frontend. The application backend for single page web applications and for mobile applications is an API and API ST is used to test it. API ST essentially involves sending not relevant data and using of inappropriate commands to increase testing effectiveness.
DAST tools increasingly need to accept API schema definitions as input to guide API ST (see detailssee details). For example, IBM added capabilities to leverage Swagger to automate DAST scanning of REST APIs (see detailssee details).
Similar to DAST, API ST requires a running application. The number of false positives with API ST is not as large as with SAST.
IAST: Interactive Application Security Testing
IAST checks the application flow and data flow related to the running application (what the application writes, what files it accesses, what system functions it calls, what it writes to the log, etc.). The IAST tool determines the security of working with data in the application.
IAST tools perform interception and analysis of application sensitive information including writing to files, communication with internal and external components, network traffic, communication with SQL databases, etc. IAST uses both dynamic and static analysis approaches. Based on the collected data, IAST composes advanced attack scenarios. IAST can check for a specific application if publicly known vulnerabilities in the application code can be exploited for attacks.
IAST does not generate as many false positives as SAST does. This is because IAST scans a running application and does not attempt to test individual components of the application outside of the execution context.
IAST is currently a very widespread practice, but typically requires a set of manual activities and is one of the most difficult to incorporate into a fully automated DevSecOps pipeline.
IAST as well as DAST requires a running application. That is why it finds security issues towards the last phases of SDLC.
BAST: Behavioral Application Security Testing
BAST is a novel AST practice of delivering additional business value from security activities through automated testing of business-critical security functionality.
BAST works in pretty much the same way as automated functional testing, but it focuses exclusively on features of the application that may have an impact on security (or specific compliance aspects of security), such as working with sensitive information or use of encryption and passwords. BAST provides a way to describe security tests in a convenient human-readable way.
In terms of SDLC, BAST is similar to DAST and IAST. It requires a running application, so security issues are discovered in the last phases of SDLC.
BCA: Byte Code Analysis
Byte Code Analysis is applied for application binary code derived from application artifacts such as DLL, JAR, APK or IPA files. BCA performs a static analysis of the decompiled source code. BCA checks configuration of the application, searches for sensitive information in the decompiled source code, and checks the application resources for all sorts of unsecure things. So, BCA practice is not a classic SAST, but close to it.
The source code derived from the application artifact can differ significantly from the original application source code if it has been obfuscated. Intentional obfuscation of the application source code can complicate BCA.
BCA cannot map the problems it finds to the actual application source code. This is a disadvantage of this practice. As for SDLC, this practice applies on its late phases when compiled application source code is available.
CKS: Container and Kubernetes Security
Container and Kubernetes Security term comes from Gartner (see detailssee details). This is a practice that aims to provide application security at the level of containers created and orchestrated by special tools like Docker and Kubernetes. This practice includes two parts: container and Kubernetes protection and container and Kubernetes security scanning. AST includes a part related to container security scanning.
Containers built from code that include security flaws pose a security risk to applications. CKS verifies a number of container security parameters, such as host security, daemon security, image security, container runtime security, system dependencies, etc.
When working with a container, you have to follow security principles, such as the principle of least privilege whereby access should be granted only to the required resources. If a vulnerable container application is launched as root, this expands the attack surface. Therefore, containers are not configured to run as root by default.
A non-secure container should be removed from all places, and a repaired container should be prepared and deployed instead.
Security issues are discovered by CKS in the last phases of SDLC.
Pen Test: Penetration Testing
Penetration testing is an important part of AST. It is performed using a black box (no application source code access) approach. Penetration testing is performed in manual mode. It simulates attack activities, such as targeted phishing or exfiltration of sensitive data or credentials, much like an actual attacker would use (see detailssee details). It attempts to uncover potential vulnerabilities that can be exploited to attack the application. This kind of testing is also known as “ethical hacking”.
Penetration testing includes two phases: testing of the application according to the penetration testing plan at the beginning, and in-depth investigation of the identified suspicious places as the second phase.
In terms of automation, this practice stands apart from other AST practices. Manual penetration testing cannot be incorporated into fully automated DevSecOps pipelines.
Many companies prefer to outsource penetration testing as an independent external service to assess their application security.
Orchestration and Correlation Practices
ASOC: Application Security Orchestration and Correlation
The DevSecOps practice of ASOC ensures end-to-end integration of the security toolchain with software engineering tools, provides automated control of security pipelines, and enables consolidation and analysis of all data within continuous secure software engineering process.
Orchestration can significantly save resources and reduce time and efforts required to implement the DevSecOps initiative for complex heterogeneous engineering environments, often by 10x or more. Implementation of orchestration protects engineering teams as well as information security teams from the technological chaos of “knee-high” tools integration and unmanaged “patchwork” automation.
The idea of correlation is to perform correlation analysis of the security issues found by the AST tools; in other words, to learn how security issues may be related Dealing with many false positives is a big issue in application security testing. Correlation products were first included on Gartner's application security Hype Cycle in 2016 (see detailssee details). Correlation tools can help to reduce the number of security defects to be considered and fixed by providing automatic correlation analysis of security issues found by different AST tools, and reduce the effort for its analysis by security engineers.
Gartner introduced ASOC practice few years back (see detailssee details). This reflects the realization of an integration of Orchestration and Correlation based on client requirements and a reflection of vendor product capabilities. In the latest Gartner Hype-cycle for Application Security, ASOC tools have reached the Peak of Inflated Expectations (see detailssee details).
Application Protection Practices
WAF and RASP are two application security practices that provide additional level of application protection. They are not testing tools, but security tools that help protect applications at runtime in production. Not all vulnerabilities can be identified and fixed during the development and testing phases, therefore such tools are essential.
WAF: Web Application Firewall
OWASP defines WAF as an application firewall for HTTP applications. WAFs apply static rules that detect common attacks to an HTTP conversation and filter or block traffic between the application and Internet based on these rules.
WAF allows you to control and protect applications running in a production environment. Various WAF tools are implemented as SaaS systems, private clouds, server plugins, VM filters, or appliances.
RASP: Runtime Application Self-Protection
RASP tools are implemented as agents. They monitor and block malicious actions for a running application by analyzing the application behavior. RASP tools adapt to the operation of applications or services without the need to tune them.
While WAF creates a perimeter for applications defense, RASP protects them from the inside. A RASP tool is built into the application runtime environment or connected to the application. An attack can be prevented here by the RASP tool by terminating an application or an open session.
As well as WAF, RASP allows you to control and protect applications running in a production environment.
Summary
Each team developing an application decides how to ensure the security of this application. The general recommendation is to use a combination of several practices from different application security areas:
- Application Security Testing
- Orchestration and Correlation
- Application Protection
This should allow you to control the security of the application at all stages of the SDLC and to assess and fix vulnerabilities as quickly as possible. In addition, this approach should allow you to organize effective work to ensure the application security in terms of efforts and resources. The key to success is integrating all selected application security practices and tools into your existing DevOps process and shifting to DevSecOps.