NISP Level 1 - Security Operations: Vulnerability Management

This domain tests whether you can turn a scanner report into a defensible remediation plan. It separates discovery, prioritisation and verification, and expects you to know the scoring systems and their limits.

Process

1. Inventory assets and assign business criticality (data class, exposure, dependency).
2. Scan - authenticated scans give far better coverage than unauthenticated ones; schedule to avoid production impact; include containers, cloud services and network devices.
3. Validate findings and separate false positives from real issues.
4. Prioritise using severity, exploitability, exposure and business impact together.
5. Remediate by patch, upgrade, configuration change, compensating control, or documented acceptance.
6. Verify by rescan and close the ticket; track exceptions with an owner and an expiry date.

Scoring and intelligence

CVSS v3.1 base score (0–10) uses attack vector, complexity, privileges required, user interaction, scope and CIA impacts. It measures severity, not organisational risk: a 9.8 on an isolated test box can matter less than a 7.5 on an internet-facing payment server. EPSS estimates the probability of exploitation in the wild, and the CISA KEV list identifies vulnerabilities known to be exploited - those jump the queue. CVSS 4.0 adds threat and environmental metric groups.

Scanning versus testing

Vulnerability scanning is broad, automated and recurring. Penetration testing is targeted, manual, time-boxed and validates exploit chains; it complements rather than replaces scanning. Responsible disclosure and bug bounty programmes give external researchers a channel. Never test without written authorisation and a defined scope.

Worked example

Two findings: CVSS 9.8 on an internal build server with no internet route, and CVSS 7.2 on the internet-facing VPN concentrator that appears in KEV. The VPN is fixed first - known exploitation plus exposure outweighs the nominal score. The build server is patched in the next cycle, with a temporary network rule as a compensating control.

Traps

• Sorting by CVSS alone and ignoring exposure and known exploitation.
• Assuming an unauthenticated scan found everything.
• Closing a ticket without a verification rescan.
• Leaving risk acceptances open-ended with no owner or expiry.

Risk Assessment and Security Auditing

This domain tests structured risk thinking and the discipline of evidence-based audit. Expect terminology questions plus at least one simple quantitative calculation.

Risk fundamentals

Risk combines the probability of an event with its consequence. Qualitatively, use likelihood × impact matrices. Quantitatively:

• SLE = Asset Value × Exposure Factor.
• ALE = SLE × Annualised Rate of Occurrence.
• A control is justified when its annual cost is below the ALE reduction it delivers.

Treatment options are mitigate, transfer, avoid and accept (documented, owned, with a review date). Inherent risk is measured before controls; residual risk is what remains after them.

Controls and frameworks

Controls are preventive, detective or corrective, and administrative, technical or physical. Frameworks: ISO 31000 for risk principles, ISO 27005 for information-security risk, and the NIST RMF (prepare, categorise, select, implement, assess, authorise, monitor). Threat modelling with STRIDE - spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege - connects design decisions to risk.

Audit

Audit types: first-party (internal), second-party (supplier or customer), third-party (independent certification body). Independence is essential: an auditor must not audit work they performed. Evidence comes from interview, observation, document review and sampling. Findings are graded as major nonconformity, minor nonconformity, or observation/opportunity for improvement. A report states objective evidence, not opinion, and assigns corrective actions with owners and dates.

Worked example

A server room asset is worth ¥2,000,000 and a flood would destroy 40% of it, so SLE = ¥800,000. Floods occur roughly once in 20 years, so ARO = 0.05 and ALE = ¥40,000 per year. A flood barrier costing ¥30,000 per year is justified. One costing ¥60,000 is not, unless it also reduces other risks or regulatory exposure.

Traps

• Confusing inherent and residual risk.
• Treating a vulnerability scan output as an audit.
• Using a return period directly as a probability without converting it (1 in 20 years = 0.05).
• Writing findings as opinions with no objective evidence attached.

Business Continuity

This domain tests continuity planning: how an organisation keeps critical services running during disruption and how it recovers afterwards. Distinguish the continuity plan from the disaster recovery plan and know the time-based metrics precisely.

BIA and the time metrics

A Business Impact Analysis identifies critical processes, their dependencies (people, systems, suppliers, facilities) and the impact of downtime as time passes. From it come:

• RTO - target time to restore a service after disruption.
• RPO - maximum acceptable data loss expressed as time, which drives backup and replication frequency.
• MTD/MAO - maximum tolerable downtime before unacceptable harm; RTO must be shorter than MTD.
• WRT - work recovery time, the part of MTD reserved for verification and catch-up.

BCP and DRP

The BCP is business-owned and covers people, premises, suppliers and communications as well as IT. The DRP is the technical recovery plan for systems and data: alternate sites (hot, warm, cold), failover sequence, dependency order and recovery runbooks. Crisis management covers command structure, escalation and communication with regulators and customers.

Testing and standards

Plans decay silently if they are never tested. Test types, from low to high impact: document review, tabletop exercise, simulation, component test, full failover. Each test produces findings and corrective actions. ISO 22301 expects exercising at planned intervals and management review of results.

Worked example

An online payment service has an MTD of 6 hours and can tolerate 15 minutes of lost transactions. That sets RTO ≤ 4 hours, leaving 2 hours of WRT for verification and reconciliation, and RPO ≤ 15 minutes. Nightly tape backup cannot meet the RPO; continuous asynchronous replication to a warm standby site can, supported by a documented failover runbook and a semi-annual failover test.

Traps

• Swapping RTO and RPO.
• Assuming a hot site removes the need for runbooks and trained staff.
• Writing a plan only IT knows about, with no business sign-off.
• Treating a tabletop exercise as proof that technical failover works.

Backup and Disaster Recovery

This domain narrows to data protection and technical recovery: backup design, restore confidence and disaster recovery arrangements for infrastructure.

Backup fundamentals

• Full - everything copied; slow, simplest restore.
• Incremental - changes since the last backup of any type; small and fast, but restore needs the full chain.
• Differential - changes since the last full; restore needs the full plus the latest differential.
• Snapshots are point-in-time copies on the same storage: fast, but not a backup, because they die with the array and replicate deletions.

The 3-2-1 rule: three copies, on two media types, one offsite. Modern practice extends it to 3-2-1-1-0: one copy offline or immutable, and zero errors verified by restore testing. Encrypt backups, protect backup credentials, and use immutability or air gaps against ransomware, which targets backup infrastructure early.

DR arrangements

Replication is synchronous (zero data loss, distance-limited) or asynchronous (small RPO, unlimited distance). DR tiers run from backup-and-restore through pilot light and warm standby to active-active. Every failover needs a documented and tested failback. DR testing ranges from restoring a sample to a full site switchover.

Worked example

A database needs RPO 15 minutes and RTO 2 hours. Nightly full backups plus hourly log shipping to a second site meet the RPO; automated provisioning of the standby database and application servers meets the RTO. Prove it by restoring a random table from last month and by performing a full failover twice a year - the restore test is what shows the backup is usable.

Traps

• Treating RAID or replication as a backup; both faithfully replicate corruption and deletion.
• Never testing restores, leaving the backup an untested hypothesis.
• Keeping the only copy online and domain-joined, where ransomware can encrypt it.
• Forgetting configuration files and encryption keys, so restored data cannot be opened.