Dự thảo tiêu chuẩn quốc gia về sản phẩm phòng, chống xâm nhập lớp mạng (NIPS) hiện đang ở giai đoạn lấy ý kiến, tạm mang số hiệu TCVN XXXXX:2026 với tên “An ninh mạng – Sản phẩm phòng, chống xâm nhập lớp mạng – Yêu cầu chung”. Dự thảo do Cục An ninh mạng và phòng, chống tội phạm sử dụng công nghệ cao biên soạn, Bộ Công an đề nghị, Ủy ban Tiêu chuẩn Đo lường Chất lượng Quốc gia thẩm định và Bộ Khoa học và Công nghệ công bố. Đây là văn bản thứ tư trong loạt dự thảo tiêu chuẩn an ninh mạng mà chúng tôi phân tích, sau SIEM, nền tảng tri thức mối đe dọa (TIP) và sản phẩm điều phối, tự động hoá và phản ứng (SOAR). Bài viết tóm tắt cấu trúc, phạm vi và các nhóm yêu cầu ở mức khái quát, kèm những ngưỡng và danh mục mà dự thảo ấn định trực tiếp.
1. Dự thảo này là gì và đang ở đâu
Như ba bản trước, đây là một dự thảo: số hiệu còn để trống, nội dung có thể thay đổi và dự thảo chưa có hiệu lực áp dụng. Phần “Lời nói đầu” ghi rõ cơ quan biên soạn, cơ quan đề nghị, cơ quan thẩm định và cơ quan công bố.
“Lời giới thiệu” nêu ngắn gọn mục đích: tiêu chuẩn quy định các yêu cầu kỹ thuật đối với sản phẩm NIPS nhằm nâng cao năng lực giám sát, chia sẻ thông tin và chủ động bảo vệ hệ thống trước các mối đe dọa; các cơ quan, tổ chức được khuyến khích triển khai NIPS đáp ứng tiêu chuẩn này, kết hợp đồng bộ với biện pháp quản lý, kỹ thuật và vận hành để xây dựng hệ sinh thái phòng thủ toàn diện.
Điều 2 chỉ có một câu: “Trong tiêu chuẩn này không có tài liệu nào được viện dẫn”. Tuy nhiên, cuối dự thảo vẫn có mục “Tài liệu tham khảo” gồm 11 tài liệu, đáng chú ý nhất là TCVN 14423:2026 về yêu cầu cơ bản đối với hệ thống thông tin, TCVN 12820:2020, NIST SP 800-94 về hệ thống phát hiện và phòng chống xâm nhập, ISO/IEC 27039, RFC 9411 (NetSecOPEN) và Quyết định số 1591/QĐ-BTTTT về yêu cầu kỹ thuật cơ bản đối với sản phẩm phòng, chống xâm nhập lớp mạng. Sự xuất hiện của Quyết định 1591 cho thấy đây không phải lần đầu có bộ yêu cầu kỹ thuật cho nhóm sản phẩm này; đơn vị đã đánh giá theo bộ cũ nên soát lại phần được bổ sung khi tiêu chuẩn ban hành.
Một chi tiết nhỏ nhưng cần lưu ý khi trích dẫn: dự thảo dùng cả hai cách viết “phòng, chống xâm nhập” và “phòng chống xâm nhập” ở các vị trí khác nhau, và mục lục có vài lỗi chính tả (ví dụ “actvie-standby”).
2. NIPS nằm ở đâu trong bộ tiêu chuẩn an ninh mạng
Bốn bản dự thảo chia nhau các lớp khác nhau của một hệ phòng thủ. SIEM thu thập và tương quan nhật ký sự kiện để phát hiện và cảnh báo. TIP thu thập, xử lý và chia sẻ tri thức về mối đe dọa từ nhiều nguồn. SOAR điều phối, tự động hoá và thực thi phản ứng. NIPS là lớp chặn tại chỗ: nằm trên đường truyền, phân tích sâu gói tin và ngăn chặn lưu lượng độc hại trước khi nó tới hệ thống được bảo vệ.
Quan hệ giữa chúng là hai chiều và đã được ghi thành yêu cầu. Dự thảo NIPS yêu cầu chia sẻ dữ liệu với SIEM theo định dạng chuẩn, đòi hỏi tách riêng luồng “nhật ký hệ thống/quản trị” với “nhật ký phát hiện xâm nhập”, đồng thời yêu cầu cung cấp API mở để SOAR tương tác hai chiều nhằm tự động hoá truy vấn, điều tra và thực thi hành động ngăn chặn. Ở chiều ngược lại, dự thảo SOAR cũng liệt kê NIPS trong danh sách các nền tảng phải tích hợp được. Với người mua, điều này có nghĩa NIPS không còn được chọn như một thiết bị đơn lẻ.
3. Phạm vi và cấu trúc dự thảo
Phạm vi áp dụng chỉ một câu: tiêu chuẩn quy định các yêu cầu kỹ thuật chung về an ninh mạng đối với sản phẩm phòng, chống xâm nhập lớp mạng. Dự thảo dài 25 trang với 5 điều và mục tài liệu tham khảo: Điều 1 phạm vi áp dụng; Điều 2 tài liệu viện dẫn; Điều 3 thuật ngữ, định nghĩa và chữ viết tắt; Điều 4 yêu cầu chung, quản trị và an toàn của nền tảng; Điều 5 yêu cầu về chức năng nghiệp vụ của nền tảng.
Cấu trúc của Điều 4 và Điều 5 có điểm khác ba bản trước: mỗi điều được chia thành “Khái quát” (4.1, 5.1) rồi “Yêu cầu cụ thể” (4.2, 5.2) với các mục con nhiều cấp. Khác biệt đáng chú ý nhất là dự thảo này không có phụ lục về phương pháp đánh giá, cũng không có phụ lục nào khác; trong khi dự thảo SOAR đưa ra Phụ lục A về phương pháp đánh giá và dự thảo TIP có Phụ lục A mang tính tham khảo. Vì vậy khi chuẩn bị hồ sơ đánh giá, NIPS phải dựa vào các yêu cầu trong Điều 4 và Điều 5 cùng cách hiểu thông thường, chứ không có sẵn khung phương pháp.
4. Thuật ngữ và chữ viết tắt
Điều 3 định nghĩa 23 thuật ngữ, nhiều nhất trong bốn bản dự thảo: NIPS; hệ thống phát hiện và ngăn chặn xâm nhập mạng (IDPS); bất thường/dị thường; chế độ nội tuyến (inline mode); chế độ active-active; chế độ active-standby; tầng ứng dụng; chữ ký số; chứng thư số; phân tích hồi tố; kiến trúc vi phân đoạn; container; ảo hoá; ngôn ngữ kịch bản; xác thực đa yếu tố; danh sách trắng; danh sách đen; chỉ báo xâm nhập; chế độ mở khi lỗi (fail-open); cơ chế đóng khi có lỗi (fail-close); phân tích sâu gói tin; thiết bị bảo mật phần cứng; đường cơ sở.
Danh mục thuật ngữ cho thấy dự thảo được viết cho cả hai đối tượng. Nhóm thuật ngữ vận hành (fail-open, fail-close, chế độ nội tuyến, đường cơ sở, phân tích hồi tố) phục vụ người triển khai; nhóm thuật ngữ hạ tầng (container, ảo hoá, vi phân đoạn, thiết bị bảo mật phần cứng, ngôn ngữ kịch bản) phục vụ người thiết kế kiến trúc. Việc định nghĩa rõ fail-open và fail-close là điểm thực tế, vì đây là hai lựa chọn ảnh hưởng trực tiếp đến tính liên tục của dịch vụ khi thiết bị gặp sự cố.
Danh mục chữ viết tắt gồm khoảng 20 mục, trong đó có cả NIPS và IDS/IPS, cùng các từ viết tắt của hệ sinh thái (SIEM, TI, SOAR, IoC, MFA) và của hạ tầng (API, CI/CD, DevSecOps, VM, TLS, Syslog, TCP, UDP, CPU, RAM). Sự có mặt của CI/CD và DevSecOps là dấu hiệu dự thảo được viết cho cả môi trường triển khai tự động, không chỉ thiết bị phần cứng đặt trong phòng máy.
5. Yêu cầu chung, quản trị và an toàn của nền tảng
Điều 4 gồm bốn nhóm yêu cầu, chiếm khoảng một phần ba dự thảo và quyết định thiết bị có vận hành được trong môi trường thật hay không.
| Mục | Nhóm yêu cầu | Nội dung chính |
|---|---|---|
| 4.2.1 | Tài liệu | Hướng dẫn cài đặt, triển khai, thiết lập cấu hình; hướng dẫn tinh chỉnh giảm cảnh báo sai và bỏ lọt, kèm hướng dẫn lập đường cơ sở; hướng dẫn sử dụng, phân quyền quản trị và quy trình vận hành |
| 4.2.2 | Quản trị hệ thống | Quản lý vận hành; quản trị từ xa; quản lý xác thực và phân quyền người dùng |
| 4.2.3 | Kiểm soát lỗi | Bảo vệ cấu hình; bảo vệ dữ liệu nhật ký, dữ liệu ứng dụng; đồng bộ thời gian hệ thống; sao lưu và phục hồi; cập nhật bản vá hệ thống |
| 4.2.4 | Quản lý nhật ký | Nhật ký quản trị hệ thống; nhật ký cảnh báo (phát hiện và ngăn chặn xâm nhập mạng); định dạng nhật ký; quản lý vòng đời lưu trữ nhật ký |
6. Tài liệu và quản trị vận hành
Nhóm tài liệu (4.2.1) có ba yêu cầu và đáng chú ý ở chỗ đặt tinh chỉnh lên ngang hàng với cài đặt. Bên cạnh hướng dẫn cài đặt, triển khai, thiết lập cấu hình, dự thảo yêu cầu tài liệu hướng dẫn tinh chỉnh NIPS nhằm tối ưu khả năng giám sát, giảm cảnh báo sai và giảm bỏ lọt tấn công, đồng thời hướng dẫn cách thiết lập đường cơ sở phục vụ phát hiện bất thường. Đây là nhóm tài liệu mà nhiều nhà cung cấp cung cấp sơ sài nhất, trong khi với NIPS thì chất lượng tinh chỉnh quyết định giá trị sử dụng thực tế.
Quản lý vận hành (4.2.2.1) yêu cầu thiết lập danh sách trắng và danh sách đen theo nhiều đối tượng mạng hơn: địa chỉ IP, dải IP, địa chỉ MAC và thông tin định vị địa lý; cho phép thay đổi thời gian hệ thống và thời gian duy trì phiên kết nối; thiết lập và thay đổi tham số giới hạn cho kết nối quản trị từ xa như giới hạn địa chỉ IP hoặc số phiên quản trị đồng thời; cho phép đăng xuất tài khoản đang có phiên còn hiệu lực; và cho phép tìm kiếm dữ liệu nhật ký theo từ khoá để xem lại.
7. Quản trị từ xa, xác thực và phân quyền
Quản trị từ xa (4.2.2.2) được quy định khá chặt với ba yêu cầu: hỗ trợ và bắt buộc cấu hình xác thực đa yếu tố cho mọi kết nối quản trị từ xa qua các giao thức an toàn; tự động đăng xuất và huỷ bỏ phiên quản trị khi hết thời gian duy trì; và cho phép cấu hình giới hạn IP quản trị, số lượng phiên đăng nhập cùng cơ chế chống dò đoán mật khẩu. Việc buộc MFA ở mức “mọi kết nối quản trị từ xa” là điểm mạnh so với nhiều bộ yêu cầu cũ chỉ dừng ở mức “hỗ trợ”.
Quản lý xác thực và phân quyền (4.2.2.3) yêu cầu hỗ trợ phương thức tài khoản – mật khẩu với khả năng thiết lập và thay đổi độ phức tạp của mật khẩu; phân nhóm tài khoản tối thiểu thành hai nhóm quản trị viên và người dùng thường với quyền hạn cụ thể cho từng nhóm; với nhóm có đặc quyền cao nhất, cung cấp tuỳ chọn bắt buộc kích hoạt MFA cho cả phiên đăng nhập cục bộ và từ xa; và yêu cầu xác thực lại bằng yếu tố thứ hai khi thay đổi quyền hạn tài khoản hoặc khi leo thang đặc quyền trong phiên kết nối. Yêu cầu xác thực lại khi leo thang đặc quyền là điểm mà nhiều sản phẩm hiện chưa làm đủ. Dự thảo cũng khuyến khích hỗ trợ xác thực tập trung qua LDAP, Active Directory hoặc RADIUS.
8. Kiểm soát lỗi, sao lưu và cập nhật bản vá
Bảo vệ cấu hình (4.2.3.1) yêu cầu khi NIPS phải khởi động lại do lỗi phát sinh (trừ lỗi phần cứng), bảy loại cấu hình đang áp dụng phải được lưu lại và không bị thay đổi: cấu hình NIPS; cấu hình quản trị từ xa; cấu hình tài khoản xác thực và phân quyền; cấu hình tập luật bảo vệ; danh sách trắng IP; danh sách đen IP; và danh sách các địa chỉ IP đang bị chặn kết nối. Dữ liệu nhật ký đã lưu cũng phải không đổi qua lần khởi động kế tiếp, và thời gian hệ thống phải tự đồng bộ về thời điểm hiện tại.
Sao lưu và phục hồi (4.2.3.4) yêu cầu sao lưu và phục hồi đúng bảy nhóm cấu hình và dữ liệu nói trên, với điều kiện phục hồi phải bảo đảm các cấu hình và dữ liệu được áp dụng trước thời điểm xảy ra lỗi có thể được khôi phục phù hợp. Với thiết bị nằm trên đường truyền, đây là yêu cầu tối thiểu để bảo đảm sau sự cố không bị mất chính sách bảo vệ.
Cập nhật bản vá hệ thống (4.2.3.5) gồm ba yêu cầu và là một trong những điểm đáng chú ý nhất của dự thảo: bản vá phải được kiểm tra chữ ký số của nhà sản xuất hoặc cơ chế xác thực toàn vẹn tương đương trước khi áp dụng; hệ điều hành của NIPS phải được tinh gọn, thiết lập cấu hình an toàn, loại bỏ dịch vụ và cổng kết nối không cần thiết theo các khung thực hành an toàn được công nhận; và NIPS phải có cơ chế khởi động an toàn nhằm ngăn chặn việc chèn mã độc vào tiến trình khởi động. Yêu cầu cuối cùng hướng tới nguy cơ thiết bị bảo mật bị biến thành điểm yếu trong chuỗi cung ứng.
9. Quản lý nhật ký
Nhật ký quản trị hệ thống (4.2.4.1) phải ghi sáu nhóm sự kiện: đăng nhập, đăng xuất tài khoản; xác thực trước khi cho phép truy cập tài nguyên, sử dụng chức năng; áp dụng và hoàn tác thay đổi trong cấu hình hệ thống, cấu hình quản trị từ xa, cấu hình tài khoản xác thực và phân quyền, cấu hình tập luật bảo vệ; kích hoạt lệnh khởi động lại, tắt hệ thống; thay đổi thủ công thời gian hệ thống; và thay đổi trạng thái liên kết của giao diện giám sát. Bảy trường thông tin bắt buộc gồm thời gian sinh nhật ký tới giây, địa chỉ IP hoặc định danh máy trạm, định danh tác nhân, thông tin hành vi, kết quả thành công hay thất bại, lý do giải trình đối với hành vi thất bại và phân loại theo mức độ rủi ro hoặc mức độ nghiêm trọng.
Nhóm nhật ký cảnh báo là phần đặc thù của NIPS. Nhật ký chức năng phát hiện và ngăn chặn xâm nhập mạng phải ghi mọi sự kiện hành vi xâm nhập phát hiện được với các trường: thời gian tới giây; địa chỉ IP nguồn và đích; số hiệu cổng nguồn và đích; tên giao thức; mô tả hành vi xâm nhập kèm mức độ nghiêm trọng, kết quả hành động và mã sự kiện nếu có; giao diện mạng vật lý hoặc ảo hoá nơi gói tin vi phạm được tiếp nhận; và cấu trúc dữ liệu, trường tiêu đề hoặc chuỗi văn bản cụ thể của gói tin đã kích hoạt luật bảo vệ.
Hai yêu cầu đáng chú ý hơn cả trong nhóm này: thứ nhất, nhật ký phát hiện tấn công phải bao gồm hoặc hỗ trợ ánh xạ tới các khung tiêu chuẩn phân loại kỹ thuật và chiến thuật tấn công mạng quốc tế để làm rõ ngữ cảnh rủi ro; thứ hai, NIPS phải có khả năng tự động lưu trữ và cho phép tải về gói tin thô của luồng giao tiếp trước và sau khi phát sinh cảnh báo rủi ro cao. Khả năng lấy lại gói tin thô là điều kiện để điều tra sự cố, nhưng cũng đặt ra yêu cầu về dung lượng lưu trữ và xử lý dữ liệu cá nhân có thể có trong gói tin.
Về định dạng và vòng đời, NIPS phải chuẩn hoá nhật ký theo tối thiểu một định dạng được định nghĩa trước để truyền cho các phần mềm quản lý, phân tích, điều tra; cho phép thiết lập cấu hình lưu trữ và huỷ bỏ nhật ký như ngưỡng dung lượng và thời gian lưu; cho phép tìm kiếm nhật ký theo từ khoá trên tất cả các trường, kể cả trường cấp thấp hơn; và cho phép xuất dữ liệu nhật ký để tích hợp vào SIEM hoặc giải pháp khác.
10. Bốn nhóm chức năng nghiệp vụ
Điều 5 chia chức năng nghiệp vụ thành bốn nhóm lớn, mỗi nhóm có các mục con nhiều cấp.
| Mục | Nhóm chức năng | Nội dung chính |
|---|---|---|
| 5.2.1 | Thu thập, tiếp nhận và mô hình hoá dữ liệu | Quản lý giao diện mạng; hỗ trợ giao thức mạng; nhận diện ứng dụng; nhận thức ngữ cảnh |
| 5.2.2 | Xử lý dữ liệu phân tích | Phân tích phần tiêu đề gói tin; phân tích phần dữ liệu; phát hiện tấn công trên phần dữ liệu; chuẩn hoá, tái lắp ghép và chống lẩn tránh |
| 5.2.3 | Quản lý vòng đời chỉ báo và tri thức mối đe dọa | Quản lý và cập nhật tập luật bảo vệ; danh sách trắng, danh sách đen địa chỉ IP; tập IP đang bị chặn; tích hợp tình báo mối đe dọa; phát hiện theo chữ ký và theo bất thường; quản lý tài sản và lỗ hổng |
| 5.2.4 | Chia sẻ, phân phối, tích hợp và kiểm soát sử dụng dữ liệu | Chia sẻ dữ liệu; tích hợp SIEM và các hệ thống khác; tích hợp SOAR; API và tự động hoá; tích hợp môi trường đám mây |
| 5.2.5 | Thống kê xu hướng, cảnh báo và báo cáo | Quản lý báo cáo; cơ chế thực thi bảo vệ theo thứ tự ưu tiên; danh mục dạng tấn công phải phát hiện; cảnh báo và kiểm soát lưu lượng |
| 5.2.6 | Hiệu năng xử lý, khả năng mở rộng và phục hồi | Hiệu năng xử lý; chịu lỗi vận hành; dự phòng và tính sẵn sàng; cơ chế vá lỗi ảo |
11. Thu thập, tiếp nhận và nhận thức ngữ cảnh
Nhóm đầu tiên (5.2.1) chủ yếu nói về khả năng đọc và hiểu lưu lượng. Về quản lý giao diện, NIPS phải cho phép thiết lập một hoặc nhiều giao diện giám sát ở chế độ giám sát chủ động, thụ động hoặc kết hợp cả hai, và tối thiểu một giao diện quản trị tách khỏi giao diện giám sát để quản trị hệ thống và tương tác với thiết bị mạng khác.
Về giao thức, dự thảo yêu cầu phân tích được IPv4 (RFC 791), IPv6 (RFC 8200), ICMPv4 (RFC 792), ICMPv6 (RFC 4443), TCP (RFC 9293), UDP (RFC 768), cùng các giao thức SMB, DCERPC, DNS và HTTP. Điểm đáng chú ý là yêu cầu hỗ trợ nhận diện và phân tích tối thiểu với bốn giao thức công nghiệp phổ biến: Modbus TCP, DNP3, IEC 60870-5-104 và MQTT. Với các cơ sở sản xuất, điện lực, nước và toà nhà thông minh, việc ghi tên các giao thức này trong tiêu chuẩn là tín hiệu quan trọng, vì thiết bị IT thuần tuý thường không đọc được chúng.
Về nhận diện ứng dụng (5.2.1.3), dự thảo yêu cầu nhận diện, phân tích và áp dụng luật kiểm soát lưu lượng dựa trên đặc điểm kỹ thuật và bản chất ứng dụng ở tầng ứng dụng, sử dụng các kỹ thuật kiểm tra sâu như phân tích hành vi suy luận và đối sánh mẫu, bảo đảm độc lập và chính xác cả khi ứng dụng dùng cổng TCP/UDP phi tiêu chuẩn, cổng chia sẻ hoặc thay đổi cổng động. Về nhận thức ngữ cảnh (5.2.1.4), thiết bị phải tích hợp được thông tin định danh và vai trò người dùng gắn với phiên kết nối, đặc điểm nhận dạng thiết bị đầu cuối, tình trạng thiết bị và thông tin định vị địa lý vào tập luật bảo vệ và quá trình phân tích sự kiện.
12. Phân tích gói tin và chống kỹ thuật lẩn tránh
Nhóm xử lý dữ liệu (5.2.2) là phần kỹ thuật sâu nhất của dự thảo và cũng là phần phân biệt NIPS với thiết bị tường lửa thông thường. Về phân tích tiêu đề, dự thảo liệt kê tường minh các trường phải đọc được với từng giao thức: với IPv4 gồm Version, Header Length, Packet Length, ID, Flags, Fragment Offset, Time to Live, Protocol, Header Checksum, địa chỉ nguồn, địa chỉ đích và Options; với IPv6 gồm Version, Payload Length, Next Header, Hop Limit, địa chỉ nguồn, địa chỉ đích và Routing Header; với ICMPv4 và ICMPv6 gồm Type, Code và Header Checksum; với TCP gồm mười một trường từ Source Port, Destination Port, Sequence Number, Acknowledgment Number tới Flags, Window, Checksum, Urgent Pointer và Options; với UDP gồm Source Port, Destination Port, Payload Length và Checksum.
Về phân tích phần dữ liệu, dự thảo yêu cầu đọc chuỗi dữ liệu sau phần tiêu đề và kiểm tra theo đặc thù giao thức, ví dụ với FTP là danh sách lệnh như USER, PASS, RETR, STOR, LIST, CWD, với HTTP là phương thức GET, phương thức POST và so khớp nội dung trên URL/URI và nội dung trang, với SMTP là các trạng thái start, commands, mail header, mail body và abort. NIPS cũng phải duy trì bảng máy trạng thái cho các giao thức ứng dụng để nhận diện và ngăn chặn giao tiếp vi phạm trình tự hợp lệ của ngữ cảnh giao thức, và phải cung cấp ngôn ngữ kịch bản cho phép tự định nghĩa bộ bóc tách để kiểm tra sâu dữ liệu của giao thức hoặc ứng dụng đặc thù.
Phần chuẩn hoá, tái lắp ghép và chống lẩn tránh (5.2.2.4) gồm bảy yêu cầu và là một trong những điểm mạnh của dự thảo: tái tổ hợp các phân mảnh IP; tái tổ hợp luồng TCP, xử lý gói lỗi tuần tự và loại bỏ gói TCP trùng lặp hoặc giả mạo; giải mã trước khi xử lý các phần dữ liệu bị xáo trộn hoặc mã hoá trước khi quét chữ ký; hỗ trợ giải mã nội tuyến để kiểm tra sâu với luồng mã hoá mà không làm suy giảm nghiêm trọng băng thông; tích hợp với hệ thống quản lý khoá mật mã chuyên dụng hoặc thiết bị bảo mật phần cứng để bảo vệ vòng đời khoá; cơ chế huỷ khoá an toàn khi thay đổi cấu hình hoặc gỡ bỏ chứng thư số, bảo đảm dữ liệu giải mã trong quá khứ không thể bị khôi phục trái phép; và khả năng trích xuất, phân tích siêu dữ liệu của luồng mã hoá như thông tin chứng thư số, chuẩn mã hoá, băm dấu vân tay máy khách và máy chủ để phát hiện lưu lượng sinh ra từ mã độc hoặc công cụ lẩn tránh mà không cần giải mã toàn bộ dữ liệu tải.
Yêu cầu cuối cùng đáng được đọc kỹ vì nó phản ánh thực tế phần lớn lưu lượng hiện nay đã mã hoá. Thay vì buộc giải mã tất cả, dự thảo cho phép phân tích dấu vân tay và siêu dữ liệu TLS, đồng thời vẫn yêu cầu năng lực giải mã nội tuyến khi cần. Cách viết hai lớp này cho thấy dự thảo tính đến cả hai hướng triển khai: nơi có pháp lý và hạ tầng để giải mã, và nơi chỉ có thể phân tích metadata.
13. Quản lý tập luật, tri thức mối đe dọa và phát hiện
Nhóm vòng đời chỉ báo và tri thức (5.2.3) gồm tám mục. Quản lý tập luật bảo vệ (5.2.3.1) yêu cầu đủ bảy thao tác: thêm luật mới, tinh chỉnh luật, tìm kiếm luật, xoá luật, kích hoạt hoặc vô hiệu hoá luật, xuất tập luật ra tệp tin và khôi phục tập luật từ tệp tin.
Cập nhật tập luật (5.2.3.2) yêu cầu tự động thông báo khi có bản cập nhật mới, cho phép tải về trực tuyến và áp dụng thủ công bản cập nhật, và với tập luật do nhà sản xuất phát hành thì phải kiểm tra chữ ký số tệp tải về hoặc cơ chế xác thực tương đương, kèm khả năng khôi phục tập luật khi cập nhật lỗi.
Quản lý danh sách trắng và danh sách đen địa chỉ IP (5.2.3.3) yêu cầu thêm, xoá, sửa địa chỉ hoặc dải địa chỉ; tìm kiếm theo địa chỉ hoặc dải địa chỉ; thiết lập hành động kiểm soát lưu lượng với địa chỉ hoặc dải địa chỉ; kích hoạt hoặc vô hiệu hoá hành động kiểm soát đang áp dụng; xuất và khôi phục danh sách từ tệp tin; và với danh sách trắng thì cho phép thiết lập, thay đổi thời hạn hiệu lực. Chi tiết cuối cùng đáng lưu ý vì danh sách trắng không có thời hạn là một trong những khoảng trống bị khai thác phổ biến nhất.
Quản lý tập địa chỉ IP đang bị chặn kết nối (5.2.3.4) yêu cầu tìm kiếm theo địa chỉ IP hoặc từ khoá; xem thông tin của một địa chỉ đang bị chặn, tối thiểu gồm thời điểm bắt đầu chặn, khoảng thời gian chặn có hiệu lực tính từ thời điểm bắt đầu và số hiệu định danh của luật gây ra việc chặn; và huỷ chặn đối với một hoặc nhiều địa chỉ cùng lúc. Với thiết bị chặn tự động, việc biết chính xác luật nào gây ra lệnh chặn là điều kiện để xử lý nhanh khi chặn nhầm đối tác.
Tích hợp thông tin tình báo mối đe dọa (5.2.3.5) yêu cầu tiếp nhận và tự động cập nhật chỉ báo xâm nhập từ nguồn tình báo bên ngoài mà không cần cập nhật toàn bộ tập luật, và hỗ trợ tiếp nhận luồng dữ liệu tình báo theo định dạng tiêu chuẩn quốc tế hoặc tiêu chuẩn tương đương. Phát hiện dựa trên chữ ký (5.2.3.6) yêu cầu phát hiện và ngăn chặn bằng đối sánh với cơ sở dữ liệu chữ ký tấn công đã biết; cho phép quản trị viên tùy biến và gán các tập chữ ký khác nhau cho từng giao diện mạng, phân đoạn mạng hoặc chiều lưu lượng; và hỗ trợ các định dạng chữ ký tiêu chuẩn phổ biến để định nghĩa luật bảo vệ thủ công.
Phát hiện dựa trên sự bất thường (5.2.3.7) gồm bốn yêu cầu: hỗ trợ xây dựng và định nghĩa đường cơ sở lưu lượng; tự động sinh cảnh báo và kích hoạt hành động ngăn chặn với sự cố bất thường dựa trên giới hạn thông lượng, tần suất sự kiện và thời điểm bất thường trong ngày; ứng dụng thuật toán học máy để phân tích đặc điểm nhận dạng và phát hiện hành vi liên lạc bất thường, điển hình như thuật toán sinh tên miền tự động, liên lạc với máy chủ điều khiển hoặc kỹ thuật truyền dữ liệu nhỏ giọt; và phân tích hồi tố, cho phép tự động đối chiếu dấu hiệu thỏa hiệp cùng tập luật mới với kho nhật ký và siêu dữ liệu mạng trong quá khứ. Phân tích hồi tố là điểm mạnh về mặt khái niệm, nhưng cũng là yêu cầu nặng về lưu trữ và năng lực tính toán. Cuối nhóm, hỗ trợ quản lý tài sản và lỗ hổng (5.2.3.8) yêu cầu tích hợp thông tin tài sản, cấu hình và lỗ hổng bảo mật để phân tích ngữ cảnh sự cố.
14. Chia sẻ, tích hợp với SIEM, SOAR và môi trường đám mây
Nhóm chia sẻ và tích hợp (5.2.4) là cầu nối giữa NIPS và phần còn lại của hệ sinh thái. Về chia sẻ dữ liệu, NIPS phải hỗ trợ tối thiểu một định dạng chuẩn trong số Syslog, CEF, LEEF hoặc JSON, và truyền nhật ký qua kênh an toàn có mã hoá như TLS hoặc tương đương.
Với tích hợp SIEM (5.2.4.2), dự thảo yêu cầu khả năng kết nối với nhiều loại hệ thống SIEM để chia sẻ dữ liệu, và đặc biệt yêu cầu phân định rõ ràng và cung cấp cấu hình luồng dữ liệu độc lập giữa “nhật ký hệ thống/quản trị” và “nhật ký phát hiện xâm nhập” khi chia sẻ với SIEM bên ngoài. Đây là yêu cầu thực tế: trộn hai loại nhật ký vào một luồng làm tăng nhiễu và khó phân tích ở phía SIEM, đồng thời ảnh hưởng đến việc phân quyền xem dữ liệu. NIPS cũng phải kết nối được với các hệ thống giám sát, phân tích và điều tra an ninh mạng khác thông qua định dạng dữ liệu tiêu chuẩn được hỗ trợ.
Với SOAR (5.2.4.3), NIPS phải cung cấp API mở cho phép tương tác hai chiều để tự động hoá truy vấn thông tin, điều tra sự cố và thực thi hành động ngăn chặn. Yêu cầu API và tự động hoá (5.2.4.4) bổ sung hai điểm: API an toàn hỗ trợ tự động hoá cấu hình, cập nhật tập luật bảo vệ và tích hợp với đường ống triển khai liên tục CI/CD; và việc tích hợp API phải hỗ trợ xác thực, phân quyền và bảo vệ kênh truyền.
Về môi trường đám mây (5.2.4.5), dự thảo yêu cầu hỗ trợ triển khai dưới dạng máy ảo hoặc kiến trúc vùng chứa; tự động áp dụng đường cơ sở bảo mật khi hạ tầng mở rộng hoặc thu hẹp quy mô; và giám sát, bảo vệ lưu lượng mạng nội bộ qua các cảm biến phân tán hoặc tích hợp với kiến trúc vi phân đoạn. Ba yêu cầu này cho thấy dự thảo không chỉ nhắm tới thiết bị đặt tại chỗ.
15. Báo cáo, thứ tự ưu tiên thực thi và danh mục tấn công
Quản lý báo cáo (5.2.5.1) yêu cầu giao diện đồ hoạ cho phép tạo mới, xem lại và xoá báo cáo; tạo báo cáo theo mẫu định nghĩa trước; áp dụng quy tắc tìm kiếm thông tin, dữ liệu log để thêm, lọc và tinh chỉnh nội dung báo cáo; chọn định dạng tệp xuất ra đáp ứng tối thiểu hai trong các định dạng WORD, EXCEL, PDF, HTML, XML; và tải về tệp báo cáo đã xuất.
Cơ chế thực thi bảo vệ (5.2.5.2) yêu cầu NIPS phân tích lưu lượng theo đúng thứ tự ưu tiên xử lý của tập luật bảo vệ, danh sách trắng và danh sách đen đã cấu hình, trong đó tối thiểu một thứ tự đã được nhà sản xuất cấu hình mặc định. Trong thực tế, thứ tự áp dụng giữa luật, danh sách trắng và danh sách đen quyết định kết quả cuối cùng khi một địa chỉ xuất hiện ở cả hai danh sách, nên việc buộc công bố thứ tự mặc định là điểm có giá trị khi đánh giá.
Phát hiện các dạng tấn công (5.2.5.3) là một trong những phần cụ thể nhất của dự thảo: trong môi trường kiểm thử, NIPS phải phát hiện tối thiểu 17 dạng tấn công lớp mạng phổ biến, gồm tấn công IP Fragments Overlap như Teardrop, Bonk/Boink; tấn công có địa chỉ IP nguồn và đích trùng nhau như Land; Fragmented ICMP Traffic như Nuke; Large ICMP Traffic như Ping of Death; tấn công TCP NULL flags; TCP SYN+FIN flags; TCP FIN flags; TCP SYN+RST flags; UDP Bomb; UDP Chargen DoS; Flooding a host như Smurf, Ping Flood, SYN Flood; Flooding a network; IP protocol scanning; TCP port scanning; UDP port scanning; và ICMP scanning. Danh mục này hữu ích cho cả nhà sản xuất lẫn đơn vị kiểm thử, vì nó là danh sách kiểm tra tối thiểu có thể tái lập.
Về cảnh báo và kiểm soát lưu lượng (5.2.5.4), NIPS phải sinh cảnh báo cho các sự kiện phát hiện, ngăn chặn xâm nhập và sự cố bất thường; cho phép thiết lập hành động kiểm soát lưu lượng và khoảng thời gian hiệu lực cho từng luật bảo vệ với tối thiểu một trong các hành động: cho phép tiếp tục kết nối; gửi gói TCP RST về phía nguồn; gửi gói TCP RST về phía đích; gửi ICMP Destination Unreachable; hoặc loại bỏ gói tin không phản hồi. Hai hành động gửi TCP RST chỉ áp dụng cho luật tương ứng với lưu lượng TCP. Khi vận hành ở chế độ giám sát chủ động, NIPS phải cho phép chặn kết nối theo địa chỉ IP nguồn phát sinh sự kiện hoặc theo địa chỉ IP đích phát sinh sự kiện.
16. Hiệu năng, chịu lỗi, dự phòng và vá lỗi ảo
Về hiệu năng (5.2.6.1), dự thảo chọn cách giao việc công bố cho nhà sản xuất nhưng ràng buộc cách đo: NIPS phải được triển khai theo đúng cấu hình phần cứng tối thiểu đã công bố trong tài liệu hướng dẫn cài đặt; nhà sản xuất phải công bố các thông số hiệu năng tối thiểu tương ứng, tối thiểu gồm số lượng kết nối trên giây và số lượng kết nối đồng thời tối đa; và việc đánh giá hiệu năng băng thông, độ trễ phải được tiến hành bằng các bài kiểm tra áp dụng lưu lượng hỗn hợp ở lớp 7 như HTTP/HTTPS. Thiết bị được coi là đáp ứng nếu kết quả đo không thấp hơn thông số đã công bố. Cách viết này vừa cho phép sản phẩm khác nhau về hiệu năng, vừa chặn tình trạng công bố một đằng đo một nẻo.
Về chịu lỗi vận hành (5.2.6.2), có ba yêu cầu: khi gặp lỗi trong quá trình vận hành ở chế độ giám sát chủ động, NIPS phải tự động kích hoạt chức năng bỏ qua kiểm soát đồng thời cho phép quản trị viên kích hoạt thủ công, và khi kích hoạt phải sinh cảnh báo và ghi nhật ký; thiết bị phải cấu hình được fail-open hoặc fail-close; và khi vận hành ở chế độ fail-close, phải có cơ chế ngăn chặn hoàn toàn lưu lượng đi qua giao diện nội tuyến nếu chức năng kiểm tra sâu bị gián đoạn, đồng thời bắt buộc sinh cảnh báo khi tài nguyên phần cứng gồm CPU, RAM và phiên kết nối đạt tới hạn mức tối đa.
Về dự phòng (5.2.6.3), NIPS phải hỗ trợ triển khai theo kiến trúc dự phòng cụm ở tối thiểu một trong hai chế độ Active-Active hoặc Active-Passive, và trong quá trình chuyển đổi dự phòng phải có cơ chế đồng bộ trạng thái để bảo đảm các phiên kết nối mạng đang hợp lệ không bị gián đoạn. Điểm đáng lưu ý là dự thảo không ấn định con số thời gian chuyển đổi, mà đặt yêu cầu ở mức “không làm gián đoạn phiên hợp lệ”, tiêu chí này cần được thống nhất bằng kịch bản kiểm thử cụ thể khi đánh giá.
Cơ chế vá lỗi ảo (5.2.6.4) là một trong những yêu cầu mới so với các bộ yêu cầu cũ: NIPS phải cung cấp cơ chế vá lỗi ảo cho phép áp dụng các luật bảo vệ được ánh xạ trực tiếp tới các mã lỗ hổng bảo mật phổ biến, và có khả năng đề xuất hoặc tự động kích hoạt luật vá lỗi ảo tương ứng dựa trên cấu hình hệ điều hành và ứng dụng mục tiêu đang được bảo vệ. Với các hệ thống không thể vá ngay, ví dụ hệ điều hành cũ trong dây chuyền sản xuất, đây là yêu cầu có giá trị thực tế.
17. Một điểm biên tập nên lưu ý
Khi đọc dự thảo, có một điểm về cách đặt tên cần lưu ý để không suy luận sai về nội dung. Các tiêu đề của Chương 5 dùng cụm từ mang hơi hướng tình báo như “thu thập, tiếp nhận và mô hình hoá dữ liệu tình báo”, “xử lý dữ liệu tình báo” hay “quản lý vòng đời chỉ báo và tri thức mối đe dọa”, trong khi phần nội dung bên dưới là các yêu cầu kỹ thuật NIPS cụ thể như quản lý giao diện mạng, phân tích tiêu đề gói tin, tập luật bảo vệ và kiểm soát lưu lượng. Nói cách khác, với Chương 5 của dự thảo này, cần đọc theo nội dung chứ không chỉ theo tên mục.
Điểm thứ hai là dự thảo không ghi rõ phương pháp đánh giá và không có phụ lục kỹ thuật, khác với bản SOAR. Vì vậy khi chuẩn bị, nên thống nhất trước với bên đánh giá về cách kiểm chứng từng nhóm yêu cầu, đặc biệt là các yêu cầu định tính như “giảm cảnh báo sai và giảm bỏ lọt”, “không gián đoạn phiên hợp lệ” hay “không làm suy giảm nghiêm trọng băng thông”.
18. Doanh nghiệp và tổ chức cần chuẩn bị gì
Với nhà sản xuất và nhà cung cấp giải pháp NIPS, cần soát theo bốn lớp: tài liệu, trong đó tài liệu tinh chỉnh và hướng dẫn lập đường cơ sở thường bị bỏ qua; quản trị và an toàn, chú ý các yêu cầu dạng bắt buộc như MFA cho mọi kết nối quản trị từ xa, xác thực lại khi leo thang đặc quyền, kiểm tra chữ ký số cho bản vá và tập luật, cùng cơ chế khởi động an toàn; chức năng nghiệp vụ, đặc biệt phần chống lẩn tránh, tái lắp ghép, phân tích siêu dữ liệu luồng mã hoá và phân tích hồi tố; và hiệu năng, nơi phải công bố cấu hình phần cứng tối thiểu cùng thông số kết nối trên giây, kết nối đồng thời và đo bằng lưu lượng hỗn hợp lớp 7.
Với tổ chức triển khai, nên chuẩn bị trước những gì tiêu chuẩn sẽ đòi: danh mục giao diện và phân đoạn mạng, trong đó giao diện quản trị phải tách khỏi giao diện giám sát; phương án fail-open hay fail-close cho từng vị trí triển khai, vì hai lựa chọn này đánh đổi giữa an toàn và liên tục dịch vụ; kế hoạch tách luồng nhật ký quản trị và nhật ký phát hiện khi gửi về SIEM; chính sách lưu gói tin thô và xử lý dữ liệu cá nhân có thể xuất hiện trong gói tin; và với cơ sở có hệ thống công nghiệp, danh mục thiết bị dùng Modbus TCP, DNP3, IEC 60870-5-104 và MQTT.
Với đơn vị kiểm thử và đánh giá, hướng chuẩn bị nằm ở ba việc: xây bộ kịch bản cho 17 dạng tấn công được liệt kê; thiết kế bài đo lưu lượng hỗn hợp lớp 7 để kiểm chứng thông số hiệu năng nhà sản xuất công bố; và xây kịch bản chuyển đổi dự phòng để kiểm chứng yêu cầu không gián đoạn phiên hợp lệ. Với người mua, ở giai đoạn này dự thảo phù hợp nhất để dùng làm danh sách câu hỏi đánh giá nhà cung cấp, đặc biệt ở phần chống lẩn tránh, phân tích luồng mã hoá và vá lỗi ảo.
19. Câu hỏi thường gặp
Dự thảo đã có hiệu lực chưa?
Chưa. Dự thảo đang ở giai đoạn lấy ý kiến và thẩm định, tạm mang số hiệu TCVN XXXXX:2026, nội dung có thể thay đổi trước khi công bố.
Tiêu chuẩn này có bắt buộc áp dụng không?
Tiêu chuẩn quốc gia áp dụng tự nguyện, chỉ trở thành bắt buộc khi được viện dẫn trong văn bản quy phạm pháp luật, quy chuẩn kỹ thuật, hợp đồng hoặc hồ sơ dự án.
Dự thảo NIPS khác gì dự thảo SIEM, TIP và SOAR?
Bốn bản nói về bốn lớp khác nhau trong cùng một hệ phòng thủ: SIEM phát hiện trên dữ liệu nhật ký, TIP quản lý tri thức mối đe dọa, SOAR thực thi và điều phối phản ứng, còn NIPS phân tích sâu gói tin và ngăn chặn ngay trên đường truyền. Dự thảo NIPS cũng là bản duy nhất trong bốn bản định nghĩa fail-open, fail-close và chế độ nội tuyến.
Dự thảo có phụ lục phương pháp đánh giá không?
Không. Khác với bản SOAR có Phụ lục A về phương pháp đánh giá, bản NIPS không có phụ lục nào; các yêu cầu nằm trọn trong Điều 4 và Điều 5.
Các con số nêu trong bài đã là cuối cùng chưa?
Chưa. Bài viết ghi lại nội dung và các danh mục có trong dự thảo tại thời điểm phân tích; khi tiêu chuẩn được ban hành, cần đối chiếu với văn bản chính thức.
20. Đọc kèm
- Dự thảo TCVN về SIEM: yêu cầu chung cho sản phẩm quản lý và phân tích sự kiện an ninh mạng
- Dự thảo TCVN về TIP: yêu cầu chung cho nền tảng tri thức mối đe dọa an ninh mạng
- Dự thảo TCVN về SOAR: yêu cầu chung cho sản phẩm điều phối, tự động hoá và phản ứng an ninh mạng
- Thông tư 125/2026/TT-BCA: camera giám sát vào danh mục sản phẩm, hàng hóa rủi ro trung bình
- Thông tư 14/2026/TT-BKHCN: tám phương thức chứng nhận và cách lựa chọn
21. Nguồn tham khảo
- Dự thảo TCVN XXXXX:2026, “An ninh mạng – Sản phẩm phòng, chống xâm nhập lớp mạng – Yêu cầu chung”, do Cục An ninh mạng và phòng, chống tội phạm sử dụng công nghệ cao biên soạn, Bộ Công an đề nghị, Ủy ban Tiêu chuẩn Đo lường Chất lượng Quốc gia thẩm định và Bộ Khoa học và Công nghệ công bố. Dự thảo chưa có hiệu lực áp dụng; bài viết tóm tắt cấu trúc, phạm vi và các nhóm yêu cầu, không sao chép nguyên văn điều khoản.
- Các tài liệu được dự thảo liệt kê trong mục tài liệu tham khảo, trong đó đáng chú ý: TCVN 14423:2026 về yêu cầu cơ bản đối với hệ thống thông tin; NIST SP 800-94 về hướng dẫn hệ thống phát hiện và phòng chống xâm nhập; ISO/IEC 27039; RFC 9411 (NetSecOPEN); và Quyết định số 1591/QĐ-BTTTT về yêu cầu kỹ thuật cơ bản đối với sản phẩm phòng, chống xâm nhập lớp mạng.
- Ba bản dự thảo cùng loạt đã phân tích: TCVN XXXXX:2026 về SIEM, về nền tảng tri thức mối đe dọa (TIP) và về sản phẩm điều phối, tự động hoá và phản ứng (SOAR).
22. Liên hệ
Nhà sản xuất và nhà cung cấp sản phẩm NIPS, đơn vị đang xây dựng hệ thống phòng thủ nhiều lớp, cùng các tổ chức đang chuẩn bị hồ sơ đánh giá thiết bị có thể gửi yêu cầu qua biểu mẫu dưới đây để trao đổi về phạm vi đánh giá, kịch bản kiểm thử và hồ sơ cần chuẩn bị trước thời điểm tiêu chuẩn được ban hành.
Bài viết phân tích một dự thảo tiêu chuẩn chưa được ban hành, chỉ nhằm mục đích thông tin, không thay thế tiêu chuẩn và không thay thế tư vấn kỹ thuật, pháp lý cho từng trường hợp cụ thể. Nội dung dự thảo có thể thay đổi trước khi công bố; các số liệu, danh mục nêu trong bài là những nội dung có trong dự thảo tại thời điểm phân tích. Khi tiêu chuẩn được ban hành, đề nghị sử dụng văn bản chính thức cùng các văn bản quy phạm pháp luật đang có hiệu lực.
