USEM: Automated As-Built Configuration

[michael1906]

All, I'm trying to figure out the best way to automate an as-built configuration report specifically for configurations done in USEM/VR. I envision this being a report out post-deployment that shows all configurations performed, users/roles created, policies, integrations, table mapping, etc. What is the best way to go about generating this in an automated way? Report? Update Sets?

[Aravind2799 · Accepted solution]

Hi, 

Short answer: neither a standard report nor update sets will get you there on their own, because an as-built covers two different kinds of things.

• Configuration records (business rules, script includes, UI policies, properties, transform maps) are captured in update sets and sys_update_xml.
• Data records (users, groups, role assignments, VR rule records, integration instance settings, scheduled job runs) mostly are not. Update sets will quietly miss a large part of what a reviewer expects to see.

But , What has worked well for me is a manifest-driven scripted export: a maintained list of tables and filters that a script walks through, producing one structured document.

1. Capture configuration changes from update history

• Query sys_update_xml (or sys_update_version) filtered by the VR/USEM application scopes and a date range starting at your deployment window. This gives you every customer update, with type, target name, author and timestamp.
• Filter sys_scope for the Vulnerability Response and Exposure Management related scopes to build that scope list. It varies by version and installed plugins, so derive it from the instance rather than hardcoding it.
• Add sys_properties in those scopes, and compare against defaults where possible, so the report shows changed values rather than every property.

2. Capture data-driven configuration directly

• Users, groups, roles: sys_user_group, sys_user_grmember and sys_user_has_role, filtered to VR/USEM roles (e.g. sn_vul.*) and the groups you created.

3. Generate the document

Two options, depending on where you want the logic to live:

• On-instance: a Script Include driven by a small custom manifest table (table + encoded query + fields to display). A scheduled job or Flow runs it and attaches an HTML or PDF output to a record. This is easy to rerun after each release.
• Off-instance: a Python (or similar) script calling the Table API with a read-only integration user, rendering to Word, Markdown or Excel. Once built, it can be reused across instances or clients and kept in version control alongside the deployment artifacts. This is the option I'd lean toward if you produce as-builts repeatedly.

4. Make it trustworthy

• Stamp the report with instance name, version/family, plugin versions (from sys_store_app / v_plugin) and run date.
• Separate "changed from baseline" from "full current state." Reviewers usually want both.
• Cross-check against update set and deployment records, so nothing that went in through a fix script or manual data change is missed.
• Mask anything sensitive: endpoint URLs if needed, and never secrets.
• VR rules: assignment rules, remediation target rules, vulnerability group rules, exception and approval rules, risk calculators. The easiest way to get the exact table names for your version is to open each module and read the table from the list URL, then add it to the manifest.
• Integrations: the integration configuration records for each scanner (Qualys, Tenable, Rapid7, etc.), sys_data_source, scheduled imports and jobs (sysauto), and the MID Server used.
• Table mapping: sys_transform_map plus sys_transform_entry for field-level mappings, including source and target fields and whether a script is involved.
• Connection and credential aliases: list the alias names and which connection they point to. Never export credential values.

Thanks
Aravind Panchanathan