[#4][ComptiaPentest+] Terminologies of Vulnerability Scanning Phase

Vulnerability scanning, also commonly known as 'vuln scan', is an automated process of proactively identifying network, application, and security vulnerabilities. Vulnerability scanning is typically performed by the IT department of an organization or a third-party security service provider. This scan is also performed by attackers who try to find points of entry into your network.

Scanning Types

External vulnerability scans target the areas of an IT ecosystem that are exposed to the internet, or not restricted for internal use. These areas can include applications, ports, websites, services, networks, and systems that are accessed by external customers or users.

With internal vulnerability scans, the primary target of the software is the internal enterprise network. Once a threat agent makes it through a security hole, the threat agent can leave enterprise systems prone to damage. These scans search for and identify the vulnerabilities inside the network in order to avoid damage, as well as to allow organizations to protect and tighten systems and application security that are not exposed by external scans.

Environmental vulnerability scans are based on the specific environment of an enterprise's technology operations. These vulnerability scans are specialized and are available to deploy for multiple technologies, such as IoT devices, websites, cloud-based services, and mobile devices.

SECURITY CONTENT AUTOMATION PROTOCOL (SCAP)

The Security Content Automation Protocol (SCAP) is an effort by the security community, led by the National Institute of Standards and Technology (NIST), to create a standardized approach for communicating security-related information. This standardization is important to the automation of interactions between security components. The SCAP standards include the following:

Common Configuration Enumeration (CCE) Provides a standard nomenclature for discussing system configuration issues.

Common Platform Enumeration (CPE) Provides a standard nomenclature for describing product names and versions.

Common Vulnerabilities and Exposures (CVE) Provides a standard nomenclature for describing security-related software flaws.

Common Vulnerability Scoring System (CVSS) Provides a standardized approach for measuring and describing the severity of security-related software flaws.

Extensible Configuration Checklist Description Format (XCCDF) Is a language for specifying checklists and reporting checklist results.

Open Vulnerability and Assessment Language (OVAL) Is a language for specifying low-level testing procedures used by checklists.

ANALYZING AND TESTING CODE

The source code that is the basis of every application and program can contain a variety of bugs and flaws, from programming and syntax errors to problems with business logic, error handling, and integration with other services and systems. It is important to be able to analyze the code to understand what the code does, how it performs that task, and where flaws may occur in the program itself. This information may point to critical undiscovered vulnerabilities that may be exploited during a penetration test.

Code testing is often done via static or dynamic code analysis along with testing methods like fuzzing and fault injection. Once changes are made to code and it is deployed, it must be regression-tested to ensure that the fixes put in place didn’t create new security issues!

Static Code Analysis

Static code analysis (sometimes called source code analysis) is conducted by reviewing the code for an application. Since static analysis uses the source code for an application, it can be seen as a type of white box testing with full visibility to the testers. This can allow testers to find problems that other tests might miss, either because the logic is not exposed to other testing methods or because of internal business logic problems.

Unlike many other methods, static analysis does not run the program being analyzed; instead it focuses on understanding how the program is written and what the code is intended to do. Static code analysis can be conducted using automated tools or manually by reviewing the code—a process sometimes called “code understanding.” Automated static code analysis can be very effective at finding known issues, and manual static code analysis helps to identify programmer-induced errors.

Dynamic Code Analysis

Dynamic code analysis relies on execution of the code while providing it with input to test the software. Much like static code analysis, dynamic code analysis may be done via automated tools or manually, but there is a strong preference for automated testing because of the volume of tests that need to be conducted in most dynamic code testing processes.

Penetration testers are much more likely to find themselves able to conduct dynamic analysis of code rather than static analysis because the terms of penetration-testing SOWs often restrict access to source code.

Fuzzing

Fuzz testing, or fuzzing, involves sending invalid or random data to an application to test its ability to handle unexpected data. The application is monitored to determine if it crashes, fails, or responds in an incorrect manner. Fuzzing is typically automated because of the large amount of data that a fuzz test involves, and is particularly useful for detecting input validation and logic issues as well as memory leaks and error handling.

Fuzz testing can often be performed externally without any privileged access to systems and is therefore a popular technique among penetration testers. However, fuzz testing is also a noisy testing method that may attract undue attention from cybersecurity teams.

The risk appetite is the willingness to tolerate risk within the environment. If an organization is extremely risk averse, it may choose to conduct scans more frequently to minimize the amount of time between when a vulnerability comes into existence and when it is detected by a scan.

Continuous monitoring is the process and technology used to detect compliance and risk issues associated with an organization's financial and operational environment.

Vulnerability management life cycle

This remediation workflow should be as automated as possible, given the tools available to the organization. Many vulnerability management products include a built-in workflow mechanism that allows cybersecurity experts to track vulnerabilities through the remediation process and automatically close out vulnerabilities after testing confirms that the remediation was successful.

Happy Pentesting!