--- title: "Security Tools" description: "Built-in security scanning and vulnerability management tools for PCI DSS compliance validation." version: "en" --- > Documentation Index > Fetch the complete documentation index at: https://docs.kliper.dev/llms.txt > Use this file to discover all available pages before exploring further. # Security Tools Kliper includes a suite of integrated security tools — grouped into **Assessment Tools** and **Threat Intelligence** — that let assessors validate technical controls directly from the assessment workbench. Each tool targets a specific PCI DSS requirement, produces structured findings, and can auto-fill assessment answers with a single click. | Tool | PCI Requirement | Purpose | |---|---|---| | **Port & Service Scanner** | 1.2.1 | Scan targets with nmap or import XML results to inventory open ports and services | | **SSL/TLS Checker** | 4.2.1 | Validate certificate grades, protocols, and cipher suites | | **CVE Lookup + EPSS** | 6.3 | Search the NVD for known vulnerabilities with exploit probability scores | | **ASV Scan Import** | 11.3.2 | Upload and parse Qualys/Tenable/Rapid7 scan results | | **Patch Management** | 6.3.3 | Upload WSUS/SCCM/Qualys CSV reports to verify patch compliance | | **Log Audit Validator** | 10.2 | Upload log samples to verify required audit trail fields are present | | **Access Review** | 7.2.1, 7.2.5, 8.6.1 | Upload AD/Azure AD/AWS IAM exports to detect access control issues | | **Pen Test Parser** | 11.4 | Upload and parse Burp Suite, Nessus, or ZAP reports | | **Headers & DNS** | 2.2.5 | Check HTTP security headers and DNS records | | **Payment Page Script Monitor** | 11.6.1 | Live-scan payment pages or import script inventories to verify SRI and CSP controls | | **Firewall Rule Analyzer** | 1.2.5, 1.3.1, 1.3.2 | Upload firewall rule exports to detect any-any rules, deprecated protocols, and overly broad CIDRs | | **Password Policy Analyzer** | 8.3.6, 8.3.7, 8.3.9 | Upload AD GPO, Azure AD, AWS IAM, or CSV policy exports and check against PCI password requirements | | **CISA KEV Tracker** | 6.3, 11.3 | Track CISA Known Exploited Vulnerabilities catalog with search, ransomware filter, and vendor breakdown | | **Secret Scanner** | 6.2, 6.3 | Scan public Git repositories for leaked secrets, API keys, and credentials using Gitleaks | | **Credential Leak Monitor** | 8.3, 8.6 | Check domains and companies against the Have I Been Pwned breach database | | **Threat Briefing** | 6.3, 11.3 | Aggregated threat intelligence from NVD, CISA KEV, EPSS, and HIBP sources | | **Anti-Malware Deployment Checker** | 5.2.1, 5.3.1, 5.3.2 | Upload endpoint protection reports to verify agent deployment, signature freshness, and real-time protection | | **FIM Report Parser** | 11.5.1, 11.5.2 | Upload file integrity monitoring reports to identify unauthorized changes to critical system files | | **Cloud Posture** | — | Cloud security posture review *(Enterprise placeholder — not yet available)* | | **Dark Web OSINT** | — | Dark-web exposure monitoring *(Enterprise placeholder — not yet available)* | | **Remediation Dashboard** | — | Aggregated view of all findings across all tools | > **Note** > > **Available in your language.** The entire Security Tools interface — tool names, upload panels, filters, table headers, and empty states — follows your [language preference](/operations/personal-settings#language) in English, French, Spanish, and German. > > Scan **output** stays in English by design: findings, CVE descriptions, and vendor or protocol names (Qualys, Nessus, TLS 1.2, Heartbleed) are quoted verbatim from the source so they match the evidence you attach to a requirement. ## Accessing Security Tools There are two ways to reach the tools, depending on how you want to work. ### From the workspace (global page) Open **Security Tools** in the main sidebar to run scans across your whole workspace, independent of any single assessment. The page uses a **focused shell** — the sidebar becomes the tool list (Assessment Tools + Threat Intelligence) with a **Back to workspace** link, so you get one clean navigation column and the tool content fills the page. Scans you run here are **org-level**; attach a completed scan to a requirement on any assessment with **Link to requirement** (see [Linking scans to a requirement](#linking-scans-to-a-requirement)). ### From inside an assessment 1. **Open Your Assessment** Navigate to an assessment from the Engagement Hub or the Assessments page. 2. **Open the Security Tools Tab** In the assessment workbench, open the **Security** dropdown in the top navigation bar and select **Security Tools**. The panel opens with a sidebar listing the available tools, grouped into **Assessment Tools** and **Threat Intelligence**. 3. **Select a Tool** Click a tool in the left sidebar to switch between them. Each tool operates independently — results from one tool do not affect another. > **Tip** > > Use the **global page** as a scan factory — run and manage scans across all your clients in one place — and the **in-assessment tab** when you're actively working a requirement and want one-click apply. > **Note** > > **Enterprise placeholders.** Four tools — **Port Scanner**, **Headers & DNS**, **Cloud Posture**, and **Dark Web OSINT** — currently appear in the sidebar as **Enterprise** placeholders and are **not yet enabled for any plan**. Port Scanner and Headers & DNS are fully built (the walkthroughs below apply once they're turned on); Cloud Posture and Dark Web OSINT are reserved names without an implementation yet. Everything else is available on all paid plans. ## Linking scans to a requirement Each scan-based tool maps to a canonical PCI DSS requirement (the **PCI Requirement** column in the table above). Applying a completed scan attaches it to an assessment as evidence and **auto-fills that requirement's testing-procedure answer** with a structured justification — grade or findings summary, the scan target, and a compliant / non-compliant verdict. How you apply depends on where you're working: - **Inside an assessment** — a completed result shows an **Apply to Req X** button. One click applies it to that requirement on the assessment you're currently in. - **On the global page** — a completed result shows **Link to requirement**. This opens a picker where you choose the **client → assessment**; the target requirement is fixed per tool. The scan is then applied to that assessment. > **Note** > > Linking is enforced on the server. You can only apply a scan to an assessment **in your workspace that you have access to** — admins and managers can apply to any assessment; assessors and QA reviewers must be a collaborator on the target assessment. A scan can never cross into another organization. > **Tip** > > The requirement each tool applies to is fixed (for example, SSL/TLS always maps to **Req 4.2.1**). Run the scan once on the global page, then link it to the right assessment when you're ready — no need to re-run it per assessment. --- ## Choose from the evidence library Every file-parsing tool (Patch Management, ASV, FIM, Firewall, Access Review, Log Audit, Pen Test, and the rest) can source its input from a file **already in the platform** instead of a fresh local upload. Under the drop zone, click **or choose from evidence library**. 1. **Browse an assessment** The picker lists **every assessment in your workspace**. Open one to see its files, or search by filename. The list is filtered to the file types that tool accepts. 2. **Pick a file** Click a file. Its contents are pulled from storage and handed straight to the tool — no re-upload on your side. 3. **It imports in one step** Because a library file is one you've already decided to use, picking it **runs the import immediately** — the tool parses it and adds the result. (Most tools parse a fresh local upload the same way as soon as you choose it; **Pen Test** and **ASV** let you set test details first, then click **Upload & parse**.) > **Caution** > > The picker filters by file **extension**, not content — so make sure the file matches the tool. A patch-management CSV fed into the Pen Test tool will parse, but its rows won't be meaningful pen-test findings. Pick the file that belongs to the tool. > **Note** > > Because the picker browses **all** your assessments, it works the same on the global Security Tools page and inside an assessment — no current-assessment context is needed. Access is still workspace- and permission-scoped. --- ## Port & Service Scanner > **Caution** > > The Port & Service Scanner currently appears as an **Enterprise** placeholder and is not yet enabled. The walkthrough below describes its behavior once it's turned on. The Port & Service Scanner inventories open ports and running services on target hosts. It supports live nmap scanning directly from Kliper and importing existing nmap XML output files. ### Running a Live Scan 1. **Switch to Live Scan Mode** In the Port Scanner tab, ensure the **Live Scan** toggle is selected (default). 2. **Enter a Target** Type a target IP address, hostname, or CIDR range (e.g., `192.168.1.0/24`) in the input field. 3. **Click Start Scan** The scan runs server-side using nmap with service version detection (`-sV -sS --open`). Scans typically complete in 30–120 seconds depending on the target range. 4. **Review Results** The result card displays: | Field | Description | |---|---| | **Hosts** | Number of live hosts discovered | | **Open Ports** | Total number of open ports across all hosts | | **PCI Issues** | Count of risky ports/services flagged | | **PCI Compliance** | PASS or FAIL badge | Expand the card to see every open port with host, port number, protocol, service name, version, and risk level. 5. **Apply to Requirement** Click **Apply to Req 1.2.1** to auto-fill the assessment answer with a summary of open ports, risky services, and compliance status. ### Importing nmap XML Switch to the **Import XML** toggle, then select an nmap XML output file. The parser extracts the same host, port, service, and version data as a live scan. ### Risky Port Detection The scanner flags these commonly risky ports and services: | Port | Service | Risk | |---|---|---| | 21 | FTP | Unencrypted file transfer | | 23 | Telnet | Unencrypted remote access | | 445 | SMB | File sharing — common attack vector | | 3306 | MySQL | Database exposed externally | | 3389 | RDP | Remote desktop — brute force target | | 5432 | PostgreSQL | Database exposed externally | | 6379 | Redis | In-memory store — often unauthenticated | > **Caution** > > Live scans require nmap to be installed on the Kliper server. Only scan targets you are authorized to scan. Unauthorized port scanning may violate network policies or laws. --- ## Asset Discovery Asset Discovery finds the external-facing hosts on a domain and checks which ones still answer. You give it a root domain; it enumerates subdomains from public sources, resolves each, and probes it. The value is the hosts you did not know were there — a forgotten staging box, a marketing subdomain, a service someone stood up and never decommissioned. It supports **PCI DSS Requirement 11.3.1** (external vulnerability scanning of systems in scope) by surfacing scope you may have missed. ### Running a Discovery 1. **Enter a root domain** Type a bare domain such as `example.com` — no `https://`, no path. Subdomains are enumerated from public sources. 2. **Confirm authorization** Tick **"I confirm I own this target or have written permission to scan it."** The **Discover** button stays disabled until you do. 3. **Let it run** Discovery runs server-side and keeps running if you navigate away. When it finishes you get a toast with the host count, and the run appears in the list below. ### Reading the results Each discovered host carries one of three states: | State | Meaning | Why it matters | |---|---|---| | **Live** | Resolves and answers | In scope and reachable — confirm it belongs | | **Dangling** | DNS record exists, but nothing answers on the address | A subdomain-takeover risk: the name points somewhere you may no longer control | | **No DNS** | Enumerated but does not resolve | Historical or internal-only — usually informational | Dangling records are listed first: a name pointing at an address nobody answers on is the finding worth acting on, not the healthy hosts. --- ## Vulnerability Scanner The Vulnerability Scanner runs [nuclei](https://github.com/projectdiscovery/nuclei) against a URL — a large community template set that checks for known CVEs, exposed panels, misconfigurations, and default credentials. ### Running a Scan 1. **Enter a URL** A full URL including scheme, e.g. `https://example.com`. 2. **Confirm authorization** The same attestation as Asset Discovery gates the **Scan** button. 3. **Let it run** nuclei runs a large template set, so a scan takes **several minutes** and keeps running if you leave the page. Come back to the tool to see the result. ### Reading the results Findings split into two groups: - **Actionable** — findings with a severity worth triaging. - **Informational** — low-signal notices (technology fingerprints, present-but-benign headers). These are hidden behind a **"Hide informational findings"** toggle so the actionable set stands on its own. --- ## Scan authorization and scanner health The three tools that reach out and touch a live target — Asset Discovery, the Vulnerability Scanner, and the Port Scanner once enabled — share two guardrails. **Authorization attestation.** Before an active scan runs, you must tick **"I confirm I own this target or have written permission to scan it."** The run button is disabled until you do, and the box resets after each run. This is a deliberate friction point: active scanning of a target you do not control can violate network policy or law. **Scanner status banner.** Asset Discovery and the Vulnerability Scanner run on a dedicated scanning host. If that host is unreachable, a banner reads *"The scanning host is unreachable, so scans will fail until it is back. This is our infrastructure, not your target."* — so a failed scan is never mistaken for a problem with the site you are assessing. --- ## SSL/TLS Checker The SSL/TLS Checker validates a domain's certificate configuration and assigns a letter grade (A through F). It uses SSL Labs for detailed analysis with a direct TLS fallback when SSL Labs is unavailable. ### Running a Check 1. **Enter the Domain** Type the domain name (e.g., `example.com`) in the input field. Do not include `https://` — the checker adds it automatically. 2. **Click Run Check** The check runs server-side. SSL Labs analysis may take 30–60 seconds; if SSL Labs is overloaded, the system falls back to a direct TLS connection check that completes in under 5 seconds. 3. **Review Results** The result card displays: | Field | Description | |---|---| | **Grade** | Letter grade badge (A+, A, B, C, D, F) color-coded green through red | | **PCI Compliance** | PASS or FAIL badge — FAIL if grade is below B, TLS < 1.2, or weak ciphers detected | | **Certificate Issuer** | The certificate authority (e.g., Let's Encrypt, DigiCert) | | **Valid Until** | Certificate expiration date | | **Protocol** | Supported TLS versions | | **Cipher Suite** | Active cipher suites | | **PCI Issues** | Specific problems that affect PCI compliance (e.g., "TLS 1.0 enabled", "Weak cipher suites") | 4. **Apply to Requirement** Click **Apply to Req 4.2.1** to auto-fill the assessment answer with a structured summary of the check results, including grade, compliance status, and identified issues. ### Check History Previous checks are listed below the input form with the domain, grade, date, and PCI status. Expand any previous check to view its full results or re-apply it to the assessment. > **Note** > > SSL Labs results are cached by SSL Labs itself. If you need a fresh analysis, wait a few minutes between checks of the same domain. --- ## CVE Vulnerability Lookup The CVE Lookup tool searches the NIST National Vulnerability Database (NVD) for known vulnerabilities affecting a specific software product and version. Results are cached locally to reduce API calls and improve response times. ### Searching for Vulnerabilities 1. **Enter Product and Version** Type the software product name (e.g., `Apache HTTP Server`) and version (e.g., `2.4.49`) in the input fields. 2. **Click Search** The system queries the NVD API. Results typically return within 2–5 seconds, or instantly if the product/version combination has been searched before (cached for 7 days). 3. **Review CVEs** Each CVE result displays: | Field | Description | |---|---| | **CVE ID** | The unique identifier (e.g., CVE-2021-41773) | | **Severity** | Color-coded badge — Critical (red), High (orange), Medium (yellow), Low (blue) | | **CVSS Score** | Numerical score from 0.0 to 10.0 | | **Description** | Summary of the vulnerability | | **Published** | Date the CVE was published | 4. **Apply to Requirement** Click **Apply to Req 6.3** to auto-fill the assessment answer with a summary of discovered CVEs, including severity counts and CVSS scores. ### Lookup History All previous lookups are displayed below the search form with product, version, CVE count, and date. Expand any previous lookup to review its results or re-apply to the assessment. > **Tip** > > Good candidates for CVE lookup include web servers (Apache, Nginx), databases (MySQL, PostgreSQL), frameworks (Node.js, Spring), and libraries (OpenSSL, jQuery, Log4j). --- ## Patch Management The Patch Management tool parses CSV exports from patch management systems — WSUS, SCCM, Qualys, and generic formats — to verify that security patches are applied within PCI DSS timelines. ### Uploading a Patch Report 1. **Select the CSV File** Click **Upload CSV** and select a `.csv` file exported from your patch management tool. 2. **Automatic Vendor Detection** The system auto-detects the vendor format from CSV column headers: | Vendor | Detection Method | Key Columns | |---|---|---| | **WSUS** | `UpdateTitle` or `KBArticle` header | UpdateTitle, KBArticle, MsrcSeverity, ReleaseDate, Status | | **SCCM** | `CI_UniqueID` or `ComplianceState` header | Title, ArticleID, Severity, ComplianceState | | **Qualys** | `QID` and `Patch` headers | QID, Title, Severity, Status | | **Generic** | Fallback | Best-effort column matching for patch name, severity, status, dates | 3. **Review Results** The result card shows: | Field | Description | |---|---| | **Total Patches** | Number of patches in the report | | **Missing Critical** | Count of uninstalled critical patches | | **Missing High** | Count of uninstalled high-severity patches | | **Overdue (>30d)** | Patches not installed within 30 days of release | | **Vendor** | Detected patch management vendor | | **PCI Compliance** | PASS if no critical/high patches are overdue beyond 30 days | Expand the card to see every patch with name, KB article, severity, release date, install status, and days overdue. 4. **Apply to Requirement** Click **Apply to Req 6.3.3** to auto-fill the assessment answer with patch compliance status, missing patch counts, and overdue details. > **Note** > > PCI DSS Requirement 6.3.3 requires that critical and high-severity security patches be installed within one month of release. The tool flags any patch exceeding this 30-day threshold. --- ## Log Audit Validator The Log Audit Validator analyzes log samples to verify that all six PCI DSS Requirement 10.2 audit trail fields are present. It supports syslog (RFC 3164 and 5424), Windows Event XML, Windows Event CSV, JSON lines, and generic CSV formats. ### Uploading a Log Sample 1. **Select the Log File** Click **Upload Log File** and select a log file (`.log`, `.txt`, `.json`, `.csv`, or `.xml`). 2. **Automatic Format Detection** The system auto-detects the log format: | Format | Detection Method | |---|---| | **Syslog (RFC 3164)** | Lines starting with timestamp pattern `Mon DD HH:MM:SS` | | **Syslog (RFC 5424)** | Lines starting with `version` and ISO 8601 timestamps | | **Windows Event XML** | Contains `` or `` tags | | **Windows Event CSV** | CSV with `EventID` and `Source`/`Level` columns | | **JSON Lines** | Lines starting with `{` that parse as valid JSON | | **Generic CSV** | CSV with comma-separated values and a header row | 3. **Review Results** The result card shows a **field completeness score** (e.g., 5/6) and checks each of the six required PCI audit trail fields: | Required Field | PCI Reference | What It Looks For | |---|---|---| | **User Identification** | 10.2.1 | Username, UID, account name, actor | | **Event Type / Action** | 10.2.1 | Event ID, action, category, facility | | **Date and Time** | 10.2.1 | Timestamps in ISO 8601, syslog, or epoch format | | **Success / Failure** | 10.2.1 | Status codes, success/failure/denied keywords | | **Event Origination** | 10.2.1 | Source IP, client address, hostname | | **Affected Resource** | 10.2.1 | Target object, destination, file path, endpoint | Each field displays a **confidence level** (high, medium, low, or none) and sample values extracted from the log. 4. **Apply to Requirement** Click **Apply to Req 10.2** to auto-fill the assessment answer with the log format, field completeness, confidence levels, and compliance determination. > **Tip** > > Upload a representative sample of 50–500 log entries rather than full log archives. The validator samples up to 500 entries for analysis — larger files are parsed but only the first 500 entries are evaluated for field detection. --- ## Access Review The Access Review tool parses user account exports from identity providers to detect inactive accounts, shared/generic accounts, excessive privileges, and missing MFA — all key requirements under PCI DSS Requirements 7 and 8. ### Uploading a User Export 1. **Select the CSV File** Click **Upload CSV** and select a `.csv` file exported from your directory service or identity provider. 2. **Automatic Source Detection** The system auto-detects the identity provider: | Source | Detection Method | Key Columns | |---|---|---| | **Active Directory** | `SamAccountName` or `LastLogonDate` header | SamAccountName, Enabled, LastLogonDate, PasswordLastSet, MemberOf | | **Azure AD** | `UserPrincipalName` or `AccountEnabled` header | UserPrincipalName, AccountEnabled, LastSignInDateTime, AssignedRoles, MFAStatus | | **AWS IAM** | `arn` and `password_last_used` headers | user, arn, password_enabled, password_last_used, mfa_active | | **Generic** | Fallback | Best-effort column matching for username, status, last login, groups, MFA | 3. **Review Results** The result card shows summary statistics and a PCI compliance determination: | Metric | Description | |---|---| | **Total Accounts** | Number of user accounts in the export | | **Inactive (>90d)** | Enabled accounts with no login in over 90 days (violates Req 8.1.4) | | **Shared Accounts** | Generic/shared accounts like `admin`, `test`, `service` (violates Req 8.5) | | **Elevated Access** | Accounts with admin/privileged roles (review per Req 7.2.1) | | **No MFA** | Accounts without multi-factor authentication (violates Req 8.4.2) | Expand the card to see a detailed findings table with each flagged account, the finding type, risk level, last login date, MFA status, and admin status. 4. **Apply to Requirements** Click **Apply to Req 7.2 & 8.6** to auto-fill three assessment answers simultaneously: | Requirement | What Is Filled | |---|---| | **7.2.1** | Access privileges assigned based on job classification and function | | **7.2.5** | Access privileges reviewed at least semi-annually | | **8.6.1** | System or application accounts managed based on least privilege | ### Finding Types and Risk Levels | Finding | Risk Level | PCI Reference | |---|---|---| | **No MFA on admin account** | Critical | 8.4.2 | | **Inactive account (>90 days)** | High | 8.1.4 | | **Shared/generic account** | High | 8.5 | | **No MFA (non-admin)** | High | 8.4.2 | | **Excessive privilege** | Medium | 7.2.1 | | **Password expired (>90 days)** | Medium | 8.3.9 | > **Caution** > > The Access Review tool flags potential issues based on pattern matching (e.g., usernames matching "admin", "shared", "service"). Always verify flagged accounts manually — some service accounts may be legitimate and properly managed. --- ## ASV Scan Import The ASV Scan Import tool parses CSV exports from Approved Scanning Vendors — Qualys, Tenable (Nessus), and Rapid7 — and converts them into structured findings with PCI compliance determination. ### Uploading a Scan 1. **Fill In Scan Details** Enter the scan metadata: - **Scan Date** — when the scan was performed - **Quarter** — the PCI quarter this scan covers (e.g., Q1 2026) - **Vendor** — select Qualys, Tenable, Rapid7, or Generic (auto-detected if left as Auto) 2. **Select the CSV File** Click the file input to select a `.csv` file exported from your ASV scanning tool. 3. **Click Upload & Parse** The system detects the vendor format from the CSV column headers and parses each row into a normalized finding with host, port, severity, CVSS score, and remediation guidance. 4. **Review Results** The result card shows: - **PASS / FAIL** badge — FAIL if any finding has CVSS score >= 4.0 - **Host count** — number of unique hosts scanned - **Vulnerability count** — total number of findings - **Severity breakdown** — badge counts for Critical, High, Medium, Low, Info 5. **Apply to Requirement** Click **Apply to Req 11.3.2** to auto-fill the assessment answer with scan summary, compliance status, host count, and severity breakdown. ### Supported Vendor Formats | Vendor | Detection Method | Key Columns | |---|---|---| | **Qualys** | Column header contains `QID` | IP, DNS, QID, Title, Severity, CVSS, Port, Protocol, CVE ID, PCI Vuln | | **Tenable (Nessus)** | Column header contains `Plugin ID` | Plugin ID, CVE, CVSS, Risk, Host, Port, Name, Synopsis, Solution | | **Rapid7** | Column header contains `Vulnerability ID` | Vulnerability ID, Asset IP, Asset Names, Severity, CVSS Score, Title | | **Generic CSV** | Fallback format | Best-effort column matching — looks for host, port, severity, cvss, title, description | ### Managing Findings Expand a scan result to view all findings. Each finding row displays: - **Severity badge** — color-coded (Critical, High, Medium, Low, Info) - **Title** — vulnerability name - **Host and Port** — affected asset - **CVSS Score** — numerical risk score - **Remediation Status** — dropdown to mark as Open, In Progress, Fixed, or Accepted Risk - **False Positive** — toggle to flag false positives (excluded from compliance calculation) Use the severity filter dropdown to focus on specific severity levels. > **Caution** > > PCI DSS requires that all vulnerabilities with CVSS score 4.0 or higher are resolved for a passing ASV scan. Findings marked as False Positive are excluded from this calculation, but the assessor must document the justification. --- ## Penetration Test Parser The Pen Test Parser imports results from common penetration testing tools and normalizes findings into a unified format. It supports three major formats and a generic CSV fallback. ### Uploading Test Results 1. **Fill In Test Details** Enter the penetration test metadata: - **Test Type** — External, Internal, or Segmentation - **Test Date** — when the test was performed - **Tester Name** — the person or firm that conducted the test - **Tool** — select Burp Suite, Nessus, OWASP ZAP, or Generic (leave as Auto-detect for automatic format detection) 2. **Select the Report File** Click the file input to select an `.xml` or `.csv` file exported from the penetration testing tool. 3. **Click Upload & Parse** The system auto-detects the file format: | Format | Detection | |---|---| | **Burp Suite XML** | `.xml` file with `` root element | | **OWASP ZAP XML** | `.xml` file with `` root element | | **Nessus CSV** | `.csv` file with `Plugin ID` column header | | **Generic CSV** | `.csv` file — best-effort column matching | Findings are extracted and normalized with severity, confidence, host, port, CVE/CWE references, and remediation guidance. 4. **Review Results** The result card shows: - **PASS / FAIL** badge — FAIL if any Critical or High findings exist - **Tool detected** — which parser was used (Burp, Nessus, ZAP, Generic) - **Test type** — External, Internal, or Segmentation - **Severity breakdown** — badge counts for High, Medium, Low 5. **Apply to Requirement** Click **Apply to Req 11.4** to auto-fill the assessment answer. The auto-fill maps the test type to the correct sub-requirement: | Test Type | Target Sub-Requirement | |---|---| | External | 11.4.3 (External penetration testing) | | Internal | 11.4.2 (Internal penetration testing) | | Segmentation | 11.4.5 (Segmentation penetration testing) | ### Managing Findings Expand a result to view all findings with severity filter and pagination. Each finding displays: - **Severity badge** — High (orange), Medium (yellow), Low (blue) - **Title** — vulnerability name - **Host** — target URL or IP - **Confidence** — Certain, Firm, or Tentative - **Remediation Status** — dropdown to track fix progress - **Expandable detail** — full description and recommended remediation (click the finding row) > **Note** > > Informational findings are parsed and stored but excluded from the PASS/FAIL determination and severity badge counts. Only Critical, High, Medium, and Low findings affect compliance status. --- ## HTTP Header & DNS Checker > **Caution** > > The Header & DNS Checker currently appears as an **Enterprise** placeholder and is not yet enabled. The walkthrough below describes its behavior once it's turned on. The Header & DNS Checker validates HTTP security headers and DNS security records for a domain, assigning a letter grade (A through F) and identifying PCI-relevant configuration gaps. All checks run server-side using Node.js built-ins — no external API dependencies. ### Running a Check 1. **Enter the Domain** Type the domain name (e.g., `example.com`) in the input field. 2. **Click Run Check** The system performs two checks in parallel: 1. **HTTP headers** — makes an HTTPS request to the domain and evaluates the response headers 2. **DNS records** — queries DNS for SPF, DMARC, and CAA records 3. **Review Results** The result card displays a grade badge and a detailed checklist of all checks. 4. **Apply to Requirement** Click **Apply to Req 2.2.5** to auto-fill the assessment answer with the grade, header status summary, DNS record findings, and PCI compliance status. ### HTTP Security Headers | Header | Expected Value | Status if Missing | |---|---|---| | **Strict-Transport-Security (HSTS)** | Present with `max-age` >= 31,536,000 | Fail | | **Content-Security-Policy (CSP)** | Present (warn if contains `unsafe-inline` or `unsafe-eval`) | Fail | | **X-Content-Type-Options** | `nosniff` | Fail | | **X-Frame-Options** | `DENY` or `SAMEORIGIN` | Fail | | **Referrer-Policy** | Present | Warn | | **Permissions-Policy** | Present | Warn | | **Cache-Control** | Contains `no-store` or `no-cache` | Warn | ### DNS Security Records | Record | What Is Checked | Status if Missing | |---|---|---| | **SPF** | TXT record starting with `v=spf1` | Warn | | **DMARC** | TXT record at `_dmarc.{domain}` | Warn | | **CAA** | Certificate Authority Authorization records | Warn | ### Grading The overall grade is calculated from the pass/warn/fail distribution: | Grade | Condition | |---|---| | **A** | All checks pass | | **B** | All checks pass or warn (no failures) | | **C** | 1–2 failed checks | | **D** | 3 or more failed checks | | **F** | Critical failures (missing HSTS or missing CSP) | ### PCI Compliance The check is marked **PCI Fail** if any of these critical headers are missing: - Strict-Transport-Security (HSTS) - Content-Security-Policy (CSP) - X-Frame-Options > **Tip** > > For subdomains, DNS records like SPF and DMARC are typically configured on the root domain. Missing SPF/DMARC on a subdomain is reported as a warning, not a failure. --- ## Payment Page Script Monitor The Payment Page Script Monitor addresses PCI DSS 4.0.1 Requirement 11.6.1 — a brand-new requirement that mandates monitoring and integrity verification of all scripts loaded on payment pages. The tool supports two modes: live scanning a URL and importing a CSV script inventory. ### Live Scanning a Payment Page 1. **Enter the Payment Page URL** Type the full URL of the payment page (e.g., `https://shop.example.com/checkout`) in the URL input field. 2. **Click Scan URL** The system fetches the page server-side, extracts all `