Bài 70. Quản lý lỗ hổng (3): khắc phục và kiểm chứng: patch, compensating control, exception, rescan, báo cáo

Khóa học CompTIA Security+ SY0-801 · Phần 4: Vận hành bảo mật · Bài 70 · 🎯 Objective 4.3 · ⏱️ Đọc khoảng 17 phút · 🧪 Không cần lab · 📝 5 câu bài tập cuối bài

🎯 Mục tiêu bài học

• Biết các cách khắc phục một lỗ hổng: vá, phân đoạn, kiểm soát bù, ngoại lệ và chấp nhận rủi ro, bảo hiểm.
• Hiểu quy trình quản lý bản vá an toàn: thử nghiệm, quản lý thay đổi, triển khai theo đợt, kế hoạch quay lui.
• Nắm bước kiểm chứng: quét lại (rescan), kiểm toán, xác minh.
• Biết báo cáo lỗ hổng: nội dung, người đọc và các chỉ số theo dõi.

📎 Vị trí trong đề thi: bài này khép lại Objective 4.3 sau Bài 68 (phát hiện) và Bài 69 (phân tích, ưu tiên). Nó nối với phân đoạn mạng (Bài 42), hardening (Bài 59) và các biện pháp phòng thủ ở Bài 60 đến Bài 65. Quản lý thay đổi sẽ được học kỹ hơn ở phần Quản trị.

💡 Liên hệ thực tế: vá rồi mà vẫn dính

Nam đã xếp hạng xong danh sách lỗ hổng cho chị Lan. Máy chủ web bán hàng cần vá gấp. Nhân viên IT vá xong, đóng phiếu, báo "xong". Ba tuần sau, lần quét tiếp theo vẫn báo lỗ hổng đó. Hóa ra bản vá chỉ áp lên một trong hai máy chủ web chạy song song. Đây là tình huống minh họa, không phải vụ việc có thật.

Nam rút ra quy tắc: vá xong chưa phải xong; phải quét lại để kiểm chứng rồi mới đóng. Và với hệ thống kế toán cũ chạy phần mềm không còn nhà cung cấp hỗ trợ, không có bản vá nào để áp: lúc đó phải dùng cách ly và kiểm soát bù, kèm một ngoại lệ có thời hạn được chị Lan duyệt bằng văn bản.

🔁 Hình 70a. Nếu quét lại vẫn còn lỗ hổng, quay lại bước đầu chứ không đóng phiếu.

📘 Kiến thức cốt lõi

🛠️ Các cách khắc phục

🧰 Hình 70b. Ưu tiên sửa tận gốc; không vá được thì giảm rủi ro và ghi nhận rõ.

Nhớ rằng: kiểm soát bù và ngoại lệ không làm lỗ hổng biến mất; chúng chỉ giảm hoặc chấp nhận rủi ro còn lại, nên cần theo dõi và xem xét lại định kỳ (thường khi có bản vá hoặc khi thời hạn hết).

🩹 Quản lý bản vá an toàn

Vá không phải lúc nào cũng "bấm là xong"; một bản vá lỗi có thể làm hỏng hệ thống. Quy trình thận trọng:

1. Theo dõi bản vá từ nhà sản xuất và đối chiếu với kho kiểm kê (Bài 66) để biết bản nào áp dụng cho tài sản nào.
2. Thử nghiệm trên môi trường thử hoặc nhóm nhỏ trước khi áp rộng.
3. Quản lý thay đổi (change management): ghi lại thay đổi, lập lịch vào khung giờ phù hợp, có người duyệt, thông báo người bị ảnh hưởng.
4. Chuẩn bị quay lui (rollback): có bản sao lưu hoặc ảnh chụp hệ thống để phục hồi nếu bản vá gây lỗi (Bài 54).
5. Triển khai theo đợt: nhóm thử nghiệm trước, rồi mở rộng; hệ thống quan trọng chạy song song vá lần lượt để không gián đoạn.
6. Kiểm chứng sau khi vá.

Với bản vá khẩn (lỗ hổng đang bị khai thác ngoài đời) có thể rút ngắn quy trình nhưng không bỏ hẳn các bước thử và quay lui. Với thiết bị không còn được hỗ trợ (end-of-life), không có bản vá nào để chờ; cần kế hoạch thay thế và trong lúc đó dùng phân đoạn và kiểm soát bù.

✅ Kiểm chứng việc khắc phục

Mục đích: chắc chắn lỗ hổng đã thực sự hết, và không có hệ quả phụ.

Khi quét lại vẫn thấy lỗ hổng, quay lại phân tích: bản vá chưa áp đủ máy, cần khởi động lại, công cụ nhận nhầm (dương tính giả, Bài 69), hoặc cấu hình bị khôi phục về trạng thái cũ (drift, Bài 59). Chỉ đóng phiếu khi đã kiểm chứng.

📑 Báo cáo và theo dõi

Báo cáo biến kết quả kỹ thuật thành thông tin cho các nhóm người đọc khác nhau:

• Đội kỹ thuật: danh sách chi tiết (tài sản, lỗ hổng, cách sửa, thời hạn).
• Quản lý, lãnh đạo: bức tranh chung, xu hướng, rủi ro lớn nhất, nguồn lực cần thiết.
• Kiểm toán, tuân thủ: bằng chứng quy trình được thực hiện.

Nội dung và chỉ số thường gặp: số lỗ hổng theo mức nghiêm trọng, thời gian trung bình để khắc phục, tỷ lệ vá đúng hạn, số tồn đọng, số ngoại lệ đang mở và hạn của chúng, xu hướng qua các kỳ. Theo dõi tồn đọng và ngoại lệ quá hạn giúp phát hiện sớm việc bị trì hoãn.

Toàn bộ vòng quản lý lỗ hổng (Bài 68 đến Bài 70) lặp lại: kết quả báo cáo và kiểm chứng đưa trở lại bước phát hiện và cải thiện quy trình.

🎯 Mẹo làm bài: "Sửa tận gốc bằng bản cập nhật" → patching. "Không vá được, đặt vào vùng riêng" → segmentation. "Biện pháp thay thế khi không thể vá" → compensating control. "Chấp nhận có điều kiện, có thời hạn, có người duyệt" → exception / exemption. "Chuyển giao rủi ro tài chính" → insurance. "Chạy lại quét để xác nhận đã hết lỗ hổng" → rescan. "Kiểm tra việc tuân thủ quy trình" → audit. "Có thể gây gián đoạn, cần phê duyệt và lịch" → change management. "Phục hồi nếu bản vá gây lỗi" → rollback, backup. "Thiết bị hết hỗ trợ, không có bản vá" → thay thế, và trong lúc đó phân đoạn + kiểm soát bù.

🧠 Áp vào câu chuyện của Nam

📖 Thuật ngữ cần nhớ

📌 Tóm tắt nhanh

• Ưu tiên vá (sửa tận gốc); khi không vá được dùng phân đoạn, kiểm soát bù, và ngoại lệ có thời hạn được duyệt; bảo hiểm chỉ bổ sung.
• Vá an toàn cần thử nghiệm, quản lý thay đổi, triển khai theo đợt, kế hoạch quay lui.
• Kiểm chứng bằng quét lại, kiểm toán, xác minh; chưa kiểm chứng thì chưa đóng.
• Báo cáo theo từng nhóm người đọc, theo dõi tồn đọng, thời gian khắc phục và ngoại lệ quá hạn.
• Thiết bị hết hỗ trợ cần kế hoạch thay thế; trong lúc đó cách ly và kiểm soát bù.

💬 Hỏi & Đáp nhanh

❓ Có nên vá ngay mọi bản vá vừa ra không? Không nhất thiết "ngay", nhưng cũng không để quá lâu. Bản vá cho lỗ hổng đang bị khai thác cần nhanh; bản vá thường nên đi qua thử nghiệm và lịch thay đổi. Chính sách thường đặt thời hạn theo mức nghiêm trọng (Bài 69).

❓ Ngoại lệ có phải là "bỏ qua" lỗ hổng không? Không. Ngoại lệ là quyết định chấp nhận rủi ro có kiểm soát: có lý do, người chịu trách nhiệm duyệt, thời hạn, kiểm soát bù, và được xem xét lại. Ngoại lệ không hạn kỳ, không ai nhớ, chính là một loại rủi ro mới.

❓ Quét lại có thể thay bằng việc tin vào báo cáo của người vá? Không nên. Quét lại là bằng chứng độc lập; báo cáo của người vá có thể thiếu sót như trường hợp vá một trong hai máy chủ.

📝 Bài tập đánh giá

Tự chọn đáp án cho từng câu, rồi đối chiếu với phần đáp án ở cuối bài.

Câu 1. Sau khi áp bản vá, bước nào giúp chứng minh lỗ hổng đã thực sự được khắc phục?

• A. Đóng phiếu ngay vì bản vá đã áp
• B. Gửi email thông báo
• C. Đổi tên máy chủ
• D. Quét lại (rescan) trên hệ thống đã xử lý

Câu 2. Một hệ thống cũ đã hết hỗ trợ, không có bản vá và không thể thay ngay. Hướng xử lý hợp lý nhất trong lúc chờ thay thế là gì?

• A. Phớt lờ và không ghi lại
• B. Phân đoạn, thêm kiểm soát bù, và ghi một ngoại lệ có thời hạn được duyệt
• C. Tắt toàn bộ giám sát
• D. Cho mọi người truy cập tự do

Câu 3. Biện pháp thay thế giảm rủi ro khi không thể sửa lỗ hổng tận gốc được gọi là gì?

• A. Kiểm soát bù (compensating control)
• B. Dương tính giả
• C. Rescan
• D. Asset tag

Câu 4. Trước khi triển khai bản vá lên hệ thống quan trọng, việc nào sau đây cần có?

• A. Không cần thử, vá thẳng vào hệ thống thật
• B. Chỉ cần hỏi ý kiến một người dùng
• C. Thử nghiệm, được duyệt qua quản lý thay đổi và có kế hoạch quay lui
• D. Tắt sao lưu cho nhanh

Câu 5. Phát biểu nào đúng về ngoại lệ (exception) đối với một lỗ hổng chưa xử lý?

• A. Ngoại lệ làm lỗ hổng biến mất
• B. Không cần người duyệt
• C. Có thể kéo dài vô hạn mà không cần xem xét lại
• D. Là chấp nhận rủi ro có điều kiện, cần lý do, thời hạn, người duyệt và thường kèm kiểm soát bù

👉 Đáp án

Câu 1: D — Quét lại là bằng chứng độc lập rằng lỗ hổng đã hết; chưa kiểm chứng thì chưa đóng phiếu.

Câu 2: B — Phân đoạn, kiểm soát bù và ngoại lệ có thời hạn được duyệt, kèm kế hoạch thay thế.

Câu 3: A — Kiểm soát bù là biện pháp thay thế giảm rủi ro khi không sửa được gốc.

Câu 4: C — Cần thử nghiệm, quản lý thay đổi và kế hoạch quay lui trước khi vá hệ thống quan trọng.

Câu 5: D — Ngoại lệ là chấp nhận rủi ro có điều kiện: có lý do, thời hạn, người duyệt và kiểm soát bù, và phải được xem xét lại.

📚 Bài viết thuộc khóa học CompTIA Security+ của VNExperts

🧭 Điều hướng