# Qualys File Structure

The XML structure of a Qualys scan is complex and not well documented. Using python to navigate it a bit at a time, I am trying to understand its structure so we can start building automated parsers.

The <SCAN> element is what encompasses the whole scan. We will see the following at the beginning of every scan

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE SCAN SYSTEM "https://qualysguard.qg3.apps.qualys.com/scan-1.dtd">
<SCAN value="scan/1718040509.96761">

The </SCAN> closing tag is at the end of the file. The value attribute will change, but we dont use it anyway.

The first child element is <HEADER> which contains basic scan metadata such as date, title, duration, targets, exclusions, hosts alive, total hosts scanned. Those fields I mentioned will be useful for our deliverable.

The rest of the child elements are <IP>. Each one is a single host that was detected. This includes hosts with no vulnerabilities. Thats because a host that is detected but has no vulnerabilities will still have some information that was gathered about it like open ports, OS, etc that can be useful.

The IP address and DNS name are attributes of hte <IP> element.

IP {'value': '10.0.0.1', 'name': 'dc01.example.local'}

The rest of the data is stored in child elements:

• NETWORK - this is the Qualys Network that the host belongs to. Each network contains a different clients, so we wont ever be running reports across multiple networks. This field will be ignored.
• OS - detected operating system. Often times its uncertain so there will be multiple listed separated by slashes.
• NETBIOS_HOSTNAME - if the host has one, this element will be present. Might be worth having this. Some systems with no DNS name might still have a NetBIOS hostname.
• SERVICES - information about what services are running. These are not vulnerabilities, just enumeration of the running services. This will probably be the main way we report on what services are running, even though some of this same data is also in INFOS.
• INFOS - information about the host. includes authentication data, open or filtered ports, open pipes, etc. Right now I only plan to use the authentication data. Maybe will use the port scan.
• PRACTICES - these are unconfirmable vulnerabilities. We do not report on these and dont currently plan to, so it will be ignored.
• VULNS - this is the bulk of what we want. The actual vulnerabilities associated with each host. This is what we had in the spreadsheet deliverable. We will want to present each one along with ways to filter and sort. We also want totals of each severity level. Im not sure how to handle hte information severity level. It seems redundant when there is already an INFOS category. Note that the vulns are sorted first by category, and the severity is a property of the <VULN> object.

<VULNS>
    <CAT value="Windows">
      <VULN number="92094" severity="3">
        <TITLE><![CDATA[SMBv2 Signing Not Required]]></TITLE>