Skip to main content

Security Events

What are Security Events?

Security Events are alerts generated when the system detects potential security threats. These events are created automatically when software policies are violated, network IOCs are detected, or suspicious processes are identified.

Why Security Events Matter

  • Centralized Alerting: All security detections in one place
  • Prioritization: Events sorted by severity and impact
  • Context: Full information about what was detected and where
  • Workflow: Track investigation and resolution progress
  • Audit Trail: Complete history of security incidents

Accessing Security Events

  1. Navigate to Events in the main menu
  2. Filter by Category: Security
  3. Or click on a detection from Software Policies

Understanding Security Events

Event Types

Event TypeSourceDescription
Software BlacklistSoftware PolicyProhibited software detected
Process BlacklistSoftware PolicySuspicious process running
Network IOCIOC ScanConnection to malicious IP
LOLBAS DetectionProcess MonitorSystem tool abuse detected

Severity Levels

SeverityColorResponse TimeExamples
CriticalRedImmediateRansomware, Active C2
MajorOrangeWithin 1 hourRAT detected, Backdoor
WarningYellowWithin 24 hoursPUP, Policy violation
InfoBlueScheduled reviewMonitoring alerts

Event Status

StatusMeaning
OpenNew detection, needs investigation
AcknowledgedUnder investigation
ResolvedInvestigation complete, issue addressed
ClosedNo action needed or false positive

Event Details

Basic Information

Each security event displays:

  • Title: What was detected
  • Severity: How critical is this threat
  • Status: Current investigation status
  • Timestamp: When detection occurred
  • Category: Security event type

Detection Context

For each detection:

  • Affected Host: Server or workstation name
  • CI Link: Direct link to CMDB entry
  • Policy: Which software policy was triggered
  • Malware Family: Associated threat (if known)

Network IOC Details

For network-based detections:

  • Remote IP: The malicious destination
  • Remote Port: Communication port
  • Process Name: What initiated the connection
  • Connection Count: Number of observations

The system suggests next steps:

  • Investigation steps to perform
  • Remediation actions to take
  • Escalation recommendations
  • Documentation requirements

Working with Events

Acknowledging Events

When you begin investigating:

  1. Click the event to open details
  2. Click Acknowledge
  3. Add notes about your investigation
  4. Event moves to "Acknowledged" status

Adding Notes

Document your investigation:

  1. Open the event
  2. Scroll to Notes section
  3. Click Add Note
  4. Enter investigation findings
  5. Notes are timestamped and attributed

Resolving Events

When investigation is complete:

  1. Open the event
  2. Click Resolve
  3. Select resolution reason:
    • Confirmed threat (remediated)
    • False positive
    • No action required
    • Escalated to incident
  4. Add final notes
  5. Event moves to "Resolved" status

Event Filtering

By Severity

Focus on what matters most:

  • Critical only: Active threats requiring immediate response
  • Critical + Major: All significant security events
  • All: Complete visibility including informational

By Status

Track investigation progress:

  • Open: New events needing attention
  • Acknowledged: Currently being investigated
  • Resolved: Completed investigations

By Time Range

Review specific periods:

  • Last 24 hours
  • Last 7 days
  • Last 30 days
  • Custom date range

By Host

Focus on specific assets:

  • Search by hostname
  • Filter by CI type (Server/Workstation)
  • View events for specific business units

Security Event Workflow

Standard Response Process

┌─────────────────────────────────────┐
│ 1. Detection Created (Open) │
│ - System detects threat │
│ - Event created automatically │
│ - Notifications sent │
└─────────────────┬───────────────────┘


┌─────────────────────────────────────┐
│ 2. Triage (Acknowledged) │
│ - Analyst reviews event │
│ - Severity confirmed/adjusted │
│ - Initial assessment documented │
└─────────────────┬───────────────────┘


┌─────────────────────────────────────┐
│ 3. Investigation │
│ - Gather additional evidence │
│ - Assess impact and scope │
│ - Identify root cause │
└─────────────────┬───────────────────┘


┌─────────────────────────────────────┐
│ 4. Response │
│ - Contain if needed │
│ - Remediate threat │
│ - Verify cleanup │
└─────────────────┬───────────────────┘


┌─────────────────────────────────────┐
│ 5. Resolution (Resolved) │
│ - Document findings │
│ - Close event with notes │
│ - Update policies if needed │
└─────────────────────────────────────┘

Critical Event Response

For critical severity events:

  1. Immediate notification sent to security team
  2. Acknowledge within 15 minutes
  3. Initial assessment within 30 minutes
  4. Containment decision within 1 hour
  5. Full investigation within 4 hours
  6. Resolution or escalation within 8 hours

Reporting

Event Summary

Generate reports showing:

  • Total events by severity
  • Events by detection type
  • Mean time to acknowledge
  • Mean time to resolve
  • Events by host/business unit

Compliance Documentation

Export event data for audits:

  • Complete event history
  • Investigation notes
  • Resolution details
  • Timeline of actions

Best Practices

Effective Triage

  1. Review critical events first
  2. Check for related events (same host, same malware)
  3. Verify detection accuracy before escalating
  4. Document even negative findings

Investigation Quality

  1. Gather host context from CMDB
  2. Review network relationships
  3. Check for lateral movement
  4. Document evidence thoroughly

Resolution Standards

  1. Always add resolution notes
  2. Specify the root cause
  3. Document remediation steps
  4. Note any policy changes needed

Frequently Asked Questions

Q: What if I get too many events? A: Review policies for false positive patterns. Add exclusions for verified non-threats. Adjust severity levels appropriately.

Q: Can events be automatically resolved? A: No, security events require human review. This ensures proper investigation and documentation.

Q: How long are events retained? A: Event history is retained according to your organization's data retention policy, typically 1-7 years for security events.

Q: Can I reopen a resolved event? A: Yes, if new information surfaces. Add notes explaining why it was reopened.