Here is a structured, revision‑friendly set of notes for your course.

URL: https://localhost:8834/

1. Nessus Overview

• Nessus is a widely used vulnerability scanner for cybersecurity professionals, network engineers, and system administrators.
• It scans network devices and compares them against a large database of known vulnerabilities so you can remediate issues before attackers exploit them.
• Course goals: install and configure Nessus, run scans, and interpret results to improve security.

What You Need to Know

• Designed for users new to Nessus; no prior vulnerability scanning experience required.
• Helpful background: basic system administration, IP addresses, ports, and port scanning (e.g., Nmap).
• Nessus scans build on the idea of port scanning to discover services and vulnerabilities.

Nessus Editions

• Nessus began as open source in 1998; moved to closed source and commercial licensing in 2005.
• Editions:
  • Nessus Essentials: free, used in this course, limited to 16 IPs.
  • Nessus Professional / Expert: paid, per‑scanner licensing, for larger environments.
• Tenable ecosystem: Tenable Security Center / Security Center Plus (central dashboards), Tenable Vulnerability Management (cloud‑based).

2. Installing and Accessing Nessus

Installing Nessus on Linux (Ubuntu example)

• Supported: Ubuntu, RHEL, FreeBSD, SUSE, Fedora, Debian, Raspberry Pi, Amazon Linux, etc.
• Steps (Ubuntu):
  • Download Nessus installer from Tenable website (requires name, email, license acceptance).
  • Copy installer to server.
  • Install with sudo dpkg -i <package-name> (exact name may vary by version/architecture).
  • Start service: sudo systemctl start nessusd.service.
• After installation, configuration continues via web console (same for Linux and Windows).

Installing Nessus on Windows

• Download Windows installer from Tenable download page, accept license, run standard wizard.
• Use default installation path unless you have specific needs.
• After setup completes, installer opens the web console to confirm it’s running.
• Configure the Windows firewall:
  • Create inbound rule for TCP port 8834 to allow access to the Nessus web interface.
  • In production, restrict source IPs to authorized admin systems only.

Accessing the Nessus Console

• Use a browser: https://<server-ip>:8834.
• Self‑signed TLS certificate will trigger a warning; in production, use a trusted CA or internal PKI certificate.
• Initial setup workflow:
  • Choose edition (e.g., Nessus Essentials).
  • Provide name and email to obtain activation code (or paste existing activation code).
  • Create Nessus user account (username and password).
  • Nessus downloads plugins and completes setup (10–20 minutes).

3. Vulnerability Management Fundamentals

What Is Vulnerability Management?

• Modern systems have millions of lines of code; complexity guarantees bugs and vulnerabilities.
• Vendors respond by issuing patches; admins must apply patches across OSs, apps, devices, and libraries.
• A mature vulnerability management program includes:
  • Regular scanning for vulnerabilities.
  • Patch application.
  • Tracking remediation status.
  • Reporting results.

Common Drivers for Vulnerability Programs

• Improve security (primary purpose).
• Corporate policy mandates (may dictate tools, deadlines, reporting formats).
• External regulation:
  • PCI DSS (for credit card data):
    • Quarterly internal and external scans.
    • New scans after significant changes.
    • Use Approved Scanning Vendor (ASV) for external scans.
    • Remediate and rescan until no significant vulnerabilities remain.
  • FISMA (US gov):
    • Follow NIST SP 800‑53 controls.
    • Regularly scan systems/apps, analyze results, remediate, and share vulnerability info across agencies.

Types of Vulnerability Tests

• Network vulnerability scans: probe devices and services across the network.
• Application scans: test the code of applications for flaws.
• Web application scans: focus on web‑specific issues like SQL injection and XSS.
• Complement scans with configuration reviews and log analysis to detect false positives and context.

4. Building a Vulnerability Management Program

Identifying Scan Targets (Asset Inventory)

• Start from program requirements (security goals, compliance, corporate policy).
• Use a trusted asset inventory:
  • Configuration management tools with up‑to‑date system lists.
  • If missing, use a light network discovery scan (not a full vulnerability scan) to find hosts.
• Example with Nessus host discovery:
  • Create “Host Discovery” scan.
  • Enter targets (hostnames, IPs, ranges).
  • Run scan and review discovered hosts and open ports.
  • Use results as input to detailed vulnerability scans.

Prioritizing Assets

For each asset, evaluate:

1. Impact (if breached):
   • Highest data classification on the system (public, internal, sensitive, highly sensitive).
2. Likelihood of attack (exposure):
   • Public vs internal network location.
   • Firewall rules and externally exposed services (web, DNS, DB, etc.).
3. Operational criticality:
   • How much business disruption if the system is unavailable?

• Many orgs scan “everything,” but still need criticality ratings to prioritize remediation.

Choosing Scan Frequency

Key constraints and considerations:

• Compliance / policy:
  • PCI DSS: at least quarterly, plus after significant changes.
  • Internal security policies may specify frequencies.
• Risk appetite:
  • How long is acceptable to remain unaware of new vulnerabilities, especially on high‑impact systems?
• Technical constraints:
  • Number and capacity of scanners.
  • Network bandwidth and performance impact.
• Business constraints:
  • Avoid scanning during critical business windows.
• Licensing:
  • Limits on simultaneous scans, IP counts, bandwidth, etc.

Nessus scheduling example:

• Set scan from “On Demand” to “Weekly,” choose day/time (e.g., Tuesdays at 11:30).
• Align scan completion with analysts’ review schedules to keep data fresh.

Continuous monitoring:

• Scanner continuously rotates through assets as resources permit.
• Higher bandwidth/CPU cost but faster detection of new vulnerabilities.

5. Configuring Nessus Scans

Creating a Scan (Advanced Scan Template)

• Use New Scan → Advanced Scan for full control.
• General settings:
  • Name and optional description.
  • Targets: hostnames, IPs, ranges (e.g., 172.30.0.0/24 for 255 IPs).
  • Optionally upload a target file exported from an asset management system.

Organizing Scans

• Group systems with similar scanning schedules (e.g., by data sensitivity: confidential, sensitive, highly sensitive).
• Create separate scans per group to apply different frequencies and settings.

Schedule & Notifications

• Schedule tab: enable schedule (daily, weekly, etc.).
• Notifications tab: send email reports when a scan finishes.

Discovery Options

• Configure how Nessus detects live hosts: types of pings and how to handle fragile devices (printers, legacy systems).

Port Scanning

• Set ports and protocols to scan.
• Default: all commonly used ports; add custom ports if needed.

Assessment (Accuracy and Sensitivity)

• Normal accuracy (default) balances false positives vs missed vulnerabilities.
• Options:
  • “Show potential false alarms”: more sensitive, more false positives.
  • “Avoid potential false alarms”: more conservative, risk missing some issues.

Advanced Settings

• Enable safe checks (default): avoid potentially disruptive tests in production.
• Performance and behavior options:
  • Stop scanning unresponsive hosts.
  • Randomize IP scan order.
  • Auto‑accept SSH disclaimers.
  • Parallel scans for hosts with multiple domain names.
  • Generate unique IDs for credentialed hosts.

Plugins

• Nessus uses plugins to test specific vulnerabilities; plugins are grouped by system/application type.
• You can enable only relevant plugins to speed up scans.
• Save custom settings as templates to reuse across scans.

6. Scan Perspective and Credentials

Scan Perspective (Location of Scanner)

• Results depend heavily on scanner location relative to targets:

  • Same screened subnet as web server:
    • Minimal firewall interference, most complete visibility.
  • Internal network:
    • Traffic passes through firewall; some malicious probes may be filtered.
  • Internet:
    • Strict inbound firewall rules; shows external attacker’s realistic view of exposed vulnerabilities.

• All perspectives are valid; use multiple perspectives to see both full internal risk and attacker view.

Agent‑Based vs Credentialed Scans

• Agent‑based scans:

  • Install local agents on servers; agents collect deep configuration data and report back.
  • Pros: rich insight; cons: operational overhead and complexity.

• Credentialed scans:

  • Scanner uses credentials (SSH on Linux, Windows credentials/AD domain) to log in and gather data.
  • Configured in the Credentials tab per scan.

• Best practice: mix perspectives (internal, external, credentialed, agent‑based) for a complete picture.

7. Scanner Maintenance and User Management

Updating Nessus

• Two types of updates:
  • Engine updates: scanner software updates (bug fixes, new features), less frequent.
  • Plugin/feeds updates: new vulnerability checks; should be updated very frequently.
• Nessus settings:
  • Configure automatic updates: all components, plugins only, or disable.
  • Default: update all plugins daily (recommended).

Managing Users and Permissions

• If licensed for multiple users:
  • Create user accounts with role‑based permissions (read‑only vs scan operators).
  • Restrict which networks/systems each user can see and scan.
• Goal: enforce least privilege on scanner usage and visibility.

8. Reporting and Communication

Audiences for Scan Reports

Different stakeholders need different levels of detail:

• Cybersecurity team:
  • Full technical details per vulnerability and host, remediation guidance.
• Management:
  • High‑level risk overview, top vulnerabilities, trends, and remediation timelines.
• System/network engineers:
  • Device‑specific issues and clear remediation steps; scope limited to systems they own.
• Application developers:
  • Application vulnerabilities (e.g., SQL injection, XSS), location in code, and specific examples.

Reporting with Nessus

• From a completed scan, generate reports using templates (e.g., vulnerabilities by host, HTML format).
• Report structure:
  • Summary of vulnerabilities per severity and host.
  • Drill‑down into per‑host issues and plugin details (including remediation advice).

Distributing Reports

• Options:
  • Direct access to Nessus console for power users.
  • Automated or manual email distribution after scans, weekly, or on demand.
• Tailor distribution to audience preferences and information needs.

9. Prioritizing and Remediating Vulnerabilities

Factors for Remediation Priority

Use five main factors:

1. System criticality: importance of the system’s business function.
2. Data sensitivity: confidentiality impact (e.g., credit card or SSNs vs test data).
3. Vulnerability severity:
   • Nessus severity levels: Informational, Low, Medium, High, Critical.
   • Critical often implies full compromise potential; fix as soon as possible.
4. Remediation difficulty: quick configuration change vs deep redesign or major upgrade.
5. Exposure:
   • Internet‑facing vs internal, remote exploit vs requiring local access.

• Prioritization is partly science (standard criteria) and partly analyst judgment.

Building a Remediation Workflow

Typical workflow:

1. Scan detects a new vulnerability.
2. Assign to a cybersecurity analyst:
   • Validate the finding and rule out false positives.
   • Prioritize based on the five factors.
3. Remediation phase:
   • System engineers apply patches, network engineers update firewall rules, developers fix code, etc.
   • Follow change control, testing, and sandbox processes.
4. Validation phase:
   • Analyst re‑scans to confirm remediation.
   • If still present, investigate more; otherwise, close the issue.

Tooling considerations:

• Some scanners include basic workflow, but many organizations integrate with existing IT ticketing systems (incident management).
• Automation opportunities:
  • Automatic ticket creation for vulnerabilities above thresholds.
  • Auto‑assignment based on host or system owner.
  • Automatic re‑scans and auto‑closure of tickets when vulnerabilities disappear.

10. SCAP and CVSS

SCAP (Security Content Automation Protocol)

Purpose: standardize language and formats for security information to enable automation.

Core components:

• CVSS – Common Vulnerability Scoring System, numeric severity scoring.
• CCE – Common Configuration Enumeration, standardized configuration identifiers.
• CPE – Common Platform Enumeration, standardized product names/versions.
• CVE – Common Vulnerabilities and Exposures, standardized vulnerability IDs.
• XCCDF – Extensible Configuration Checklist Description Format, for checklists and results.
• OVAL – Open Vulnerability Assessment Language, for programmatic test descriptions.

CVSS Metrics (Version 4.0 Example)

Exploitability metrics:

• Attack Vector (AV): Physical, Local, Adjacent Network, Network.
• Attack Complexity (AC): High, Low.
• Attack Requirements (AT): Present, None.
• Privileges Required (PR): High, Low, None.
• User Interaction (UI): Active, Passive, None.

Impact metrics (CIA triad):

• Confidentiality (C): None, Low, High.

• Integrity (I): None, Partial, Complete.

• Availability (A): None, Partial, Complete.

• Separate metrics for vulnerable system (VC, VI, VA) and subsequent systems (SC, SI, SA).

Interpreting a CVSS Vector and Score

Example: outdated SSL protocol on a server.

• AV:N (Network), AC:L (Low), AT:N (None), PR:N (None), UI:N (None).
• High confidentiality impact; no integrity or availability impact.
• Enter values into CVSS calculator → base score 9.2.

NIST Severity Mapping:

• 0.0 → None.
• 0.1–3.9 → Low.
• 4.0–6.9 → Medium.
• 7.0–8.9 → High.
• 9.0–10.0 → Critical.

Calculator:

Common Vulnerability Scoring System Version 4.0 Calculator

11. Analyzing and Correlating Scan Results

Validating Findings

Before escalating remediation:

• Confirm that the vulnerability truly exists (review scanner input/output detail).
• Check version information and compare to vendor advisories.
• Watch for obvious mismatches (e.g., Windows server reported missing macOS patch).
• Account for exceptions: accepted risks, compensating controls; record them in the scanner or CMDB.

Result types:

• True positive, false positive, true negative, false negative.

Avoiding “Crying Wolf”

• Excessive false positives reduce trust from engineers/developers.
• Analysts must carefully vet high‑impact findings to maintain credibility.

Correlating Results

Three correlation dimensions:

1. Standards/compliance (e.g., PCI DSS guidance that external scans must not contain CVSS ≥ 4.0 items).
2. Internal technical data (CMDB, logs, configuration repositories).
3. Historical trends across scans (recurring issues, patterns).

• Trend dashboards (e.g., Tenable Security Center) help identify systemic issues (such as recurring XSS in new apps).

12. Common Vulnerability Categories

Server Vulnerabilities

Frequent issues:

• Out‑of‑date software / missing patches (OS, apps, firmware).
• Unsupported OS versions – vendors no longer issue patches; avoid in production.
• Buffer overflows – improper memory handling, often fixed via patches.
• Privilege escalation – vulnerabilities enabling user → admin escalation.
• Insecure protocols (cleartext communications).
• Debug/verbose error modes enabled on production servers exposing sensitive info.

Example: a scan shows many critical/high Apache vulnerabilities; root cause is a single out‑of‑date web server package, fixed by applying OS updates.

Endpoint Vulnerabilities

Similar to servers but with extra constraints:

• Missing security patches and outdated AV signatures.
• Users delaying or cancelling updates (e.g., to avoid reboots).
• Users installing unmanaged software, increasing patching complexity.
• Endpoints include laptops, desktops, smartphones, tablets, IoT, etc.

Network Vulnerabilities

Key areas:

• SSL/TLS issues:
  • Use of SSL (insecure) or old TLS versions; require TLS 1.2 or, preferably, 1.3.
  • Insecure cipher suites; configure servers to allow only strong ciphers.
  • Certificate problems: self‑signed, expired, wrong hostnames, non‑trusted CAs.
• VPN vulnerabilities: enforce strong encryption and patch appliances.
• DNS vulnerabilities: patch DNS servers, especially internet‑facing ones.
• Interconnected networks (partners, cloud): understand their security posture and use firewalls to limit exposure.

13. Web Application Vulnerabilities

SQL Injection and Defenses

How it works:

• Application builds SQL queries using user input (e.g., username/password) in a WHERE clause.
• Attacker injects SQL into input (using quotes, semicolons, comments) to alter the query and change data (e.g., reset passwords).

Defenses:

• Server‑side input validation: reject dangerous characters (e.g., single quotes) and enforce expected formats.
• Parameterized queries / stored procedures: pre‑defined SQL where user input is treated strictly as data, not executable code.
• Avoid client‑side only validation (easy to bypass).

Cross‑Site Scripting (XSS)

Concept:

• Attacker injects malicious script into a trusted site; script runs in other users’ browsers.
• Often occurs when a site echoes user input (posts, comments) as HTML without sanitization.

Defenses:

• Strict input validation and output encoding, especially blocking <script> tags in user‑supplied content.
• Treat any HTML from users as untrusted, sanitize thoroughly.

Cross‑Site Request Forgery (CSRF/XSRF)

Concept:

• Exploits the fact that auth cookies are shared across tabs.
• A malicious site causes the browser to send authenticated requests to another site (e.g., bank transfer) without user awareness, often via hidden image tags or similar mechanisms.

Defenses:

• Use per‑request cryptographic anti‑CSRF tokens.
• Avoid using HTTP GET for state‑changing actions.
• Enforce session timeouts and encourage logging out.

Server‑Side Request Forgery (SSRF)

• Variant of request forgery where server is tricked into making unauthorized requests (often based on tampered metadata).

Directory Traversal

Concept and example:

• File requests use patterns like ../ to traverse up directories and access unintended files.
• Demo: attacker modifies requested filename to climb up directories and read sensitive config files (e.g., tomcat-users.xml).

Defenses:

• Input validation to block . navigation (e.g., .. segments) in file paths.
• Strong file system permissions restricting web server user access to non‑sensitive areas.

Buffer / Integer Overflow in Web Context

• Overly long input that isn’t checked spills into other memory or logic.
• Example: extremely long “room number” field reveals other hotel guests’ info.
• Defense: server‑side input validation for length and format.

Code Execution Attacks

• Exploit vulnerabilities in exposed services (e.g., web servers, SMB) to run arbitrary code on the host.
• If the vulnerable process runs with admin rights, attacker gains full control.

Defenses:

• Run services with least privilege accounts.
• Keep OS and applications fully patched (e.g., patches for SMB remote code execution).

Privilege Escalation

• Using vulnerabilities to elevate from normal user to admin (often after initial code execution or overflow).

Mitigations:

• Input validation for all user input.
• Patch OS, platforms, and apps.
• Enforce least privilege for service accounts.
• Use DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization).

Race Condition Vulnerabilities (TOCTOU)

• Security depends on timing between Time of Check and Time of Use.
• Example: two ATMs checking account balance before either withdraws, allowing overdraft.

Mitigation:

• Use locking and concurrency controls so operations on shared resources are serialized safely.

OWASP Top Ten (2021)

OWASP top 10 categories:

1. Broken access control.
2. Cryptographic failures.
3. Injection.
4. Insecure design.
5. Security misconfiguration.
6. Vulnerable and outdated components.
7. Identification and authentication failures.
8. Software and data integrity failures.
9. Security logging and monitoring failures.
10. Server‑side request forgery (SSRF).

Other best‑practice resources: SANS Top 25, CIS Benchmarks.

14. Next Steps and Practice

• Get hands‑on: run Nessus Essentials in a lab or permitted environment (e.g., home network) to practice installs, scan configuration, and report analysis.
• Examine common vulnerabilities in your own devices (routers, IoT, endpoints) and walk through prioritization and remediation workflows using the criteria above.

If you want, I can now turn this into a one‑page cram sheet (keywords and bullet summaries only) or a set of Q&A flashcards for rapid revision.