Vulnerability Assessment and Security Operations

Introduction

Cybersecurity is not achieved merely by deploying firewalls, antivirus software, or strong passwords. Organisations must continually discover weaknesses, determine which weaknesses matter most, detect suspicious activity, and respond in a controlled manner. Vulnerability assessment and security operations provide the practical processes through which these activities are coordinated.

A vulnerability assessment identifies weaknesses in systems, applications, networks, configurations, and processes. Security operations then provide continuous visibility through logging, monitoring, alert analysis, threat intelligence, and incident response. Penetration testing may validate whether selected weaknesses can be exploited, but it must remain authorised, controlled, and proportionate.

The central professional challenge is that a scanner can produce thousands of findings, while an organisation has limited time, staff, and budget. Effective cybersecurity therefore requires more than technical discovery. It requires interpretation, prioritisation, communication, governance, and verification.

Learning Objectives

By the end of this chapter, a learner should be able to:

• explain the purpose and lifecycle of vulnerability assessment;
• conduct or describe an authorised basic vulnerability scan;
• distinguish vulnerability, threat, exploit, risk, and control;
• interpret scanner findings and recognise false positives and false negatives;
• prioritise remediation using technical severity and business impact;
• explain the purpose of logs, monitoring, SIEM, and threat intelligence;
• describe a basic security-operations workflow;
• distinguish vulnerability assessment from penetration testing;
• identify ethical, legal, safety, and governance boundaries;
• recommend practical improvements to an organisation’s security process.

1. Vulnerability Assessment as a Risk-Management Activity

A vulnerability is a weakness that could be used, accidentally or deliberately, to compromise confidentiality, integrity, or availability. Examples include an unpatched operating system, excessive user privileges, an exposed administrative interface, weak encryption, insecure application input handling, or an ineffective backup process.

A threat is a potential cause of harm, such as a criminal group, malicious insider, natural disaster, or software failure. An exploit is a method, tool, or sequence of actions that takes advantage of a vulnerability. Risk is the possibility that a threat will exploit a vulnerability and cause harm to an asset.

These terms should not be treated as synonyms. A high-severity vulnerability on an isolated, non-critical test system may present less organisational risk than a medium-severity weakness on an internet-facing payment server.

A useful conceptual relationship is:

Likelihood represents the estimated chance of an adverse event within a stated period, while impact represents the magnitude of harm if the event occurs. This is a risk model rather than a law of nature. It is useful for prioritisation, but the inputs are often uncertain and may be qualitative rather than numerical. Organisations should define their own scales and assumptions.

A vulnerability assessment normally answers four questions:

1. What assets and services exist?
2. What weaknesses are present?
3. How credible is exploitation?
4. What action should be taken, by whom, and by when?

The assessment should be authorised, scoped, repeatable, documented, and connected to remediation. A scan that produces a report but no corrective action is an administrative exercise rather than effective risk management.

2. The Vulnerability-Assessment Lifecycle

A professional assessment commonly follows the lifecycle below.

2.1 Preparation and authorisation

Before scanning, the organisation should identify the owner of the systems, obtain written permission, define the scope, and establish rules of engagement. The scope should specify IP ranges, hostnames, cloud accounts, applications, test accounts, permitted techniques, testing windows, and excluded systems.

The rules should also define emergency contacts, data-handling requirements, rate limits, and procedures for stopping the assessment. Production systems, medical devices, industrial-control systems, and fragile legacy equipment may require special treatment or exclusion.

Authorisation is not implied by technical access. The fact that a system is reachable does not grant permission to test it.

2.2 Asset discovery and classification

An organisation cannot protect assets that it does not know exist. Asset discovery may use configuration-management databases, cloud inventories, DNS records, endpoint-management platforms, network observations, and interviews with system owners.

Each asset should be associated with an owner, business function, location, operating environment, data classification, and criticality. Useful classifications include public-facing service, internal business system, privileged management system, development system, and safety-critical technology.

2.3 Scanning and evidence collection

A vulnerability scanner may perform host discovery, service identification, version detection, configuration checks, credentialed inspections, and tests for known weaknesses. Scanning modes have different strengths:

• Unauthenticated scanning views the system from an external perspective. It can identify exposed services and some remotely visible weaknesses.
• Authenticated or credentialed scanning uses approved credentials to inspect installed software, patches, local configurations, and security settings. It usually provides better coverage but requires careful credential protection.
• Web-application scanning examines application behaviour, input handling, session management, and common web weaknesses.
• Configuration assessment compares settings with an approved baseline or benchmark.

Scanning should be gradual and monitored. High request rates can overload services, trigger defensive systems, or create operational disruption. Test results should include timestamps, scanner configuration, target scope, evidence, and any limitations.

2.4 Validation and analysis

Scanner output is not automatically truth. Analysts should validate important findings using reliable evidence, such as version information, configuration data, vendor advisories, patch status, or controlled manual checks. Validation must not involve unsafe exploitation unless that activity is explicitly authorised.

2.5 Reporting and remediation

A useful report identifies the affected asset, finding, evidence, consequence, severity, business impact, recommended treatment, owner, and due date. Findings should be grouped where this helps decision-making, but the report must retain enough detail for technical teams to act.

Possible treatments include remediation, mitigation, risk transfer, risk acceptance, or system retirement. Risk acceptance should be explicit, time-limited where possible, approved by an accountable owner, and accompanied by compensating controls.

2.6 Retesting and closure

A finding is not closed merely because a ticket was marked complete. Retesting should verify that the weakness has been corrected and that the correction has not introduced another problem. Closure evidence may include a new scan, configuration comparison, patch verification, or a successful controlled test.

3. Interpreting Scanner Findings

A scanner finding generally contains a title, affected asset, technical description, severity score, evidence, references, remediation advice, and confidence or detection method. Analysts must read beyond the headline.

Severity and scoring

Many products use the Common Vulnerability Scoring System (CVSS). A CVSS score is intended to describe technical severity using factors such as attack vector, attack complexity, privileges required, user interaction, and effects on confidentiality, integrity, and availability. It is not a complete organisational risk score.

A high CVSS score does not automatically mean “fix first.” Business context, exposure, exploit availability, asset importance, compensating controls, and regulatory obligations must also be considered.

False positives and false negatives

A false positive occurs when a tool reports a weakness that is not actually present. Causes include inaccurate version detection, backported vendor patches, unusual configurations, or a vulnerable component that is not reachable in the reported way.

A false negative occurs when a real weakness is not detected. Causes include incomplete coverage, unsupported technologies, encrypted traffic, access restrictions, incorrect credentials, or signatures that do not recognise a new attack method.

A mature process records scanner limitations and uses multiple evidence sources. Credentialed scans, configuration review, application testing, secure code review, and manual analysis may complement one another.

Evidence quality

A finding is stronger when it includes reproducible evidence, a clearly affected component, a reliable reference, and a logical explanation of impact. Analysts should avoid overstating conclusions. For example, “the server exposes an outdated service version associated with a known vulnerability” is more accurate than claiming “the server has been compromised.”

4. Prioritising Remediation

Prioritisation combines technical information with business context. A practical decision model considers:

• severity and exploitability;
• whether the asset is internet-facing;
• business criticality;
• sensitivity of the data;
• evidence of exploitation in the environment;
• availability of a safe patch or workaround;
• regulatory or contractual obligations;
• ease of detection and recovery;
• dependencies and operational constraints.

A simple qualitative matrix can classify findings as critical, high, medium, or low. However, organisations should define the meaning of each category and apply it consistently.

One illustrative prioritisation model is:

This formula is only appropriate when each factor is assigned a defined, comparable scale. For example, an organisation might use values from 1 to 5 for each factor. The resulting number is a prioritisation aid, not an objective measurement of risk. The factors must not be multiplied if their scales are undefined or if the organisation treats them as merely descriptive labels.

Worked example

Suppose three findings are assessed using four factors, each rated from 1 to 5:

For Finding A, 4 × 5 × 4 × 4 = 320. Finding C has a lower technical severity but a substantial priority because the asset is business-critical. Finding B should still be corrected, but it is less urgent. This example assumes that all factors use the same defined 1–5 scale and that multiplication is an agreed organisational method.

Remediation service levels

An organisation may set target times such as immediate action for actively exploited critical weaknesses, short-term action for high-risk internet-facing systems, and scheduled treatment for lower-risk internal findings. These times should reflect operational reality and contractual commitments. A service-level target is not a substitute for judgement.

5. Logging and Security Monitoring

A log is a recorded event generated by a device, application, service, identity system, or security control. Typical events include authentication attempts, account changes, process execution, network connections, administrative actions, policy violations, and system errors.

Logs support several purposes:

• detecting suspicious activity;
• investigating incidents;
• reconstructing timelines;
• demonstrating compliance;
• troubleshooting failures;
• measuring control effectiveness.

Important log properties include accurate timestamps, a consistent time zone, source identification, event context, integrity protection, access control, retention, and useful detail. Network Time Protocol or another controlled time-synchronisation method is essential because investigators must correlate events from multiple systems.

Logging everything is not automatically effective. Excessive low-value data can increase cost and alert fatigue. Logging too little can make an incident impossible to investigate. Organisations should define a logging policy based on risk and legal requirements.

Sensitive values such as passwords, authentication tokens, private keys, and unnecessary personal data should not be written to logs. Logs themselves may contain confidential information and must be protected accordingly.

6. SIEM and the Security-Operations Workflow

A Security Information and Event Management (SIEM) platform collects, normalises, stores, searches, correlates, and presents security-relevant events. It may receive data from firewalls, identity providers, endpoints, cloud services, applications, vulnerability scanners, and threat-intelligence feeds.

A simplified security-operations workflow is:

Collect → Normalise → Correlate → Alert → Triage → Investigate → Respond → Learn

Collection gathers events. Normalisation converts different formats into a consistent structure. Correlation links related events, such as a suspicious login followed by privilege escalation and unusual data transfer. Alerting identifies activity that deserves attention. Triage determines urgency and credibility. Investigation develops an evidence-based understanding. Response contains and removes the threat. Learning improves controls, detection rules, and procedures.

A SIEM is not a replacement for skilled analysts. Poor data quality, missing logs, badly tuned rules, and insufficient context can produce either excessive alerts or dangerous silence.

Alert triage

A basic triage process asks:

1. Is the alert technically valid?
2. Which account, host, application, or data is involved?
3. Is the activity expected or authorised?
4. What evidence indicates compromise?
5. What is the potential business impact?
6. What containment action is safe and proportionate?

Analysts should record decisions, evidence, escalation, and follow-up actions. This supports consistency and later review.

7. Threat Intelligence

Threat intelligence is processed information about threats that supports decisions. It differs from raw data. An IP address, domain name, malware hash, or vulnerability identifier is an indicator; intelligence adds context such as reliability, target relevance, observed behaviour, confidence, and recommended action.

Threat intelligence is commonly discussed at several levels:

• Strategic intelligence: trends, adversary objectives, and business implications for leaders.
• Operational intelligence: campaigns, targeting patterns, and likely attack plans.
• Tactical intelligence: techniques, tactics, and procedures used by adversaries.
• Technical intelligence: indicators such as hashes, domains, addresses, and signatures.

Indicators have limitations. A malicious IP address can be reassigned, a hash changes when malware is modified, and legitimate cloud infrastructure may be shared by many users. Indicators should therefore be used with context and not treated as proof by themselves.

Threat modelling complements threat intelligence by asking what can go wrong in a particular system. Frameworks such as STRIDE help analysts consider spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Frameworks are prompts for structured thinking, not guarantees of completeness.

8. Vulnerability Assessment and Penetration Testing

Vulnerability assessment is primarily concerned with identifying and evaluating weaknesses across a defined scope. Penetration testing is a controlled attempt to demonstrate whether selected weaknesses can be exploited and what access or impact could result.

Penetration testing requires a detailed statement of work and rules of engagement. These should specify:

• written authorisation and system ownership;
• scope and exclusions;
• test dates and time windows;
• permitted techniques;
• prohibited actions;
• treatment of credentials and personal data;
• communication and emergency contacts;
• evidence storage and reporting;
• stop conditions;
• requirements for data deletion.

Testing must not include uncontrolled denial-of-service activity, destructive actions, persistence mechanisms, unauthorised lateral movement, or access to unrelated third-party systems. If a tester discovers sensitive information, the tester should record the minimum necessary evidence, avoid unnecessary copying, notify the authorised contact, and protect the material.

Responsible testing follows the principle of least impact: achieve the testing objective with the smallest reasonable risk to availability, confidentiality, and integrity.

9. Applied Case: Riverside Community Clinic

This is an illustrative fictional case.

Background

Riverside Community Clinic operates a public appointment portal, an internal electronic health-record system, staff laptops, wireless networks, and a small cloud environment. The clinic has two IT employees and uses an external provider for some services.

Problem

A routine authorised assessment identifies an outdated public web component, several laptops missing security updates, excessive privileges for a shared administrative account, and incomplete logging from the cloud environment. The scanner reports 86 findings.

Analysis

The IT team first removes duplicate findings and validates high-priority results. The public web component is confirmed to be affected and is reachable from the internet. The shared account is not directly associated with a scanner “critical” score, but it can access sensitive patient information and has no individual accountability. The missing cloud logs reduce the clinic’s ability to detect unauthorised access.

The team classifies assets by business impact. Patient records and appointment services are high-criticality assets. A laptop used only for reception has lower technical importance, although it still requires protection because it may provide a route into internal systems.

Approach and solution

The clinic takes the following actions:

1. It obtains a maintenance window and updates or isolates the vulnerable public component.
2. It disables the shared administrative account and creates named accounts with least privilege and multifactor authentication.
3. It establishes an emergency patch process for internet-facing systems.
4. It enables appropriate identity, administrative, and cloud-access logs.
5. It forwards selected logs to a managed SIEM service.
6. It creates an incident escalation procedure and tests it using a tabletop exercise.
7. It retests the public service and samples the remediated laptops.
8. It records lower-risk findings in a dated remediation plan with accountable owners.

Outcome

The number of open findings decreases, but the more important improvement is risk reduction: the exposed weakness is treated, privileged activity becomes attributable, and investigators gain better visibility. The clinic retains a small number of accepted risks, each approved by management with compensating controls and review dates.

Learning points

The case demonstrates that severity scores alone do not determine priority. Identity accountability, data sensitivity, exposure, detection capability, and operational context are equally important. It also shows that vulnerability management and security operations reinforce one another: scanning identifies weaknesses, while logging and monitoring help detect exploitation.

10. Governance, Ethics, and Regulatory Considerations

Cybersecurity work must comply with applicable computer-misuse, privacy, data-protection, employment, telecommunications, and contractual laws. Requirements differ between jurisdictions, so professionals must seek organisational and legal guidance when needed.

Core governance practices include:

• written authorisation;
• clear ownership and accountability;
• data minimisation;
• secure handling of assessment evidence;
• separation of duties where appropriate;
• documented risk acceptance;
• retention and deletion rules;
• supplier and cloud-provider agreements;
• regular review of procedures.

Ethical practice requires honesty about evidence and limitations. A professional must not claim that a system is secure merely because a scan found no issue. “No findings detected” is not equivalent to “no vulnerabilities exist.”

11. Challenges and Limitations

Vulnerability assessment and security operations face several persistent challenges:

• Asset drift: systems change faster than inventories are updated.
• Cloud complexity: responsibility is divided between provider and customer.
• Legacy technology: old systems may be difficult or unsafe to scan.
• Alert fatigue: excessive low-quality alerts reduce analyst attention.
• Incomplete telemetry: missing logs create blind spots.
• Patch disruption: maintenance may affect availability or compatibility.
• Third-party dependence: suppliers may control important infrastructure.
• Measurement difficulties: counting findings does not directly measure risk reduction.
• Adversary adaptation: attackers change techniques and evade static controls.

Artificial intelligence may assist with log summarisation, anomaly detection, prioritisation, and analyst workflow. However, AI-generated conclusions require human validation. Models can inherit data bias, misunderstand context, generate false explanations, or expose sensitive information through inappropriate data handling. AI should support, not replace, authorised governance and professional judgement.

12. Best-Practice Checklist

A practical programme should:

• maintain an accurate asset inventory;
• define scope and obtain written approval before assessment;
• scan regularly and after significant changes;
• use authenticated assessment where safe and appropriate;
• validate important findings;
• prioritise with both technical and business context;
• assign owners and deadlines;
• protect credentials and assessment evidence;
• centralise and time-synchronise important logs;
• tune SIEM alerts and review false positives;
• use threat intelligence with confidence and context;
• test incident-response procedures;
• retest remediation;
• document accepted risks and review them;
• prohibit destructive or unauthorised testing.

Chapter Summary

Vulnerability assessment is a structured, authorised process for discovering and evaluating weaknesses. Its value depends on accurate scope, appropriate scanning, validation, meaningful reporting, remediation, and retesting. Technical severity is important, but business impact, exposure, asset criticality, exploit evidence, and regulatory obligations determine practical priority.

Security operations transform technical events into defensive action. Logs provide evidence; monitoring identifies unusual behaviour; SIEM platforms correlate events and support triage; threat intelligence adds context about adversaries and indicators. These capabilities are strongest when connected to incident response and continuous improvement.

Penetration testing is distinct from routine vulnerability assessment and requires explicit authorisation, defined boundaries, safety controls, and responsible evidence handling. Ethical cybersecurity work protects systems while producing honest, proportionate, and useful conclusions.

Key Terms

Vulnerability: A weakness that could be exploited or cause harm.

Threat: A potential cause of an undesirable event.

Exploit: A method or action that takes advantage of a vulnerability.

Risk: The possibility of harm arising from a threat exploiting a vulnerability.

Asset: A system, service, data set, device, or capability requiring protection.

Vulnerability assessment: A systematic process of identifying and evaluating weaknesses.

Authenticated scan: An assessment performed with approved credentials.

Unauthenticated scan: An assessment conducted without internal credentials.

False positive: A reported finding that is not actually present.

False negative: A real weakness that an assessment fails to identify.

CVSS: A framework for describing the technical severity of software vulnerabilities.

Remediation: Corrective action that removes or reduces a weakness.

Compensating control: An alternative safeguard that reduces risk when the preferred control is unavailable.

Log: A recorded event generated by a system or service.

SIEM: A platform that collects, correlates, stores, and analyses security events.

Threat intelligence: Contextualised information about threats that supports decisions.

Triage: The process of assessing alert credibility, urgency, and required action.

Penetration testing: Authorised controlled testing of whether weaknesses can be exploited.

Risk acceptance: A formal decision to retain a known risk under defined conditions.

Review Questions

Short Answer Questions

1. Distinguish a vulnerability, a threat, and an exploit.
2. Why is written authorisation required before scanning?
3. What is the difference between a false positive and a false negative?
4. State two purposes of security logs.
5. Why should CVSS severity not be used as the only remediation priority?

Long Answer Questions

1. Explain the lifecycle of a vulnerability assessment from preparation through retesting.
2. Describe how a SIEM supports security operations and identify two limitations.
3. Compare authenticated and unauthenticated scanning, including advantages and risks.
4. Explain the ethical and operational boundaries of authorised penetration testing.
5. Discuss how threat intelligence can improve monitoring and incident response.

Analytical / Application Questions

1. An internet-facing server has a medium-severity vulnerability, while an isolated test server has a critical-severity vulnerability. Explain which factors should determine remediation order.
2. A company receives 10,000 SIEM alerts each day, most of which are false positives. Analyse likely causes and recommend a practical improvement plan.
3. Design a high-level assessment and remediation plan for a small clinic that operates a public web portal, staff laptops, cloud services, and sensitive personal data.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a vulnerability from an exploit?

A. A vulnerability is a weakness; an exploit is a method that takes advantage of it.

B. A vulnerability is always an attack; an exploit is always a security control.

C. A vulnerability is business impact; an exploit is asset ownership.

D. A vulnerability is a log entry; an exploit is a SIEM platform.

Correct Answer: A. A vulnerability is a weakness; an exploit is a method that takes advantage of it.

Question 2

What is the primary purpose of written authorisation before scanning?

A. To guarantee that no findings will be discovered

B. To establish legal permission, scope, and operating boundaries

C. To increase the scanner’s network speed

D. To remove the need for remediation

Correct Answer: B. To establish legal permission, scope, and operating boundaries

Question 3

Which scan generally provides better visibility into installed patches and local configuration?

A. Unauthenticated scanning

B. Authenticated scanning

C. Passive DNS collection only

D. Public search-engine analysis only

Correct Answer: B. Authenticated scanning

Question 4

A scanner reports a vulnerable version, but the vendor has backported the security fix without changing the version number. What is the most likely issue?

A. False negative

B. Data destruction

C. False positive

D. Threat intelligence poisoning

Correct Answer: C. False positive

Question 5

Using the illustrative model Priority = Severity × Exposure × Asset\ Criticality × Exploit\ Evidence, what is the priority value when the four ratings are 3, 4, 5, and 2?

A. 60

B. 90

C. 120

D. 140

Correct Answer: C. 120

Question 6

Which function is most characteristic of a SIEM?

A. Manufacturing replacement hardware

B. Collecting and correlating security events

C. Guaranteeing that every vulnerability is patched automatically

D. Replacing all incident-response procedures

Correct Answer: B. Collecting and correlating security events

Question 7

Why should an IP address from a threat-intelligence feed not be treated as conclusive proof of compromise?

A. Indicators can change, be shared, or require contextual validation.

B. IP addresses are never recorded in logs.

C. Threat intelligence applies only to physical security.

D. Every IP address is permanently assigned to one attacker.

Correct Answer: A. Indicators can change, be shared, or require contextual validation.

Question 8

Which action is outside responsible penetration-testing practice unless explicitly and safely authorised?

A. Documenting the agreed scope

B. Using a test account supplied by the client

C. Performing uncontrolled destructive denial-of-service activity

D. Reporting evidence to the authorised contact

Correct Answer: C. Performing uncontrolled destructive denial-of-service activity

Question 9

What is the main purpose of retesting after remediation?

A. To verify that the weakness was corrected

B. To increase the original severity score

C. To delete all historical reports

D. To avoid assigning an owner

Correct Answer: A. To verify that the weakness was corrected

Question 10

Which factor is most directly related to the business impact of a vulnerability?

A. The colour of the scanner interface

B. The sensitivity and criticality of the affected asset

C. The number of pages in the report

D. The brand of the analyst’s computer

Correct Answer: B. The sensitivity and criticality of the affected asset