Alerts Based on Critical Events
🌟 Objective
Prescribe practices for the definition, activation and validation of automatic alerts based on critical events, with a focus on timely detection, reduction of false positives and effective integration with the response teams.
🧬 What critical alerts are
Critical alerts are automatically generated notifications based on event patterns that indicate anomalies, security failures or undesired behaviour - requiring human validation or an immediate response.
🌟 A good alert is timely, actionable, and based on traceable and structured events.
📌 Types of events that must generate alerts
| Event type | Practical examples | Suggested severity |
|---|---|---|
| Failed authentication | Several consecutive failures from one IP or user | High / Medium |
| Privilege elevation | Profile change without a formal process | High |
| Critical changes | Permission configuration, API keys | High / Medium |
| Repeated failures | Continuous 5xx errors in an API or microservice | Medium |
| Unusual inactivity | Drop in logs from an active module | Medium / Low |
| Anomalous calls | Out-of-hours access, unusual geolocation | High / Medium |
⚠️ The set of alerts must be proportional to the application's criticality and to the sensitivity of the data processed.
🛠️ How to define an effective alert
Each alert rule must contain:
- Condition: e.g. 5 login failures within a 3-minute interval;
- Data source: log file or index in the SIEM (e.g.
auth.log); - Severity: High, Medium, Low - according to impact and urgency;
- Notification channel: e-mail, Slack, webhook, PagerDuty, etc.;
- Runbook (optional): link to a standardised response.
Example (generic YAML):
alert_name: login_failures_high
condition: count(auth.event == "login_failed") by ip > 5 in 3m
severity: high
notify: slack_channel_security
runbook: https://wiki.exemplo.org/runbooks/login-failures
🧪 Alert validation
| Technique | Description |
|---|---|
| Active simulation | Force the event in a staging environment |
| Rule unit test | Automated tests of the condition logic |
| Replay with real data | Apply the rule retroactively to historical data |
| Triage playbooks | Associate operational actions with the alert |
✅ Only validated alerts should be considered active in production.
📊 Tuning and management of false positives
Poorly calibrated alerts cause noise and discredit the system. Recommended practices:
- Define thresholds based on real data and context
- Use silencing mechanisms (e.g. snooze, threshold decay)
- Document false positives and their causes
- Review conditions periodically
💡 Per-alert statistics help to prioritise (e.g. signal/noise).
🧹 Integration with other controls
| Document | Link to this topic |
|---|---|
02-logging-centralizado.md | Defines the source events for alert generation |
06-correlacao-anomalias.md | Correlation of multiple events and domains |
05-monitorizacao-operacoes.md | Uses alerts as a response trigger |
08-matriz-controles-por-risco.md | Sets out alert requirements by criticality |
✅ Final recommendations
- Start with 5 to 10 high-value alerts (impact + frequency)
- Prioritise alerts linked to critical flows or sensitive data
- Document all rules, parameters and validations
- Integrate alerts into observability and response pipelines
🔒 An effective alerting capability is one of the pillars of operational security maturity. It must evolve on the basis of feedback, real detection and incident response.