A significant shift, in the application development process, is towards security testing and DevOps. This leads to the conjuring of terms, new and existing, which are often confused and, used interchangeably. This article enumerates a few of these terms, that are imperative for the engineering teams to be aware of from an application security and DevSecOps standpoint.
- VA: It stands for Vulnerability Assessment. Vulnerabilities are the avenues by which threats are manifested in an application. Vulnerability assessment is the process of identifying and quantifying those vulnerabilities in an application. It is an in-depth evaluation of the application’s security posture that can be done across all stages of an application development. VA is a separate activity by itself and is most often overused along with a Penetration Test, which technically is incorrect
- PT: Penetration Testing (Pen Testing) is a systematic process of using identified vulnerabilities, recognized during the VA stage, to intrude and exploit an application for its resources. You can do this manually, or automate a toolset and integrate it into your DevSecOps pipeline. Apropos to this definition, a security assessment or a VAPT is truly a combination of VA plus a PT. A corollary of this definition is that there can be no PT without a VA performed a priori
- DAST: Dynamic Application Security Testing is a process of testing an application during runtime. The purpose of such a test is to identify security vulnerabilities, while the application is operating in the environment that it was built for. This can either be carried out manually or using DAST tools. These tools crawl and test the application from the outside-in, and with appropriately designed test cases can me made to simulate security use cases effectively across the application
- Parameterised DAST Scans: Parameterised scanning is when a DAST scanner is used in conjunction with functional automation or walkthrough scripts to crawl specific sections or pages of an application. These scripts provide the much needed “context” to the DAST scanner resulting in a far more efficient security test as when compared to relying solely on its internal crawling engines. This technique is very effective while testing APIs or Single Page Applications (SPAs). Some of our regular subscribers might recollect our recent article on the need and benefits of Parameterised, contextual DAST scans in an automated CI environment
- SAST: Static Application Security Testing (aka White Box Testing) is a process of testing an application’s source code. You can do this manually or using SAST tools. These tools examine the application from the inside, looking at the source code, byte code, or application binaries for security vulnerabilities, before its being deployed.
- RASP: Run-time Application Security Protection is an “agent driven” technology that runs from within an application, and protects it against security threats in real time. It continuously analyzes both the application’s behavior and the context of the behavior. This context-driven capability enables RASP to respond to security threats automatically and protect the application from the inside. RASPs are mostly configured to run in an application’s production environment
- IAST: It stands for Interactive Application Security Testing. This form of testing is basically done by plugging an IAST tool into the application code, and run it to actively monitor the application’s behavior while the application is being attacked. The essence of IAST is to analyze an application’s behavior while the application is under attack or tested with DAST tools. The IAST tool looks into code execution and gathers information on events such as database queries, input validations, file system access, web service calls, etc. An analysis of these events gives insights into the application’s logic flow, data flow, configuration, and application response when the application is under attack
- Fuzzing: Fuzzing is systematic and automated approach to finding vulnerabilities in an application by injecting malformed data into the application. It is a black box application testing technique. A fuzzer (fuzzing tool) can use random data or use algorithms to generate data, which can include a combination of numbers, chars, metadata, and binary sequences
- Spidering: Spidering is the process of enumerating all links within an application and creating an application map that includes the different points of access into an application. You can use a tool such as WGET to retrieve all the information published by the application. Mapping out an application gives you an idea of the points of access and resources used in an application
- WAF: Stands for Web Application Firewall. Its purpose is to filter, monitor, and block all HTTP traffic to and from a web application. It is different from a regular firewall in that WAF is able to filter the content of specific web applications, whereas regular firewalls serve as a gate between servers. WAFs comes in various forms; appliance, server plugin, filter, or even an application
- Webhook: Webhooks are user-defined HTTP callbacks. It is a type of API, and also known as “Reverse API”. It is a method to alter the application’s behavior to provide custom responses in real-time, following a trigger. Since most of the interaction with an application can be described as an event, webhooks can be used to send custom response for those triggers
- Authentication: The process of proving that an user is actually the person that they said they are. In an application context, authentication consists of two parts: querying for credentials through an interface that requests a login name and password, and then verifying those credentials against a source such as a database
- Authorization: The process of determining whether an user supplying an identity is allowed to have access to a resource, and then giving access to that resource as defined by the application’s security policy. No wonder then that authorization is a key issue with most modern apps. However, one mustn't confuse this with Authentication. The difference between the two is that authorization's sole purpose is to check if the user has the permission to access the resource, whereas the sole purpose of authentication is to check if someone is actually the person they say they are
- Abuser Story: An abuser story is essentially a description of how an attacker would abuse (motives) an application’s feature, keeping in mind the associated business impact. By using user stories of an application, you can think of the different ways one can abuse the functionality, and create abuser stories. Abuser stories usually contain three important elements - an attack persona, an attack vector and an attack outcome
- Tooling: Tooling (in the context of application security) is a workflow based integration of multiple (SAST/ DAST) security testing tools into your application development the Continuous Integration pipeline. The goal here is to implement automated security testing at each stages of the application development. A security tooling is in no-way a replacement of manual penetration testing and is purely aimed at identifying a certain category of vulnerabilities that can be identified by security tools thereby reducing the effort of manual triage. Of late, companies have started to implement tools like ZAP and BURP into their CI pipelines
- Regression Testing (Exploit Scripts): Regression testing is the process of testing applications for bugs that were previously addressed in prior iterations before the next release. In AppSec context, regression testing only focuses on security vulnerabilities. The sole purpose is to test the vulnerabilities that were found and fixed in previous application iterations, and to make sure that those vulnerabilities did not resurface. At we45, we implement regression testing through automation by using exploit scripts
- Zero-day vulnerability: Unknown vulnerabilities in an application or device that are exposed, but not been patched yet, and has potential for exploitation are known as zero-day vulnerabilities. The “Zero-day” part of it refers to fact that developers had zero days to patch that vulnerability
- CVE: Common Vulnerabilities and Exposures is a repository of publicly known infrastructure related security vulnerabilities. It is a globally known repository and used across the world. It also provides a baseline for tool evaluation, and enables data exchange for security automation. The vulnerabilities in the repository are labeled with IDs, also known as CVE identifiers
- CVSS: Common Vulnerabilities Scoring System is an open industry standard to assess the severity of security vulnerabilities in an application. It provides a way to capture the key characteristics of a security vulnerability and come up with a numerical score reflecting its severity. The score is calculated based on three different metrics: Base metrics (includes authorization, authentication, availability, & impact), Temporal metrics (includes exploitability, remediation, & report confidence), environmental metrics (damage potential, & target distribution)
- CWE: Common Weakness Enumeration is a formal list of application vulnerability types created to act as a common language for describing security weaknesses in applications. It serves as a standard measuring frame for security testing tools to zone in on those weaknesses. It also sets a common baseline for weakness identification, mitigation, and prevention efforts. Additionally, CWE is an important parameter used for vulnerability correlation by AVCs such as Orchestron and others
- CWSS: Common Weakness Scoring System is a scoring system that helps identify the severity of CWE (explained above) entries discovered in an application. It can be used to prioritize the different weaknesses in an application and address them based on the vulnerabilities' severity to minimize risk
- STRIDE: STRIDE is a threat classification model developed by Microsoft. It stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service (DOS), and Elevation of Privilege respectively. Any threat an application might face can be identified and categorized into at least one of these threat categories
- DREAD: DREAD is a systematic approach to quantifying, comparing, and prioritizing the amount of risk presented by a the different threats identified in an application. It stands for Damage, Reproducibility, Exploitability, Affected Users, and Discoverability. The highest of averages in all these five categories poses the highest threat to an application
- OSSTMM: It stands for Open Source Security Testing Methodology Manual. OSSTMM methodology covers a wide range of elements that requires testing in an organization. It includes operational security of physical locations, workflow, human security, wireless & telecommunication security testing, data networks security testing, and compliance
- OSVDB: It stands for Open Source Vulnerability Database. It is an open-source database that provides detailed, accurate, and unbiased technical information about security vulnerabilities
- OWASP ASVS: The OWASP Application Security Verification Standard (ASVS) provides a basis for testing a web application’s technical security controls. It also provides a list of requirements for a secure application development. This standard helps establish a level of confidence in the security of your applications
- Vulnerability Management: Vulnerability management is the process of managing the life-cycle of a security issue akin to defect /bug management used in the QA world. A well oiled vulnerability management program involves tracking the source of the vulnerability, its associated priority / risk, business impact, associated remediation strategy with traceability metrics
- Vulnerability Correlation: It is a process of aggregating, de-duplication and correlating vulnerability data sets supplied from various DAST, SAST, and IAST tools. Security automation consists of using a wide range of testing tools. Each of these tools yield scan results, which follow different formats and vulnerability abbreviation than each other. This makes it a necessity for correlating the results
Enjoyed the read? Click here for more awesomeness in DevSecOps.Links for further reading:
