Quét lỗ hổng bảo mật là gì? Quy trình, tần suất và cách đọc báo cáo
Quét lỗ hổng bảo mật là gì? Đó là việc dùng công cụ chuyên dụng rà định kỳ máy chủ, thiết bị mạng, website để tìm lỗ hổng đã được công bố, phần mềm lỗi thời và cấu hình chưa an toàn, rồi xếp mức ưu tiên để vá.
Với IT admin và giám đốc IT, câu hỏi thực tế không phải “có nên quét không” mà là quét cái gì, bao lâu một lần, đọc hàng trăm dòng kết quả thế nào và vá cái nào trước. Bài này đi qua từng bước. Khi cần làm định kỳ có chuyên gia xác minh kết quả, xem dịch vụ quét lỗ hổng bảo mật của Musk-IS.
Điểm chính
- Quét lỗ hổng tìm trên diện rộng các lỗ hổng đã biết, thường đã có mã CVE; không khai thác sâu như kiểm thử xâm nhập.
- Một chương trình quét đúng nghĩa là vòng lặp: danh mục tài sản, quét, xác minh và xếp ưu tiên, vá, quét lại. Chỉ chạy công cụ mà không quét lại thì không biết đã vá xong chưa.
- Hệ thống thông thường nên quét ít nhất mỗi quý, hệ thống quan trọng thường xuyên hơn; chuẩn PCI DSS cho ngành thẻ yêu cầu quét nội bộ và bên ngoài ít nhất ba tháng một lần.
- Thứ tự vá nên xét cùng lúc ba yếu tố: điểm CVSS, tài sản có lộ ra Internet không, và lỗ hổng đã bị khai thác thực tế chưa, ví dụ có trong danh mục KEV của CISA.
Quét lỗ hổng bảo mật là gì? Dò quét lỗ hổng làm những gì?
Quét lỗ hổng bảo mật (vulnerability scanning), còn gọi là dò quét hay rà quét lỗ hổng, là hoạt động dùng công cụ chuyên dụng, kết hợp phân tích của chuyên gia, để phát hiện lỗ hổng đã biết trên hạ tầng, mạng và ứng dụng. Kết quả là danh sách lỗ hổng có mức nghiêm trọng, tài sản bị ảnh hưởng và cách khắc phục.
Công cụ quét làm việc giống người kiểm hàng có danh sách thu hồi trong tay. Nó dò xem máy chủ đang mở những cổng nào, chạy dịch vụ gì, phiên bản bao nhiêu, rồi đối chiếu với cơ sở dữ liệu lỗ hổng đã công bố. Thấy máy chủ web chạy phiên bản có lỗ hổng đã gán mã CVE, công cụ đánh dấu và ghi kèm mức nghiêm trọng.
Những gì một lần quét thường phát hiện gồm: lỗ hổng đã công bố và có mã CVE, hệ điều hành hoặc phần mềm lỗi thời, bản vá bảo mật chưa cài, dịch vụ mạng có lỗ hổng đã biết, cổng và dịch vụ không cần thiết đang mở, cấu hình chưa an toàn như mật khẩu mặc định, giao thức mã hóa cũ, thiếu các thiết lập bảo mật trên website.
CVE (Common Vulnerabilities and Exposures) là hệ thống mã định danh chung cho lỗ hổng đã công bố, mỗi lỗ hổng có một mã dạng CVE-năm-số. Nhờ mã này, công cụ quét, nhà cung cấp phần mềm và đội IT nói về cùng một lỗ hổng mà không nhầm lẫn.
Điều quét lỗ hổng không làm là khai thác sâu. Công cụ báo “máy chủ này có thể bị lỗ hổng X”, nhưng không chứng minh kẻ tấn công thật sự đi được bao xa. Lỗi phân quyền, lỗi logic nghiệp vụ, như đổi mã số trong đường dẫn là xem được dữ liệu của người khác, hầu như không xuất hiện trong báo cáo quét.
Các loại quét lỗ hổng
Quét lỗ hổng chia theo vị trí đứng quét, theo việc có đăng nhập hay không, và theo loại đối tượng. Một chương trình đầy đủ thường kết hợp vài loại, vì mỗi loại thấy một mặt khác của hệ thống.
| Cách chia | Loại | Thấy được gì | Dùng khi |
|---|---|---|---|
| Vị trí | Quét bên ngoài (external) | Những gì kẻ tấn công từ Internet nhìn thấy: IP công khai, website, VPN, cổng mở | Theo dõi bề mặt tấn công lộ ra ngoài |
| Vị trí | Quét nội bộ (internal) | Máy chủ, máy trạm, thiết bị trong mạng nội bộ | Giả định kẻ tấn công đã vào được bên trong |
| Đăng nhập | Không xác thực | Chỉ thấy dịch vụ lộ ra ngoài, đoán phiên bản | Nhanh, ít quyền, nhưng dễ báo sai |
| Đăng nhập | Có xác thực (authenticated) | Đăng nhập vào máy để đọc chính xác phần mềm, bản vá đã cài | Kết quả chính xác hơn nhiều với máy chủ, máy trạm |
| Đối tượng | Hạ tầng và hệ điều hành | CVE, thiếu bản vá, phần mềm hết hỗ trợ | Máy chủ Windows, Linux, máy ảo |
| Đối tượng | Thiết bị mạng | Router, switch, tường lửa, VPN gateway | Hạ tầng mạng, chi nhánh |
| Đối tượng | Website, ứng dụng web | Thiết lập bảo mật HTTP, TLS/SSL, thành phần lỗi thời | Website, cổng khách hàng |
| Đối tượng | Cloud, container | Cấu hình tài khoản cloud, ảnh container có thư viện lỗi | AWS, Azure, Kubernetes |
Quét có xác thực đáng làm hơn nhiều người nghĩ. Không đăng nhập, công cụ phải đoán phiên bản qua phản hồi của dịch vụ, nên vừa bỏ sót vừa báo sai. Đăng nhập bằng một tài khoản chỉ đọc, công cụ đọc được chính xác danh sách bản vá đã cài, nên báo cáo gọn và đúng hơn hẳn.
“Quét lỗ hổng bảo mật website” là nhu cầu phổ biến nhất ở Việt Nam. Cần lưu ý quét website thường chỉ thấy lớp ngoài: phiên bản máy chủ web, plugin lỗi thời, chứng chỉ, thiết lập bảo mật. Website có đăng nhập, giỏ hàng, thanh toán thì cần thêm kiểm thử thủ công để tìm lỗi phân quyền và logic.
Quy trình quét lỗ hổng: từ danh mục tài sản đến quét lại
Quy trình quét lỗ hổng gồm 6 bước: xác định phạm vi, chuẩn bị và quét, phân tích và xác minh, lập báo cáo, hỗ trợ khắc phục, quét lại và bàn giao. Nền của cả quy trình là danh mục tài sản: tài sản nào không có trong danh mục thì không được quét, và đó thường là chỗ bị tấn công.
| Bước | Việc chính | Doanh nghiệp cần |
|---|---|---|
| 1. Xác định phạm vi | Mục tiêu, IP, tên miền, máy chủ, quét bên ngoài hay nội bộ, hệ thống nhạy cảm | Gửi danh sách IP, tên miền, máy chủ; chỉ rõ hệ thống cần lưu ý |
| 2. Chuẩn bị và quét | Cấu hình công cụ theo phạm vi, điều chỉnh tốc độ để hạn chế ảnh hưởng | Mở quyền truy cập cần thiết, xác nhận khung giờ quét |
| 3. Phân tích và xác minh | Đối chiếu CVE, CVSS, xác minh tài sản ảnh hưởng, loại bỏ cảnh báo sai | Xác nhận tình trạng thực tế của các tài sản nghi vấn |
| 4. Lập báo cáo | Tóm tắt cho lãnh đạo, phát hiện kỹ thuật, bằng chứng, xếp hạng rủi ro, danh sách ưu tiên | Xác nhận mức quan trọng của từng tài sản |
| 5. Hỗ trợ khắc phục | Giải thích phát hiện, tư vấn bản vá, nâng phiên bản, chỉnh cấu hình | Đội IT vá lỗi, chỉnh cấu hình |
| 6. Quét lại và bàn giao | Quét xác nhận, cập nhật trạng thái từng phát hiện, báo cáo cuối, đề xuất chu kỳ tiếp | Báo khi đã khắc phục xong để quét lại |
Bước 3 là chỗ phân biệt dịch vụ quét có giá trị với một bản xuất của công cụ. Công cụ hay báo sai, ví dụ thấy chuỗi phiên bản cũ trong phản hồi của dịch vụ nhưng hệ điều hành đã được nhà phân phối vá ngược (backport). Không xác minh, đội IT tốn hàng ngày trời đi “vá” những thứ đã an toàn, trong khi lỗ hổng thật nằm lẫn trong danh sách.
Bước 6 hay bị bỏ. Không quét lại thì không ai biết bản vá đã cài đúng chưa, máy nào bị sót. Trên thực tế, quét lại sau đợt vá đầu thường còn phát hiện một phần lỗ hổng chưa đóng, vì bản vá cần khởi động lại máy, hoặc máy đó không nằm trong nhóm được cập nhật tự động.
Trong vòng lặp này, danh mục tài sản cũng phải cập nhật mỗi kỳ. Máy chủ thử nghiệm dựng tạm rồi quên tắt, tên miền phụ cho chiến dịch marketing cũ, thiết bị mạng ở chi nhánh mới là những tài sản hay nằm ngoài danh mục. Một lần quét khám phá toàn bộ dải IP trước khi quét lỗ hổng giúp phát hiện các tài sản lạ này.
Với tài sản lộ ra Internet, nhiều doanh nghiệp còn theo dõi bề mặt tấn công bên ngoài một cách liên tục: tự động tìm tên miền phụ mới, chứng chỉ mới cấp, dịch vụ mới mở trên dải IP của công ty. Cách này bắt được những thứ đội IT không biết đã tồn tại, như website khuyến mãi do agency dựng hộ trên hosting riêng nhưng vẫn mang tên miền công ty.
Công cụ quét lỗ hổng bảo mật và giới hạn khi tự quét
Công cụ quét lỗ hổng phổ biến gồm nhóm thương mại như Tenable Nessus, Qualys, Rapid7 InsightVM; nhóm mã nguồn mở như OpenVAS (Greenbone), Nuclei; và các công cụ hỗ trợ như Nmap để dò cổng, OWASP ZAP để quét ứng dụng web. Chọn công cụ quan trọng ít hơn việc có người đọc kết quả và theo dõi việc vá.
| Công cụ | Loại | Dùng tốt cho | Lưu ý |
|---|---|---|---|
| Nmap | Mã nguồn mở | Dò cổng, dịch vụ, phiên bản; tìm tài sản lạ | Không phải công cụ quét lỗ hổng đầy đủ, script NSE chỉ kiểm tra được một phần |
| OpenVAS (Greenbone) | Mã nguồn mở | Quét hạ tầng, máy chủ | Cần tự cài, tự cập nhật dữ liệu lỗ hổng, đọc kết quả mất công |
| Nuclei | Mã nguồn mở | Kiểm tra nhanh theo mẫu cho website, dịch vụ web | Phụ thuộc chất lượng mẫu kiểm tra |
| OWASP ZAP | Mã nguồn mở | Quét ứng dụng web | Chế độ tấn công chủ động có thể tạo dữ liệu rác |
| Nessus, Qualys, InsightVM | Thương mại | Quét quy mô lớn, quét có xác thực, báo cáo tuân thủ | Chi phí bản quyền theo số tài sản |
“Quét lỗ hổng bảo mật bằng Nmap” là cách nhiều người bắt đầu. Nmap rất tốt để biết máy nào đang mở cổng gì, và bộ script NSE có kiểm tra được một số lỗ hổng. Nhưng Nmap không thay được công cụ quét lỗ hổng chuyên dụng với cơ sở dữ liệu cập nhật hằng ngày và khả năng quét có xác thực.
Tự quét có ba giới hạn chính. Thứ nhất là thời gian đọc kết quả: một lần quét vài trăm máy có thể ra hàng nghìn dòng, phần lớn là thông tin hoặc mức thấp. Thứ hai là cảnh báo sai mà không ai xác minh. Thứ ba là bằng chứng: khách hàng, công ty mẹ hay kiểm toán thường muốn báo cáo có phạm vi, phương pháp và kết quả quét lại rõ ràng, điều mà bản xuất tự động của công cụ miễn phí ít khi đáp ứng.
Bản miễn phí của công cụ thương mại thường giới hạn số IP và chỉ cho mục đích phi thương mại, nên đọc kỹ điều khoản bản quyền trước khi dùng cho hệ thống công ty. Nhiều doanh nghiệp chọn mô hình kết hợp: tự quét hằng tháng bằng công cụ nội bộ, mỗi quý hoặc nửa năm thuê đơn vị bên ngoài quét đầy đủ, xác minh và quét lại.
Dù tự quét hay thuê ngoài, chỉ quét hệ thống mà doanh nghiệp sở hữu hoặc được ủy quyền. Dò quét hệ thống của người khác khi chưa được cho phép có thể vi phạm pháp luật, kể cả khi mục đích là “kiểm tra giúp”.
Bao lâu nên quét lỗ hổng một lần?
Hệ thống thông thường nên quét ít nhất mỗi quý; hệ thống quan trọng, lộ ra Internet hoặc thay đổi thường xuyên thì nên quét dày hơn, như hằng tháng. Ngoài lịch định kỳ, nên quét bổ sung khi đưa hệ thống mới vào chạy, sau thay đổi lớn về hạ tầng, hoặc khi có lỗ hổng nghiêm trọng mới công bố liên quan đến phần mềm đang dùng.
| Loại hệ thống | Tần suất gợi ý | Ghi chú |
|---|---|---|
| Website, cổng khách hàng, VPN, mọi thứ lộ ra Internet | Hằng tháng, và ngay khi có lỗ hổng nghiêm trọng mới | Đây là nơi kẻ tấn công nhìn thấy trước |
| Máy chủ nội bộ quan trọng (ERP, kế toán, cơ sở dữ liệu) | Hằng tháng hoặc hằng quý, có xác thực | Kết hợp với chu kỳ vá hằng tháng |
| Máy trạm nhân viên | Hằng quý, hoặc theo dõi liên tục bằng agent | Số lượng lớn, nên tự động hóa |
| Thiết bị mạng, tường lửa, VPN gateway | Hằng quý và sau khi đổi cấu hình | Thiết bị mạng hay bị quên vá firmware |
| Hệ thống mới trước khi go-live | Một lần trước khi chạy thật | Vá xong mới mở ra Internet |
| Môi trường cho dữ liệu thẻ (PCI DSS) | Ít nhất ba tháng một lần, bên ngoài do đơn vị quét được PCI SSC công nhận (ASV) | PCI DSS v4.0.1, yêu cầu 11.3 |
Về pháp lý, pháp luật Việt Nam chưa đặt một tần suất quét cố định cho mọi doanh nghiệp. Với hệ thống thuộc phạm vi Nghị định 331/2026/NĐ-CP, khoản 3 Điều 27 đưa việc phát hiện mã độc, lỗ hổng, điểm yếu vào nội dung kiểm tra, đánh giá an ninh mạng, thực hiện định kỳ theo cấp độ và mức độ rủi ro. Hệ thống đã xác định cấp độ an toàn hệ thống thông tin càng cao thì lịch quét càng nên dày.
Với doanh nghiệp đang làm ISO 27001, biện pháp 8.8 về quản lý lỗ hổng kỹ thuật yêu cầu có thông tin về lỗ hổng, đánh giá mức độ phơi nhiễm và có biện pháp phù hợp. Báo cáo quét định kỳ kèm kết quả quét lại là bằng chứng chuyên gia đánh giá thường hỏi đầu tiên cho biện pháp này.
Đọc báo cáo quét: CVSS và thứ tự ưu tiên vá
Đọc báo cáo quét theo thứ tự: tóm tắt cho lãnh đạo và phân bố mức nghiêm trọng, rồi danh sách ưu tiên xử lý, sau cùng mới tới chi tiết kỹ thuật. Thứ tự vá nên xét cùng lúc điểm CVSS, tài sản có lộ ra Internet không, và lỗ hổng đã bị khai thác thực tế chưa.
CVSS (Common Vulnerability Scoring System) là thang điểm mức nghiêm trọng lỗ hổng do tổ chức FIRST duy trì; bản mới nhất là CVSS v4.0, công bố ngày 01/11/2023. Điểm chia năm mức: 0.0 không có, 0.1–3.9 thấp, 4.0–6.9 trung bình, 7.0–8.9 cao, 9.0–10.0 nghiêm trọng. FIRST khuyến nghị bổ sung chỉ số về mối đe dọa và môi trường ngoài điểm cơ bản để sát rủi ro thực tế hơn.
Hai nguồn nữa nên xem cùng CVSS. Danh mục KEV (Known Exploited Vulnerabilities) của CISA, cơ quan an ninh mạng Hoa Kỳ, liệt kê các lỗ hổng đã được xác nhận bị khai thác ngoài thực tế. EPSS của FIRST ước tính xác suất một CVE bị khai thác trong 30 ngày tới, dữ liệu công khai miễn phí. Bảng dưới là thứ tự ưu tiên chúng tôi gợi ý; thời hạn là mục tiêu nội bộ, không phải quy định pháp luật:
| Mức ưu tiên | Điều kiện | Cách xử lý gợi ý |
|---|---|---|
| Khẩn cấp | Có trong KEV và nằm trên hệ thống lộ ra Internet | Vá trong vài ngày; chưa vá được thì tắt dịch vụ hoặc thêm quy tắc chặn |
| Cao | CVSS từ 7.0 trên hệ thống lộ ra Internet, hoặc có trong KEV trên hệ thống nội bộ | Đưa vào đợt bảo trì gần nhất, xong trong khoảng 2 tuần |
| Trung bình | CVSS từ 7.0 trên hệ thống nội bộ, hoặc lỗ hổng mức vừa có EPSS cao | Xử lý trong chu kỳ vá của tháng |
| Thường lệ | CVSS 4.0–6.9 thông thường | Xử lý theo đợt cập nhật định kỳ, kiểm tra lại ở kỳ quét sau |
| Theo dõi | Mức thấp, hoặc hệ thống hết hỗ trợ chưa thay được | Ghi lý do chấp nhận rủi ro, biện pháp giảm thiểu, kế hoạch thay thế |
Thứ tự này thay đổi nhiều nhất với lỗ hổng điểm cao trên hệ thống nội bộ. Một máy thử nghiệm chỉ chạy trong mạng nội bộ có lỗ hổng 9.8 điểm vẫn phải vá, nhưng thường xếp sau lỗ hổng 7.5 điểm đã bị khai thác ngoài thực tế trên website công ty.
Với phát hiện mà đội IT xác nhận là cảnh báo sai, đừng chỉ xóa khỏi danh sách. Nên ghi lại lý do, bằng chứng và người xác nhận vào một sổ ngoại lệ, để kỳ quét sau không phải xác minh lại từ đầu và để chuyên gia đánh giá thấy quyết định đó có căn cứ. Sổ này cũng nên có ngày xem xét lại, vì phiên bản và cấu hình có thể thay đổi.
Khi chưa vá ngay được, biện pháp giảm thiểu tạm thời có thể là tắt tính năng bị lỗi, giới hạn địa chỉ IP được truy cập, thêm quy tắc trên tường lửa ứng dụng web, hoặc tách máy đó sang vùng mạng riêng. NIST SP 800-40 Rev. 4 về quản lý bản vá doanh nghiệp coi đây là một phần bình thường của kế hoạch xử lý, miễn là được ghi lại và có hạn xem xét lại.
Ví dụ: chương trình quét cho một công ty thương mại điện tử
Lấy ví dụ một công ty thương mại điện tử ở TP.HCM có website bán hàng, app di động, khoảng 40 máy chủ trên cloud, văn phòng 150 nhân viên dùng máy trạm Windows. Đội IT có ba người, chưa từng có chương trình quét.
Tháng đầu, việc nên làm là dò toàn bộ dải IP công khai và tên miền phụ để lập danh mục tài sản lộ ra Internet, rồi quét bên ngoài. Kết quả kiểu này thường lộ ra vài tên miền phụ cũ còn chạy, một trang quản trị mở công khai, và chứng chỉ, giao thức mã hóa cũ trên một số dịch vụ. Đây là nhóm xử lý ngay.
Từ tháng thứ hai, chương trình đi vào nhịp: website và API quét hằng tháng, máy chủ cloud quét có xác thực hằng tháng sau chu kỳ vá, máy trạm theo dõi bằng agent và báo cáo theo quý. Mỗi quý, một đơn vị bên ngoài xác minh kết quả, quét lại và ra báo cáo để gửi đối tác thanh toán. Mỗi năm một lần, công ty làm pentest cho website và API.
Sau vài kỳ, chỉ số đáng theo dõi không phải tổng số lỗ hổng, mà là thời gian trung bình từ lúc phát hiện tới lúc đóng lỗ hổng mức cao, và số lỗ hổng mức cao còn mở quá hạn. Hai con số này cho ban giám đốc biết chương trình có chạy thật hay không.
Quét lỗ hổng và pentest khác nhau thế nào?
Quét lỗ hổng dùng công cụ tìm diện rộng các lỗ hổng đã biết, hợp để làm định kỳ trên nhiều tài sản. Kiểm thử xâm nhập do chuyên gia mô phỏng tấn công trong phạm vi được ủy quyền, để chứng minh lỗ hổng khai thác được và nối được thành chuỗi tấn công nào. Hai hoạt động bổ sung cho nhau, không thay nhau.
| Tiêu chí | Quét lỗ hổng | Kiểm thử xâm nhập |
|---|---|---|
| Câu hỏi | Có lỗ hổng đã biết nào? | Lỗ hổng có bị khai thác được không, đi được bao xa? |
| Cách làm | Chủ yếu tự động, chuyên gia xác minh | Công cụ kết hợp khai thác thủ công |
| Phạm vi | Rộng, nhiều tài sản | Hẹp, hệ thống được chốt trước |
| Tần suất | Hằng tháng đến hằng quý | Hằng năm, trước go-live, sau thay đổi lớn |
| Tìm được lỗi logic, phân quyền | Hầu như không | Có |
| Đầu ra | Danh sách lỗ hổng, mức ưu tiên, kết quả quét lại | Bằng chứng khai thác, chuỗi tấn công, kiểm thử lại |
Cách chia việc hợp lý: quét định kỳ để giữ số lỗ hổng đã biết ở mức thấp, rồi mỗi năm làm pentest sâu cho hệ thống quan trọng nhất. Quét và vá trước khi pentest giúp người kiểm thử không tốn thời gian vào các lỗi cơ bản. Chi tiết về phương pháp, báo cáo và chi phí kiểm thử xâm nhập có trong bài pentest là gì.
Nếu doanh nghiệp còn chưa nắm hết tài sản và chưa biết bắt đầu từ đâu, một đợt đánh giá tổng thể an ninh mạng sẽ cho bức tranh chung về mạng, tài khoản, sao lưu, trước khi quyết định phạm vi quét. Cách đánh giá này được giải thích trong bài đánh giá an toàn thông tin là gì.
Bốn hiểu lầm về quét lỗ hổng
“Báo cáo không có lỗ hổng mức cao nghĩa là hệ thống an toàn.” Công cụ chỉ thấy những gì nằm trong phạm vi quét và có trong cơ sở dữ liệu của nó. Tài sản ngoài danh mục, lỗi logic nghiệp vụ, tài khoản bị đánh cắp đều không xuất hiện trong báo cáo.
“Vá theo điểm CVSS từ cao xuống thấp là đúng.” FIRST tự khuyến nghị thêm chỉ số mối đe dọa và môi trường. Một lỗ hổng mức cao đã bị khai thác trên website thường gấp hơn lỗ hổng điểm cao nhất trên máy nội bộ không ai truy cập.
“Mua công cụ quét là đã có quản lý lỗ hổng.” Biện pháp 8.8 của ISO/IEC 27002:2022 nhấn mạnh việc kiểm kê, đánh giá, xử lý và theo dõi liên tục, không phải bản thân công cụ. Công cụ chạy đều mà không ai giao việc vá thì lỗ hổng vẫn nằm đó qua nhiều kỳ.
“Doanh nghiệp mình không thuộc diện bắt buộc nên không cần quét.” Quy định bắt buộc chỉ áp dụng cho một số hệ thống, nhưng bảng câu hỏi bảo mật của khách hàng, kiểm toán ISO 27001 và đánh giá nhà cung cấp gần như luôn hỏi báo cáo quét định kỳ và kết quả quét lại.
Tự quét hay thuê ngoài: doanh nghiệp nên chọn thế nào?
Doanh nghiệp có vài chục tài sản và có người trong IT đọc được kết quả thì tự quét định kỳ là điểm khởi đầu hợp lý. Doanh nghiệp có nhiều tài sản lộ ra Internet, cần bằng chứng cho kiểm toán hoặc khách hàng, hay đã từng quét mà không ai theo dõi việc vá, thì thuê ngoài thường hiệu quả hơn.
Trước khi quyết định, trả lời ba câu: danh mục tài sản đã đầy đủ chưa, ai chịu trách nhiệm đọc kết quả và đôn đốc vá, và báo cáo cần nộp cho ai. Nếu cần giúp xác định phạm vi và tần suất cho hệ thống của mình, hãy nhờ chuyên gia Musk-IS rà phạm vi quét trước khi chọn công cụ hay báo giá.
Câu hỏi thường gặp về quét lỗ hổng bảo mật
Quét lỗ hổng có ảnh hưởng hệ thống đang chạy không?
Phần lớn ảnh hưởng nhỏ, nhưng không bằng không. Công cụ gửi rất nhiều yêu cầu dò, nên hệ thống cũ, thiết bị điều khiển công nghiệp hay máy chủ đang quá tải có thể chậm hoặc lỗi. Trước khi quét nên chốt phạm vi, khung giờ, tốc độ quét, loại trừ hoặc giảm cường độ với hệ thống nhạy cảm, và có người phụ trách hệ thống trực trong lúc quét.
Công cụ quét lỗ hổng miễn phí có đủ không?
Đủ cho việc tự kiểm tra phạm vi nhỏ, nếu có người đọc và xác minh kết quả. Bản miễn phí của công cụ thương mại thường giới hạn số IP và chỉ dùng phi thương mại; công cụ mã nguồn mở như OpenVAS cần tự cài và cập nhật. Khi kết quả phải nộp cho khách hàng, kiểm toán, hoặc số tài sản lớn, nên dùng công cụ thương mại hoặc thuê đơn vị chuyên nghiệp.
Báo cáo quét lỗ hổng lưu bao lâu?
Doanh nghiệp thông thường không có thời hạn lưu chung theo luật. Thông lệ là giữ ít nhất tới khi xong kỳ quét và quét lại tiếp theo, và lưu liên tục nhiều kỳ để thấy xu hướng số lỗ hổng. Doanh nghiệp có ISO 27001 nên đặt thời hạn trong thủ tục kiểm soát thông tin dạng văn bản của mình, và bảo đảm truy xuất được khi đánh giá.
Quét lỗ hổng và quản lý lỗ hổng khác nhau thế nào?
Quét lỗ hổng là một hoạt động: dùng công cụ tìm lỗ hổng tại một thời điểm. Quản lý lỗ hổng là vòng lặp liên tục gồm kiểm kê tài sản, quét, xếp ưu tiên, vá và quét lại, có người chịu trách nhiệm từng bước. Chỉ quét mà không theo dõi việc vá thì lỗ hổng vẫn tồn tại qua nhiều kỳ.
Dò quét lỗ hổng bảo mật là gì, có khác quét lỗ hổng không?
Không khác. “Dò quét”, “rà quét” hay “quét lỗ hổng bảo mật” đều là cách gọi của vulnerability scanning. Đôi khi “dò quét” được dùng riêng cho bước dò cổng, dịch vụ, phiên bản bằng công cụ như Nmap, trước khi đối chiếu với cơ sở dữ liệu lỗ hổng.
Tài liệu tham khảo
- CVSS v4.0 Specification – Thang điểm và mức nghiêm trọng lỗ hổng. FIRST · 01/11/2023
- Known Exploited Vulnerabilities Catalog – Danh mục lỗ hổng đã bị khai thác thực tế. CISA
- Exploit Prediction Scoring System (EPSS) – Xác suất lỗ hổng bị khai thác trong 30 ngày. FIRST
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning – Kế hoạch quản lý bản vá và biện pháp giảm thiểu. NIST · 04/2022
- Nghị định 331/2026/NĐ-CP về bảo vệ an ninh mạng đối với hệ thống thông tin – Điều 27 nội dung kiểm tra, đánh giá. Chính phủ · 19/08/2026
- PCI DSS Document Library – PCI DSS v4.0.1, yêu cầu 11.3 về quét lỗ hổng. PCI Security Standards Council
