Cybersecurity Forms Specification

Form Architecture

Security forms require stricter validation, specialized approval chains, and audit-ready workflows compared to general CMDB forms.

Portal Structure

Security-Specific Form Requirements

1. Audit Trail: Every submission creates a permanent record
2. Segregation of Duties: Creators cannot approve their own submissions
3. Time-Sensitivity: Vulnerability forms have SLA-driven urgency
4. Classification Awareness: Forms adapt based on data sensitivity
5. Evidence Capture: Links to external systems are validated

Form 1: New Security Asset

Register physical or virtual devices requiring security management.

┌──────────────────────────────────────────────────────────────────┐
│  NEW SECURITY ASSET                                              │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Name *                              Asset Tag                   │
│  ┌───────────────────────┐  ┌───────────────────────┐           │
│  │ PROD-WEB-001          │  │ i-0abc123def456       │           │
│  └───────────────────────┘  └───────────────────────┘           │
│  Hostname or asset ID          Physical tag or instance ID       │
│                                                                  │
│  FQDN                            IP Address                      │
│  ┌───────────────────────┐  ┌───────────────────────┐           │
│  │ web01.prod.example.com│  │ 10.100.50.25          │           │
│  └───────────────────────┘  └───────────────────────┘           │
│  For scanner correlation        Primary IP address               │
│                                                                  │
│  Type *                          Environment *                   │
│  ┌───────────────────────┐  ┌───────────────────────┐           │
│  │ Server            ▼   │  │ Production        ▼   │           │
│  └───────────────────────┘  └───────────────────────┘           │
│                                                                  │
│  Criticality *                   Data Classification             │
│  ┌───────────────────────┐  ┌───────────────────────┐           │
│  │ Critical          ▼   │  │ Restricted        ▼   │           │
│  └───────────────────────┘  └───────────────────────┘           │
│                                                                  │
│  Owner                           Owning Team                     │
│  ┌───────────────────────┐  ┌───────────────────────┐           │
│  │ Select person...   ▼  │  │ Select team...     ▼  │           │
│  └───────────────────────┘  └───────────────────────┘           │
│                                                                  │
│              ┌───────────┐  ┌───────────┐                       │
│              │  Cancel   │  │  Create   │                       │
│              └───────────┘  └───────────┘                       │
└──────────────────────────────────────────────────────────────────┘

Conditional Logic

• When Environment = Production AND Criticality = Critical: Owner and Owning Team become required
• When Data Classification = Restricted: Show "Compliance Scope" multi-select (PCI-DSS, HIPAA, SOX, GDPR)
• When Status = Decommissioned: Show "Decommission Date" and "Data Wiped Confirmation" checkbox

Form 2: New Vulnerability

Register security vulnerabilities for tracking through remediation lifecycle.

Field Specifications

Conditional Logic

• When Severity = Critical: Priority auto-set to Highest; show "Emergency Response Required" checkbox
• When Remediation Status = Accepted Risk: Show "Risk Acceptance Justification" (required, min 100 chars), "Compensating Controls", "Acceptance Expiration Date"
• When Remediation Status = False Positive: Show "False Positive Evidence" (required), "Verified By"
• When Remediation Status = Remediated: Remediated Date becomes required; show "Verification Method" select

Form 3: New Security Control

Document controls that protect assets and satisfy compliance requirements.

Field Specifications

Conditional Logic

• When Implementation Status = Implemented: Evidence Location and Last Assessed become required
• When Implementation Status = Partial: Show "Implementation Gap" and "Gap Remediation Plan"
• When Category = Compensating: Show "Primary Control Gap" and "Compensating Justification" (required)

Form 4: New Risk

Register security risks requiring tracking and treatment.

Risk Score Auto-Calculation

Risk Score is automatically calculated as Likelihood (1-5) x Impact (1-5):

Conditional Logic

• When Risk Score >= 20: Show "Executive Notification" checkbox (auto-checked), route to CISO for approval
• When Treatment = Accept: Show "Acceptance Justification" (required, min 100 chars), "Acceptance Period" select, route to CISO for Critical/High
• When Treatment = Transfer: Show "Transfer Method" select, "Transfer Partner" text field

Security Validation Patterns

CVE ID Validation

Pattern: ^CVE-\d{4}-\d{4,}$
Valid:   CVE-2025-1234, CVE-2024-12345
Invalid: cve-2025-1234, CVE-25-1234, CVE2025-1234

CVSS Score Validation

Pattern: ^(10\.0|[0-9]\.[0-9])$
Valid:   0.0, 5.5, 9.9, 10.0
Invalid: 10.1, 11.0, -1.0, 5

IP Address Validation

IPv4: ^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$
Valid: 192.168.1.100, 10.0.0.1
Invalid: 256.1.1.1, 192.168.1

Control ID Validation

Pattern: ^[A-Z]{2,10}[\-\.]?[A-Z0-9\.\-]+$
Valid:   CIS-6.5, NIST-PR.AC-7, ISO-A.9.4.2, PCI-1.1.1
Invalid: cis-6.5, 6.5-CIS

Approval Chain Design

Vulnerability Risk Acceptance Workflow

1. Submitted - Acceptance request received
2. Security Review - Validate compensating controls (Approver: Security Operations Lead)
3. Risk Owner Approval - Formal acceptance (Approver: Related Object Owner)
4. Executive Approval - Required for Critical/High (Approver: CISO)
5. Documentation - Compliance documents acceptance
6. Completed - Acceptance granted, monitoring initiated

Risk Treatment Workflow

Automation Triggers

On Vulnerability Submission

• Validate CVE ID format matches CVE-YYYY-NNNNN pattern
• Check for duplicate: CVE ID + Affected Asset combination
• Auto-calculate Remediation Due based on Severity + Asset Criticality matrix

On Status Changes

• Open → In Progress: Notify Assigned To with SLA deadline
• Any → Accepted Risk: Create or link to Risk object; schedule re-review
• Any → Remediated: Trigger verification scan via scanner API