Skip to main content

Managing False Positives

Reduce alert fatigue by identifying and suppressing false positive security alerts while maintaining comprehensive threat coverage.

Understanding False Positives​

A false positive occurs when legitimate activity triggers a security alert. While some false positives are unavoidable in comprehensive security monitoring, excessive false positives lead to alert fatigue and missed threats.

ImpactDescription
Alert FatigueToo many false positives cause teams to ignore or dismiss alerts without investigation
Wasted ResourcesSecurity analysts spend valuable time investigating non-threats instead of real incidents
Tuning RequiredDetection rules need continuous refinement to match your environment's unique patterns

Common False Positive Scenarios​

These are the most frequent sources of false positive alerts in CastellanAI:

Legitimate Administrative Tools​

Scenario: PowerShell scripts used by IT teams trigger "Suspicious PowerShell Activity" alerts.

Examples of legitimate tools flagged:

  • PowerShell remoting for system administration
  • Configuration management tools (Ansible, Puppet, Chef)
  • Automated patch management scripts
  • Software deployment automation

Service Accounts and Automation​

Scenario: Service accounts with high privileges generate "Privilege Escalation" or "Lateral Movement" alerts.

Common service account activities:

  • Backup agents accessing multiple systems
  • Monitoring agents performing health checks
  • CI/CD pipelines deploying to production servers
  • Database replication service accounts

Development and Testing Activities​

Scenario: Security testing tools and development activities trigger malware or attack alerts.

Legitimate activities flagged:

  • Penetration testing tools (Metasploit, Cobalt Strike)
  • Code obfuscators and packers used in development
  • Security research VMs running malware samples
  • Load testing tools simulating attacks

Authentication Patterns​

Scenario: Normal authentication behaviors trigger "Brute Force" or "Account Compromise" alerts.

Benign authentication patterns:

  • Users with multiple saved credentials attempting wrong accounts
  • Mobile apps retrying authentication after network interruption
  • Password manager browser extensions testing credentials
  • VPN reconnection attempts during network transitions

Reducing False Positives: Step-by-Step​

Follow this systematic approach to tune detection rules and reduce false positives:

Step 1: Identify the Pattern​

Review recurring false positive alerts to identify common characteristics.

Look for patterns in:

  • Source Host: Same server consistently triggering alerts?
  • User Account: Specific service account or user involved?
  • Process Name: Legitimate application causing alerts?
  • Time Pattern: Alerts occurring during scheduled maintenance?
  • Event Frequency: Multiple similar alerts within short timeframe?

Step 2: Verify Legitimacy​

Important

Always verify the activity is truly benign before suppressing alerts.

Verification checklist:

  • Confirm with asset owner or IT team that activity is authorized
  • Review activity context (what else happened before/after?)
  • Check if activity matches documented business processes
  • Verify user/account identity and authorization level
  • Cross-reference with other security tools or logs

Step 3: Create Suppression Rule​

Navigate to Configuration → Detection Rules and create an exception.

Suppression rule options (use narrowest scope):

OptionDescriptionExample
Host-BasedSuppress alerts from specific hostsHost: backup-server-01.company.com
Process-BasedAllow specific legitimate applicationsProcess: C:\Program Files\Backup\BackupAgent.exe
User-BasedSuppress alerts for service accountsUser: DOMAIN\svc-backup
Time-BasedSuppress during maintenance windowsTime: Daily 02:00-04:00 UTC

Step 4: Document the Exception​

Add clear justification and approval information to the suppression rule.

Required documentation:

  • Business Justification: Why is this activity legitimate?
  • Approval: Who authorized the exception?
  • Review Date: When should this be re-evaluated?
  • Risk Assessment: What risk remains after suppression?

Step 5: Monitor and Review​

Regularly review suppression rules to ensure they remain valid and necessary.

Exception TypeReview Frequency
High-Risk ExceptionsMonthly
Service Account ExceptionsQuarterly
Development EnvironmentSemi-annually
All Other ExceptionsAnnually

Alternative Approaches​

Beyond suppression rules, these techniques can reduce false positives:

Adjust Detection Thresholds​

Modify rule sensitivity instead of completely suppressing alerts.

Example: Authentication failure threshold

  • Too sensitive: Alert on 3 failures (many false positives)
  • Optimized: Alert on 10 failures within 5 minutes
  • Too lenient: Alert on 50 failures (missed attacks)

Environment Segmentation​

Apply different detection rules to production vs. development environments.

EnvironmentDetection Strategy
ProductionStrict detection rules, immediate alerts
StagingStandard rules, delayed notifications
DevelopmentRelaxed rules, daily digest summaries
Security ResearchMinimal detection, logging only

Correlation-Based Filtering​

Use CastellanAI's correlation engine to filter isolated events that lack supporting context.

Correlation reduces false positives by requiring:

  • Multiple related events within time window
  • Events from different detection categories
  • Unusual pattern deviations vs. baseline behavior

Best Practices​

  • Use Narrowest Scope Possible - Suppress specific host/process/user combinations instead of broad categories to minimize blind spots.

  • Set Expiration Dates - Configure suppression rules with expiration dates to force periodic review and prevent stale exceptions.

  • Monitor Suppression Impact - Track how many alerts each suppression rule blocks to identify overly broad exceptions.

  • Prefer Threshold Tuning Over Suppression - When possible, adjust detection sensitivity instead of completely suppressing alerts.

What's Next?​