Application Security Testing

The pace of digital transformation shows no signs of slowing down, quite the opposite. Driven by both the need for smooth hybrid IT-Eco systems and high innovation requirements, digital transformation remains a top initiative for companies.

Book A Demo

Security by Design

Security by design means that organizations are thinking about cybersecurity from the beginning of a development life cycle. Security by design states software engineers have designed the software to be secure from the start to reduce the likelihood of flaws that might compromise an organization’s information security.

Why is Security by Design important?

Security by design summarizes the responsibilities for the security controls, cyber security configuration, the automation of security baselines, and the end-user audit of security controls for infrastructure, operating systems, services, and applications according to good practices and cyber security framework guidelines (such as NIST framework).

Secure by design is important for developing software because it becomes more difficult to add security concepts (such as vulnerability elimination steps) as an application develops. In addition, dealing with existing cybersecurity vulnerabilities and patching them in real-time can be difficult or almost impossible. And it will never be as effective as designing systems to be as secure as possible from the beginning. The security-by-design approach is also important in the rapidly evolving world of the Internet of Things (IoT). One of the main challenges for IoT security is that typically organizations haven’t considered security when it comes to designing and manufacturing connected appliances and objects.

Application Security Testing Tools

Application Security Testing (AST) tools are offered either as on-premises software or, more often, as software as a service (SaaS)-based subscription offerings. Many vendors offer both options. Core capabilities offer foundational testing functionality, with most organizations using one or more types, which include:

SAST

Static AST (SAST) analyzes an application’s source, bytecode, or binary code for security vulnerabilities, typically during the programming and/or testing phases of the software development life cycle (SDLC).

DAST

Dynamic AST (DAST) analyzes applications in their running (i.e., dynamic) state during testing or operational phases. DAST simulates attacks against an application (typically web-enabled applications, but, increasingly, application programming interfaces known as APIs as well), analyzes the application’s reactions and, thus, determines whether it is vulnerable and where.

IAST

Interactive AST (IAST) instruments a running application (e.g., via the Java Virtual Machine[JVM] or the .NET Common Language Runtime [CLR]), and examines its operation to identify vulnerabilities. Most implementations are considered passive, in that they rely on other application testing to create activity.

SCA

SCA is used to identify open-source and, less frequently, commercial components in use in an application. From this, known security vulnerabilities, potential licensing concerns and operational risks can be identified.

RASP

Runtime Application Self Protection (RASP) is a security solution designed to provide personalized protection to applications. It takes advantage of insight into an application's internal data and state to enable it to identify threats at runtime that may have otherwise been overlooked by other security solutions.

Optional capabilities provide more specialized forms of tests, and typically supplement core capabilities based on an organization’s application portfolio or application security program maturity.

They include:

API Testing

APIs have become a crucial part of modern applications, but traditional AST toolsets may not be able to test them, leading to the requirement for specialized tools and protection capabilities. The ability to discover APIs in both development and production environments and test API source code, as well as the ability to ingest recorded traffic or API definitions to support the testing of a running API, are typical disciplines required for this group.

Application security orchestration and correlation (ASOC)

ASOC tools ease software vulnerability testing and remediation by automating workflows and processing findings. They automate security testing within and across development life cycles and CI/CD pipelines, while ingesting data from multiple sources. ASOC tools correlate and analyze findings to centralize efforts for easier interpretation, triage, and remediation. They act as a management and orchestration layer between application development and security testing.

Business-critical AST

In the context of large-scale business applications (e.g., SAP, Oracle, Salesforce etc.), identifying vulnerabilities within application code (such as ABAP or other vendor-specific customization languages), as well as misconfigurations, known vulnerabilities and errors resulting in security exposures. Especially if the organization is integrating components from third parties detecting unwanted risk exposure or vulnaebilites are very important.

Container security

Container security scanning examines container images, or a fully instantiated container before deployment, for security issues. Container security tools focus different tasks, including configuration hardening and vulnerability assessment tasks. Tools also scan for the presence of secrets, such as hard-coded credentials or authentication keys. Container security scanning tools may operate as part of the application deployment process, or be integrated with container repositories, so security assessments can be performed as images are stored for future use.

Developer enablement

Developer enablement tools and features support developers and members of the engineering team in their efforts to create secure code. These tools focus primarily on security training and vulnerability remediation guidance — in stand-alone form or integrated into the development environment.

Fuzzing

Fuzz testing relies on providing random, malformed, or unexpected input to a program to identify potential security vulnerabilities — e.g., application crashes or abnormal behavior, memory leaks or buffer overflows, or other results leaving the program in an indeterminate state. Fuzzing, sometimes called nondeterministic testing, can be used with most types of programs, although it is particularly useful with systems that rely on a significant amount of input processing (e.g., web applications and services, APIs).

Infrastructure as code (IaC) testing

IaC nowadays is understood as the creation, provisioning, and configuration of software-defined compute (SDC), network and storage infrastructure as source code. IaC security testing tools help ensure conformance with common configuration hardening standards, identify security issues associated with specific operational environments, locate embedded secrets, and perform other tests supporting organization-specific standards and compliance requirements.

Mobile AST (MAST):

This addresses the specialized requirements associated with testing mobile applications, such as those that run on devices using iOS, Android, or other OSs. These tools generally use traditional testing approaches (e.g., SAST and DAST) that have been optimized to support languages and frameworks commonly used to develop mobile and/or Internet of things (IoT) applications. They also test for vulnerabilities and security issues unique to those environments.

Why do we need to consider an AST Tooling?

Main drivers are to support organizations DevSecOps and cloud-native application initiatives such as cloud-first strategies.

For those organizations is important to integration principles and tools that provide high-assurance, high-value findings with less noise which are not unnecessarily slowing down the development effort and therefore the time to market.

The main expectation is that the solutions are integrated early in the development process, with testing driven by developers rather than cyber security specialists. This also includes to invest in the developer’s knowledge and maturity in security by design principles on the day to day business while bringing the remediation information tailored to the developers needs while detecting vulnerabilities.

Where feasible and possible the solutions considered need involving support of rapid and accurate testing for various application types, capable of integration in an increasingly automated fashion throughout software delivery workflows.

Our assessement workshop

We plan and conduct workshops to develop the basics for technical measures. Our workshops usually last 2 to 3 days on-site at the customer and include the following structure:

Introduction to the topic
Create a common understanding
Development of the main topics (e.g. data identification)
Documentation of the results

Send us your request and we will be happy to contact you for further information.

OWASP - Open Web Application Security Project

The Open Web Application Security Project (OWASP) is a nonprofit foundation that provides guidance on how to develop, purchase and maintain trustworthy and secure software applications. OWASP is noted for its popular Top 10 list of web application security vulnerabilities. OWASP released the update of OWASP Top Ten vulnerabilities in 2021.

Three of the items in the updated edition of the OWASP Top Ten are new, attempts to identify emerging trends based on data analysis and a broad industry survey. Insecure Design debuts at number 4 and brings visibility to underlying architectural problems that can result in a host of vulnerabilities in an application. Its inclusion in the Top Ten highlights the need to design applications for security, even before the first line of code is written.

Similarly, Software and Data Integrity Failures is a new category that addresses the need to ensure that applications and data are not tampered with by malicious third parties before being accessed by users. Finally, Server-Side Request Forgery (SSRF) is an emerging vulnerability that can give an attacker access to internal systems.

In general, the Top Ten has evolved from focusing on individual vulnerabilities to covering broader security control areas. Items in the Top Ten include risks from the software supply chain, opensource libraries and frameworks, and common problems like broken access control and injection. In all, nearly 200 Common Vulnerabilities and Exposures (CVEs) are now included in the Top Ten. Now is the time for organizations to start focusing on the new Top Ten—especially the three new items. They must ensure that adequate precautions are in place for each of its categories and underlying elements.

The 2021 OWASP Top Ten

Find the current OWASP 10 categories here:

1 – Broken Access Control

Since access control features control who can perform functions, see and manipulate data, and do administrative tasks, failures of these controls can have devastating consequences.

2- Cryptographic failures

Formerly known as Sensitive Data Exposure, this category of vulnerabilities focuses on the correct use of encryption, hashing, and other cryptographic mechanisms. Mistakes can result in significant compliance penalties for organizations under the jurisdiction of the E.U.’s General Data Protection Regulation (GDPR), the California Consumer Protection Act (CCPA), the Health Insurance Portability and Accountability Act (HIPAA), and other laws governing the disclosure of personally identifiable information (PII), personal health information (PHI), and financial data for publicly traded companies.

3- Injection

Several types of injection were combined into a single category in 2017, including SQL, NoSQL, LDAP, Command, and Expression Language (EL) Injection. For 2021, another common vulnerability type was added to this category—Cross-Site Scripting (XSS). These vulnerabilities enable attackers to relay malicious code through an application to another system and often result in a complete takeover of the target host.

4- Insecure Design

New for 2021, Insecure Design relates to the increased risk posed by applications with an underlying architecture that is not secure. Threat modeling is now required by OWASP, NIST, and the PCI Councils, so organizations should accelerate adoption of secure design patterns and reference architectures. Avoiding this element of the OWASP Top Ten must begin before the first line of code is written, making security an integral part of the initial design rather than an afterthought.

5- Security Misconfiguration

This category now includes XML External Entities (XEE) along with the vulnerability types it represented in 2017. Configuration errors are common in applications in production, and misconfiguration vulnerabilities can make these human errors even more likely by failing to harden security across the software stack. Including unnecessary features, ports, or privileges is an example, as is enabling default passwords.

6- Vulnerable and outdated components

This category relates to the hygiene of keeping open-source libraries and frameworks up to date and ensuring that newly discovered CVEs are remediated. It is important to understand which libraries and library classes are used by the software, as these pose the most imminent risk.

7- Identification and authentication failures

Formerly known as Broken Authentication, issues with identification were added to this category in 2021. This category of vulnerabilities can enable tactics such as credential stuffing, brute-force attacks, and exploitation of weak credential recovery processes.

8- Software & Data Integrity Failures

This new category, identified through the industry survey, is confusing because it bundles two unrelated items together: software supply chain issues and data integrity mistakes such as digital signatures, hashes, and checksums. To make things more complicated, unsafe deserialization was added to the category, which at its root is more of an injection problem.

Nevertheless, the category highlights the need for integrity of application code and the data accessed through applications. The devastating SolarWinds attack in late 2020 is a prime example of a software integrity failure, as cyber criminals were able to insert malware into a routine software update for SolarWinds Orion infrastructure software, impacting thousands of networks. An insecure continuous integration/continuous deployment (CI/CD) infrastructure can result in such an attack.

9- Security logging and monitoring failures

This category relates to ongoing incident response processes employed by security operations teams. At the end of the day, applications should be able to detect and block attacks. If security tools are in place that log attacks, then organizations should do something to respond, rather than simply letting them sit in a forgotten log. When applications have inadequate logging and monitoring features, breaches cannot be detected. When penetration tests, application security scans, and security logs do not trigger alerts of an active attack, organizations cannot mount a defense.

10- Server-side request forgery (SSRF)

New for 2021, SSRF was selected because of its prevalence in both the 2021 industry survey and the collected data as an emerging threat. SSRF vulnerabilities enable an attacker to trick the targeted application or application programming interface (API) into sending a crafted request to an unexpected destination—turning a vulnerable application into a sort of attack relay that gives an attacker access to internal systems. OWASP’s intent in adding this category to the Top Ten is to raise awareness and potentially roll it into another category in the next edition.