Vulnerability Assessment and Management Questions

Definition — credentialed vs non-credentialed

• Credentialed (authenticated) scan: scanner logs into target systems using supplied accounts/privileges to assess configuration, installed software, missing patches and user-level vulnerabilities.
• Non-credentialed (unauthenticated) scan: scanner probes services and externally visible weaknesses without logging in—simulates an external attacker with no valid credentials.

Three advantages of credentialed scans

• Deeper visibility: finds missing patches, weak configs, and insecure services only visible after login (e.g., outdated DLLs, weak permissions).
• Lower false positives: verifies vulnerability presence by reading system files/registries rather than inferring from banners.
• Better prioritization: produces asset-level risk data (installed CVEs, user rights) so I can focus remediation on high-impact issues.

Two risks / downsides

• Risk of disruption: privileged checks or agents can cause performance issues or trigger system instability.
• Credential management & exposure: storing/use of credentials increases attack surface; compromised scan account could be abused.

When to use non-credentialed scanning

• External perimeter testing to simulate an Internet attacker
• Environments where credentials can’t be shared (third-party systems) or where scanning access is restricted
• Quick discovery of publicly exposed services before deeper internal assessment

I’d choose a mix: non-credentialed for external threat emulation and credentialed for thorough internal vulnerability prioritization.

Brief approach

• Parse Nessus XML, canonicalize findings (host, plugin id, port, severity, vuln id), deduplicate by key.
• For idempotent JIRA creation, store / query a ticket mapping (custom field or external DB) and use a deterministic external_id (hash of canonical key) in JIRA issue property.
• Handle API rate limits with exponential backoff + respect Retry-After header; implement retries with jitter.

Pseudocode / Python sketch

import xml.etree.ElementTree as ET
import hashlib, time, requests, json, sqlite3, random

# DB to map external_id -> jira_key
conn = sqlite3.connect('jira_map.db')
conn.execute('CREATE TABLE IF NOT EXISTS map(external_id TEXT PRIMARY KEY, jira_key TEXT)')

def parse_nessus(path):
    root = ET.parse(path).getroot()
    findings = {}
    for report in root.findall('.//ReportHost'):
        host = report.get('name')
        for item in report.findall('.//ReportItem'):
            key = (host, item.get('pluginID'), item.get('port'), item.get('severity'))
            ext_id = hashlib.sha256('|'.join(map(str,key)).encode()).hexdigest()
            findings[ext_id] = {'host':host, 'plugin':item.get('pluginID'), 'port':item.get('port'),
                                'severity':item.get('severity'), 'desc': item.findtext('description') or ''}
    return findings.values()

def jira_request(method, url, **kwargs):
    max_retries=5
    backoff=1
    for attempt in range(max_retries):
        resp = requests.request(method, url, **kwargs)
        if resp.status_code == 429:
            wait = int(resp.headers.get('Retry-After', backoff)) + random.random()
            time.sleep(wait)
            backoff *= 2
            continue
        if 500 <= resp.status_code < 600:
            time.sleep(backoff + random.random()); backoff *= 2; continue
        return resp
    raise Exception('jira api failed')

def find_existing_ticket_by_external_id(ext_id):
    # prefer local DB for speed
    r = conn.execute('SELECT jira_key FROM map WHERE external_id=?', (ext_id,)).fetchone()
    if r: return r[0]
    # fallback: search JIRA via JQL on issueProperty or custom field
    jql = f'issue.property["vuln_ext_id"] = "{ext_id}"'
    resp = jira_request('GET', JIRA_URL + '/search', params={'jql':jql}, auth=AUTH).json()
    issues = resp.get('issues', [])
    if issues:
        key = issues[0]['key']
        conn.execute('INSERT OR REPLACE INTO map VALUES (?,?)', (ext_id,key)); conn.commit()
        return key
    return None

def create_issue_for(finding):
    ext_id = hashlib.sha256('|'.join([finding['host'], finding['plugin'], finding['port'], finding['severity']]).encode()).hexdigest()
    existing = find_existing_ticket_by_external_id(ext_id)
    if existing: return existing
    payload = {'fields': {'project':{'key':'SEC'}, 'summary': f"Vuln {finding['plugin']} on {finding['host']}",
                          'description': finding['desc'], 'issuetype':{'name':'Bug'}}}
    resp = jira_request('POST', JIRA_URL + '/issue', json=payload, auth=AUTH)
    if resp.status_code == 201:
        key = resp.json()['key']
        # attach external id to issue properties for idempotency
        jira_request('PUT', JIRA_URL + f'/issue/{key}/properties/vuln_ext_id', json={'value':ext_id}, auth=AUTH)
        conn.execute('INSERT OR REPLACE INTO map VALUES (?,?)', (ext_id,key)); conn.commit()
        return key
    raise Exception('create failed')

# main
for f in parse_nessus('scan.nessus'):
    create_issue_for(f)

Complexity & notes

• Deduplication uses hash map; memory ~ O(n findings).
• Use local DB to avoid repeated JIRA queries.
• Ensure JIRA credentials scoped; sanitize descriptions; mark severity mappings.
• Consider batching, rate-limit headers, and monitoring for long runs.

Asset Discovery

• Activity: Build/update an authoritative asset inventory (IP, hostname, OS, owner).
• Tool: Nmap (network discovery) — I run regular network sweeps and reconcile with CMDB.

Scanning

• Activity: Schedule authenticated and unauthenticated vulnerability scans.
• Tool: Nessus — scan policies for OS, apps, and credentials to improve coverage.

Manual Verification

• Activity: Validate exploitability of high-risk findings via targeted manual checks.
• Tool: Burp Suite / manual SSH checks — confirm whether patches or compensating controls truly mitigate risk.

False-Positive Reduction

• Activity: Correlate scan results with asset context and patch levels to suppress false alerts.
• Tool: Qualys / Tenable + enrichment from CMDB — mark verified vs. noise.

Contextual Analysis & Prioritization

• Activity: Rank vulnerabilities by CVSS, asset criticality, exposure, and threat intel.
• Tool: RiskSense or a SIEM (Splunk) with threat feeds — prioritize remediation sprints.

Remediation

• Activity: Coordinate patching or configuration changes with owners; create change tickets.
• Tool: SCCM/Intune or ticketing system (Jira) — deploy hotfixes and track progress.

Remediation Validation

• Activity: Re-scan and perform spot checks to confirm fixes.
• Tool: Nessus / automated post-change scans — verify absence and log evidence.

Continuous Monitoring

• Activity: Implement continuous scanning, alerting, and trend reporting.
• Tool: EDR (CrowdStrike) + SIEM (Splunk) — detect regressions and emerging vulnerabilities.

Situation & Goal
Maintain a single accurate vulnerability state per real-world asset despite scans running at different cadences and multiple identifiers (IP, hostname, asset tag, cloud instance ID).

Process (high-level)

1. Ingest vulnerability findings and asset records into a central store (Vuln DB + CMDB).
2. Normalize identifiers and enrich via authoritative sources (DHCP, AD, cloud APIs, asset management, network scans).
3. Apply deterministic canonicalization rules to link identifiers to a canonical asset ID.
4. Reconcile findings over time using timestamped state and business rules (priority to newest authoritative mapping).
5. Produce final asset-level vulnerability state and audit trail.

Technical Approach

• Canonical ID: create an immutable UUID per physical/logical asset in CMDB.
• Matching hierarchy (example): asset tag > cloud instance ID > MAC address > hostname > IP. Use weighted scoring for partial matches (e.g., hostname similarity + subnet).
• Enrichment: query cloud APIs (AWS/GCP/Azure), AD, DHCP, EDR, and ticketing to resolve conflicts.
• Time-window logic: maintain time-series of identifier-to-UUID mappings; when an identifier moves (e.g., DHCP IP reassigned), close prior mapping and open new with timestamps.
• Deduplication: merge vuln findings by CVE and canonical asset UUID; if multiple IPs map to same UUID, consolidate with most recent scan results per plugin severity.
• Confidence and overrides: attach confidence score; require manual review for low-confidence merges.

Example
A scan shows IP 10.0.1.5 with CVE-2021-1234. CMDB shows hostname A mapped to UUID-1, cloud API shows instance-id xyz mapped to UUID-1, DHCP shows IP->hostname A within last hour → map vulnerability to UUID-1. If later 10.0.1.5 maps to different UUID, keep prior record time-bound and flag for review.

Automation & Tools

• Use ETL (Kafka), graph DB (Neo4j) or relational CMDB, enrichment microservices, and SIEM/Orchestration playbooks for alerts and manual workflows.
• Log full provenance and expose APIs for reporting and ticket creation.

Metrics & Controls

• Track reconciliation accuracy, % manual joins, time-to-canonicalize, and stale-identifier age. Regularly validate with asset inventory audits.

Context (brief): As an Information Security Analyst, I’d present five executive KPIs that balance risk reduction, responsiveness, and program efficiency.

1. Mean Time to Remediate (MTTR)
   Formula:

MTTR = Sum( Time to remediate each vulnerability ) / Count( remediated vulnerabilities )

Target: <= 30 days (critical <= 7 days)
Why: Measures responsiveness to fix exploitable issues; short MTTR lowers exposure window.
Chart: Line chart (trend) with drill-down by severity (stacked area for severities).

2. Remediation Rate (Perc. closed on time)
   Formula:

Remediation Rate = Count( vulnerabilities remediated within SLA ) / Count( vulnerabilities assigned ) * 100%

Target: >= 90% (overall), 95% for critical
Why: Shows operational effectiveness against SLAs.
Chart: KPI gauge + bar by severity.

3. Percent of Assets with Critical Vulnerabilities
   Formula:

%AssetsCritical = Count( assets with >=1 critical vuln ) / Total asset count * 100%

Target: <= 5%
Why: Focuses on exposure breadth across estate.
Chart: Heatmap by business unit or stacked bar.

4. Time to Patch Availability (Detection-to-Patch)
   Formula:

Detection-to-Patch = Median( time from vulnerability disclosure/scan detection to available patch ) 

Target: <= 14 days for critical
Why: Identifies external dependency delays and patch backlog.
Chart: Boxplot (distribution) + trend line.

5. Reopened/Recurring Vulnerability Rate
   Formula:

Recurring Rate = Count( vulnerabilities re-opened or re-detected within 90 days ) / Count( closed vulnerabilities ) * 100%

Target: <= 3%
Why: Indicates quality of fixes and root-cause resolution.
Chart: Bar trend with drill to root-cause categories.

I’d include severity filters, business-unit breakdowns, and SLA overlays so leadership sees both trend and risk impact.