FoxuTech

Security Vulnerabilities

Security Vulnerabilities

Managing vulnerabilities are one of the difficult, why? As there is multiple reason we can say, one should how to detect? as we always face issue how to find. Because there is so many different types of vulnerabilities. We aware there is multiple tool and tricks to get the vulnerabilities and we can fix based on the layer and identifications, even hidden one can be.

What is a security vulnerability?

A security vulnerability is an error or flaw within an IT resource that could be exploited by attackers.

As explained in further detail below, these errors or flaws could take a variety of ways. A security vulnerability could be a coding mistake like within application source code that can be used to launch a buffer overflow attack. It could be an oversight by developers who forget to validate input properly within an application, thereby enabling injection attacks. It could be a misconfiguration within an access control policy or a networking configuration that grants outsiders access to sensitive resources. Best example Apache log4j

Security Vulnerability vs. exploit vs. threat vs. breach

It is always good to know the terms used in cybersecurity risks like “security vulnerability,” “exploit,” “threat” & “breach”. However, although these terms are closely related, they each refer to different parts of the chain of events that may lead to a security incident:

For example, the CodeRed exploit on the Microsoft IIS vulnerability has been actively used to infect more than 300,000 targets. These threats have caused huge financial losses around the globe.

With this we all should aware that security vulnerabilities are on the key to form the foundation for the chain of exploits, threats, and breaches. It is always detecting vulnerabilities is the best way to avoid other security risks. If you able fix the vulnerability, you also remove the exploits, threats and potential breaches that also can result from the vulnerabilities.

Types of security vulnerabilities

Well, there are variety of security vulnerabilities that possibly exists on organization infrastructure, network, and application.

There are two important lists that track the weaknesses that make web applications and websites vulnerable to cybersecurity risk. The first is maintained by the open-community, global Open Web Application Security Project (OWASP). Of the 60 or so application security weaknesses described in OWASP, the OWASP Top 10 Vulnerabilities features those that are most commonly exploited as vulnerabilities. The current list is from 2017 and it is in the process of being updated.

The second list is CWE, or Common Weakness Enumeration, which is a “community-developed list of common software and hardware weakness types that have security ramifications.” CWE, like the well-known Common Vulnerabilities and Exposures (CVE) standardized dictionary, is run by the MITRE Corporation, a not-for-profit company that operates federal government funded R&D centers. The CWE-25 is an annually updated listing of the 25 most dangerous software weaknesses.

Here are some categories on those:

Malicious code: Malicious code is the term used to describe any code in any part of a software system or script that is intended to cause undesired effects, security breaches or damage to a system. Malicious code is an application security threat that cannot be efficiently controlled by conventional antivirus software alone.

Misconfigurations: Configuration mistakes like a cloud Identity and Access Management (IAM) rule that provides public access to sensitive data may lead to breaches.

Coding flaws: Coding mistakes or oversights — such as failure to perform input validation to detect application input designed to gain unauthorized access — can lead to exploits.

Lack of encryption: Data that is not properly encrypted, either at rest or in transit over a network, is vulnerable to attack.

How to detect application security vulnerabilities

Detecting security vulnerabilities can be enabled with Secure SDLC, where you can identify the issue earlier and we can avoid 99% of issues by enabling following automated tools with their pipelines.

Static Application Security Analysis

Static Application Security Analysis, or SAST, is a category of security testing that scans source code and (in some cases) binary code to identify vulnerabilities within it. SAST provides the earliest check-in opportunity, allowing you to identify potential issues at the coding stage, so you can resolve problems without breaking builds or allowing vulnerabilities to get passed to the final application release.

Example Tools: Veracode, Coverity, HCL AppScan, Checkmarx, etc.

Application Security Analysis

Dynamic Application Security Analysis, or Dynamic Application Security Testing (DAST) is the process of analyzing a web application through the front-end to find vulnerabilities through simulated attacks. This type of approach evaluates the application from the “outside in” by attacking an application like a malicious user would.

Example Tools: Veracode, Code Dx, HCL AppScan, Checkmarx, etc.

Penetration testing

In penetration testing, security testers manually seek to identify and exploit vulnerabilities. Penetration testing is different from DAST in that penetration testing involves security experts actively looking for vulnerabilities, whereas DAST relies on automated attack emulation.

Read more on: What is Penetration Testing? | Core Security

Image scanners

There are more number of the image scanners available, which detect vulnerabilities in software after it has been compiled or packaged. As such, image scanners are useful for identifying vulnerable dependencies or configurations within a container which may cause any threat. For example, an image scanner could check a container image to determine whether any of the image’s dependencies contain vulnerabilities.

Example Tools: Aqua Security, Docker bench, Harbor, Jfrog Xray, Synk, Twistlock

Configuration audits

Configuration auditing tools are typically used to validate the configuration of infrastructure that hosts applications, as opposed to applications themselves (although in some cases configuration audits can be performed on configuration files that define application settings).

For instance, a configuration audit of a cloud environment could detect insecure IAM rules or networking configurations. Alternatively, a configuration auditor could be used to scan a Kubernetes environment to detect misconfigurations in Kubernetes security contexts, network policies or other settings that weaken the security posture of the environment. Which is mandatory now a days to avoid any major issue, as all we are moving towards Cloud, where the is high possibilities for high risks.

So often performing configuration even pre-post changes will avoid any risks.

Exit mobile version