The Sphere of Weakness, Risk and Mitigation
In the context of Web Application Security Testing, my previous two articles were about multi-dimensional security mapping followed by an overview of security assessment methods. Now let’s enliven these fundamental concepts by adding an asymmetrical layer in motion: the words to describe the main actions of a Cyberpower Wizard.
I will be using the described wizardry language of points, layers, dimensions and spheres from the point of view of an alternate sphere of InfoSec.
If you think this is a wasteful stream of alphabet strings then consider changing dimensions for a day: when calculating risk, you are essentially moving across levels in a dimension while maintaining a connection with a second dimension! More on this in the deeper “Risk” layer.
UNDERSTANDING RISK WIZARDRY
In the process of web application security testing, from threat modelling to red teaming, you’re looking for weaknesses and simulating threats that could exploit any vulnerabilities, assessing the risks associated with those vulnerabilities, determining the severity level and potential impact of exploiting those vulnerabilities, and then working on mitigation strategies to reduce those risks. If an incident occurs, you’d engage in incident response to manage and learn from the situation.
So many words, yet all very meaningful and precise. What came first, the threat or the weakness? Viewing this question from an alternate sphere I don’t think there would be any weaknesses if there was no threats. So threats come first. Human life on Earth is not weak nor destructive when it is able to evolve psychologically.
As I wrote in my article about Vipassana last year, if people weren’t taken by an attachment to impermanence then there would be no need for security.
THE THREAT
A threat is any factor (internal or external) that can take advantage of a vulnerability. Anything that may adversely impact the organization, assets, individuals or simply harm the assets owned by an application. The assets in an application may be resources of value, such as the data in a database or in the file system.
The threat may be a malicious external attacker, an internal user, a rogue malicious software, a system instability, a circumstance, a situation or state, an event etc. The types of threats that could exploit the vulnerabilities outlined in the OWASP Top Ten include:
Malicious Actors (Hackers): These are individuals or groups who intentionally exploit vulnerabilities in web applications for personal gain, to inflict damage, or for other malicious purposes. They might be motivated by financial gain, political reasons, or simply the thrill of breaking into systems. They could be located anywhere in the world.
Insider Threats: These are individuals within an organization who have authorized access to the network and systems. They can be employees, former employees, contractors or business partners. Insider threats can be malicious (individuals who intentionally cause harm) or unintentional (individuals who accidentally cause a breach).
Botnets: Networks of infected computers that are controlled remotely by an attacker, usually without the knowledge of the computer owners. Botnets can be used to carry out attacks such as DDoS attacks, sending spam emails, spreading malware, or stealing data.
Malware: Malware is software that is specifically designed to disrupt, damage, or gain unauthorized access to a computer system. This includes viruses, worms, ransomware, spyware, and other malicious programs.
Phishing Attacks: Phishing is a type of social engineering attack where the attacker tricks the victim into revealing sensitive information, such as usernames, passwords, credit card numbers, etc. Phishing can also be used to trick users into clicking on malicious links or attachments that install malware.
Brute Force Attacks: In a brute force attack, the attacker attempts to gain access to a system by systematically trying all possible combinations of passwords or encryption keys until the correct one is found.
Woman-in-the-Middle (WitM) Attacks: In a WitM attack, the attacker secretly intercepts and possibly alters the communication between two parties who believe they are directly communicating with each other. Just joking about the Woman, it’s usually called a Man, but I have seen Person. Due to machine learning, it could be called Entity now, but when I come up with a good one from another sphere I will let you know. Could be Trust, as trust is actually trustlessness - but not in the sense of Zero-Knowledge Proofs on M.L. output checks of algorithms.
Exploit Kits: Exploit kits are software tools that automate the exploitation of vulnerabilities in software. They are typically used by attackers to propagate malware.
State-Sponsored Attacks: Some attacks are carried out by groups that are believed to be directed or funded by nation-states. These attacks are often highly sophisticated and targeted.
Advanced Persistent Threats (APTs): APTs are stealthy and continuous computer hacking processes, often orchestrated by criminals targeting a specific entity. These threats often use multiple phases to break into a network, avoid detection, and harvest valuable information over the long term.
Each of these threats can potentially exploit one or more of the vulnerabilities listed in the OWASP Top Ten, either directly or indirectly. For example, a phishing attack could lead to broken authentication if a user is tricked into revealing their login credentials.
WEAKNESS
A type of issue that under certain circumstances could lead to a vulnerability in the application. In human-designed systems, the human is the source, whether intentional or unintentional.
The maliciousness of the Dark Triad in this realm and its spheres is for another upcoming article series.
VULNERABILITY
The presence of a flaw or weakness (single or chained) in the design or implementation, operation or management of an information system or its environment that could be exploited to adversely affect an organization’s security objectives, assets or operations. It is a layer higher than weakness.
Sometimes, as part of Red Teaming, the application itself (a product/IT system) could be the vulnerability.
In the context of information security, the terms “weakness” and “vulnerability” are often used interchangeably, but they do have nuanced differences:
Weakness: This is a broader term referring to a flaw or inadequacy in a system or its components, which may potentially lead to a vulnerability. It’s essentially a defect or limitation in a system, which in certain circumstances may provide an attacker with an avenue for exploitation. However, a weakness does not automatically equate to a vulnerability. For example, weak or simplistic passwords can be a security weakness.
Vulnerability: A vulnerability is a specific type of weakness that can be exploited by a threat to gain unauthorized access or perform unauthorized actions in a system. Vulnerabilities are actual security holes or bugs in a system that can be directly leveraged by an attacker. Continuing with the previous example, if an attacker knows a user’s weak password and can gain access to their account, the weak password is then considered a vulnerability.
In summary, while all vulnerabilities are weaknesses, not all weaknesses necessarily constitute vulnerabilities. It is the context and potential for exploitation that can transform a weakness into a vulnerability.
MITRE CWE and CVE
The MITRE Corporation maintains both the Common Vulnerabilities and Exposures (CVE) system and the Common Weakness Enumeration (CWE) system, and while they are related, they serve different purposes in the field of cybersecurity:
Common Vulnerabilities and Exposures (CVE): The CVE is a list of publicly disclosed cybersecurity vulnerabilities. Each entry in the CVE list, called a CVE ID, includes an identification number, a description of the vulnerability, and at least one public reference. The aim of the CVE system is to standardize the way that vulnerabilities are identified. This allows different security tools and services to share information efficiently, making it easier to manage vulnerabilities.
Common Weakness Enumeration (CWE): The CWE, on the other hand, is a community-developed list of software and hardware weakness types. It aims to serve as a common language for describing vulnerabilities, to facilitate understanding and discussion about their causes, and to provide a standard measuring stick for software security tools targeting these issues. CWE goes a layer deeper than CVE by focusing on the underlying vulnerabilities in software and hardware that could lead to exploitable security risks.
CVE entries represent individual, publicly reported vulnerabilities, each of which has a specific occurrence in a specific product and version. CWE entries, on the other hand, represent types of security weaknesses that could lead to vulnerabilities. CVE is about specific, reported vulnerabilities, while CWE is about categorizing types of weaknesses that can lead to those vulnerabilities.
VULNERABILITY ASSESSMENT
Vulnerability assessment in the context of web application security testing involves identifying, quantifying, and prioritizing (or ranking) the vulnerabilities in a system. Here are some steps involved in assessing vulnerabilities:
Scoping: Determine the extent of the assessment. Define which systems, networks, or software need to be tested. Also, define the rules of engagement if it’s a live environment.
Information Gathering: Gather information about the target application, such as the languages used, the APIs it exposes, the servers it runs on, and more. This is also known as the reconnaissance phase.
Vulnerability Identification: Utilize various tools and methodologies to identify vulnerabilities. This might involve:
- Static Analysis: Analyze the application’s source code or binary code for vulnerabilities without actually executing the code.
- Dynamic Analysis: Analyze the application during runtime. This method can identify runtime errors that might not be visible during static analysis.
- Automated Scanning: Automated vulnerability scanning tools like OWASP ZAP or Nessus can help identify vulnerabilities like SQL injection, cross-site scripting, insecure server configurations, and more.
- Manual Penetration Testing: This involves manually interacting with the application to identify vulnerabilities that automated tools might miss. It usually involves tactics like fuzzing input fields, manipulating cookies, and more.
Vulnerability Analysis: Once vulnerabilities have been identified, analyze them to understand their nature, the potential impact, and the degree of risk they represent. This could involve reproducing the vulnerability to confirm its existence and potential impact.
IBM SkillsBuild:
Vulnerabilities are potential weaknesses within a system that could be exploited to compromise it. For instance, a vulnerability could be a webpage that does not authenticate a user correctly.
Reporting: Document the findings, including the vulnerabilities identified, their potential impact, and recommended remediation steps. Reports should be written in clear, understandable language.
Risk Classification: Classify the vulnerabilities based on their risk level. This usually considers the potential impact of the vulnerability and the likelihood of it being exploited. Common scales are High/Medium/Low or using a numeric scale like CVSS (Common Vulnerability Scoring System).
Remediation: Provide actionable remediation advice for each vulnerability, such as software patches, configuration changes, or coding best practices.
Vulnerability assessment is not a one-time activity but a continuous process, as new vulnerabilities may be introduced over time through changes in the application, newly discovered vulnerability types, or changes in the threat landscape.
ADDRESSING VULNERABILITIES
When a vulnerability has been identified and addressed, it is commonly said to have been “mitigated”, “resolved”, or “patched”.
Mitigated: This term suggests that actions have been taken to lessen the severity, seriousness, or painfulness of the vulnerability.
Resolved: This indicates that the vulnerability issue has been settled or found a solution to.
Patched: This is often used when a piece of code has been specifically written and deployed to fix the vulnerability. It’s named after the idea of putting a “patch” on a hole.
In the context of a report or documentation, you might say something like “The reported XSS vulnerability in the application’s search function has been patched as of version 2.1.4.”
RISKS
Risks represent the potential for loss or damage when a threat exploits a vulnerability arising out of a weakness. Risk is a function of the likelihood of a given threat source exploiting a vulnerability and the resulting impact on the Web Application product and organization.
This is fascinating because in order to evaluate the risk one has to move into a higher level within the dimension of the Web Application product under test!
This level has to surround the Web Application and sufficient knowledge of two dimensions is necessary: the language of the corresponding security and the language of the particular product. Then a Cyberpower Wizard has to bridge the two — and ZAP!
Identifying impact and likelihood for crtical system security vulnerabilities might be the highest paid job on the planet, if you know what I mean. Realm* hint wink.
Risk assessment in the context of web application security testing is a systematic process that involves identifying vulnerabilities, determining the potential impacts of exploiting those vulnerabilities, and prioritizing remediation efforts based on the level of risk:
Identify Vulnerabilities: Using tools and techniques like static analysis, dynamic analysis, and penetration testing, you can find potential vulnerabilities in a web application. This can include things like code flaws, insecure configurations, unpatched software, etc.
Determine Impact: For each identified vulnerability, determine the potential impact if it were to be exploited. For a Web Application, this could range from relatively minor impacts, such as slight performance degradation, to severe impacts, such as data breaches resulting in loss of sensitive data, damage to the organization’s reputation, financial loss, or legal implications.
Evaluate Likelihood: Assess the likelihood of each vulnerability being exploited. This can depend on factors like the complexity of the exploit, the skills and resources required, the visibility of the vulnerability, and the presence of motivated, skilled and funded attackers. Likelihood can be noteworthy, as it is on the rise due to the increasing popularity of Unethical Hacking. Also depends on the threat actor’s ability for multi-dimensionality. A vulnerability that is easy to exploit and provides a high reward for an attacker would be likely to be exploited.
An extra deeper note from IBM SkillsBuild:
Within cybersecurity, likelihood is hard to directly measure due to the constant evolution of technology and involvement of outside attackers. As a good rule of thumb, the likelihood of an organization being attacked depends partly on three attributes as follows:
Likelihood = Adversary capability x Adversary motivation x Vulnerability severity.
An adversary is a general term used to describe an entity who wishes to compromise an information system.
Calculate Risk: Risk is typically calculated as a function of the impact and likelihood. For example, a high-impact vulnerability that is also likely to be exploited would be considered a high-risk vulnerability. Conversely, a low-impact vulnerability that is unlikely to be exploited would be a low-risk vulnerability.
Risk = Impact x Likelihood (ease). Get severity level from this result.
Severity Level: A measure of the seriousness of a vulnerability, typically based on the potential impact and the ease of exploitation. Vulnerabilities are often classified into severity levels such as low, medium, high, or critical to help prioritize remediation efforts.
For a more quantitative approach, you might use a scoring system such as the Common Vulnerability Scoring System (CVSS). It provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity, based on factors such as the impact to the confidentiality, integrity, and availability of the affected system, and the complexity of exploiting the vulnerability.
Prioritize Remediation Efforts: Based on the calculated risk, you can prioritize your remediation efforts. High-risk vulnerabilities should generally be addressed first, followed by medium- and low-risk vulnerabilities.
The goal of risk assessment is not to eliminate all risk (which is likely impossible), but to manage risk to an acceptable level given the resources available and the risk tolerance of the organization. Once the risks are understood, they can be addressed.
Example:
A company develops an online service (an asset). An error in the code (a vulnerability) allows for unauthorized access to user data. Cybercriminals (the threats) discover this vulnerability. The potential damage to the company, such as financial loss and reputational damage due to a data breach, represents the risk. The company can mitigate this risk by fixing the coding error, thus eliminating the vulnerability and reducing the likelihood of the threat causing harm.
Start by identifying vulnerabilities in the web application (through methods such as penetration testing or using automated scanning tools). For each vulnerability, you’d assess the potential impact and the likelihood of exploitation to determine the risk associated with the vulnerability. Based on the risk, you’d assign a severity level to the vulnerability, which can then guide your remediation efforts (e.g., vulnerabilities with a higher severity level should typically be addressed first).
MANAGING SECURITY RISKS
When it comes to managing security risks, mitigation is just one part of a larger strategy. Several other steps can be taken as part of a comprehensive approach to reduce the risk of security incidents:
Risk Acceptance: Sometimes, the cost of mitigating a risk can outweigh the potential loss. In such cases, an organization may choose to accept the risk. This doesn’t mean ignoring the risk, but consciously deciding to accept it and monitor it closely.
Risk Avoidance: In some cases, a risk can be avoided altogether by not performing an activity that could lead to the risk. For example, not storing sensitive customer data, if not necessary for the business, would avoid the risk associated with a potential data breach.
Risk Transfer: This involves offloading some of the risk to another party, often in the form of insurance. For instance, cybersecurity insurance can help cover the costs related to a security incident.
Risk Mitigation: As you mentioned, this is about reducing the risk level by implementing controls and measures to minimize the likelihood or impact of a security incident.
Patching and Updating: Keeping systems, software, and applications up-to-date is crucial in reducing the risk of security incidents. Many security breaches are due to unpatched vulnerabilities.
Security Awareness Training: Employees can often be a weak point in security, due to phishing attacks or simple mistakes. Regular training can significantly reduce the risk of such incidents.
Incident Response Planning: Despite all precautions, incidents can still happen. Having a robust incident response plan can help minimize the damage when they do.
Regular Auditing and Testing: Regular security audits, penetration testing, and vulnerability assessments are crucial to discover and address potential security issues before they can be exploited.
These steps, together with a strong security culture and the use of security frameworks and best practices, can help organizations significantly reduce their risk of security incidents.
SERIOUS VULNERABILITY OR RISK?
Why is the Severity Level a measure of the seriousness of a Vulnerability instead of the seriousness of Risk?
Severity level is often associated with a specific vulnerability because it helps to describe the potential impact that could result if that vulnerability were to be exploited, as well as factors like the complexity of exploiting the vulnerability.
Risk, on the other hand, is more encompassing and extends beyond individual vulnerabilities. It considers not only the severity of the vulnerabilities but also external factors such as threats and their capabilities, as well as the likelihood of the vulnerabilities being exploited.
While severity gives us an idea about how bad a vulnerability could be, risk gives us an idea about the likelihood that a vulnerability could actually lead to an impactful event, given the broader context.
So, in a sense, the severity of a vulnerability is a component of the overall risk, but it’s not the whole picture. The risk involves other factors such as threat landscape, exposure time, mitigating factors, and even aspects like the value of the affected assets, business impact, or regulatory and compliance implications.
In a practical scenario, you might have a high-severity vulnerability in an application, but if there are other controls in place, like network segregation, limited user access, or threat detection systems, the actual risk of it being exploited might be lower. Conversely, a low-severity vulnerability might present a high risk if it’s in a critical system, is easily exploitable, and the impact of exploitation is high.
That’s why it’s important to use both severity and risk as part of a comprehensive approach to vulnerability management and not conflate the two.
THE OWASP TOP TEN DIMENSION
The OWASP (Open Web Application Security Project) Top Ten is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
The goal of the OWASP Top Ten is to educate developers, designers, architects, managers, and organizations about the consequences of the most common and most important web application security weaknesses. The OWASP Top Ten provides basic techniques to protect against these high risk problem areas and also provides guidance on where to go from here.
GRATITUDE
I wrote this with the knowledge from my excellent school course instructors, such as AD from bezpiecznykod.pl, select books, some experience, my own mind-maps and ChatGPT. The bridged dimensions I wished to present are my work, as part of a deep dive into specific upcoming articles about Vulnerability Assessments through black-box Stealth Recon.
