Chuyển đến nội dung chính (Skip to content)
Mục lục bài viết
Security Essentials

Security Essentials 021.2: Đánh giá và Quản lý Rủi ro

Security Essentials 021.2: Đánh giá và Quản lý Rủi ro

Đánh giá rủi ro bảo mật từ tài sản, CVE và CVSS; dùng tình huống giả lập để chọn ưu tiên, ghi dữ kiện thiếu, người phụ trách và tiêu chí kiểm chứng.

Một cảnh báo chưa phải quyết định xử lý

Một cảnh báo Critical chưa cho biết máy nào bị ảnh hưởng và cần xử lý gì trước. Cần ghép thông tin lỗ hổng với tài sản, đường tiếp cận và ảnh hưởng công việc.

Bài thuộc Security Essentials 021.2, giáo trình 020-100 bản 15/04/2026, trang in 16–29, trang PDF 24–37. Mốc đối chiếu: 23/10/2026. Bạn sẽ đọc nguồn cảnh báo, tách lỗ hổng khỏi sự cố đã xác nhận và viết một quyết định ưu tiên có căn cứ. Cần nắm tài sản, CIA và vai trò ở bài trước.

Lab của bài là bài tập đánh giá trên giấy với dữ kiện giả lập. Không quét mạng, thử exploit, vá máy thật hoặc điều tra pháp y. Phương án mẫu minh họa lập luận, không thay lịch xử lý và thẩm quyền của tổ chức. Không có phép thử kỹ thuật nào được nhận là đã chạy trên ba tài sản tưởng tượng.

Tách tài sản, mối đe dọa, lỗ hổng và rủi ro

Tài sản là điều cần bảo vệ. Lỗ hổng là điểm yếu có thể bị khai thác trong điều kiện nhất định. Mối đe dọa liên quan khả năng xảy ra một sự kiện gây hại; tác nhân chỉ là một phần khi tình huống có người chủ động hành động. Rủi ro cần xét khả năng và ảnh hưởng trong bối cảnh cụ thể, cùng sự không chắc chắn của đánh giá.

Một lỗ hổng công khai không tự chứng minh máy bạn bị ảnh hưởng hoặc đã bị xâm nhập. Ngược lại, không tìm thấy mã lỗ hổng cho một cấu hình sai cũng không biến cấu hình đó thành an toàn. Hãy xác định thành phần, cách dùng, đường tiếp cận và điều kiện khai thác thay vì chỉ tìm một nhãn.

NIST SP 800-30 Rev. 1 là nguồn nền tảng về đánh giá rủi ro trong quá trình quản lý rủi ro. Bài dùng tư duy thu thập thông tin để hỗ trợ quyết định, không áp toàn bộ quy trình của hệ thống liên bang Hoa Kỳ lên một ticket Help Desk.

Mức cao/vừa/thấp cần có định nghĩa. Không nhân nhãn thứ bậc rồi coi kết quả là xác suất chính xác; ghi rõ dữ kiện thiếu và người xác nhận lại.

CVE giúp gọi đúng vấn đề, không tự xếp lịch vá

CVE Program cung cấp cách nhận diện và mô tả các lỗ hổng được công bố. Mã CVE giúp nhiều bên nói về cùng vấn đề; nó không phải một con số đo thiệt hại hoặc bằng chứng rằng mọi sản phẩm cùng nhà cung cấp đều bị ảnh hưởng.

Khi nhận cảnh báo, đọc advisory chính thức của nhà cung cấp hoặc dự án: sản phẩm, thành phần, phiên bản/build bị ảnh hưởng, điều kiện, bản sửa và biện pháp giảm thiểu. Với gói do distro bảo trì, bản vá có thể được backport; chỉ so một chuỗi phiên bản upstream đôi khi chưa đủ kết luận. Cần đối chiếu thông báo đúng nhà phân phối và bản gói thực tế.

Ghi mã cảnh báo cùng URL, ngày đọc và phiên bản thông tin. Nội dung advisory có thể được sửa khi có phát hiện mới. Nếu nguồn bị chặn hoặc thiếu dữ liệu, ghi giới hạn và tìm kênh chính thức khác.

CERT hoặc CSIRT là đầu mối thường hỗ trợ phối hợp cảnh báo, phản hồi và chia sẻ thông tin theo phạm vi trách nhiệm. Cần xác định nhóm nào tiếp nhận tình huống của mình, không mặc định một đầu mối xử lý mọi sự cố.

Dùng CVSS và KEV như đầu vào có phạm vi

FIRST mô tả CVSS v4.0 với các nhóm metric Base, Threat, Environmental và Supplemental. Một điểm số cần được đọc cùng phiên bản, vector và những nhóm metric đã dùng; hai con số thiếu ngữ cảnh không đủ để so sánh quyết định vận hành.

Base mô tả đặc tính của lỗ hổng; Threat và Environmental thêm góc nhìn về mối đe dọa và môi trường. FIRST cũng nêu việc quản lý lỗ hổng còn xét những yếu tố ngoài CVSS. Vì vậy, severity là đầu vào cho đánh giá, chưa tự quyết định tài sản nào được thay đổi trước, khi nào được dừng dịch vụ hoặc ai chấp nhận phần rủi ro còn lại.

Danh mục Known Exploited Vulnerabilities của CISA là nguồn bổ sung về những lỗ hổng đã được biết có khai thác. Kho dữ liệu do CISA duy trì cung cấp bản mirror khi cần tra cứu dữ liệu nguồn. Không có mặt trong danh mục chưa chứng minh lỗ hổng chưa từng hoặc không thể bị khai thác.

Việc có một mục KEV cũng chưa chứng minh máy cụ thể đã bị tấn công. Cần ghép với phiên bản, phơi lộ và dữ kiện tại tài sản. Nếu dùng ngày xử lý trong một chương trình quản lý của cơ quan khác, phải hiểu phạm vi áp dụng; không sao chép thành cam kết bắt buộc của mọi doanh nghiệp.

CVE nhận diện vấn đề, CVSS cung cấp severity; quyết định còn cần bối cảnh tài sản.
Hình 2. CVE nhận diện vấn đề, CVSS cung cấp severity; quyết định còn cần bối cảnh tài sản. Mở hình để xem chi tiết.

Đọc loại lỗ hổng mà không suy rộng hậu quả

Remote code execution, RCE, liên quan khả năng thực thi mã từ xa theo điều kiện lỗ hổng. Không phải mọi RCE đều không cần xác thực hoặc lập tức có root. Cần đọc điểm vào, quyền cần trước đó và danh tính tiến trình bị ảnh hưởng. Bản thân cụm từ này không thay mô tả kỹ thuật của advisory.

Privilege escalation liên quan việc đạt quyền vượt phạm vi cho phép. Nó có thể cần một điểm truy cập đã có; lỗi kiểm soát quyền cũng có thể cho phép chạm dữ liệu của người khác. Đừng mặc định một người dùng đã đăng nhập là được phép thử những hành vi này ngoài lab có ủy quyền.

Zero-day thường mô tả bối cảnh lỗ hổng chưa được biết hoặc chưa có bản sửa trong thời điểm được đề cập. Cách dùng thuật ngữ cần đọc theo nguồn và thời gian. Nó không đồng nghĩa không còn biện pháp giảm thiểu nào; nhà cung cấp có thể đề nghị giới hạn chức năng hoặc đường tiếp cận trong lúc chờ sửa.

Tấn công cơ hội có thể tự động tìm nhiều mục tiêu, nên tổ chức nhỏ vẫn cần xem phơi lộ. APT nhấn mạnh bối cảnh đối thủ có khả năng và duy trì hoạt động theo mục tiêu; không phải nhãn có thể gán chỉ vì một sự cố khó xử lý. Phân loại cần bằng chứng, không dùng để đoán người đứng sau cảnh báo.

Lab trên giấy: ba tài sản và một cảnh báo giả lập

Giả định có advisory nội bộ DEMO-ADVISORY-01, hoàn toàn hư cấu và không phải mã CVE. Nó nói thành phần mẫu phiên bản A có điểm yếu khi một chức năng mạng được bật. Bản sửa giả định đã có. Ba hàng sau là dữ kiện được cấp cho bài, không phải kết quả kiểm tra máy thật:

Tài sản Dữ kiện giả lập đã biết Điều cần đưa vào quyết định
PORTAL-A Thành phần A khớp, chức năng bật, nhận kết nối Internet, phục vụ nhóm hỗ trợ Ưu tiên xác nhận giảm phơi lộ và kế hoạch sửa có phục hồi
LAB-B Thành phần A khớp, chức năng bật, mạng lab cô lập theo sơ đồ được cung cấp Kiểm tra ranh giới cô lập còn đúng và lên kế hoạch sửa
DEVICE-C Chỉ biết tên sản phẩm, chưa rõ build hay chức năng Thu thập inventory, không tự đánh dấu đã bị ảnh hưởng hoặc miễn nhiễm

Advisory hư cấu không có CVSS chính thức. Khi giả định thay đổi, thứ tự xử lý cần được xét lại.

Thực hiện bài tập theo năm bước

  1. Xác nhận phạm vi. Ghi sản phẩm, thành phần, build, chức năng và nguồn đã dùng. Với DEVICE-C, đánh dấu thông tin chưa đủ thay vì suy từ tên.
  2. Nêu ảnh hưởng. Liên hệ bí mật, toàn vẹn, sẵn sàng với công việc thực tế của từng tài sản. Không viết chung chung “có thể mất tất cả”.
  3. Xem đường tiếp cận. Dùng dữ kiện về Internet, mạng nội bộ hoặc ranh giới lab; ghi điều cần xác nhận, không tự nhận đã kiểm chứng firewall.
  4. Đề xuất hành động và người phụ trách. Có thể gồm giảm phơi lộ được nhà cung cấp hỗ trợ, cập nhật, kiểm thử và phương án phục hồi. Thay đổi có thể gián đoạn phải có đánh giá tác động.
  5. Đặt tiêu chí kết thúc và xem lại. Xác nhận bản sửa, trạng thái chức năng, dịch vụ còn dùng được và dữ kiện nào có thể làm quyết định thay đổi.

Một phương án mẫu là chuyển PORTAL-A cho chủ dịch vụ và nhóm phụ trách ngay để đánh giá giảm phơi lộ, chuẩn bị cập nhật và phục hồi; với LAB-B, xác nhận cách ly rồi xếp lịch sửa phù hợp; với DEVICE-C, ưu tiên thu inventory có người và thời điểm phụ trách. Đây là thứ tự công việc theo giả định, không phải SLA phổ quát.

Nếu PORTAL-A không thể dừng ngay, không tự ghi “chấp nhận rủi ro” thay người có thẩm quyền. Nêu biện pháp tạm, điều chưa kiểm chứng và thời điểm đánh giá lại. Trì hoãn không có người chịu trách nhiệm hoặc không có mốc xem lại làm mất khả năng quản lý quyết định.

Xác nhận phạm vi ảnh hưởng trước khi đề xuất hành động và kiểm chứng.
Hình 1. Xác nhận phạm vi ảnh hưởng trước khi đề xuất hành động và kiểm chứng. Mở hình để xem chi tiết.

Phân biệt đánh giá, pentest và điều tra sự cố

Đánh giá bảo mật có thể xem cấu hình, inventory, lỗ hổng hoặc hiệu lực kiểm soát theo phạm vi. Pentest là một hình thức kiểm thử chủ động có mục tiêu và quyền hạn xác định; không phải yêu cầu bắt buộc để Help Desk xác nhận mọi cảnh báo. Không tải exploit rồi thử trên dịch vụ đang dùng để “chắc chắn nó lỗi”.

Pháp y số tập trung vào dữ kiện liên quan sự kiện và việc bảo quản, phân tích bằng chứng. Tự xóa log, cài lại máy hoặc chạy công cụ làm đổi dữ liệu có thể làm mất thông tin cần điều tra. Khi có dấu hiệu sự cố thực tế, chuyển theo kế hoạch phản hồi thay vì tiếp tục bài tập đánh giá lỗ hổng như thể chỉ cần vá là xong.

NIST SP 800-61 Rev. 3 là nguồn hiện hành được dùng để liên hệ phản hồi sự cố với quản lý rủi ro. Bài chỉ giới thiệu việc chuẩn bị người nhận, trách nhiệm và bằng chứng; không hướng dẫn thu thập toàn bộ bộ nhớ hay tạo ảnh đĩa pháp y. Những công việc đó cần năng lực và quy trình riêng.

Tổng quan ISO/IEC 27001:2022 mô tả ISMS ở cấp quản lý. Nó gồm trách nhiệm, quy trình và cải tiến, không phải tên phần mềm giám sát. Kế hoạch phản hồi cần làm rõ đầu mối, quyền ra quyết định, liên lạc và phục hồi. Có kế hoạch chưa chứng minh đã diễn tập hoặc được chứng nhận.

Tự kiểm tra và tiêu chí đạt

  1. Một mã CVE có chứng minh tài sản đã bị khai thác không? Không.
  2. CVSS Base có tự xếp lịch vá mọi tài sản không? Không, còn cần bối cảnh và thẩm quyền.
  3. DEVICE-C thiếu build có được ghi “không ảnh hưởng” không? Chưa có đủ bằng chứng.
  4. Cập nhật thành công đã kết thúc một sự cố đang điều tra chưa? Cần xét phạm vi xâm nhập và kế hoạch phản hồi.

Bạn đạt bài tập khi mỗi tài sản có dữ kiện, điều chưa biết, ảnh hưởng, hành động, người phụ trách và tiêu chí kiểm chứng. Phần đáp án được rà theo logic của dữ kiện giả, không phải bằng chứng đã vá, quét hay kiểm thử ba tài sản. Nội dung và hình được biên soạn độc lập theo giáo trình, đối chiếu thêm mục tiêu 021.2 của LPI. Bài sau bàn sâu hơn về quyền hành động và xử lý thông tin có trách nhiệm.

Bài liên quan trong bộ LPI

Tìm hiểu thêm