Security Monitoring (SIEM)

Overview

Security Monitoring is Fencer’s built-in SIEM (Security Information and Event Management) module. It ingests security events from your cloud infrastructure, SaaS tools, and identity providers, then applies detection rules to surface threats automatically. The module gives you a centralized place to investigate, triage, and resolve security detections across your entire environment.

You open it from Operations > Security Monitoring. The page has these tabs:

• Detections — the detections raised in your organization. See Detections.
• Rules — the detection rules, their variables, and the rule sources. See Detection Rules.
• Alerting — opens Settings > Notifications filtered to the detection trigger, where you route detections to Slack, email, or a webhook. Shown to roles that can read organization settings. See SIEM Alerting.

The Integrations button in the page header lists the monitoring integrations you can connect.

Note

Security Monitoring is a paid feature. You need an active subscription with the SIEM entitlement to access it. Without it, the Threat Hunting, Security Monitoring, and Network Flows links show as locked.

Prerequisites

• At least one monitoring integration connected, such as AWS, GCP, GitHub, or 1Password.
• An active paid subscription with the SIEM feature enabled.

How it works

Fencer collects security events from connected log sources and stores them in a data warehouse. A scheduled pipeline runs the enabled detection rules against these events. When a rule matches, a detection is created and appears on the Detections tab.

Each detection includes a title, description, severity, confidence, the rule that matched, the asset involved, and recommended actions. Detections are deduplicated using a grouping key, so repeated matches for the same activity do not create duplicate entries.

The raw events behind the detections are also searchable in Threat Hunting (Operations > Threat Hunting).

Supported log sources

Each connected source appears as a Data Source Type in Threat Hunting.

Batch data sources are deprecated

Fencer is deprecating batch data sources, which load AWS and GCP logs from storage buckets, and moving to streaming ingestion. To use streaming, contact us. The AWS Streaming Monitor page describes the AWS setup.

AWS — see AWS Log Sources

• AWS CloudTrail
• AWS VPC Flow Logs
• AWS ALB Access Logs and AWS ALB Connection Logs
• AWS NLB Access Logs
• AWS S3 Bucket Access Logs
• AWS RDS PostgreSQL standard logs
• AWS Route53 DNS Query Logs

GCP — see GCP Log Sources

• GCP Cloud Audit Logs
• GCP VPC Flow Logs
• GCP Cloud Storage Access Logs
• GCP Firewall Rule Logs
• GCP Cloud Armor Logs
• GCP Cloud DNS Logs
• GCP Cloud SQL Logs

SaaS and platforms

• GitHub Events, from the GitHub (Monitor) integration. See GitHub.
• 1Password Audit Events, Sign-in Attempt Events, and Item Usage Events, from the 1Password integration. See 1Password.
• Google Workspace Audit Logs, from the Google Workspace (Monitor) integration. See Google Workspace.
• GitLab Audit Events, from the GitLab (Monitor) integration. See GitLab.
• Cloudflare Logs, from the Cloudflare (Monitor) integration. See Cloudflare.
• Heroku Logs and DigitalOcean Actions, from the Heroku (Monitor) and DigitalOcean (Monitor) integrations. See Hosting Platforms.
• New Relic Logs, which Threat Hunting searches directly in your New Relic account. Detection rules do not run on them. See Observability.

Some sources, such as AWS streaming, are turned on per organization. Contact us if you need one that is not in your integrations list.

Who can do what

What a member can do depends on the abilities of their role:

Action	Ability	Built-in roles that have it
View detections, rules, and Network Flows	detections:read	Administrator, Team Member, Read Only
Search events in Threat Hunting	hunt:read	Administrator, Team Member, Read Only
Change a detection’s status or assignee	detections:edit	Administrator
Enable or disable a rule, edit its variables	detections:edit	Administrator
Comment on a detection	secops:edit	Administrator, Team Member
Manage global variables and external rule sources	secops:create, secops:edit, secops:delete	Administrator, Team Member

Custom roles can hold any of these abilities. See Roles and Permissions.

Detection lifecycle

Every detection has one of four statuses:

1. New — The detection has just been created by the rules engine.
2. Under Investigation — A team member is investigating the detection.
3. False Positive — The detection was reviewed and found to be benign.
4. True Positive — The detection was confirmed as a genuine security event.

The allowed transitions are:

• New can move to Under Investigation or False Positive.
• Under Investigation can move to False Positive or True Positive.
• False Positive can be reclassified as True Positive or reopened to Under Investigation.
• True Positive can be reclassified as False Positive or reopened to Under Investigation.

Detections describes the buttons that make each transition.

Usage / Configuration

Viewing detections

1. Go to Operations > Security Monitoring. The Detections tab opens.
2. The list shows your organization’s detections, most recent first.
3. Use Filter to narrow the list by severity, status, asset, assignee, event type, detection rule, whether the detection is tracked externally, or detection date.
4. Click a detection to open its details in a side panel.

Triaging a detection

1. Open a detection from the list.
2. Review the description, severity, confidence, the matched events, and the recommended actions.
3. Under Actions, click the next step, for example Investigate to move a New detection to Under Investigation.
4. Set the Assignee to hand the detection to a team member. The assignee is notified.

Bulk operations

1. Select detections with the checkboxes in the list. To select every detection that matches your filters, open the selection menu and choose All, which shows the number of matches.
2. Choose Transition or Assign in the bar that appears to update them all at once.

Linking to external tools

If you have a Linear or Jira integration connected, you can create an issue from a detection, or link it to an existing one, to track remediation in your existing workflow.

Examples

A typical workflow for responding to a detection:

1. A Medium detection arrives from the AWS CloudTrail Important Change rule, which fires when someone stops, updates, or deletes a CloudTrail trail.
2. Open the detection and review the Details and Events sections, which show the affected AWS account and the principal that changed the trail.
3. Click Investigate and set the Assignee to your cloud security lead.
4. After confirming the change was unauthorized, click Mark as True Positive and create a Jira issue to track the incident response.

Troubleshooting

• No detections appearing — Verify that at least one monitoring integration is connected and that log data is flowing: search for recent events in Operations > Threat Hunting. A rule whose data source is not connected is disabled, and its detail panel names the missing source.
• No status buttons on a detection — Changing a detection’s status or assignee needs the detections:edit ability, which the built-in Administrator role has. Team Member and Read Only can view detections but not change them.
• Duplicate detections — Detections are deduplicated by grouping key. Two detections that look alike have different grouping characteristics, such as a different actor. Compare their Details sections.

Related pages

• Detections
• Detection Rules
• Threat Hunting
• AWS Log Sources
• AWS Streaming Monitor
• GCP Log Sources
• Network Flows
• Platform Overview