Lately there have been several stories about big $$ penalties for privacy violations or breaches. This is real news to those companies. Since the majority of successful breaches target exploitable vulnerabilities residing in the application layer, enterprise IT departments must be extra vigilant about application security. Many enterprises are still early in developing their application security program, so let’s dive in to some fundamentals about AppSec.
It has long been understood that a successful attack requires the exploitation of reachable vulnerabilities, which result from inherent weaknesses in software. Got it? Ok, let’s first define a few common terms used in most AppSec discussions.
- A vulnerability is caused by one or more weaknesses in software, or its configuration, that may be exploited by an attacker.
- An attack itself can come in a variety of classes, including distributed denial of service (DDoS), cross-site scripting (XSS), SQL injection, and many others. Well-known attacks are often given common names, such as “WannaCry.”
- A threat is the potential for one or more of these attacks to occur. Threats include possible attacks by ransomware, viruses, and other types of exploits.
To understand the types of vulnerabilities and threat levels you need to guard against, it helps to use the following structure: “known knowns, known unknowns, and unknown unknowns.” In terms of cybersecurity, here’s how you can understand them:
- Known-knowns: These are previously identified vulnerabilities that are, usually, listed in one or more vulnerability databases. They can be guarded against by patch management and software composition analysis (SCA)—i.e., by installing the fixes sent by vendors after some vulnerability in their software has been detected and, usually, corrected. Of course, it is the responsibility of individual customers to install the patch properly and in a timely way.
- Known unknowns: These are vulnerabilities based on known types of weaknesses, but you don’t know if instances exist in your own systems. To guard against this potential you need to scan your code and its dependencies for instances of vulnerabilities or active malicious code. Let’s say you know about a specific cross-site scripting (XSS) vulnerability in a consumed software component, in which malicious scripts are injected into otherwise benign and trusted web sites. The vulnerability has a name, and an assigned CVE, but you don’t know if that vulnerability resides in your code. Ideally, scanning for the signature of that particular XSS will discover any threat.
- Unknown unknowns: In cybersecurity terms, these are zero-day vulnerabilities that represent the discovery—and often the exploit— of a fundamentally new attack vector (involving a new weakness type). No tool can find them, because no signature has ever been recorded, no ID has been assigned to instances of it, and there are “zero” days between the discovery and the attack. In other words, the first symptom of the vulnerability is the attack, or exploit, itself.
When a vulnerability is discovered in released code, the most obvious course of action is to fix it, patch it, and make the patch available to customers. But this is not always the case. If your organization writes software and also runs software written by other organizations, then there are several models for vulnerability disclosure and multiple “expert sources” that can apply to you—depending on whether the code is yours (“my code”) or another party’s (“not my code”).
Anyone, especially anyone with a background in software security and software vulnerabilities, can discover a weakness in software code. People looking for vulnerabilities are often referred to as researchers. They may be contributors to a “bug bounty” program, or they may work directly with a software vendor to discover and report weaknesses in code before and after software release.
The CVE and Vulnerability Databases
Known vulnerabilities are collected and maintained in widely available databases, the best-known being the “Common vulnerabilities and exposures” (CVE) list maintained by the MITRE Corporation and the “National vulnerability database” (NVD) maintained by the US Federal government.
Most security experts recognize that the CVE and the NVD provide valuable information to serve as guidelines or bare minimums for organizations. The important thing for application security teams to do, in return, is to stay up to date on reported vulnerabilities, apply security patches immediately as they become available from their software providers, and implement a patch management program as a routine part of IT operations.
If this discussion resonates with the enterprise security challenges you are trying to solve, I highly recommend the The 2019 TechBeacon Buyer’s Guide to Application Security. You’ll learn about “What processes and products enable application security risks to be mitigated?” and “What questions do application development teams need to answer in order to determine their next steps in application security risk mitigation?”
About Micro Focus Fortify
Fortify offers end-to-end application security solutions with the flexibility of testing on-premises and on-demand to cover the entire software development lifecycle. Complete software security assurance with Fortify on Demand -our application security as a service - integrates static, dynamic and mobile AppSec testing with continuous monitoring for web apps in production.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.