Migrating Workloads To Azure

Guide

Guide

Tenable Nessus

Author: Platform and Security Engineering

Illustration for Tenable Nessus
Nessus Server Build in Azure - Design Document

Document Control

  • **Author:** Platform and Security Engineering
  • **Date:** 2026-08-07
  • **Status:** Draft for review
  • **Target Environment:** Azure (Production)

---

1. Purpose

This document defines the target design for deploying a new Nessus vulnerability scanning server in Azure. The goal is to provide a secure, supportable, and scalable scanning platform for internal infrastructure and approved external endpoints.

---

2. Scope

In Scope

  • One new Nessus server deployed on Azure IaaS
  • Network, identity, security, backup, monitoring, and operational design
  • Build and implementation steps
  • Acceptance criteria and handover requirements

Out of Scope

  • Enterprise SIEM use-case design (only integration hooks are covered)
  • Full CMDB and asset onboarding strategy
  • Scan policy authoring for every business application

---

3. Assumptions and Constraints

  • Azure subscription and landing zone are already available.
  • Connectivity to target networks exists (VNet peering/ER/VPN as required).
  • Licensing for Nessus is available before go-live.
  • Security team owns scan policy approvals and maintenance windows.
  • Server will be private-access only (no direct internet UI exposure).

---

4. High-Level Requirements

Functional Requirements

  1. Host Nessus web UI/API for authenticated administrators.
  2. Perform scheduled authenticated and unauthenticated scans.
  3. Export reports and integrate with downstream reporting workflows.
  4. Preserve configuration and scan history via backup.

Non-Functional Requirements

  1. High security baseline and least-privilege access.
  2. 99.9%+ service availability objective.
  3. RPO <= 24 hours and RTO <= 4 hours.
  4. Operational observability for service health, security, and performance.

---

5. Target Architecture

5.1 Logical Components

  • **Nessus VM**: Primary scanner and web/API endpoint
  • **Azure VNet/Subnet**: Dedicated security-tooling subnet
  • **NSG**: Strict inbound/outbound control
  • **Azure Key Vault**: Secrets/certificates (if required)
  • **Azure Monitor + Log Analytics**: Metrics, logs, alerting
  • **Recovery Services Vault**: VM backup and restore points
  • **Bastion or Jump Host**: Controlled admin access path

5.2 Deployment Pattern

  • Single VM design for phase 1.
  • Regional deployment in primary Azure region.
  • Zonal pinning optional; if regional risk posture requires, deploy to an Availability Zone.

---

6. Network and Access Design

6.1 Subnet Placement

  • Deploy in dedicated subnet: `snet-security-tools`.
  • Apply subnet NSG and (if used by standards) route table controls.

6.2 Inbound Rules (Minimum)

  1. Allow `TCP/8834` from approved admin source ranges only.
  2. Allow `TCP/3389` (Windows) only from Bastion/Jump subnet.
  3. Deny all other inbound traffic.

6.3 Outbound Rules (Minimum)

  1. Allow outbound HTTPS to Tenable plugin/update and licensing endpoints.
  2. Allow outbound traffic to approved scan target ranges and required service ports.
  3. Allow outbound DNS/NTP to approved internal or Azure resolver services.
  4. Allow outbound Windows update path (WSUS or Microsoft Update, based on enterprise policy).
  5. Deny all other outbound traffic by default.

6.3.1 Outbound Firewall Allow-List (Windows Nessus VM)

| Priority | Destination | Protocol/Port | Purpose | | --- | --- | --- | --- | | 100 | Internal DNS servers or Azure DNS resolver | UDP/TCP 53 | Name resolution | | 110 | Internal NTP servers | UDP 123 | Time sync | | 120 | Tenable update endpoints (vendor published FQDN list; include `plugins.nessus.org`) | TCP 443 | Plugin feed updates | | 130 | Tenable licensing and registration endpoints (vendor published FQDN list) | TCP 443 | License validation and service registration | | 140 | WSUS servers (preferred) | TCP 8530 or 8531 | Windows patching via enterprise update path | | 150 | Microsoft Update endpoints (only if WSUS not used) | TCP 80 and 443 | Windows patching from Microsoft | | 160 | Approved scan targets (CIDR/FQDN groups) | TCP/UDP as required | Vulnerability scan traffic |

Implementation notes:

  • Use FQDN-based firewall objects for Tenable endpoints and keep them synced with vendor documentation.
  • Keep scan target ports in separate rule groups by environment (prod, non-prod, shared services).
  • Do not allow unrestricted outbound internet from the Nessus subnet.
  • If forced tunneling is used, validate SSL inspection exceptions for Tenable update traffic.

6.4 Access Model

  • Administrator access through Bastion or approved jump host only.
  • No public IP on the Nessus VM NIC.
  • Use Azure RBAC for platform actions and local Nessus roles for scanner administration.

---

7. Compute and Storage Sizing

7.1 Recommended Initial VM Profile

  • **OS:** Windows Server 2022 Datacenter: Azure Edition (Gen2), Desktop Experience
  • **Size (starting point):** 8 vCPU / 32 GB RAM class (example: `Standard_D8as_v5`)
  • **OS Disk:** Premium SSD, 128 GB+
  • **Data Disk:** Premium SSD, 256 GB+ for plugin/cache/report growth

7.1.1 Sizing by Target Estate

| Estate Size | Suggested VM | CPU/RAM | Notes | | --- | --- | --- | --- | | Up to 500 assets, light authenticated scanning | `d4` | 4 vCPU / 16 GB | Suitable for pilot and low-concurrency schedules | | 500 to 2,000 assets, mixed authenticated scanning | `Standard_D8as_v5` | 8 vCPU / 32 GB | Recommended production starting point | | 2,000+ assets or tight scan windows | `Standard_D16as_v5` | 16 vCPU / 64 GB | Use when high parallel scan concurrency is required |

7.2 Sizing Notes

  • Right-size based on target count, scan concurrency, plugin volume, and scan frequency.
  • For large authenticated estates, scale to 16 vCPU / 64 GB RAM if scan windows are tight.
  • Keep 25% free disk headroom at all times.

7.3 Windows Prerequisites and Roles

Required position:

  1. Build as a standard Windows member server for Nessus only.
  2. Join domain only if required by enterprise policy for identity, patching, and management.

Windows Server roles:

  1. No additional Windows Server roles are required for Nessus operation.
  2. Do not install AD DS, DNS Server, DHCP Server, IIS, WSUS, or File Server roles unless separately approved for another workload.

Optional features (only when needed):

  1. SNMP service/tools if the scanner host must perform SNMP-based validation workflows.
  2. RSAT tools only when operationally required; preferred location is privileged admin workstations, not the scanner server.

Operational controls:

  1. Keep the host single-purpose and avoid collocating other management workloads.
  2. Enforce least privilege for local administrators and service accounts.
  3. Validate RDP restriction to Bastion/jump subnet and deny all other management paths.

---

8. Security Baseline

8.1 Host Hardening

  1. Apply CIS-aligned OS hardening baseline.
  2. Disable password SSH/RDP where possible; enforce key/certificate or MFA path.
  3. Restrict local admin rights and use named admin accounts.
  4. Enforce automatic security updates and reboot policy.

8.2 Secrets and Certificates

  1. Store integration secrets in Key Vault when external integrations are used.
  2. Use internal PKI or approved CA certificate for Nessus HTTPS UI.
  3. Rotate credentials and certificates per policy.

8.3 Endpoint and Threat Protection

  1. Enable Microsoft Defender for Servers plan as per subscription policy.
  2. Enable file integrity/EDR capabilities as required.
  3. Send security logs to central Log Analytics/SIEM.

---

9. Backup, Recovery, and Resilience

9.1 Backup

  • Protect VM with daily Azure Backup.
  • Retention baseline: 30 daily, 12 monthly (adjust to policy).
  • Include periodic application-level export of critical Nessus configuration/report artifacts.

9.2 Recovery Targets

  • **RPO:** <= 24 hours
  • **RTO:** <= 4 hours

9.3 Recovery Approach

  1. Restore VM from Recovery Services Vault to isolated recovery subnet.
  2. Validate Nessus service health and plugin state.
  3. Re-point DNS/management access once verified.

9.4 Resilience Option

  • For stricter availability needs, evaluate:
  • Zone-pinned VM and tested zone failover process.
  • Secondary cold-standby Nessus node in paired region with documented activation runbook.

---

10. Monitoring and Alerting

10.1 Platform Monitoring

  • CPU, memory, disk latency, disk free %, network throughput
  • VM availability and agent heartbeat

10.2 Service Monitoring

  • Nessus service process status
  • Certificate expiry monitoring
  • Backup job success/failure
  • Failed admin login attempts

10.3 Alert Routing

  • Route critical alerts to SOC/on-call channel.
  • Route operational warnings to platform operations queue.

---

11. Implementation Plan

Phase 1 - Foundation

  1. Confirm region, subnet, NSG, DNS, and route dependencies.
  2. Confirm licensing and approved outbound endpoints.
  3. Confirm access path (Bastion/jump host).

Phase 2 - Build

  1. Deploy VM from hardened base image.
  2. Apply OS patching and hardening baseline.
  3. Install Nessus and register license.
  4. Bind approved TLS certificate.

Phase 3 - Integrate

  1. Connect monitoring and backup.
  2. Configure scan repositories, schedules, and credential vaulting.
  3. Validate outbound plugin feed and scan target reachability.

Phase 4 - Validate and Handover

  1. Execute connectivity, security, and performance checks.
  2. Run pilot scans against representative targets.
  3. Complete restore test and evidence capture.
  4. Handover runbook, support model, and operational ownership.

---

12. Acceptance Criteria

  1. Nessus UI reachable only from approved admin paths.
  2. Plugin updates succeed and are schedulable.
  3. Test authenticated and unauthenticated scans complete successfully.
  4. Backups succeed and one restore test is evidenced.
  5. Critical monitoring and alerting are active.
  6. Security sign-off and operational handover completed.

---

13. Risks and Mitigations

| Risk | Impact | Mitigation | | --- | --- | --- | | Outbound endpoint restrictions block plugin updates | Scanner becomes stale | Pre-approve Tenable endpoints and validate in pre-prod | | Overly broad scan windows impact target systems | Service degradation on targets | Controlled scan schedules and rate limiting by policy | | Single-VM failure impacts scanning availability | Temporary loss of service | Daily backup, documented restore, optional standby design | | Credential sprawl for authenticated scans | Security exposure | Central secret handling and rotation policy |

---

14. Open Decisions

  1. Final VM size based on expected target count and scan SLA.
  2. Whether zone pinning is mandatory in this environment.
  3. Whether SIEM integration is required at day 1 or phase 2.
  4. Whether Windows updates will be sourced via WSUS only or with controlled Microsoft Update fallback.

---

15. Handover Artifacts

  • Build record (image, size, network, NSG, backup policy)
  • Security baseline evidence
  • Nessus configuration export and admin guide
  • Monitoring and alert rule inventory
  • Recovery runbook and tested restore evidence

---

16. Summary

This design delivers a secure and operationally supportable Nessus deployment in Azure with clear controls for access, resilience, monitoring, and recovery. The solution is intentionally phased to enable rapid delivery while preserving a path to higher resilience and scale as scanning demand grows.

Summary

Practical guidance about Tenable Nessus.