Giới thiệu về Hoạt động SIEM: Hướng dẫn Thực tế cho Blue Team

Security Information and Event Management (SIEM) là nền tảng ở trung tâm của hầu hết các Security Operations Centers (SOCs). Chúng tập hợp các log, tương quan các sự kiện, và hiển thị các alert mà các nhà phân tích phải phân loại và điều tra. Hướng dẫn này hướng dẫn qua quy trình hoạt động cốt lõi để bạn có thể bắt đầu suy nghĩ như một nhà phân tích SIEM, bất kể nền tảng nào (Splunk, Elastic, Microsoft Sentinel, QRadar, v.v.) mà tổ chức của bạn sử dụng.

SIEM Thực sự Làm gì

Tại cốt lõi, một SIEM thực hiện ba công việc: thu thập log từ các endpoint, thiết bị mạng, ứng dụng và dịch vụ cloud; chuẩn hóa dữ liệu đó thành một lược đồ nhất quán; và tương quan các sự kiện bằng cách sử dụng các quy tắc phát hiện để tạo ra các alert. Các nhà phân tích sau đó xử lý các alert đó thông qua một vòng đời phân loại và điều tra. Hiểu quy trình này giúp bạn chẩn đoán các vấn đề khi dữ liệu trông không đúng hoặc các alert dường như bị thiếu.

Thiết lập các Nguồn Log

Trước khi bất kỳ logic phát hiện nào quan trọng, bạn cần dữ liệu đáng tin cậy. Các nguồn phổ biến bao gồm:

• Telemetry từ endpoint (EDR agents, Windows Event Logs qua Sysmon)
• Dữ liệu mạng (firewall logs, DNS queries, proxy logs, NetFlow)
• Authentication logs (Active Directory, VPN, SSO providers)
• Cloud audit logs (AWS CloudTrail, Azure Activity Logs, GCP Audit Logs)

Khi tích hợp một nguồn mới, xác minh độ chính xác của dấu thời gian, xác nhận rằng phân tích trường là chính xác, và kiểm tra khối lượng tiếp nhập so với các đường cơ sở dự kiến. Một bộ phân tích cấu hình sai sẽ im lặng phá vỡ các phát hiện mà không throw lỗi, vì vậy hãy thường xuyên kiểm tra các sự kiện thô so với các trường được phân tích.

Viết và Điều chỉnh các Quy tắc Phát hiện

Hầu hết các SIEM sử dụng một số hình thức tìm kiếm tương quan hoặc cú pháp quy tắc phát hiện. Một ví dụ đơn giản trong SPL của Splunk có thể trông như thế này:

index=auth sourcetype=windows EventCode=4625
| stats count by user, src_ip
| where count > 10

Điều này đánh dấu các tài khoản có hơn 10 nỗ lực đăng nhập thất bại, một chỉ báo brute-force kinh điển. Khi xây dựng các quy tắc:

1. Bắt đầu hẹp, sau đó mở rộng dựa trên tỷ lệ dương tính giả.
2. Ánh xạ từng quy tắc tới một kỹ thuật MITRE ATT&CK để theo dõi ngữ cảnh và phạm vi.
3. Ghi chép ý định của quy tắc, nguồn dữ liệu dự kiến, và các kịch bản dương tính giả đã biết.
4. Đặt các ngưỡng thực tế — quá nhạy cảm và các nhà phân tích chìm trong tiếng ồn; quá lỏng lẻo và các mối đe dọa thực sự sẽ lọt qua.

Quy trình Phân loại Alert

Khi một alert được kích hoạt, công việc của nhà phân tích là trả lời: đây có phải là độc hại không, và nó có cần được escalate không? Danh sách kiểm tra phân loại thực tế:

• Xác thực alert — xác nhận sự kiện cơ bản thực sự xảy ra và không phải là một artifact phân tích.
• Làm phong phú với ngữ cảnh — kiểm tra tính quan trọng của asset, vai trò người dùng, vị trí địa lý của source IP, và các alert liên quan gần đây trên cùng một host.
• Kiểm tra một mẫu — pivot trên người dùng, IP, hoặc hash trong một cửa sổ thời gian rộng hơn để xem liệu đây là cô lập hay là một phần của một chiến dịch rộng hơn.
• Phân loại — dương tính thực, dương tính giả, hoặc dương tính thực lành tính (hoạt động thực, nhưng không độc hại, như một script hợp pháp của quản trị viên).
• Escalate hoặc đóng — ghi chép lý do của bạn dù bằng cách nào; các alert đóng vẫn cần một lý do chính đáng rõ ràng cho các mục đích kiểm toán.

Xây dựng Dashboards Hiệu quả

Dashboards nên trả lời các câu hỏi hoạt động cụ thể, không chỉ trông ấn tượng. Các ví dụ hữu ích bao gồm:

• Các nguồn xác thực thất bại hàng đầu trong 24 giờ qua
• Khối lượng alert theo mức độ nghiêm trọng và phân công nhà phân tích
• Tình trạng nguồn dữ liệu (độ trễ tiếp nhập, đứt gãy)
• Phạm vi phát hiện được ánh xạ với các tactic ATT&CK

Tránh sự bùng nổ dashboard — một số views tín hiệu cao đánh bại hai mươi panel hiếm khi được kiểm tra.

Xử lý Mệt mỏi vì Dương tính Giả

Alert fatigue là một trong những rủi ro hoạt động lớn nhất trong một SOC. Chống lại nó bằng cách:

• Thường xuyên xem xét các alert đóng để xác định các mẫu dương tính giả lặp lại.
• Suppress hoạt động đã biết là lành tính với các ngoại lệ được ghi chép (không vô hiệu hóa quy tắc tổng quát).
• Theo dõi mean time to triage và mean time to respond như các metrics để bắt các nút cổ chai.
• Xoay vòng đánh giá quy tắc phát hiện để các quy tắc cũ, ồn ào được tinh chỉnh hoặc loại bỏ.

Tài liệu và Handoff

Mỗi cuộc điều tra nên để lại một dấu vết giấy: điều gì kích hoạt alert, điều gì được kiểm tra, kết luận nào đã được đưa ra, và bất kỳ hành động tiếp theo nào. Điều này quan trọng đối với shift handoffs, kiểm toán tuân thủ, và xây dựng kiến thức thể chế vượt qua việc thay đổi nhà phân tích. Một runbook template đơn giản cho mỗi loại alert — các bước điều tra, liên hệ escalation, và bằng chứng dự kiến — tiết kiệm thời gian đáng kể dưới áp lực.

Nhận Thực hành Hands-On

Cách nhanh nhất để xây dựng SIEM fluency là lặp lại: tiếp nhập các sample log, viết một số lượng quy tắc phát hiện so với các kỹ thuật tấn công đã biết, và thực hành toàn bộ chu kỳ phân loại từ đầu đến cuối. Các dataset miễn phí và các stack SIEM mã nguồn mở (như Elastic Stack) là các môi trường chi phí thấp tuyệt vời cho điều này.

Sẵn sàng đi sâu hơn vào các nguyên tắc cơ bản của blue team không? Khám phá các segment liên quan của Korra Studio về log analysis, incident response workflows, và detection engineering để tiếp tục xây dựng bộ kỹ năng SOC của bạn.