Practical SecOps + Vulnerability Response (VRO) — From Scratch

§1 — SecOps overview: SIR + VR + TI + CTD

§2 — Full VRO description cycle (scanner → close)

2.1 Scanner → import

Production: IntegrationHub spoke (Qualys, Tenable, Rapid7, CrowdStrike VM, Microsoft Defender) schedules pull or receives push. PDI lab: CSV/XML import set mimics the same transform targets.

2.2 Vulnerability master (CVE catalog)

sn_vul_vulnerability holds one record per CVE (or vendor vuln ID): title, CVSS, published dates, exploit flags, solutions references. Many VIs point to one master.

2.3 Vulnerable item (asset × vulnerability)

sn_vul_vulnerable_item is the work unit: state, priority, risk score, assignment group, link to cmdb_ci, link to master vulnerability, remediation dates.

2.4 Assignment → remediation change → close

2.5 Supporting VR objects in the cycle

• sn_vul_entry — raw/normalized entries from imports before master/VI upsert.
• sn_vul_software — software products tied to findings (library / package context).
• sn_vul_solution — vendor fix text, KB, patch links referenced from master/VI.
• sn_vul_third_party_entry — NVD/exploit intel overlays (exploit available boosts priority).

2.6 Cross-app touchpoints

Example: default credentials VI may auto-create SIR; TI indicator on C2 IP enriches SIR; CTD CIS failure creates configuration-related VI.

§3 — Related tables (purpose + CMDB / SIR / TI links)

// PDI: prove VI → CI join (Scripts - Background)
var vi = new GlideRecord('sn_vul_vulnerable_item');
vi.addNotNullQuery('cmdb_ci');
vi.setLimit(5);
vi.query();
while (vi.next()) {
  gs.info(vi.number + ' → ' + vi.cmdb_ci.getDisplayValue() +
    ' | CVE ' + vi.vulnerability.cve_id);
}

§4 — Direct {BASE} URLs (major pages)

§5 — PDI lab steps (SOC analyst + implementer)

Lab A — Enable SecOps stack

1. Open VR + SIR + TI + CTD plugins; activate (PDI may take several minutes).
2. Run Guided Setup SecOps/Vulnerability tiles until green checks (groups, properties, sample data if offered).
3. Create groups: Vulnerability Managers, Unix Admins, Windows Admins via Groups; assign test users.
4. Confirm roles: e.g. sn_vul.vulnerability_read, sn_vul.vulnerability_write (names vary by version — search role list).

Lab B — CMDB anchor (before scan data)

1. Create or pick two servers in cmdb_ci_server; set name, ip_address, business_criticality.
2. Note FQDN/IP — import transform will match on these keys.
3. Optional: open IRE identifiers and trace which fields identify a Linux server.

Lab C — Simulate scanner import

1. Locate VR import set table (often vendor-specific staging) via tables sn_vul% or use OOB sample import if Guided Setup loaded one.
2. Load 2 rows: same CVE, two different hostnames matching your CIs.
3. Run transform; open Vulnerabilities — expect one master.
4. Open Vulnerable Items — expect two VIs with CI populated.

// Optional: adjust risk on a VI (Background script)
var vi = new GlideRecord('sn_vul_vulnerable_item');
vi.addQuery('state', 'open');
vi.setLimit(1);
vi.query();
if (vi.next()) {
  vi.setValue('priority', '1');
  vi.update();
  gs.info('Updated ' + vi.number);
}

Lab D — Assignment rule

1. Open Assignment rules; New.
2. Condition: CI class = Linux Server OR tag = production.
3. Action: Assignment group = Unix Admins.
4. Re-import or update VI; confirm group changed on form.

Lab E — Analyst workflow (workspace)

1. Open VR workspace as vulnerability manager.
2. Filter open P1; open one VI; review linked CVE master and solution.
3. Create Change Request (category security); link from VI related lists.
4. Move VI to In progress; set planned remediation date.

Lab F — Close loop

1. Simulate rescan: update VI state to Closed with close code Fixed (or import absent row per OOB logic).
2. Verify master still shows correct open VI count.
3. Document SLA: compare opened vs closed timestamps on VI.

Lab G — Cross-app (optional 30 min)

1. Create TI indicator on sn_ti_indicator; relate to SIR test incident.
2. Run one CTD test from CTD tests; observe failing CI → VI pattern if configured.
3. Open SIR workspace; confirm shared CI appears on both SIR and VI.

§6 — Best practice chips (VR / SecOps)

§7 — Flow Designer automates VR

OOB VR ships flows and subflows for common patterns. Custom implementations typically add: auto-assign on VI insert, create change when priority=1, notify owner on assignment or SLA warning.

7.1 Implementer click-path (PDI)

Flow name: VR - Critical VI - Assign and Change
Scope: Global (OOB VR) OR your scoped app for extensions only
Trigger: Record Created — sn_vul_vulnerable_item
Condition: priority IN 1,2
Actions:
  1) Lookup assignment_group (from CI.support_group or assignment rule output)
  2) Update Record (VI.assignment_group, VI.state = in_progress)
  3) Create Record change_request (short_description, cmdb_ci, category=security)
  4) Create Record task_ci (link CI to change if needed)
  5) Send Notification (template: include VI.number, CVE, CI name, {BASE} link)

§8 — ServiceNow SDK: CAN vs CANNOT for VR/SecOps

See full toolchain: SDK_CURSOR_FULL_DOCUMENTATION.html · SDK Windows full cycle · Flow labs: PRACTICAL_FLOW_DESIGNER_FROM_SCRATCH.html · events: 06_NOTIFICATIONS_EVENTS_JOBS.html.

// Scoped app pattern (conceptual — lives in YOUR scope, not sn_vul)
// tables.now.ts — custom integration log
// business-rules.now.ts — on insert x_scope_scan_event → call OOB Import API
// flows — trigger on x_scope_scan_event, not fork sn_vul_vulnerable_item OOB flows
// CANNOT: npm package that rewrites com.snc.vulnerability plugin tables

§9 — Related documentation

VR description cycle — single-page recap flow

SIR ↔ VR ↔ TI ↔ CTD — operator glance board

Appendix — State vocabulary (typical VI)

Appendix — Priority ↔ SLA (OOB reference bands)

Appendix — Scanner integration checklist

• Connection credentials in IH Connection (mid-server if on-prem scanner).
• Spoke actions scheduled via Scheduled job or vendor pull frequency.
• Transform errors: Import set runs → error rows.
• Duplicate VI prevention: OOB dedupe on CI + vulnerability; do not disable without design.
• Post-import: run VR prioritization job if enabled (check Jobs named Vulnerability).

Appendix — CMDB fields that affect VR score

Appendix — sn_si_incident vs VR

Create SIR when human response is required for active threat (malware, exfil, account compromise). VR handles exposure management (vuln present). Same CI may appear on both; use related records instead of duplicating work in ITSM incident unless policy requires.

Appendix — Third-party intel (sn_vul_third_party_entry)

Feeds update exploit availability on CVE masters. Implementers schedule intel pull (NVD, vendor APIs). Analysts use exploit flag to escalate priority without manual CVE research.

Appendix — Vulnerability groups (bulk remediation)

Group VIs by host, application, or patch ID to open one change for many items. Search lists/filters on VI for shared vulnerability.patch_id or business service. Pattern documented in SECOPS.html §4.5.

// Bulk change pattern (background — adapt thresholds)
var agg = new GlideAggregate('sn_vul_vulnerable_item');
agg.addQuery('state', 'open');
agg.addQuery('priority', 'IN', '1,2');
agg.addAggregate('COUNT');
agg.groupBy('vulnerability.patch_id');
agg.query();
while (agg.next()) {
  var patchId = agg.getValue('vulnerability.patch_id');
  var count = parseInt(agg.getAggregate('COUNT'), 10);
  if (patchId && count >= 5) {
    gs.info('Consider bulk CHG for patch ' + patchId + ' (' + count + ' VIs)');
  }
}

Appendix — Roles smoke test (impersonation)

1. Impersonate vulnerability manager → workspace + edit VI.
2. Impersonate CI owner → see only assigned VIs (ACL check).
3. Impersonate unauthorized user → expect read denial on admin lists.

Next depth: For certification-style labs and 30-question drills, continue in SECOPS §19. For HR Leave scoped SDK examples, use scoped tables only — do not merge with OOB sn_vul store apps.

Practical SecOps + VRO From Scratch · visual tutorial · replace {BASE} via bar above · Portal