mcpField
B
breach-detection-system

breach-detection-system

github.com/mukul975Security32340 installsUpdated 32w ago
Repository

About breach-detection-system

An implementation guide for security and privacy response teams detecting personal data breaches. It covers SIEM, DLP, behavioral analytics, and insider threat monitoring, and connects alerts to privacy incident response.

Key features

  1. 01Classify confidentiality, integrity, and availability events
  2. 02Configure SIEM correlation rules
  3. 03Set email and endpoint DLP policies
  4. 04Establish UEBA behavioral baselines
  5. 05Connect alerts to privacy incident response

Use cases

  1. 01Design breach alerts for systems holding personal data
  2. 02Monitor unusual access and data exfiltration
  3. 03Route security alerts to a privacy incident queue
  4. 04Assess detection-to-notification response timelines

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill breach-detection-system

After installing, type/breach-detection-systemin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

assets/
template.md
references/
standards.md
workflows.md
scripts/
process.py

Details

From the project README

Implementing Breach Detection System

Overview

Effective breach detection is the prerequisite for timely Art. 33 notification. The GDPR does not prescribe specific detection technologies, but Art. 32 requires appropriate technical and organisational measures, and Art. 33(1) creates a de facto obligation to detect breaches promptly — a controller cannot notify within 72 hours if it takes months to discover a breach. This skill covers the technical architecture for personal data breach detection, including SIEM integration, DLP alerting, behavioral analytics, and insider threat monitoring.

Breach Classification Taxonomy

Level 1: CIA Triad Classification
TypeDefinitionDetection Method
ConfidentialityUnauthorized disclosure or access to personal dataDLP alerts, access log anomalies, data exfiltration detection
IntegrityUnauthorized modification of personal dataFile integrity monitoring, database audit logs, checksum validation
AvailabilityLoss of access to or destruction of personal dataSystem health monitoring, backup verification, ransomware detection
Level 2: Attack Vector Classification
VectorDescriptionPrimary Detection
External attackUnauthorized access from outside the network perimeterIDS/IPS, firewall logs, authentication failures
Insider threatAuthorized user acting beyond their authorized scopeUEBA, DLP, access pattern analysis
Third-party compromiseBreach originating from a processor or vendorVendor monitoring, API anomaly detection
Accidental disclosureHuman error leading to data exposureDLP content inspection, email gateway filters
System failureTechnical failure causing data loss or corruptionInfrastructure monitoring, backup validation
Physical breachLoss or theft of physical devices containing dataAsset tracking, device encryption verification
Level 3: Data Sensitivity Classification
LevelData TypesDetection Priority
CriticalArt. 9 special categories, Art. 10 criminal data, financial credentialsReal-time alerting, immediate escalation
HighGovernment identifiers, financial account data, authentication credentialsReal-time alerting, 15-minute escalation
MediumContact details, employment records, purchase historyNear-real-time (5-minute batching), 1-hour escalation
LowPublicly available business contact data, non-personal metadataBatch processing (hourly), daily review

SIEM Integration Architecture

Event Source Configuration

Stellar Payments Group deploys Splunk Enterprise Security as the primary SIEM platform. The following log sources are ingested for breach detection:

SourceLog TypeIngestion MethodEvents/Day
Active DirectoryAuthentication, authorization, group changesSplunk Universal Forwarder2.4M
AWS CloudTrailAPI calls, console logins, resource changesS3-to-Splunk via SQS8.7M
PostgreSQL auditQuery logs, schema changes, failed authenticationssyslog-ng to Splunk HEC14.2M
Palo Alto PA-5260Firewall sessions, URL filtering, threat preventionsyslog to Splunk45.3M
CrowdStrike FalconEndpoint detections, process execution, file writesFalcon SIEM Connector6.1M
Microsoft 365Email audit, SharePoint access, Teams DLPMicrosoft Graph API via Splunk Add-on3.8M
OktaSSO authentications, MFA events, admin changesOkta Event Hook to Splunk HEC890K
AWS GuardDutyThreat intelligence findings, anomaly detectionsCloudWatch to Splunk12K
Correlation Rules for Breach Detection
Rule 1: Mass Data Access Anomaly
Trigger: Single user account accesses more than 500 unique personal data records within a 30-minute window.
Data sources: PostgreSQL audit logs, application access logs.
Severity: High
Action: Create incident ticket, alert SOC analyst, notify DPO on-call.
False positive mitigation: Whitelist batch processing service accounts (reviewed quarterly). Flag whitelisted accounts if access occurs outside scheduled batch windows.
Rule 2: Data Exfiltration Indicator
Trigger: Outbound data transfer exceeding 50MB to an unclassified external destination from a system containing personal data.
Data sources: Palo Alto firewall, CrowdStrike network telemetry, DLP alerts.
Severity: Critical
Action: Automated network isolation of source endpoint, SOC analyst investigation, DPO notification.
False positive mitigation: Baseline normal data transfer patterns per endpoint. Whitelist approved SaaS destinations (Salesforce, Workday, etc.).
Rule 3: Privileged Account Anomaly
Trigger: Database administrator account performs SELECT queries on personal data tables outside of change management windows OR from an unrecognized source IP.
Data sources: PostgreSQL audit logs, Okta authentication logs, IP geolocation.
Severity: High
Action: Alert SOC lead and database security team. Log full query text for forensic review.
Rule 4: Ransomware Behavior Pattern
Trigger: More than 20 file rename/encrypt operations per second on file servers or database storage volumes, OR known ransomware file extension creation (.lockbit, .encrypted, .crypt).
Data sources: CrowdStrike Falcon, Windows file audit logs, storage IOPS monitoring.
Severity: Critical
Action: Automated isolation of affected system, activate incident response team, preserve forensic image.
Rule 5: Authentication Brute Force
Trigger: More than 50 failed authentication attempts against personal data systems within 10 minutes from a single source, OR more than 200 failed attempts across multiple accounts from the same source within 30 minutes (password spray).
Data sources: Active Directory, Okta, application authentication logs.
Severity: Medium (escalates to High if followed by successful authentication).
Action: Block source IP at firewall, SOC investigation, check for compromised credentials.

DLP Alert Configuration

Email DLP Policies
Policy NameDetection ContentActionSeverity
PII OutboundRegex: German ID (Personalausweisnummer), IBAN, credit card numbers, health insurance numbersBlock + encrypt + alert DPOHigh
Bulk PIIMore than 10 rows of structured personal data (name + email/phone/address) in email body or attachmentBlock + alert sender manager + SOCCritical
Special CategoryKeywords/patterns matching health diagnoses, genetic markers, biometric templates, trade union referencesBlock + alert DPOCritical
Cross-Border TransferPersonal data sent to recipients in non-adequate countries without approved transfer mechanismHold for review + alert privacy teamMedium
Endpoint DLP Policies
Policy NameDetection ContentAction
USB Copy PIICopy of files containing personal data to removable mediaBlock (exceptions via DPO-approved ticket)
Cloud Upload PIIUpload of personal data files to non-approved cloud servicesBlock + alert SOC
Print PII BulkPrint job containing more than 50 records of personal dataAlert line manager + SOC
Screenshot PIIScreen capture of application displaying personal data recordsLog + alert SOC (for pattern analysis)

Anomaly Detection and UEBA

Behavioral Baselines

User and Entity Behavior Analytics (UEBA) establishes normal patterns for each user and system account:

Baseline MetricNormal RangeAnomaly ThresholdDetection Window
Daily record access countPer-user historical average3x standard deviation above meanRolling 30-day baseline
Access time patternsHistorical working hoursAccess outside 95th percentile time rangeRolling 90-day baseline
Data download volumePer-user historical average2x standard deviation above mean for 2+ consecutive hoursRolling 14-day baseline
Geographic access locationHistorical IP geolocationNew country not seen in 90-day historyRolling 90-day baseline
Application access patternHistorical application mixAccess to new personal data application not in 60-day historyRolling 60-day baseline
Insider Threat Indicators

Composite risk scoring for insider threat detection combines multiple low-severity indicators:

IndicatorWeightSource
Access outside normal hours to personal data systems15Okta + application logs
Bulk data download from HR or customer databases25DLP + database audit
Use of personal email or cloud storage from corporate device10CrowdStrike + proxy logs
Notice period or performance improvement plan status20HR system integration (Workday)
Access to data outside role scope20Role-based access comparison
Disabling or circumventing security controls30Endpoint agent tampering alerts
Repeated failed access to restricted personal data10Application access logs

Composite scores above 60 trigger enhanced monitoring. Scores above 80 trigger SOC analyst investigation and DPO notification.

Integration with Privacy Incident Response

Automated Workflow
  1. SIEM correlation rule or DLP policy triggers an alert.
  2. Alert is enriched with contextual data: user identity, data classification of affected system, data subject count estimate.
  3. If the affected system is classified as containing personal data (tagged in the CMDB), the alert is automatically duplicated to the privacy incident queue in ServiceNow.
  4. Privacy incident coordinator performs initial triage within 30 minutes.
  5. If personal data breach is confirmed, the Art. 33 72-hour clock activation is triggered and the DPO is notified.
Detection-to-Notification Timeline Target
PhaseTargetOwner
Detection to alertUnder 5 minutesSIEM platform (automated)
Alert to triageUnder 30 minutesSOC analyst
Triage to breach confirmationUnder 4 hoursSOC lead + privacy coordinator
Breach confirmation to DPO notificationUnder 1 hourPrivacy incident coordinator
DPO notification to 72-hour clock startImmediateDPO

Monitoring and Tuning

Monthly Review Cadence
  1. Review false positive rates for all breach detection correlation rules. Target: under 15% false positive rate.
  2. Analyze detection gap assessments against known breach scenarios from EDPB Guidelines 01/2021.
  3. Update behavioral baselines following organizational changes (new hires, departures, role changes).
  4. Validate that all new personal data systems have been onboarded to the SIEM and DLP platforms.
  5. Test end-to-end detection-to-notification workflow with a simulated breach scenario quarterly.

Comments

Markdown supported