Mục tiêu chương / Learning objectives
- Mô tả cấu trúc SOC (Security Operations Center) theo 3 tầng và vai trò của từng tầng.
- Giải thích hệ thống phân cấp chính sách bảo mật: Policy → Standard → Procedure → Guideline.
- Áp dụng quy trình quản lý thay đổi (Change Management) và quản lý cấu hình (Configuration Management).
- Tính toán và diễn giải các chỉ số bảo mật: MTTD, MTTR, vulnerability density.
- Thực hiện vòng đời quản lý lỗ hổng (Vulnerability Management Lifecycle) từ quét đến xác minh.
- Liên kết các framework tuân thủ (ISO 27001, NIST CSF, SOC 2) với hoạt động vận hành thực tế.
1. Lý thuyết cốt lõi / Core theory
1.1. Security Operations Center (SOC) — Cấu trúc và vai trò
SOC là trái tim của vận hành bảo mật, hoạt động 24/7 để giám sát, phát hiện và phản ứng sự cố. Cấu trúc 3 tầng phổ biến:
- Tier 1 — Alert Analyst: Phân loại cảnh báo từ SIEM, loại bỏ false positive, leo thang sự cố lên Tier 2.
- Tier 2 — Incident Responder: Điều tra chuyên sâu, xác định phạm vi tấn công, thực hiện containment.
- Tier 3 — Threat Hunter / SME: Chủ động săn lùng mối đe dọa tiềm ẩn, phân tích malware, phát triển detection rule.
Khái niệm then chốt — Asset Inventory & CMDB: Configuration Management Database (CMDB) lưu thông tin tất cả tài sản IT (Configuration Items — CI) và mối quan hệ giữa chúng. Không có CMDB chính xác, SOC không biết bề mặt tấn công (attack surface) thực sự của tổ chức. CMDB là nền tảng để ưu tiên vá lỗ hổng: tài sản quan trọng được vá trước.
1.2. Hệ thống phân cấp chính sách bảo mật (Security Policy Hierarchy)
Bốn cấp tài liệu bảo mật từ trừu tượng nhất đến cụ thể nhất:
- Policy (Chính sách): Tuyên bố ý định cấp cao của ban lãnh đạo. Ví dụ: "Mọi dữ liệu khách hàng phải được mã hóa." Không kỹ thuật, không thay đổi thường xuyên.
- Standard (Tiêu chuẩn): Quy định cụ thể hơn để đạt policy. Ví dụ: "Mã hóa AES-256 cho dữ liệu at-rest, TLS 1.2+ cho in-transit."
- Procedure (Quy trình): Các bước thực hiện chi tiết. Ví dụ: hướng dẫn từng bước cấu hình BitLocker.
- Guideline (Hướng dẫn): Khuyến nghị không bắt buộc. Ví dụ: "Nên sử dụng password manager."
Lưu ý thi SSCP: Policy & Standard là mandatory (bắt buộc); Guideline là optional (tùy chọn). Procedure mô tả HOW, Policy mô tả WHAT và WHY.
1.3. Quản lý thay đổi và cấu hình (Change & Configuration Management)
Quy trình quản lý thay đổi (Change Management) theo ITIL bao gồm: RFC (Request For Change) → đánh giá rủi ro → phê duyệt bởi CAB (Change Advisory Board) → lập kế hoạch rollback → triển khai → xác nhận sau thay đổi (Post-Implementation Review). Emergency Change được phê duyệt nhanh nhưng vẫn phải documented sau khi triển khai — tránh "shadow IT".
Configuration Management thiết lập baseline (cấu hình an toàn chuẩn) cho từng loại thiết bị/hệ điều hành. CIS Benchmarks và DISA STIGs là nguồn baseline phổ biến. Bất kỳ sai lệch nào so với baseline cần phê duyệt và được ghi nhận.
1.4. Chỉ số bảo mật & KPIs (Security Metrics)
Các chỉ số đo lường hiệu quả SOC quan trọng nhất:
- MTTD (Mean Time To Detect): Thời gian trung bình từ khi xâm phạm xảy ra đến khi phát hiện. MTTD ngắn = phát hiện nhanh.
- MTTR (Mean Time To Respond/Recover): Thời gian trung bình từ khi phát hiện đến khi phục hồi hoàn toàn.
- False Positive Rate: Tỷ lệ cảnh báo sai — quá cao gây alert fatigue.
- Patch Compliance Rate: % hệ thống đã vá trong SLA quy định (vd 95% critical patch trong 72 giờ).
- Vulnerability Density: Số lỗ hổng / 1000 lines of code hoặc / thiết bị — đo lường hygiene tổng thể.
1.5. Vòng đời quản lý lỗ hổng & Frameworks tuân thủ (Vulnerability Management & Compliance)
Vòng đời lỗ hổng gồm 5 bước: Scan (quét bằng Nessus/Qualys/OpenVAS) → Assess (đánh giá CVSS, business context) → Prioritize (ưu tiên theo criticality & exposure) → Patch/Remediate → Verify (quét lại để xác nhận đã vá).
Các framework tuân thủ phổ biến: ISO 27001 (hệ thống quản lý bảo mật thông tin — ISMS, yêu cầu audit độc lập); NIST CSF (Identify/Protect/Detect/Respond/Recover — framework tự nguyện, phổ biến tại Mỹ); SOC 2 Type II (kiểm toán 6–12 tháng về Trust Service Criteria: Security, Availability, Confidentiality, Processing Integrity, Privacy).
Phân biệt NIST CSF vs ISO 27001: NIST CSF là framework tự nguyện, không cần chứng chỉ. ISO 27001 là tiêu chuẩn quốc tế, có thể được chứng nhận (certified) bởi tổ chức kiểm toán độc lập — giá trị thương mại cao hơn.
1.6. Tiêu chuẩn tiêu hủy dữ liệu — NIST SP 800-88 (Data Destruction Standards)
NIST SP 800-88 "Guidelines for Media Sanitization" định nghĩa 3 phương pháp tiêu hủy dữ liệu theo mức độ nhạy cảm, áp dụng khi thanh lý, tái sử dụng hoặc xử lý thiết bị lưu trữ:
| Phương pháp | Kỹ thuật (Technique) | Trường hợp sử dụng |
|---|---|---|
| Clear (Xóa thông thường) | Ghi đè bằng pattern biết trước (overwrite với 0s hoặc random data) | Phương tiện có thể tái sử dụng, dữ liệu độ nhạy cảm thấp. Phù hợp tái phân bổ nội bộ. |
| Purge (Tẩy sạch) | Cryptographic Erase (xóa khóa mã hóa) hoặc degaussing (từ tính cho HDD) | Dữ liệu độ nhạy cảm trung bình. Dùng trước khi chuyển thiết bị ra ngoài tổ chức. |
| Destroy (Phá hủy vật lý) | Nghiền nát (shred), hòa tan (disintegrate), thiêu hủy (incinerate) | Dữ liệu tối mật / cực kỳ nhạy cảm. Thiết bị không thể tái sử dụng sau thao tác này. |
Lưu ý thi SSCP: Degaussing không hiệu quả với SSD/Flash — SSD không dùng từ tính nên cần Cryptographic Erase (nếu ổ hỗ trợ) hoặc Destroy vật lý. Cryptographic Erase xóa khóa mã hóa làm cho toàn bộ dữ liệu không thể giải mã — hiệu quả và nhanh nhất với Self-Encrypting Drives (SED).
2. Bài thực hành / Hands-on labs
Lab 1 — Kiểm tra lỗ hổng cơ bản trên Windows Server (PowerShell)
OS: Windows Server 2022 · Tool: PowerShell 7 (Run as Administrator)
- Mở PowerShell với quyền Administrator. Kiểm tra log Windows Update để xem lịch sử vá:
# Xem log cập nhật Windows (có thể chậm — tạo log file mới)
Get-WindowsUpdateLog -LogPath "$env:TEMP\WULog.txt"
# Đọc 50 dòng cuối để xem các bản vá gần nhất
Get-Content "$env:TEMP\WULog.txt" -Tail 50 | Select-String "KB\d+"
# Liệt kê phần mềm đã cài — tìm phần mềm hết hạn hỗ trợ
Get-Package | Where-Object { $_.Name -like "*expired*" -or $_.Name -like "*end of life*" } | Select-Object Name, Version
# Kiểm tra dịch vụ đang chạy — quan sát dịch vụ lạ/không cần thiết
Get-Service | Where-Object { $_.Status -eq 'Running' } | Select-Object Name, DisplayName, StartType | Sort-Object Name
# Liệt kê Scheduled Tasks đang sẵn sàng — vector tấn công persistence phổ biến
Get-ScheduledTask | Where-Object { $_.State -eq 'Ready' } | Select-Object TaskName, TaskPath, State | Format-Table -AutoSize✅ Kết quả mong đợi / Expected output: Danh sách KB số hiệu các bản vá đã cài, danh sách dịch vụ running (nên so sánh với baseline), danh sách Scheduled Tasks. Ý nghĩa bảo mật: SOC Tier 1 dùng script tương tự để nhanh chóng đánh giá trạng thái patch compliance và phát hiện persistence mechanism của attacker (scheduled task lạ).
Lab 2 — Security audit Linux với Lynis (Ubuntu 22.04)
OS: Ubuntu 22.04 · Tool: Bash + Lynis (cài: sudo apt install lynis -y)
- Cài và chạy Lynis audit nhanh:
# Cài Lynis nếu chưa có
sudo apt install lynis chkrootkit -y
# Chạy audit hệ thống nhanh — in 50 dòng cuối kết quả
sudo lynis audit system --quick 2>/dev/null | tail -50
# Kiểm tra rootkit cơ bản
sudo chkrootkit 2>/dev/null | grep -v "not infected" | grep -v "^$"
# Liệt kê tất cả cron jobs hệ thống — vector persistence phổ biến
find /etc/cron* /var/spool/cron -type f 2>/dev/null | xargs ls -la 2>/dev/null
# Xem 20 lần đăng nhập gần nhất — phát hiện đăng nhập bất thường
last -n 20
# Kiểm tra port đang lắng nghe — cần tối thiểu hóa attack surface
ss -tlnp✅ Kết quả mong đợi / Expected output: Lynis in ra Hardening Index (vd 65/100) với danh sách WARNINGS và SUGGESTIONS. chkrootkit liệt kê các kiểm tra — dòng nào không phải "not infected" cần điều tra. Quan sát: Hardening Index dưới 70 cho thấy hệ thống chưa được cứng hóa đúng mức — cần lên kế hoạch remediation theo vòng đời lỗ hổng.
3. Tình huống doanh nghiệp / Real-world scenario
Bối cảnh:
Công ty fintech vừa nhận thông báo từ vendor: lỗ hổng critical (CVSS 9.8) trong phần mềm VPN client được triển khai trên 500 máy tính nhân viên. Exploit đã công khai trên internet. CISO yêu cầu SOC xử lý trong 4 giờ.
Quy trình xử lý theo Vulnerability Management Lifecycle:
- Scan: Chạy vulnerability scanner để xác định chính xác số máy bị ảnh hưởng và phiên bản VPN client.
- Assess: CVSS 9.8 + exploit public + dữ liệu tài chính → Priority: Critical. Không thể đợi maintenance window thông thường.
- Emergency Change: Tạo Emergency RFC, CISO phê duyệt thay vì chờ CAB họp định kỳ.
- Patch: Deploy patch qua SCCM/Intune. Với máy không vá được ngay: tắt VPN client, chuyển sang VPN thay thế tạm thời.
- Verify: Quét lại sau 2 giờ, xác nhận 100% máy đã vá hoặc có compensating control.
- Document: Ghi nhận Emergency Change với root cause, timeline, lessons learned vào CMDB.
Bài học: Emergency Change không có nghĩa là bỏ qua quy trình — vẫn cần phê duyệt (nhanh hơn) và documentation đầy đủ để không tạo ra "shadow changes" trong CMDB.
4. Tự kiểm tra / Knowledge check
- SOC Tier 2 khác Tier 1 như thế nào? Khi nào Tier 1 leo thang lên Tier 2?
- Phân biệt Policy và Standard. Đưa ra ví dụ cụ thể về policy mật khẩu và standard tương ứng.
- MTTD cao (vd 200 ngày) nói lên điều gì về năng lực phát hiện của SOC? Biện pháp cải thiện?
- Tại sao Emergency Change vẫn phải được documentation đầy đủ sau khi triển khai?
- ISO 27001 và NIST CSF khác nhau về tính bắt buộc và phạm vi áp dụng như thế nào?