ldhnam
Công nghệ, kinh tế, và những suy nghĩ rời rạc.Technology, economics, and scattered thoughts.
← DevSecOps← DevSecOps
DevSecOpsDevSecOps19 Th7, 2026Jul 19, 202620 phút đọc15 min read

Monitoring & LoggingMonitoring & Logging

Thuộc bộ kiến thức DevSecOps Roadmap.

Tổng quan

Hệ thống nào cũng đã có monitoring và logging vì lý do vận hành — service có đang chạy không, latency có chấp nhận được không, job có chạy thành công không. Security monitoring và logging đặt ra một câu hỏi khác hẳn: có ai đó đang làm điều họ không được phép làm hay không? Hai mảng này dùng chung công cụ (cùng log pipeline, cùng dashboard) nhưng khác nhau rất lớn về mục đích, dữ liệu cần giữ lại, và thế nào là một “event đáng alert.”

Một stack monitoring thuần vận hành sẵn sàng bỏ qua một login failure coi như noise, xoay vòng (rotate) audit trail sau 3 ngày để tiết kiệm chi phí lưu trữ, hoặc thậm chí không bao giờ ghi lại “ai đã chạy lệnh này với quyền root.” Một stack monitoring thiên về security thì coi chính những chi tiết đó là sản phẩm chính: các sự kiện xác thực (authentication), leo thang đặc quyền, thay đổi cấu hình, truy cập dữ liệu, và kết nối mạng chính là nguyên liệu để phát hiện xâm nhập (compromise), lạm dụng nội bộ (insider misuse), và vi phạm chính sách — chứ không chỉ là “tỷ lệ lỗi 5xx đang tăng.”

Note này bàn về những gì cần log cho mục đích bảo mật, cách phân tích các log đó ở quy mô lớn, endpoint detection (EDR) mở rộng monitoring xuống tận cấp độ host/process như thế nào, cách quản lý khối lượng alert mà không bị chìm trong noise, và các thực hành này áp dụng cụ thể ra sao cho pipeline DevSecOps/CI-CD. Note này bổ sung cho các note monitoring vận hành ở ../backend/en/18-observability-and-monitoring.md và ../devops/en/15-monitoring-and-observability.md — đọc các note đó cho khía cạnh “hệ thống có khỏe không”; note này là khía cạnh “hệ thống có đang bị tấn công hoặc lạm dụng không.” Nội dung ở đây chảy trực tiếp vào ./14-siem-and-security-automation.md (nơi các log này được correlate và xử lý) và ./15-incident-response-and-digital-forensics.md (nơi các log này trở thành bằng chứng — evidence).

Kiến thức nền tảng

Ops monitoring vs. security monitoring

Khía cạnhOps (Observability) MonitoringSecurity Monitoring
Câu hỏi cốt lõiHệ thống có khỏe và hiệu năng tốt không?Hệ thống có đang bị lạm dụng hoặc xâm nhập không?
Tín hiệu điển hìnhLatency, error rate, throughput, saturation (các “golden signals”)Event AuthN/AuthZ, thay đổi đặc quyền, truy cập dữ liệu, hoạt động process/network bất thường
Trigger đáng lo ngạiVượt threshold, vi phạm SLOVi phạm chính sách, mẫu tấn công đã biết, hành vi bất thường so với baseline
Thời gian giữ dữ liệuVài ngày đến vài tuần (do chi phí)Nhiều tháng đến nhiều năm (do compliance và forensics)
Kỳ vọng chống giả mạoLog thường được tin tưởng nguyên trạngLog phải được bảo vệ khỏi bị chính đối tượng đang bị giám sát chỉnh sửa (kẻ tấn công có quyền truy cập sẽ cố xóa dấu vết)
Chủ sở hữuTeam SRE / platformTeam Security / SOC, với team platform là bên cung cấp dữ liệu
Ví dụ alert”p99 latency > 500ms trong 5 phút""Cùng một service account authenticate từ 2 quốc gia trong vòng 10 phút”

Cả hai mảng đều cần chung một telemetry pipeline nền tảng (log, metric, trace), nhưng security monitoring yêu cầu thêm các trường dữ liệu (ai, từ đâu, với đặc quyền gì), thời gian giữ lâu hơn, và đảm bảo tính bất biến (immutability) mà ops monitoring hiếm khi cần.

Log pipeline cho security

Một log pipeline tối thiểu có khả năng phục vụ security có bốn giai đoạn:

  1. Collection (thu thập) — các agent/forwarder (Fluent Bit, Filebeat, Vector, CloudWatch agent, auditd, osquery) chuyển các event thô từ host, container, application, thiết bị mạng, và cloud API.
  2. Centralization (tập trung hóa) — toàn bộ nguồn log đổ về một nơi duy nhất (SIEM, log aggregator, data lake) để có thể tái dựng lại dấu vết của một sự cố trên nhiều hệ thống. Một log chỉ tồn tại trên host đã bị xâm nhập là một log mà kẻ tấn công có thể xóa được.
  3. Normalization (chuẩn hóa) — các định dạng khác nhau (syslog, JSON, Windows Event Log, CloudTrail JSON, Apache combined log format) được parse về một schema chung (ví dụ ECS — Elastic Common Schema, hoặc OCSF — Open Cybersecurity Schema Framework) để có thể truy vấn cùng lúc “login thất bại” từ Okta và “login thất bại” từ SSH.
  4. Correlation (tương quan) — các rule hoặc mô hình ML nối các event qua nhiều nguồn và khung thời gian để phát hiện những mẫu mà một dòng log đơn lẻ không thể tiết lộ (ví dụ: một lần SSH login thất bại, theo sau bởi một lần login thành công từ cùng IP, rồi theo sau bởi việc tạo mới một IAM key).

Yêu cầu về retention (thời gian lưu trữ)

Thời gian phải giữ log chủ yếu do compliance quyết định, và do thời gian thực tế cần để phát hiện một breach (trung bình ngành vẫn tính bằng tuần đến tháng). Xem ./16-compliance-governance-and-risk-management.md để biết ma trận retention theo từng yêu cầu compliance (PCI-DSS, HIPAA, SOC 2, GDPR, v.v.) — quy tắc chung:

Khái niệm chính

Cần log những gì cho bảo mật

Nguyên tắc chỉ đạo: log đủ để sau này trả lời được “ai đã làm gì, với cái gì, từ đâu, khi nào, và có được phép hay không” — nhưng không log nhiều đến mức bản thân log chứa dữ liệu nhạy cảm (mật khẩu, số thẻ đầy đủ, payload PII) và trở thành một rủi ro mới.

Nguồn logCần capture những gìVì sao quan trọng với security
Authentication (SSO/IdP, SSH, DB, VPN)Thành công/thất bại, source IP, user agent, trạng thái MFA, timestampPhát hiện credential stuffing, brute force, login “impossible travel”
Authorization / access controlKiểm tra quyền, từ chối, leo thang đặc quyền, thay đổi role/groupPhát hiện lạm dụng đặc quyền, cấu hình access sai, insider threat
Hành động admin & superuserSử dụng sudo/su, thao tác admin console, chỉnh sửa IAM policy, dùng tài khoản rootTài khoản root/admin là mục tiêu giá trị cao nhất; mọi lần sử dụng phải quy trách nhiệm được
Truy cập dữ liệuĐọc/query/export bảng dữ liệu nhạy cảm, tải file, S3 object GET trên bucket nhạy cảmPhát hiện exfiltration dữ liệu và lạm dụng nội bộ
Thay đổi cấu hìnhSửa security group/firewall rule, thay đổi IAM policy, xoay vòng secret, bật/tắt feature flagPhát hiện việc can thiệp vào control, thường là hành động đầu tiên sau khi có initial access
Kết nối mạngKết nối inbound/outbound, DNS query, port/protocol bất thường, egress đến đích mớiPhát hiện C2 (command-and-control) beaconing, di chuyển ngang (lateral movement), kênh exfiltration
Process execution (host/container)Process start/stop, chuỗi parent-child, tham số command-linePhát hiện malware chạy, LOLBins (living-off-the-land binaries), reverse shell
File integrityTạo/sửa/xóa các file nhạy cảm (binary, config, crontab, SSH key)Phát hiện cơ chế persistence, can thiệp, hành vi ransomware
Event của CI/CD pipelineAi trigger build/deploy, artifact/commit nào được deploy, approval, việc truy cập secret trong lúc chạyPhát hiện can thiệp supply-chain và deploy trái phép (xem phần dưới)
Cloud control-plane API callThay đổi IAM, tạo/xóa resource, tạo key/credential (ví dụ AWS CloudTrail, GCP Audit Logs)Phát hiện account bị compromise và misconfiguration gần thời gian thực

Một mẹo dễ nhớ: AAA + DCN — AuthN, AuthZ, Admin actions, Data access, Config changes, Network connections. Nếu một nguồn log không giúp trả lời một trong sáu câu hỏi đó, nó nhiều khả năng là telemetry vận hành chứ không phải security (vẫn hữu ích, chỉ khác đối tượng sử dụng).

Ví dụ structured log

Log bảo mật nên có cấu trúc (structured — JSON hoặc schema được định nghĩa rõ ràng), không phải free-text, để có thể parse, normalize, và correlate một cách đáng tin cậy. Ví dụ: một lần SSH login thất bại rồi thành công, theo sau bởi một hành động sudo đáng ngờ, theo kiểu schema giống ECS.

{
  "@timestamp": "2026-07-19T08:12:03.501Z",
  "event": {
    "kind": "event",
    "category": ["authentication"],
    "type": ["start"],
    "outcome": "failure",
    "action": "ssh_login"
  },
  "user": {
    "name": "svc-deploy",
    "id": "1002"
  },
  "source": {
    "ip": "203.0.113.44",
    "geo": { "country_name": "Vietnam" }
  },
  "destination": {
    "ip": "10.20.4.17",
    "port": 22
  },
  "host": {
    "name": "prod-app-03",
    "os": { "family": "linux" }
  },
  "related": {
    "user": ["svc-deploy"],
    "ip": ["203.0.113.44", "10.20.4.17"]
  },
  "message": "SSH login failed: invalid password for svc-deploy from 203.0.113.44 port 51422"
}
{
  "@timestamp": "2026-07-19T08:12:47.112Z",
  "event": {
    "kind": "event",
    "category": ["process"],
    "type": ["start"],
    "outcome": "success",
    "action": "sudo_command"
  },
  "user": {
    "name": "svc-deploy",
    "effective": { "name": "root" }
  },
  "process": {
    "command_line": "sudo cat /etc/shadow",
    "parent": { "name": "bash" }
  },
  "host": { "name": "prod-app-03" },
  "source": { "ip": "203.0.113.44" },
  "message": "svc-deploy executed 'sudo cat /etc/shadow' on prod-app-03"
}

Một correlation rule trong SIEM giờ có thể nối hai event này theo user.name + host.name trong một khung thời gian ngắn và raise alert: “Login thành công ngay sau một lần thất bại trước đó, tiếp theo ngay lập tức là việc đọc file nhạy cảm qua sudo, từ một tài khoản chưa từng làm việc này.” Chính sự correlation đó — chứ không phải một dòng log riêng lẻ nào — mới là detection thật sự.

Bảng nguồn log security → phát hiện được gì

Nguồn logCác detection chính được kích hoạt
Log IdP/SSO (Okta, Azure AD, Google Workspace)Credential stuffing, impossible travel, cố bypass MFA, account takeover
Log SSH/RDPBrute force, truy cập remote trái phép, di chuyển ngang giữa các host
Cloud audit log (CloudTrail, GCP Audit Logs, Azure Activity Log)Leo thang đặc quyền IAM, tắt logging, chuẩn bị exfiltrate resource, lạm dụng tài khoản root/console
Firewall / VPC flow logPort scanning, egress bất thường, C2 beaconing, di chuyển ngang giữa các subnet
Log DNS queryMalware dùng DGA (domain generation algorithm), exfiltration dữ liệu qua DNS tunneling, phân giải domain độc hại
Log web/application (WAF, reverse proxy)Tấn công SQLi/XSS, credential stuffing vào endpoint login, scraping, path traversal
Telemetry endpoint/EDRProcess độc hại chạy, LOLBins, injection trong memory, hành vi file kiểu ransomware
File integrity monitoring (FIM)Thay đổi binary/config trái phép, cơ chế persistence, can thiệp vào công cụ bảo mật
Audit log databaseExport dữ liệu hàng loạt, lạm dụng query đặc quyền, can thiệp schema
Log CI/CD pipelineDeploy trái phép, can thiệp cấu hình pipeline, lộ secret trong build log, can thiệp supply-chain/dependency
Log container runtime (Falco, auditd trong container)Cố thoát container (container escape), spawn shell bất thường trong container, syscall privileged

Endpoint Detection and Response (EDR)

EDR là monitoring bảo mật ở cấp độ host, đi xa hơn nhiều so với antivirus (AV) dựa trên signature truyền thống. Trong khi AV truyền thống chủ yếu hash/scan file để so khớp với signature malware đã biết khi ở trạng thái nghỉ (at rest) hoặc khi thực thi, EDR liên tục quan sát hành vi của host và giữ một cửa sổ telemetry cuộn (rolling window) để analyst có thể tái dựng lại “chuyện gì đã xảy ra” sau này, chứ không chỉ là “có tồn tại một file malware đã biết hay không.”

EDR giám sát gì trên một host:

Khía cạnhAntivirus truyền thốngEDR
Cơ sở detectionSignature đã biết, hash tĩnhHành vi, dòng dõi process (process lineage), mẫu bất thường, cộng với signature
Khả năng nhìn thấyScan file khi ở trạng thái nghỉ / khi thực thiTelemetry liên tục: process, file, network, memory
Khả năng phản ứngQuarantine/xóa một fileCách ly host khỏi mạng, kill process, rollback thay đổi, remote shell để điều tra
Malware zero-day / filelessVề cơ bản không thấy đượcĐược thiết kế để bắt được qua hành vi, không chỉ signature
Giá trị forensicLịch sử tối thiểuGiữ lại timeline hoạt động host có thể tìm kiếm để điều tra
Sản phẩm tiêu biểuClamAV, các AV suite truyền thốngCrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Elastic Security, Wazuh (mã nguồn mở)

Telemetry của EDR được đổ vào cùng pipeline tập trung như mọi nguồn khác, và các detection/alert của nó là một trong những input phong phú nhất cho tầng correlation của SIEM được mô tả trong ./14-siem-and-security-automation.md.

Các loại alert, signal vs. noise, và alert fatigue

Nhiều alert hơn không đồng nghĩa với an toàn hơn — thường là ngược lại, vì analyst sẽ ngừng tin tưởng (và cuối cùng ngừng đọc) một luồng alert ồn ào. Alert fatigue là kẻ giết chết số một của các chương trình security monitoring: một SOC nhận 10.000 alert giá trị thấp mỗi ngày sẽ bỏ lỡ đúng cái alert quan trọng.

Các tier mức độ nghiêm trọng (severity) phổ biến:

TierÝ nghĩaVí dụThời gian phản ứng kỳ vọng
CriticalĐang bị xâm nhập hoặc tác động kinh doanh sắp xảy raPhát hiện hành vi file kiểu ransomware trên host productionNgay lập tức (vài phút)
HighDấu hiệu mạnh của hoạt động độc hại, cần con người triage ngayTài khoản đặc quyền login từ quốc gia mới + thiết bị mớiTrong vòng 1 giờ
MediumĐáng ngờ nhưng có lời giải thích lành tính hợp lýHành động admin bất thường nhưng không phải bất khả thi, ngoài giờ làm việcTrong ca trực / trong ngày
LowMang tính thông tin, đáng xem xét theo tổng hợp, không cần từng cái riêng lẻMột lần login thất bại đơn lẻGom lại / xem trong digest hàng ngày

Các thực hành để giữ tỷ lệ signal-to-noise cao:

Monitoring riêng cho pipeline DevSecOps

Pipeline CI/CD là hạ tầng có đặc quyền — chúng nắm giữ credential deploy, signing key, và quyền truy cập production — và một pipeline bị compromise chính là một cuộc tấn công supply-chain. Vì vậy monitoring pipeline cần các nguồn log riêng, khác với log ứng dụng:

Vì danh tính pipeline (service account, OIDC token, deploy key) là mục tiêu giá trị cao, các event authentication và authorization của chúng thuộc cùng nhóm “hành động admin” như hoạt động admin của con người — một service account hành xử bất thường xứng đáng được alert nghiêm ngặt như một tài khoản con người.

Best Practices

Tài liệu tham khảo

Part of the DevSecOps Roadmap knowledge base.

Overview

Every system already has monitoring and logging for operational reasons — is the service up, is latency acceptable, did the job succeed. Security monitoring and logging asks a different question: is someone doing something they shouldn’t be doing? The two overlap in tooling (same log pipelines, same dashboards) but diverge sharply in intent, data retained, and what counts as an “event worth alerting on.”

An ops-focused monitoring stack will happily discard a login failure as noise, rotate away an audit trail after 3 days to save storage cost, or never even capture “who ran this command as root.” A security-focused monitoring stack treats those exact details as the primary product: authentication attempts, privilege escalations, configuration changes, data access, and network connections are the raw material for detecting compromise, insider misuse, and policy violations — not just “5xx rate is up.”

This note covers what to log for security purposes, how to analyze those logs at scale, how endpoint detection (EDR) extends monitoring down to the host/process level, how to manage alert volume without drowning in noise, and how these practices apply specifically to DevSecOps/CI-CD pipelines. It complements the operational monitoring notes in ../backend/en/18-observability-and-monitoring.md and ../devops/en/15-monitoring-and-observability.md — read those for the “is it healthy” side; this note is the “is it being attacked or misused” side. It feeds directly into ./14-siem-and-security-automation.md (where these logs get correlated and actioned) and ./15-incident-response-and-digital-forensics.md (where these logs become evidence).

Fundamentals

Ops monitoring vs. security monitoring

DimensionOps (Observability) MonitoringSecurity Monitoring
Core questionIs the system healthy and performant?Is the system being abused or compromised?
Typical signalsLatency, error rate, throughput, saturation (the “golden signals”)AuthN/AuthZ events, privilege changes, data access, anomalous process/network activity
Trigger for concernThreshold breach, SLO violationPolicy violation, known attack pattern, anomaly vs. baseline behavior
Data lifespanDays to weeks (cost-driven)Months to years (compliance- and forensics-driven)
Tamper expectationsLogs can usually be trusted as-isLogs must be protected against tampering by the very actor being monitored (attacker with access will try to erase tracks)
OwnershipSRE / platform teamsSecurity / SOC teams, with platform teams as data providers
Example alert”p99 latency > 500ms for 5 minutes""Same service account authenticated from 2 countries within 10 minutes”

Both disciplines need the same underlying telemetry pipeline (logs, metrics, traces), but security monitoring asks for additional fields (who, from where, with what privilege), longer retention, and immutability guarantees that ops monitoring rarely needs.

The security logging pipeline

A minimal security-capable logging pipeline has four stages:

  1. Collection — agents/forwarders (Fluent Bit, Filebeat, Vector, CloudWatch agent, auditd, osquery) ship raw events from hosts, containers, applications, network devices, and cloud APIs.
  2. Centralization — all sources land in one place (SIEM, log aggregator, data lake) so that a single incident’s footprint across systems can be reconstructed. A log that only lives on the compromised host is a log an attacker can delete.
  3. Normalization — heterogeneous formats (syslog, JSON, Windows Event Log, CloudTrail JSON, Apache combined log format) are parsed into a common schema (e.g., ECS — Elastic Common Schema, or OCSF — Open Cybersecurity Schema Framework) so that a “failed login” from Okta and a “failed login” from SSH can be queried together.
  4. Correlation — rules or ML models join events across sources and time windows to detect patterns a single log line can’t reveal (e.g., a failed SSH login followed by a successful login from the same IP, followed by a new IAM key creation).

Retention requirements

How long logs must be kept is driven largely by compliance and by how long it realistically takes to detect a breach (industry averages are still measured in weeks to months). See ./16-compliance-governance-and-risk-management.md for the compliance-driven retention matrix (PCI-DSS, HIPAA, SOC 2, GDPR, etc.) — as a rule of thumb:

Key Concepts

What to log for security

The guiding principle: log enough to answer “who did what, to what, from where, when, and was it authorized” after the fact — without logging so much sensitive data (passwords, full card numbers, PII payloads) that the log store itself becomes a liability.

Log sourceWhat to captureWhy it matters for security
Authentication (SSO/IdP, SSH, DB, VPN)Success/failure, source IP, user agent, MFA status, timestampDetects credential stuffing, brute force, impossible-travel logins
Authorization / access controlPermission checks, denials, privilege escalation, role/group changesDetects privilege abuse, misconfigured access, insider threat
Admin & superuser actionssudo/su usage, admin console actions, IAM policy edits, root account useRoot/admin accounts are the highest-value target; every use should be attributable
Data accessRead/query/export of sensitive tables, file downloads, S3 object GETs on sensitive bucketsDetects data exfiltration and insider misuse
Configuration changesSecurity group/firewall rule edits, IAM policy changes, secret rotation, feature flag flipsDetects tampering with controls, often the first move after initial access
Network connectionsInbound/outbound connections, DNS queries, unusual ports/protocols, egress to new destinationsDetects C2 (command-and-control) beaconing, lateral movement, exfiltration channels
Process execution (host/container)Process start/stop, parent-child chain, command-line argumentsDetects malware execution, living-off-the-land binaries (LOLBins), reverse shells
File integrityCreation/modification/deletion of sensitive files (binaries, config, crontab, SSH keys)Detects persistence mechanisms, tampering, ransomware behavior
CI/CD pipeline eventsWho triggered a build/deploy, what artifact/commit was deployed, approvals, secret access during a runDetects supply-chain tampering and unauthorized deployments (see below)
Cloud control-plane API callsIAM changes, resource creation/deletion, key/credential creation (e.g., AWS CloudTrail, GCP Audit Logs)Detects account compromise and cloud misconfiguration in near real time

A useful mnemonic: AAA + DCN — AuthN, AuthZ, Admin actions, Data access, Config changes, Network connections. If a log source doesn’t help answer one of those six, it’s probably operational rather than security telemetry (still useful, just a different consumer).

Structured log example

Security logs should be structured (JSON or a well-defined schema), not free-text, so they can be parsed, normalized, and correlated reliably. Example: a failed-then-successful SSH login followed by a suspicious sudo action, in an ECS-like structure.

{
  "@timestamp": "2026-07-19T08:12:03.501Z",
  "event": {
    "kind": "event",
    "category": ["authentication"],
    "type": ["start"],
    "outcome": "failure",
    "action": "ssh_login"
  },
  "user": {
    "name": "svc-deploy",
    "id": "1002"
  },
  "source": {
    "ip": "203.0.113.44",
    "geo": { "country_name": "Vietnam" }
  },
  "destination": {
    "ip": "10.20.4.17",
    "port": 22
  },
  "host": {
    "name": "prod-app-03",
    "os": { "family": "linux" }
  },
  "related": {
    "user": ["svc-deploy"],
    "ip": ["203.0.113.44", "10.20.4.17"]
  },
  "message": "SSH login failed: invalid password for svc-deploy from 203.0.113.44 port 51422"
}
{
  "@timestamp": "2026-07-19T08:12:47.112Z",
  "event": {
    "kind": "event",
    "category": ["process"],
    "type": ["start"],
    "outcome": "success",
    "action": "sudo_command"
  },
  "user": {
    "name": "svc-deploy",
    "effective": { "name": "root" }
  },
  "process": {
    "command_line": "sudo cat /etc/shadow",
    "parent": { "name": "bash" }
  },
  "host": { "name": "prod-app-03" },
  "source": { "ip": "203.0.113.44" },
  "message": "svc-deploy executed 'sudo cat /etc/shadow' on prod-app-03"
}

A SIEM correlation rule can now join these two events by user.name + host.name within a short time window and raise: “Successful login after a prior failure, immediately followed by a sensitive file read via sudo, from an account that never does this.” That correlation — not either log line alone — is the actual detection.

Security log source → what it detects

Log sourcePrimary detections enabled
IdP/SSO logs (Okta, Azure AD, Google Workspace)Credential stuffing, impossible travel, MFA bypass attempts, account takeover
SSH/RDP logsBrute force, unauthorized remote access, lateral movement between hosts
Cloud audit logs (CloudTrail, GCP Audit Logs, Azure Activity Log)IAM privilege escalation, disabled logging, resource exfiltration setup, root/console account misuse
Firewall / VPC flow logsPort scanning, unexpected egress, C2 beaconing, lateral movement across subnets
DNS query logsDGA (domain generation algorithm) malware, data exfiltration via DNS tunneling, malicious domain resolution
Web/application access logs (WAF, reverse proxy)SQLi/XSS attempts, credential stuffing against login endpoints, scraping, path traversal
Endpoint/EDR telemetryMalicious process execution, LOLBins, in-memory injection, ransomware file behavior
File integrity monitoring (FIM)Unauthorized binary/config changes, persistence mechanisms, tampering with security tooling
Database audit logsBulk data export, privileged query abuse, schema tampering
CI/CD pipeline logsUnauthorized deploys, pipeline config tampering, secret exposure in build logs, dependency/supply-chain tampering
Container runtime logs (Falco, auditd in-container)Container escape attempts, unexpected shell spawned in a container, privileged syscalls

Endpoint Detection and Response (EDR)

EDR is host-level security monitoring that goes far beyond signature-based antivirus (AV). Where traditional AV mainly hashes/scans files against known-malware signatures at rest or on execution, EDR continuously observes host behavior and retains a rolling window of telemetry so analysts can reconstruct “what happened” after the fact, not just “was a known-bad file present.”

What EDR monitors on a host:

AspectTraditional AntivirusEDR
Detection basisKnown signatures, static hashesBehavior, process lineage, anomaly patterns, plus signatures
VisibilityFile scan at rest / on executionContinuous telemetry: process, file, network, memory
Response capabilityQuarantine/delete a fileIsolate host from network, kill process, roll back changes, remote shell for investigation
Zero-day / fileless malwareGenerally blind to itDesigned to catch it via behavior, not signature
Forensic valueMinimal historyRetains a searchable timeline of host activity for investigation
Typical productsClamAV, legacy AV suitesCrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Elastic Security, Wazuh (open source)

EDR feeds its telemetry into the same centralized pipeline as everything else, and its detections/alerts are one of the richest inputs to the SIEM correlation layer described in ./14-siem-and-security-automation.md.

Alert types, signal vs. noise, and alert fatigue

More alerts is not more security — it’s often less, because analysts stop trusting (and eventually stop reading) a noisy feed. Alert fatigue is the single biggest killer of security monitoring programs: a SOC that gets 10,000 low-value alerts a day will miss the one that matters.

Common alert severity tiers:

TierMeaningExampleExpected response time
CriticalActive compromise or imminent business impactRansomware file behavior detected on production hostImmediate (minutes)
HighStrong indicator of malicious activity, needs human triage nowPrivileged account login from new country + new deviceWithin the hour
MediumSuspicious but plausible benign explanationUnusual but not impossible admin action outside business hoursSame shift / same day
LowInformational, worth reviewing in aggregate, not individuallySingle failed login attemptBatched / reviewed in daily digest

Practices to keep signal-to-noise high:

Monitoring for DevSecOps pipelines specifically

CI/CD pipelines are privileged infrastructure — they hold deploy credentials, signing keys, and production access — and a compromised pipeline is a supply-chain attack. Pipeline monitoring therefore needs its own log sources, distinct from application logs:

Because pipeline identities (service accounts, OIDC tokens, deploy keys) are high-value targets, their authentication and authorization events belong in the same “admin actions” bucket as human admin activity — a service account behaving anomalously deserves the same alerting rigor as a human account.

Best Practices

References