Vulnerability Assessment

Vulnerability Assessment in a Network

A vulnerability assessment systematically checks assets, services, software, and configuration within a defined scope. Tools and analysts collect information about reachable hosts, ports, versions, and settings, then compare it with databases of known weaknesses. The result is not an attempt to break into a system. It is an ordered record of findings, their conditions, risk level, and recommended action. A report can distinguish critical issues, such as a publicly reachable service with a high-impact vulnerability, from lower-impact issues such as a configuration outside policy. This description helps asset owners plan remediation, accept risk, and verify the result later.

A vulnerability assessment is a proactive diagnostic practice. Its scope can include asset inventory, network scanning, configuration analysis, patch verification, and risk-based classification of findings. The assessment provides information before an incident and supports recurring vulnerability management. In a mature security program it is combined with remediation, rescanning, monitoring, and reporting so that changes in the security posture can be measured over time.

Defining a Vulnerability: A System Weakness

A vulnerability is a weakness in the design, implementation, or configuration of a system that can be exploited under particular conditions. The result can affect confidentiality, integrity, or availability, grant privileges, or bypass access controls. The source of the weakness influences how it is detected and corrected:

• Software Bugs:An error in an application or operating system can create an exploitable condition. A buffer overflow is one example: incorrect data handling can let an attacker overwrite memory, alter program flow, or execute code with the process's privileges.
• Misconfiguration:System settings can differ from a secure baseline. Examples include default or easily guessed passwords such as 'admin'/'password', sensitive ports reachable from the Internet, and disabled security features. An assessment should identify the access scope and asset affected by the setting.
• Outdated Systems: Missing security patches leave known weaknesses in software. Vendors publish updates and vulnerability information, often with a CVE identifier. A system without a required patch can be exposed to a publicly described exploit, which makes version inventory, prioritization, and deployment verification important.
• Design Flaws: A weakness in a protocol or architecture can permit misuse even when the implementation has no programming defect. Correction may require a design change, a compensating restriction, or withdrawal of the service.

The Vulnerability Management Lifecycle: A Continuous Process

Effective vulnerability management is a continuous, cyclical process. A scan and report are the beginning of the work. The lifecycle includes identification, tracking, prioritization, remediation, and verification, together with documentation of risk-acceptance decisions. Repeating these activities provides a measurable view of changes in the security posture over time.

1. 1. Discover: What Do We Have?

   The first step is asset discovery and an up-to-date inventory of devices, applications, and services running on the network. The inventory covers servers, workstations, printers, switches, firewalls, and IoT devices, together with owners, addresses, versions, and purpose. It defines the attack surface and identifies assets that could be missed by later steps.

2. 2. Scan: Finding the Flaws

   During identification, a vulnerability scanner probes discovered assets for known weaknesses. It checks open ports, identifies services and software versions, and compares the results with vulnerability databases and configuration rules. The output is a list of findings for each asset. Findings require interpretation because a banner can be incomplete, a version can be misidentified, and a vulnerability condition can depend on configuration.

3. 3. Analyze and prioritize: setting the remediation order

   A scan of a large network can generate a report with thousands of findings. Analysis determines actual risk and the order of remediation. The team can use CVSS, available exploit information, asset criticality, and business context. Public exposure, the server's position in the network, and the data it stores all matter. These criteria help select findings for the first response and separate duplicates or false positives.

4. 4. Remediate: Fixing the Problems

   In this phase, IT operations and development teams correct findings selected by priority. Remediation can include applying a vendor's patch, reconfiguring a system to a secure baseline, disabling a vulnerable service, or adding a compensating control such as a firewall rule. Each change should have an owner, a deadline, and a verification criterion.

5. 5. Verify: Did the Fix Work?

   After a fix, its effectiveness and effect on the service must be checked. A rescan of the remediated system should confirm removal of the vulnerability condition, while a configuration or application test should identify unwanted side effects. The result closes the loop for the finding and supports an updated assessment of residual risk.

6. 6. Report: Documenting and Tracking Progress

   Progress is documented and reported throughout the lifecycle. A technical report for IT teams should include the asset, evidence, condition, recommendation, and status. Management needs a risk-based summary with owners and deadlines, while trend analysis shows changes in finding counts, remediation time, and exposure. These data support compliance evidence and security investment decisions.

How Vulnerability Scanners Work

Vulnerability scanners automate part of reconnaissance and asset checking. The exact order depends on the product, scope, and credentials, but a typical sequence contains these steps:

1. Host Discovery: The scanner determines which hosts in a network range respond, often using ARP requests or ICMP (ping) scans. Lack of a response does not prove that a host is offline because a firewall can filter that traffic type.
2. Port Scanning: For each active host, a scanner can check the full range of $65,536$ TCP or UDP port-number values, although it often selects ranges relevant to the environment. The result shows ports reachable from the scanner; an open port suggests a listening service but does not describe its vulnerability.
3. Service and Version Identification:The scanner interacts with an open port to identify the service, such as a web server or database, and its version. It can use banner grabbing to read the introductory message sent by the service. A web server might return a banner such as 'Server: Apache/2.4.29 (Ubuntu)'. A banner is evidence to validate with other methods, not proof of the installed version.
4. Vulnerability Matching: Using the identified software and version, the scanner consults updated databases of known vulnerabilities, configuration rules, and patch information. It correlates target data with conditions for the relevant version and creates findings for review. Matching an identifier alone does not prove that the vulnerability can be exploited.

Scanning perspectives: unauthenticated and authenticated

Scan results depend on the perspective and the credentials available to the scanner. This distinction affects visibility of services, configuration, and patch state.

• Unauthenticated Scan (Black Box): This scan is performed from the perspective of an external user without special privileges. The scanner sees services reachable from the selected network and can identify their vulnerabilities, but it cannot read the internal state of the operating system, installed applications, or patch level. The result describes externally visible exposure and can miss issues that require local access.
• Authenticated Scan (Credentialed / White Box): The scanner receives credentials, such as a username and password or an SSH key, and logs in to the target system. It can then run local commands, read installed software, check versions, and verify patch levels through the package manager or registry. The result is usually more complete for internal systems, although its scope depends on privileges, agent support, and configuration. Credentials should be limited, protected, and used according to procedure.

The Language of Vulnerabilities: CVE and CVSS

Shared identifiers and scores help researchers, vendors, administrators, and response teams exchange information. CVE names a publicly disclosed vulnerability, while CVSS describes its base severity under stated exploitation conditions.

CVE: A Unique Identifier for Every Flaw

Common Vulnerabilities and Exposures (CVE) is a public collection of identifiers, descriptions, and references; detailed product, patch, and impact information can reside in other databases. The identifier provides an unambiguous reference to a disclosed vulnerability. Its syntax is 'CVE-YYYY-NNNN...', because the sequence contains at least four digits and can be longer. An example is $CVE-2017-5754$, which is associated with the Meltdown vulnerability.

A shared identifier lets security vendors, researchers, and administrators refer to the same issue without relying on a product name. If a scanner reports 'CVE-2021-44228' and a system or security vendor publishes Log4Shell information with the same identifier, teams can connect the finding, description, and recommended patch. The identifier does not replace checking the installed version and conditions of exposure.

CVSS: A Score for Severity

With many findings, teams need a comparable severity assessment. The Common Vulnerability Scoring System (CVSS) describes severity with a numerical score from $0.0$ to $10.0$ and a qualitative label. The base score describes vulnerability characteristics; temporal and environmental metrics can add context to the final assessment.

A CVSS base score is calculated from metrics describing exploitation conditions and impact on the vulnerable component. CVSS describes vulnerability severity rather than an organization's complete risk; prioritization also requires exposure, asset value, and available controls:

• Attack Vector (AV): Specifies whether exploitation requires network, adjacent-network, local, or physical access. Network (N) describes exploitation from the network; its contribution depends on the other metrics.
• Attack Complexity (AC): Describes conditions outside the attacker's control that must be present. Low (L) means that no special conditions of this type are required; it does not guarantee success on every attempt.
• Privileges Required (PR): Specifies the privileges needed before exploitation. None (N) means that no account or privilege is required.
• User Interaction (UI): Specifies whether a person other than the attacker must perform an action, such as opening a document or clicking a link. None (N) means no such interaction is required.
• Scope (S): Specifies whether exploiting the vulnerable component can affect a component beyond its security authority. Changed (C) indicates a change of scope; Unchanged (U) keeps the same boundary.
• Impact Metrics (Confidentiality, Integrity, Availability): C, I, and A describe impact on confidentiality, integrity, and availability. Each is rated None (N), Low (L), or High (H). High values for all three represent complete impact in the CVSS model.

For example, a CVSS v3.1 vector with AV:N, AC:L, PR:N, UI:N, Changed scope, and High impact on confidentiality, integrity, and availability receives the maximum base score of $10.0$ (Critical). In practice, each metric must be assigned from the definition and evidence for the specific vulnerability.

Vulnerability assessment and penetration testing: different objectives

Vulnerability assessment and penetration testing have different objectives and scopes. An assessment searches for and organizes many potential weaknesses, while a penetration test deliberately exercises selected paths to check actual impact and defensive behavior.

Both activities complement a mature security program. Vulnerability assessment provides a regular view of many assets and supports remediation planning, while penetration testing examines selected defenses from a controlled adversarial perspective. Results from both activities should be connected to asset owners, remediation deadlines, and follow-up verification.