Cybersecurity Best Practices Guide

Overview

This guide provides comprehensive best practices for implementing and managing the Cybersecurity Asset Inventory Schema v1.0 in Jira Service Management Assets. This domain schema extends the Core Schema to provide security teams with a complete view of their security posture, enabling vulnerability management, risk tracking, control mapping, and compliance evidence collection.

Who Should Read This Guide

• Security Analysts responsible for vulnerability triage and incident response
• Security Engineers implementing scanner integrations and control frameworks
• CISO and Security Leadership requiring risk visibility and compliance reporting
• IT Operations teams managing patch cycles and asset lifecycle
• Compliance and Audit teams mapping controls to requirements and collecting evidence
• GRC Analysts tracking regulatory compliance across the organization

What You Will Learn

• How to effectively use each of the five object types in the Cybersecurity schema
• The purpose and significance of every attribute across all object types
• Scanner integration strategies for Tenable, Qualys, Rapid7, and other tools
• CVE tracking and vulnerability lifecycle management
• Risk scoring methodologies and residual risk calculation
• Compliance mapping across multiple regulatory frameworks
• Troubleshooting guidance for frequent security data issues

Prerequisites

• JSM Premium or Enterprise license (Assets requires Premium tier minimum)
• Object Schema Manager or Jira Admin permissions
• Core Schema v1.1 deployed with Person, Team, Application, Vendor, and Location object types populated
• Familiarity with basic JSM Assets concepts
• Understanding of vulnerability management fundamentals (CVE, CVSS, remediation workflows)

Schema Architecture

How This Schema Extends Core

The Cybersecurity Asset Inventory Schema follows the Schema-Forge principle of referencing Core Schema objects rather than duplicating master data. This design ensures that security asset ownership, team assignments, vendor relationships, and location data remain synchronized across your entire CMDB ecosystem.

Benefits of Extension Architecture

• Update a person's job title or team assignment once in Core, and it reflects across all security records
• Query cross-schema: find all assets in a specific location, or all vulnerabilities affecting a specific vendor's products
• Eliminate duplicate data entry for organizational information
• Enable consistent reporting across IT and Security teams

Object Type 1: Security Asset

Purpose and Business Context

The Security Asset object type represents any physical or virtual device that requires security management. This differs from the Core Schema's Application object, which focuses on business software. Security Assets encompass infrastructure: servers, workstations, network devices, IoT sensors, virtual machines, and containers that need vulnerability scanning, patching, and compliance monitoring.

Why Security Asset Records Matter

• Vulnerability Management: Which assets are affected by CVE-2025-XXXXX?
• Patch Management: What needs updating in the next maintenance window?
• Compliance Scope: Which assets handle restricted data and require PCI-DSS compliance?
• Incident Response: What is the criticality and owner of this compromised system?
• Asset Inventory: Do we have visibility into all security-relevant assets?
• Risk Assessment: What is our exposure from this asset classification?

Key Attributes

Real-World Example

Name: PROD-PAY-WEB-001
FQDN: pay-web-001.prod.corp.example.com
Asset Tag: i-0abc123def456789 (AWS EC2 instance ID)
Type: Virtual Machine
OS: Amazon Linux 2023
IP Address: 10.100.50.25
Environment: Production
Criticality: Critical (processes payment data)
Data Classification: Restricted (PCI-DSS scope)
Owner: Sarah Chen (Payment Systems Manager)
Owning Team: Payment Engineering
Location: AWS us-east-1 (N. Virginia)
Application: Payment Gateway
Vendor: Amazon Web Services
Discovery Source: Cloud API
Last Seen: 2026-01-31
Status: Active

Object Type 2: Vulnerability

Purpose and Business Context

The Vulnerability object type represents known security weaknesses affecting your assets. Vulnerabilities are typically imported from vulnerability scanners (Tenable, Qualys, Rapid7) and tracked through a remediation lifecycle from detection to closure.

Why Vulnerability Records Matter

• Remediation Prioritization: Which vulnerabilities pose the greatest risk?
• SLA Compliance: Are we meeting our patching commitments?
• Risk Quantification: What is our vulnerability exposure by criticality?
• Trend Analysis: Is our vulnerability count improving or worsening?
• Compliance Evidence: Can we demonstrate timely remediation?

Severity to CVSS Mapping

Implementation Best Practice: SLA Calculation

Remediation Due should be calculated automatically based on Vulnerability Severity and Asset Criticality:

Object Type 3: Security Control

Purpose and Business Context

The Security Control object type represents safeguards or countermeasures that protect your assets and address vulnerabilities. Controls map to compliance frameworks (CIS Controls, NIST CSF, ISO 27001, SOC 2, PCI-DSS) and provide the documented evidence of your security program.

Why Security Control Records Matter

• Compliance Mapping: Which controls satisfy PCI-DSS requirement 6.5?
• Gap Analysis: Which framework controls are not yet implemented?
• Asset Protection: What controls protect our critical assets?
• Audit Evidence: Where is the documentation for this control?
• Assessment Tracking: When was this control last tested?

Control Category Explained

Object Type 4: Risk

Purpose and Business Context

The Risk object type represents identified security risks requiring tracking and mitigation. Unlike vulnerabilities (which are specific technical weaknesses), risks represent broader business exposure that may encompass multiple vulnerabilities, controls, and assets.

Risk Scoring Methodology: 5x5 Risk Matrix

Risk Score = Likelihood (1-5) × Impact (1-5)

Score Interpretation:

• 20-25: Critical risk - immediate treatment required
• 12-19: High risk - prioritized treatment within 30 days
• 6-11: Medium risk - treatment planned within 90 days
• 1-5: Low risk - monitor and review annually

Object Type 5: Compliance Requirement

Purpose and Business Context

The Compliance Requirement object type represents regulatory or policy requirements that your organization must meet. Requirements are tracked independently from controls because a single requirement may be satisfied by multiple controls, and a single control may satisfy multiple requirements.

Framework Values

Scanner Integration

Vulnerability Scanner Integration

Integrating vulnerability scanners with JSM Assets enables automated vulnerability tracking and eliminates manual data entry.

Recommended Integration Flow

1. Schedule daily export from scanner API (vulnerabilities endpoint)
2. Transform scanner data to schema format
3. Deduplicate on Scanner Plugin ID + asset combination
4. Import via JSM Assets Import API or CSV import
5. Calculate Remediation Due based on severity and asset criticality

Tenable Integration

Troubleshooting Guide

Scanner Import Issues

Common Mistakes to Avoid

• Missing CVE ID: Without CVE ID, you cannot correlate vulnerabilities to threat intelligence or vendor advisories
• Severity inflation by scanners: Some scanners rate everything as Critical. Validate CVSS Score and adjust Severity if scanner defaults are unreliable
• Unassigned vulnerabilities: Vulnerabilities without Assigned To have no accountability. Route to asset Owning Team by default
• No First Seen tracking: Without First Seen, you cannot measure remediation time
• Stale Open vulnerabilities: Implement escalation for vulnerabilities exceeding SLA

FAQ

Q: How do I handle vulnerabilities that affect multiple assets?

Answer: Create one Vulnerability object per asset-vulnerability combination, not one Vulnerability object with multiple Affected Assets. This approach enables per-asset remediation tracking, supports different remediation assignees per asset, allows accurate SLA tracking per asset, and matches how scanners report findings.

Q: Should I import all scanner findings or filter first?

Answer: Filter before import. Import findings that match your remediation scope. Include all severities above Informational (or per your risk tolerance), but exclude purely informational findings unless compliance requires them. Over-importing creates noise; under-importing creates blind spots.

Q: How do I map a single control to multiple compliance frameworks?

Answer: Create one Security Control for your implementation, then create separate Compliance Requirement objects for each framework requirement, linking each to the same Security Control via Mapped Controls. This shows how one implementation satisfies multiple requirements and supports framework-specific reporting.

Q: What is the difference between Risk and Vulnerability?

Answer: Vulnerabilities are specific technical weaknesses (CVE-2025-XXXX affects server A). Risks are broader business exposures that may encompass multiple vulnerabilities. For example, a Vulnerability is "CVE-2025-1234 on PROD-WEB-001" while a Risk is "Ransomware infection due to unpatched systems" (encompasses many vulnerabilities).

Related Resources

This guide is part of the Cybersecurity Asset Inventory Schema v1.0 documentation suite:

• Governance Playbook: Enterprise governance framework including roles, review cadences, and escalation procedures
• JSM Forms Specification: Detailed form configurations for each object type with field validation
• Automation Examples: Automation rule patterns for vulnerability assignment and SLA breach notifications