Dự thảo tiêu chuẩn quốc gia về sản phẩm điều phối, tự động hoá và phản ứng an ninh mạng (SOAR) 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 điều phối, tự động hoá và phản ứng an ninh 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ứ ba trong loạt dự thảo tiêu chuẩn an ninh mạng mà chúng tôi phân tích, sau bản dự thảo về SIEM và bản dự thảo về nền tảng tri thức mối đe dọa (TIP). Bài viết tóm tắt cấu trúc, phạm vi và các nhóm yêu cầu chính ở mức khái quát, kèm một số ngưỡng mà dự thảo ấn định trực tiếp.
1. Dự thảo này là gì và đang ở đâu
Như hai bản trước, đây là 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. 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 tiêu: tiêu chuẩn quy định các yêu cầu chung đối với sản phẩm SOAR và là cơ sở để tổ chức, doanh nghiệp phát triển, cung cấp, đánh giá và lựa chọn sử dụng sản phẩm, dịch vụ SOAR, đồng thời khuyến khích chủ quản của sản phẩm, dịch vụ SOAR triển khai các yêu cầu trong tiêu chuẩn.
Thư mục tài liệu tham khảo của dự thảo gồm ba mục: hướng dẫn thị trường của Gartner về các giải pháp SOAR ban hành tháng 11/2023; NIST SP 800-61r3 về ứng cứu sự cố trong quản lý rủi ro an ninh mạng; và Quyết định số 1907/QĐ-BTTTT ngày 02/12/2021 của Bộ trưởng Bộ Thông tin và Truyền thông ban hành yêu cầu kỹ thuật cơ bản đối với sản phẩm điều phối, tự động hóa và phản ứng an toàn thông tin. Sự xuất hiện của Quyết định 1907 tại đây cho thấy dự thảo không phải văn bản đầu tiên đặt yêu cầu kỹ thuật cho loại sản phẩm này, và các đơn vị đã từng đánh giá theo bộ yêu cầu cũ nên đối chiếu phần mới bổ sung khi tiêu chuẩn được ban hành.
2. Vị trí của SOAR trong bộ ba tiêu chuẩn về hệ sinh thái phòng thủ
Ba dự thảo phân định khá rõ vai trò của nhau. SIEM thu thập và tương quan nhật ký sự kiện trong hệ thống thông tin của tổ chức để 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ừ đa nguồn. SOAR là lớp thực thi: tiếp nhận cảnh báo, làm giàu dữ liệu, tổ chức xử lý theo kịch bản, điều phối con người và thực hiện hành động ứng phó trên các nền tảng tích hợp.
Mối liên hệ này được ghi nhận hai chiều. Dự thảo SIEM dành một mục cho tích hợp với SOAR và TIP; dự thảo TIP yêu cầu tích hợp trực tiếp tới SIEM, SOAR, EDR, WAF; còn dự thảo SOAR yêu cầu khả năng kết nối tối thiểu tới chín nhóm nền tảng, trong đó có SIEM và TIP. Về mặt hồ sơ, lựa chọn sản phẩm SOAR vì thế không thể tách khỏi hai sản phẩm còn lại, vì kịch bản chỉ chạy được khi thành phần tích hợp hoạt động.
3. Phạm vi và cấu trúc của dự thảo
Phạm vi áp dụng một câu: tiêu chuẩn quy định các yêu cầu chung về an ninh mạng đối với nền tảng tự động hoá, điều phối và phản ứng an ninh mạng. Đây là bản dự thảo dài nhất trong ba bản: khoảng 31 trang với 5 điều và Phụ lục A. Đ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 đối với sản phẩm; Điều 5 yêu cầu chức năng nghiệp vụ đối với sản phẩm; Phụ lục A quy định phương pháp đánh giá.
Hai điểm về cấu trúc đáng chú ý. Thứ nhất, Phụ lục A của bản này không ghi “(tham khảo)” như Phụ lục A của bản dự thảo TIP; nội dung phụ lục là phương pháp đánh giá theo từng nhóm yêu cầu và phương pháp đo lường hiệu năng, cho thấy dự thảo này tham vọng ở mức độ “đo được”, không chỉ “mô tả được”. Thứ hai, Điều 2 nêu đoạn dẫn chuẩn về tài liệu viện dẫn nhưng không kèm danh mục cụ thể, tức chưa có tài liệu nào được viện dẫn trong bản dự thảo này.
4. Thuật ngữ và chữ viết tắt
Điều 3 định nghĩa 18 thuật ngữ, nhiều hơn hẳn hai bản trước: an ninh mạng; thời gian duy trì phiên kết nối; nhật ký hệ thống; cảnh báo; tình huống; thành phần tích hợp; sự cố an ninh mạng; nền tảng tích hợp; mở/đóng tình huống; kịch bản; sản phẩm SOAR; phân loại và xử lý ban đầu; làm giàu dữ liệu; dấu hiệu tấn công; leo thang; chuỗi hành trình bằng chứng; nhật ký kiểm toán; và khử trùng lặp. Cách định nghĩa cho thấy dự thảo viết cho cả hai đối tượng: nhà sản xuất cần hiểu kịch bản là gì, còn chủ hệ thống cần hiểu chuỗi hành trình bằng chứng có ý nghĩa gì về pháp lý khi sự cố phải đưa ra cơ quan chức năng.
Danh mục chữ viết tắt dài nhất trong ba bản, phản ánh tính chất tích hợp: ngoài SOAR, SIEM, TIP, EDR, EPP, NIPS, WAF, IAM, API và TLS còn có bộ chỉ số MTTA, MTTD, MTTR, MTBF, SLA, các mục tiêu RTO, RPO, cùng RBAC, SSO, NTP, UTC, CMDB, SBOM, DFIR và CTI. Điều đáng nói là dự thảo dùng các chỉ số này như chỉ tiêu bắt buộc phải báo cáo, sẽ nêu ở mục quản lý báo cáo.
5. Yêu cầu chung, quản trị và an toàn đối với sản phẩm
Điều 4 gồm tám nhóm yêu cầu, chiếm gần một nửa văn bản và là phần quyết định sản phẩm có vận hành được trong môi trường thật hay không.
| Mục | Nhóm yêu cầu | Trọng tâm |
|---|---|---|
| 4.1 | Tài liệu | Mười hai loại tài liệu, từ cài đặt, hướng dẫn sử dụng, quản trị, sao lưu và khôi phục, kiến trúc và yêu cầu hạ tầng theo từng mức tải, tài liệu API, hướng dẫn phát triển thành phần tích hợp và kịch bản, hướng dẫn tăng cường an toàn, ma trận tương thích phiên bản, đến chính sách hỗ trợ và thời hạn kết thúc hỗ trợ |
| 4.2 | Quản trị hệ thống | Quản lý vận hành, quản trị từ xa, xác thực và phân quyền, quản lý báo cáo, quản lý thông tin xác thực của thành phần tích hợp |
| 4.3 | Kiểm soát lỗi | Bảo vệ cấu hình theo sáu loại cấu hình, bảo vệ dữ liệu nhật ký, cảnh báo, tình huống và bằng chứng, đồng bộ thời gian |
| 4.4 | Nhật ký hệ thống | Log quản trị hệ thống và trường thông tin, định dạng log, quản lý log, bảo vệ nhật ký kiểm toán |
| 4.5 | Tính sẵn sàng | Kiến trúc dự phòng, cơ chế chuyển đổi dự phòng, đồng bộ dữ liệu và khôi phục sau sự cố |
| 4.6 | Giám sát tình trạng hoạt động | Giám sát thành phần hệ thống, thành phần tích hợp, luồng thu thập dữ liệu, cảnh báo vận hành và xuất dữ liệu giám sát |
| 4.7 | Bảo vệ dữ liệu | Mã hoá khi lưu trữ và khi truyền, xử lý dữ liệu cá nhân, thời hạn lưu trữ, công bố thông tin khi triển khai dạng dịch vụ đám mây |
| 4.8 | An toàn và vòng đời sản phẩm | Danh mục thành phần phần mềm, không dùng thành phần đã kết thúc hỗ trợ, quy trình xử lý lỗ hổng, xác thực bản cập nhật, nâng cấp và quay lui |
6. Tài liệu, quản trị hệ thống và quản lý báo cáo
Nhóm tài liệu (4.1) liệt kê mười hai loại, từ cài đặt, hướng dẫn sử dụng, quản trị hệ thống, sao lưu và khôi phục, tài liệu API, hướng dẫn phát triển thành phần tích hợp và kịch bản, hướng dẫn tăng cường an toàn đến ma trận tương thích phiên bản và chính sách hỗ trợ. Ba loại thường bị bỏ trống trong hồ sơ nhà cung cấp là tài liệu kiến trúc và yêu cầu hạ tầng tối thiểu tương ứng với từng mức tải, ma trận tương thích phiên bản giữa sản phẩm và các nền tảng tích hợp, và chính sách hỗ trợ kèm thời hạn kết thúc hỗ trợ của từng phiên bản.
Nhóm quản trị hệ thống yêu cầu cấu hình được các đối tượng vận hành chính (quản trị từ xa, tài khoản và phân quyền, thu thập cảnh báo, kịch bản, thành phần tích hợp), xem được thời gian hệ thống chạy từ lần khởi động gần nhất, và triển khai được tại chỗ hoặc dưới dạng giải pháp đám mây. Về quản trị từ xa, dự thảo đòi hỏi cụ thể: dùng TLS từ phiên bản 1.2 trở lên với bộ thuật toán không thuộc danh mục khuyến cáo ngừng sử dụng, cho phép vô hiệu hoá các phiên bản và bộ thuật toán cũ, tự động đăng xuất khi hết thời gian phiên, và thiết lập được tham số giới hạn kết nối như giới hạn địa chỉ IP hay số phiên đồng thời.
Phần xác thực và phân quyền là phần dài nhất của Điều 4, với những điểm đáng lưu ý về vận hành: cung cấp sẵn ít nhất hai vai trò mặc định là quản trị viên và người dùng thường; hỗ trợ kiểm soát truy cập dựa trên vai trò; hỗ trợ xác thực đa nhân tố cho tất cả tài khoản; tích hợp với hệ thống quản lý định danh tập trung qua ít nhất một giao thức được thừa nhận rộng rãi, cho phép đồng bộ tài khoản và thu hồi quyền tự động; cho phép đặt chính sách mật khẩu gồm độ dài tối thiểu, thành phần ký tự, thời hạn sử dụng và số mật khẩu không được dùng lại; bắt buộc đổi mật khẩu mặc định ngay lần đăng nhập đầu tiên; tự động khoá tài khoản khi số lần xác thực thất bại vượt ngưỡng; lưu mật khẩu ở dạng băm có chuỗi ngẫu nhiên bổ sung; cho phép định nghĩa vai trò tuỳ biến với quyền chi tiết tới từng chức năng và từng loại hành động; kiểm soát truy cập ở mức đối tượng, giới hạn phạm vi dữ liệu mà một vai trò được xem; và cho phép xuất danh sách tài khoản, vai trò, quyền hạn cùng xác định tài khoản không hoạt động để rà soát định kỳ.
Quản lý báo cáo (4.2.4) yêu cầu bảng điều khiển trực quan theo thời gian thực, tạo và xoá báo cáo, chọn định dạng xuất tối thiểu một trong các định dạng WORD, EXCEL, PDF, HTML, XML, đặt lịch gửi báo cáo định kỳ qua email, báo cáo hiệu năng hoạt động và báo cáo hiệu quả công việc của từng người xử lý qua tối thiểu hai thông số mỗi loại, và báo cáo giám sát gồm các chỉ số MTBF, MTTA, MTTD, MTTR và SLA. Tiêu chuẩn biến việc đo năng suất, chất lượng vận hành thành yêu cầu chức năng, không còn là việc làm thủ công ngoài hệ thống.
Quản lý thông tin xác thực của thành phần tích hợp (4.2.5) quy định sáu điểm: lưu trữ ở dạng đã mã hoá bằng thuật toán chưa công bố điểm yếu; không hiển thị ở dạng rõ trên giao diện, trong nhật ký hệ thống, trong dữ liệu đầu vào và đầu ra của kịch bản cũng như trong tệp tin xuất kịch bản; phân quyền riêng cho chức năng xem, tạo, sửa đổi thông tin xác thực, tách biệt với quyền sử dụng thành phần tích hợp; cho phép thay đổi thông tin xác thực mà không phải sửa kịch bản đang dùng; khuyến khích tích hợp với hệ thống quản lý bí mật tập trung; và ghi nhật ký mọi hành vi truy cập, tạo, sửa, xoá thông tin xác thực. Yêu cầu không để lộ thông tin xác thực trong tệp tin xuất kịch bản là chi tiết thực tế, vì kịch bản thường được chia sẻ giữa các đơn vị.
7. Kiểm soát lỗi và nhật ký hệ thống
Kiểm soát lỗi (4.3) dùng cùng nguyên tắc với hai bản dự thảo trước nhưng mở rộng danh mục cấu hình phải giữ nguyên sau khi khởi động lại do lỗi, trừ lỗi phần cứng: cấu hình hệ thống, quản trị từ xa, tài khoản xác thực và phân quyền, thu thập cảnh báo, kịch bản và thành phần tích hợp. Dữ liệu nhật ký, cảnh báo, tình huống và bằng chứng đã lưu cũng phải không bị thay đổi, và thời gian hệ thống phải tự đồng bộ về thời điểm hiện tại.
Nhóm nhật ký (4.4) đáng đọc kỹ vì được phân tầng. Log quản trị hệ thống phải ghi mười ba loại sự kiện, trong đó có những loại riêng của SOAR: tạo lập, sửa đổi, xoá, phê duyệt, ban hành, ngừng sử dụng kịch bản và thành phần tích hợp; thực thi hành động tác động đến nền tảng tích hợp kèm tham số và đối tượng bị tác động; truy cập, tải xuống, sửa đổi, tiêu huỷ bằng chứng; thay đổi vai trò, quyền hạn tài khoản; hành vi phê duyệt hoặc từ chối phê duyệt; xuất dữ liệu ra khỏi hệ thống; truy cập thông tin xác thực của thành phần tích hợp; và truy cập tình huống có chế độ hạn chế. Trường thông tin gồm thời gian đầy đủ đến giây, địa chỉ IP hoặc định danh máy trạm, định danh tác nhân, hành vi, kết quả, và lý do giải trình đối với hành vi thất bại, trường cuối giúp phân biệt lỗi do thiếu quyền với lỗi do hệ thống.
Về định dạng và quản lý log, dự thảo yêu cầu chuẩn hoá theo tối thiểu một định dạng đã định nghĩa trước để truyền dữ liệu cho các phần mềm quản lý, phân tích, điều tra log; cho phép cấu hình lưu trữ và huỷ bỏ log; tìm kiếm theo từ khoá trên mọi trường kể cả trường cấp thấp hơn; xuất log để tích hợp vào SIEM; và lưu log tại chỗ hoặc trên hệ thống thứ ba phục vụ điều tra.
Điểm mạnh nhất của nhóm này là mục bảo vệ nhật ký kiểm toán (4.4.4): bảo đảm bản ghi không bị sửa đổi hoặc xoá bởi bất kỳ vai trò người dùng nào, kể cả vai trò quản trị hệ thống, trong thời hạn lưu trữ đã thiết lập; có cơ chế phát hiện sửa đổi trái phép; cho phép chuyển tiếp nhật ký kiểm toán tới hệ thống lưu trữ độc lập theo thời gian thực hoặc gần thời gian thực; và cho phép thiết lập thời hạn lưu trữ theo quy định của pháp luật, không cho phép xoá trước thời hạn. Dự thảo còn nêu rõ thứ tự ưu tiên: yêu cầu bảo vệ tại 4.4.4 cao hơn yêu cầu quản lý log chung, và cấu hình huỷ bỏ log thông thường không được phép rút ngắn thời hạn lưu trữ nhật ký kiểm toán.
8. Tính sẵn sàng và giám sát tình trạng hoạt động
Về tính sẵn sàng (4.5), dự thảo yêu cầu triển khai theo mô hình cụm dự phòng tối thiểu ở cấu trúc active-passive hoặc active-active, hỗ trợ cân bằng tải nội bộ hoặc tích hợp bộ cân bằng tải bên ngoài; quá trình chuyển đổi dự phòng không được làm mất dữ liệu nhật ký, cảnh báo, tình huống đang tiếp nhận và không làm thay đổi trạng thái các kịch bản đang thực thi; ngưỡng thời gian phục hồi hoạt động (RTO) phải được nhà cung cấp công bố và kiểm tra xác nhận được bằng thử nghiệm chuyển đổi dự phòng. Về sao lưu, dự thảo yêu cầu tự động sao lưu hoặc tích hợp công cụ sao lưu định kỳ cho cấu hình, cơ sở dữ liệu, kịch bản và thành phần tích hợp, cùng khả năng khôi phục có kiểm tra tính toàn vẹn của bản sao lưu.
Về giám sát tình trạng (4.6), dự thảo yêu cầu giao diện đồ hoạ hiển thị theo thời gian thực trạng thái từng thành phần hệ thống, mức sử dụng tài nguyên, số phần tử tồn đọng trong hàng đợi cùng độ trễ trung bình, số phiên kịch bản đang thực thi, đang chờ và thất bại, tình trạng cụm dự phòng và chỉ số MTBF. Với thành phần tích hợp, dự thảo yêu cầu kiểm tra kết nối theo yêu cầu kèm thông tin chẩn đoán lỗi, kiểm tra tự động theo chu kỳ, hiển thị thời điểm giao tiếp thành công gần nhất cùng tỷ lệ và mã lỗi gần nhất, và cảnh báo khi thông tin xác thực sắp hết hoặc đã hết hiệu lực. Với luồng thu thập dữ liệu, dự thảo yêu cầu thống kê số cảnh báo tiếp nhận thành công, thất bại và bị loại bỏ theo từng nguồn, và cảnh báo khi một nguồn ngừng gửi dữ liệu vượt ngưỡng thời gian đã thiết lập.
Phần cảnh báo vận hành khép lại nhóm này: thiết lập ngưỡng cảnh báo cho các chỉ số trên và gửi cảnh báo qua tối thiểu hai kênh như thư điện tử, ứng dụng nhắn tin hoặc syslog; và cung cấp API hoặc điểm truy xuất tiêu chuẩn để hệ thống giám sát bên ngoài thu thập chỉ số.
9. Bảo vệ dữ liệu, an toàn và vòng đời sản phẩm
Nhóm bảo vệ dữ liệu (4.7) gồm những yêu cầu khá mới: mã hoá dữ liệu khi lưu trữ đối với thông tin xác thực, bằng chứng và các trường được đánh dấu nhạy cảm; dùng kênh truyền mã hoá cho mọi kết nối giữa các thành phần hệ thống và giữa SOAR với nền tảng tích hợp, kèm khả năng xác thực chứng thư của phía đối tác; cho phép đánh dấu trường chứa dữ liệu cá nhân và che giá trị với vai trò không được cấp quyền; đặt thời hạn lưu trữ riêng cho từng loại dữ liệu và tự động xoá hoặc ẩn danh khi hết hạn; và cho phép tìm kiếm, kết xuất, xoá dữ liệu liên quan đến một chủ thể dữ liệu cụ thể. Với triển khai dạng dịch vụ đám mây, nhà cung cấp phải công bố vị trí lưu trữ và xử lý dữ liệu, các bên thứ ba có khả năng truy cập dữ liệu, và cơ chế bảo đảm tuân thủ quy định của pháp luật Việt Nam về lưu trữ dữ liệu và bảo vệ dữ liệu cá nhân.
Nhóm an toàn và vòng đời sản phẩm (4.8) đặt trách nhiệm lên nhà cung cấp: công bố danh mục thành phần phần mềm kèm phiên bản, gồm cả thư viện và thành phần nguồn mở; không dùng thành phần đã kết thúc hỗ trợ; có quy trình tiếp nhận, xử lý và thông báo lỗ hổng bảo mật kèm cam kết thời hạn xử lý theo mức độ nghiêm trọng; bản cập nhật và bản vá phải có cơ chế xác thực nguồn gốc và kiểm tra tính toàn vẹn; cho phép nâng cấp không mất dữ liệu và cấu hình, có cơ chế quay lui khi nâng cấp thất bại; và cung cấp tài liệu tăng cường an toàn. Đây là nhóm câu hỏi nên đưa vào hồ sơ ngay từ giai đoạn đánh giá nhà cung cấp, vì liên quan tới cam kết hỗ trợ dài hạn.
10. Bảy nhóm yêu cầu chức năng nghiệp vụ
Điều 5 chia chức năng nghiệp vụ thành bảy nhóm, đi từ điều phối xử lý, phân tích sự cố, tích hợp và tự động hoá, hiệu năng, bằng chứng số, điều hành ứng cứu sự cố đến quản lý thông tin về mối đe doạ.
| Mục | Nhóm chức năng | Trọng tâm |
|---|---|---|
| 5.1 | Điều phối xử lý | Điều phối xử lý cảnh báo, điều phối xử lý tình huống, leo thang và thông báo |
| 5.2 | Giám sát và phân tích sự cố | Trực quan liên kết giữa các đối tượng trong sự cố, dòng thời gian sự kiện |
| 5.3 | Tích hợp và tự động hoá | Quản lý thành phần tích hợp, tích hợp nhiều nền tảng, hỗ trợ API, quản lý và thực hiện kịch bản, kiểm soát thực thi |
| 5.4 | Hiệu năng xử lý | Độ trễ truy vấn dữ liệu, thu thập đồng thời nhiều cảnh báo, thực thi đồng thời nhiều kịch bản |
| 5.5 | Quản lý bằng chứng số | Tiếp nhận và bảo toàn bằng chứng, chuỗi hành trình bằng chứng, xử lý bằng chứng có khả năng độc hại, lưu giữ và tiêu huỷ |
| 5.6 | Điều hành ứng cứu sự cố | Nhiệm vụ trong tình huống, vai trò trong sự cố, nhật ký điều hành, phân cấp và liên kết tình huống, báo cáo sự cố |
| 5.7 | Quản lý thông tin về mối đe doạ | Quản lý dấu hiệu tấn công, tiếp nhận và chia sẻ, đối sánh và ghi nhận phát hiện, quản lý thực thể mối đe doạ, ban hành biện pháp phòng vệ |
11. Điều phối xử lý cảnh báo và tình huống
Mục điều phối xử lý cảnh báo (5.1.1) dài nhất trong Điều 5 với hơn hai mươi yêu cầu, mô tả khá đầy đủ quy trình làm việc của một trung tâm điều hành an ninh: cấu hình thu thập cảnh báo từ các giải pháp an ninh mạng và công nghệ thông tin khác, với cảnh báo ban đầu được gán trạng thái mới; tìm kiếm cảnh báo theo từ khoá trên mọi trường; lưu trữ và phân nhóm cảnh báo theo tiêu chí như mức độ quan trọng hay nguồn gửi; cập nhật trạng thái xử lý từ mới, đang xử lý, chờ bổ sung thông tin, đã leo thang đến đã xử lý; cập nhật kết quả xử lý với các giá trị cảnh báo thật, cảnh báo giả, hoạt động hợp lệ được xác nhận và trùng lặp; cập nhật bằng chứng bằng cách tải tệp tin hoặc nhập nội dung văn bản; xem lại lịch sử xử lý gồm thời điểm, người thực hiện và nội dung; thiết lập thời hạn xử lý và xác định cảnh báo có bị quá hạn; và áp dụng kịch bản cho cảnh báo.
Phần tự động hoá trong xử lý cảnh báo nằm ở các yêu cầu về quy tắc: khử trùng lặp theo tổ hợp trường thông tin và khoảng thời gian, trong đó cảnh báo trùng lặp phải được gộp thành một cảnh báo kèm số lần xuất hiện; tự động nhóm các cảnh báo liên quan thành tình huống; và quy tắc loại trừ để tự động chuyển cảnh báo đã biết là nhiễu sang trạng thái đã xử lý, với điều kiện mỗi quy tắc phải có thời hạn hiệu lực, lý do và người phê duyệt, điều kiện kèm theo này đáng chú ý về kiểm soát, vì danh sách cho phép không có thời hạn thường trở thành lỗ hổng bị khai thác sau này.
Về vận hành nhóm, dự thảo yêu cầu mức độ nghiêm trọng của cảnh báo có tối thiểu bốn giá trị và cấu hình được quy tắc tự động xác định hoặc điều chỉnh mức độ này theo nội dung cảnh báo, mức độ quan trọng của tài sản và kết quả làm giàu; gán người xử lý và cho phép tự nhận xử lý; phân công tự động theo nhóm, ca trực hoặc mức độ nghiêm trọng; hiển thị hàng đợi theo người, nhóm và ca trực kèm bộ lọc lưu lại được; và hiển thị dữ liệu đã làm giàu ngay trên màn hình xử lý.
Với tình huống (5.1.2), dự thảo yêu cầu tạo tình huống bằng cách nhóm một hoặc nhiều cảnh báo, mặc định trạng thái là mở; tìm kiếm và phân nhóm tình huống; cập nhật trạng thái mở hoặc đóng và kết quả xử lý là phát hiện đúng hoặc phát hiện sai; xem lại lịch sử xử lý; thiết lập thời hạn và xác định tình huống có bị quá hạn; áp dụng kịch bản cho tình huống; và gán một hoặc nhiều người xử lý. Mục leo thang và thông báo (5.1.3) yêu cầu cấu hình quy tắc leo thang tự động khi quá hạn xử lý hoặc đạt mức nghiêm trọng đã thiết lập, hỗ trợ nhiều mức leo thang với người tiếp nhận tương ứng, và gửi thông báo qua tối thiểu hai kênh khi cảnh báo hoặc tình huống được gán, sắp đến hạn, quá hạn, hay khi kịch bản cần người dùng tương tác hoặc phê duyệt; ở mức khuyến khích là quản lý lịch trực và tự động xác định người tiếp nhận theo ca trực.
12. Giám sát, phân tích sự cố và điều hành ứng cứu sự cố
Mục giám sát và phân tích sự cố (5.2) chỉ gồm hai yêu cầu nhưng đều then chốt: hiển thị trực quan mối liên kết giữa các đối tượng trong sự cố bằng đường đi kèm thông tin của liên kết, tối thiểu với địa chỉ IP, địa chỉ thư điện tử và tên miền; và xem dòng thời gian của các sự kiện trong sự cố với thời điểm xuất hiện, nội dung, các đối tượng liên quan và bằng chứng thu thập được. Đây là hai chức năng phân tích viên dùng nhiều nhất khi phải tái dựng diễn biến.
Mục điều hành ứng cứu sự cố (5.6) đi sâu vào quản lý công việc nhóm: nhiệm vụ trong tình huống có các trường tên, mô tả, người thực hiện, thời hạn, trạng thái, kết quả và giai đoạn ứng cứu, được phân nhóm theo sáu giai đoạn (chuẩn bị, phát hiện và phân tích, ngăn chặn, loại bỏ, khôi phục, tổng kết rút kinh nghiệm), áp dụng được mẫu danh sách nhiệm vụ theo từng loại sự cố và có quan hệ phụ thuộc giữa các nhiệm vụ.
Về vai trò, dự thảo yêu cầu gán vai trò cho người tham gia trong từng tình huống, tối thiểu gồm chỉ huy ứng cứu, người phân tích và người ghi nhận, đồng thời hiển thị danh sách người đang tham gia xử lý theo thời gian thực. Về nhật ký điều hành, dự thảo yêu cầu tự động ghi vào một dòng thời gian thống nhất của tình huống mọi hành vi phát sinh: hành vi do người dùng thực hiện, bước thực thi của kịch bản, thay đổi trạng thái, thay đổi nhiệm vụ, tiếp nhận và truy cập bằng chứng, thông tin trao đổi; dòng thời gian này không được sửa đổi hoặc xoá và phải xuất được ra tệp tin để lập báo cáo sự cố. Về phân cấp và liên kết, dự thảo yêu cầu phân loại mức độ nghiêm trọng của sự cố với tối thiểu bốn mức; liên kết, gộp và tách tình huống mà giữ nguyên lịch sử xử lý; và thiết lập chế độ hạn chế truy cập cho từng tình huống kèm ghi nhật ký kiểm toán.
Về báo cáo sự cố (5.6.5), dự thảo yêu cầu tạo báo cáo từ dữ liệu của tình huống theo mẫu do người dùng định nghĩa, tối thiểu gồm tóm tắt sự cố, dòng thời gian, phạm vi ảnh hưởng, các dấu hiệu tấn công liên quan, biện pháp đã thực hiện, kết quả và khuyến nghị; ở mức khuyến khích là theo dõi thời hạn thực hiện nghĩa vụ báo cáo sự cố theo quy định của pháp luật, tính từ thời điểm ghi nhận sự cố. Gợi ý này cho thấy ban soạn thảo tính đến cả nghĩa vụ báo cáo theo pháp luật hiện hành, không chỉ nhu cầu nội bộ.
13. Quản lý bằng chứng số
Đây là nhóm chức năng ít gặp trong các bộ yêu cầu cũ và là điểm mạnh của dự thảo, vì bằng chứng số là phần quyết định khi sự cố phải chuyển sang cơ quan chức năng hoặc xử lý theo quy định pháp luật. Bốn mục con gồm tiếp nhận và bảo toàn bằng chứng, chuỗi hành trình bằng chứng, xử lý an toàn đối với bằng chứng có khả năng độc hại, và lưu giữ, tiêu huỷ.
Về tiếp nhận và bảo toàn (5.5.1), dự thảo yêu cầu tự động tính và lưu giá trị băm của mỗi tệp tin bằng chứng ngay khi tiếp nhận bằng thuật toán băm chưa công bố điểm yếu; cho phép kiểm tra lại tính toàn vẹn bằng cách đối chiếu giá trị băm theo yêu cầu hoặc theo chu kỳ; ngăn chặn việc sửa đổi nội dung tệp tin sau khi tiếp nhận, trong đó mọi thay đổi phải thực hiện bằng cách tạo phiên bản mới và giữ nguyên bản gốc; và lưu trữ bằng chứng ở dạng đã mã hoá.
Về chuỗi hành trình (5.5.2), dự thảo yêu cầu ghi nhận và xem lại chuỗi hành trình của từng bằng chứng với thời điểm, tài khoản thực hiện, địa chỉ máy trạm, loại hành vi (tiếp nhận, xem, tải xuống, sao chép, chuyển giao, tiêu huỷ) và tình huống liên quan; bản ghi không được phép sửa đổi hoặc xoá bởi bất kỳ vai trò nào kể cả quản trị hệ thống; và phải xuất được ra tệp tin kèm giá trị băm của bản xuất.
Về bằng chứng có khả năng độc hại (5.5.3), dự thảo yêu cầu cho phép đánh dấu và lưu trữ ở khu vực cách ly; không tự động hiển thị nội dung, thực thi hoặc mở tệp tin đã đánh dấu; và khi tải xuống thì phải đóng gói ở định dạng có bảo vệ kèm cảnh báo. Về lưu giữ và tiêu huỷ (5.5.4), dự thảo yêu cầu đặt thời hạn lưu giữ theo loại tình huống, tự động thông báo khi đến hạn, yêu cầu phê duyệt trước khi tiêu huỷ và ghi nhật ký kiểm toán cho hành vi tiêu huỷ.
14. Tích hợp và tự động hoá: kịch bản và thành phần tích hợp
Đây là trái tim của một sản phẩm SOAR và cũng là nhóm dài nhất trong Điều 5. Về quản lý thành phần tích hợp (5.3.1), dự thảo yêu cầu tạo mới, xem lại, cập nhật, xoá qua giao diện đồ hoạ; cho phép phát triển bằng tối thiểu một ngôn ngữ lập trình dạng thông dịch; thực thi mã trong môi trường cách ly có giới hạn tài nguyên về thời gian thực thi, bộ nhớ và tiến trình con; cho phép giới hạn phạm vi truy cập mạng và truy cập hệ thống tệp tin của mã; yêu cầu phê duyệt trước khi thành phần do người dùng tự phát triển được dùng trong môi trường vận hành; và ghi nhật ký kiểm toán việc tạo lập, sửa đổi mã.
Về quản lý kịch bản (5.3.4), dự thảo yêu cầu kịch bản phải xây dựng được với tối thiểu các thành phần: khối thực thi, đường đi giữa các khối, điều kiện rẽ nhánh, vòng lặp trên tập dữ liệu, nhánh thực thi song song và điểm hợp lưu, khối yêu cầu người dùng thao tác thủ công, khối yêu cầu phê duyệt, và biến cùng biểu thức biến đổi dữ liệu. Kịch bản phải xuất và nhập được qua tệp tin, trong đó khi nhập phải kiểm tra tính toàn vẹn của tệp và hiển thị danh sách thành phần tích hợp cùng quyền hạn mà kịch bản yêu cầu trước khi xác nhận; cho phép đưa một kịch bản vào một kịch bản khác; lưu lịch sử phiên bản kèm người thực hiện và thời điểm từng thay đổi, cho phép so sánh hai phiên bản bất kỳ và khôi phục về phiên bản trước đó; đặt trạng thái kịch bản gồm đang soạn thảo, chờ phê duyệt, đã ban hành, ngừng sử dụng; cấu hình quy trình phê duyệt trước khi ban hành, trong đó tài khoản phê duyệt phải khác tài khoản tạo lập hoặc sửa đổi kịch bản; chạy thử với dữ liệu đầu vào mẫu trong chế độ mô phỏng không tác động đến nền tảng tích hợp; gán nhãn, phân nhóm và tìm kiếm kịch bản; và xác định danh sách kịch bản, thành phần tích hợp bị ảnh hưởng khi có sửa đổi hoặc xoá.
Về thực hiện kịch bản, dự thảo có yêu cầu chung (5.3.5) áp dụng cho cả hai chế độ: đặt thời hạn thực hiện, xác định kịch bản và từng bước có bị quá hạn, và xem lại lịch sử thực hiện của từng bước với tập dữ liệu đầu vào, tập dữ liệu đầu ra, thời điểm bắt đầu và kết thúc, trạng thái thành công hay thất bại. Chế độ tự động (5.3.6) cho phép cấu hình kịch bản dựa trên điều kiện và quy tắc tìm kiếm cảnh báo, tình huống để thực hiện tất cả các bước mà không cần con người tương tác. Chế độ bán tự động (5.3.7) cho phép thực hiện kịch bản dựa trên dữ liệu người dùng đưa vào qua các thao tác như nhập giá trị số hoặc chuỗi, chọn một hoặc một số giá trị có sẵn, tải lên tệp tin, đặt thời điểm bắt đầu tự động; lịch sử thực hiện phải bổ sung trường tài khoản người dùng có tương tác; cho phép dùng kết quả của bước trước làm đầu vào cho bước tiếp theo; và gán người tương tác cho những bước cần con người.
15. Kiểm soát thực thi và xử lý ngoại lệ kịch bản
Mục 5.3.8 là phần quy định “van an toàn” cho tự động hoá, gồm mười hai yêu cầu và theo đánh giá của chúng tôi là phần thực dụng nhất của dự thảo đối với người vận hành. Các yêu cầu gồm: định nghĩa nhánh xử lý khi một bước thất bại; thiết lập số lần thực hiện lại và khoảng thời gian chờ giữa các lần thực hiện lại cho từng bước; thiết lập thời hạn riêng cho từng bước ngoài thời hạn toàn kịch bản; tạm dừng, tiếp tục và huỷ bỏ một phiên thực thi đang chạy; thực hiện lại một bước hoặc toàn bộ kịch bản với cảnh báo, tình huống đã xử lý trước đó; cơ chế ngăn chặn việc thực thi đồng thời nhiều phiên của cùng một kịch bản trên cùng một cảnh báo hoặc tình huống; giới hạn số lượng đối tượng tối đa mà một kịch bản được phép tác động trong một phiên, khi vượt giới hạn thì kịch bản phải dừng và chuyển sang trạng thái chờ phê duyệt; giới hạn tần suất gọi đối với từng thành phần tích hợp để tránh vượt ngưỡng của nền tảng tích hợp; yêu cầu xác nhận hoặc phê duyệt trước khi thực thi hành động được xác định là nguy hiểm; thiết lập thời gian chờ tối đa cho việc gọi thực thi hành động trên nền tảng tích hợp, độc lập với thời hạn của bước; và cho phép khôi phục hành động đã thực thi khi nền tảng đích hỗ trợ cơ chế khôi phục.
Hai yêu cầu đáng nhấn mạnh về mặt rủi ro: giới hạn số đối tượng tác động với cơ chế dừng lại và chuyển sang chờ phê duyệt ngăn một kịch bản lỗi quét hàng loạt thiết bị; còn giới hạn tần suất gọi thành phần tích hợp ngăn kịch bản tự động gây quá tải hoặc vượt ngưỡng dịch vụ của nền tảng tích hợp. Cả hai đều là loại sự cố vận hành đã xảy ra ở nhiều đơn vị khi bật tự động hoá mà chưa đặt giới hạn.
16. Hiệu năng xử lý và Phụ lục A: cách đánh giá
Khác hai bản dự thảo trước, bản này ấn định trực tiếp một số ngưỡng hiệu năng thay vì chỉ yêu cầu nhà sản xuất công bố. Ba mục của 5.4 gồm: độ trễ tìm kiếm log, cảnh báo và tình huống với độ phức tạp bất kỳ phải có phản hồi trong khoảng thời gian tối đa 01 phút; khả năng thu thập, xử lý và lưu trữ đồng thời tối thiểu 1.000 cảnh báo trong 01 phút; và yêu cầu công bố tối thiểu số lượng luồng kịch bản cùng số lượng connector có thể xử lý đồng thời.
Phần đáng giá nhất về mặt đánh giá nằm ở Phụ lục A, với bốn phương pháp là xem xét tài liệu, thử nghiệm chức năng, đo lường hiệu năng và đánh giá cấu hình an toàn, kèm nguyên tắc ánh xạ từng nhóm yêu cầu với phương pháp tương ứng: tài liệu thì xem xét tài liệu; quản trị, xác thực và phân quyền thì thử nghiệm chức năng kết hợp xem xét cấu hình; kiểm soát lỗi và nhật ký thì thử nghiệm mô phỏng lỗi kết hợp xem xét nhật ký; tính sẵn sàng thì thử nghiệm chuyển đổi dự phòng; chức năng nghiệp vụ thì thử nghiệm chức năng; và hiệu năng xử lý thì đo lường theo phương pháp riêng. Kết quả đánh giá phải lập thành báo cáo nêu rõ phương pháp áp dụng, điều kiện đo và kết luận về mức độ đáp ứng của từng yêu cầu.
Phần đo lường hiệu năng quy định điều kiện đo tham chiếu, trong đó nhà cung cấp phải công bố cấu hình phần cứng và phần mềm tham chiếu gồm số lượng và loại CPU hoặc vCPU, dung lượng bộ nhớ, loại và tốc độ thiết bị lưu trữ, băng thông mạng, phiên bản phần mềm và hệ điều hành nền. Phương pháp đo độ trễ dùng tập dữ liệu tham chiếu không nhỏ hơn 10 triệu bản ghi log, cảnh báo và tình huống; thực hiện tối thiểu ba loại truy vấn tiêu biểu là truy vấn đơn giản theo một điều kiện, truy vấn phức tạp kết hợp nhiều điều kiện và nhiều trường, và truy vấn toàn văn; đo thời gian phản hồi trung bình cùng thời gian phản hồi tại phân vị thứ 95 với tối thiểu 30 lần lặp cho mỗi loại truy vấn. Phương pháp đo khả năng thu thập đồng thời mô phỏng gửi từ tối thiểu hai nguồn cảnh báo với tổng số tối thiểu 1.000 cảnh báo trong một phút và đo tỷ lệ tiếp nhận, xử lý, lưu trữ thành công. Phương pháp đo thực thi đồng thời kịch bản xác định số luồng kịch bản và số connector tối đa chạy đồng thời không phát sinh lỗi, đồng thời đo mức suy giảm thời gian phản hồi ở mức tải tối đa so với mức tải cơ sở (mức tải cơ sở không quá 50% số luồng tối đa), với mức suy giảm phải được nhà cung cấp công bố kèm con số cụ thể.
Với phòng thử nghiệm, Phụ lục A gần như là một đề cương phương pháp luận sẵn có: có điều kiện đo, tập dữ liệu tối thiểu, loại truy vấn, chỉ số phân vị và số lần lặp, chỉ tiêu tỷ lệ thành công. Đây là phần nên đọc trước khi xây dựng năng lực thử nghiệm cho loại sản phẩm này.
17. Quản lý thông tin về mối đe doạ trong SOAR
Điểm đáng chú ý về kiến trúc tiêu chuẩn: dù đã có bản dự thảo riêng cho TIP, bản SOAR vẫn dành một mục cho quản lý thông tin về mối đe doạ ở mức đủ dùng cho vận hành. Mục 5.7.1 yêu cầu lưu trữ và quản lý dấu hiệu tấn công với tối thiểu năm loại gồm địa chỉ IP, tên miền, URL, giá trị băm tệp tin và địa chỉ thư điện tử; mỗi dấu hiệu có tối thiểu các trường loại, giá trị, nguồn cung cấp, thời điểm ghi nhận, mức độ tin cậy, mức độ nguy hiểm, nhãn chia sẻ và thời hạn hiệu lực; tự động khử trùng lặp theo loại và giá trị nhưng giữ lại thông tin về tất cả các nguồn cung cấp; cho phép thiết lập danh sách loại trừ để không ghi nhận dấu hiệu thuộc hạ tầng hợp lệ đã biết; và tự động chuyển dấu hiệu sang trạng thái hết hiệu lực khi quá hạn.
Mục tiếp nhận và chia sẻ (5.7.2) yêu cầu tiếp nhận dấu hiệu từ tệp tin và từ nguồn cấp dữ liệu bên ngoài theo lịch định trước; hỗ trợ tối thiểu một định dạng trao đổi được thừa nhận rộng rãi cho cả hai chiều; và kiểm soát việc chia sẻ ra bên ngoài theo nhãn chia sẻ của từng dấu hiệu. Mục đối sánh và ghi nhận phát hiện (5.7.3) yêu cầu tự động đối sánh dấu hiệu với cảnh báo, tình huống mới; cho phép đối sánh ngược dấu hiệu mới với dữ liệu đã lưu trong khoảng thời gian chỉ định, tạo cảnh báo khi trùng khớp; và ghi nhận số lần cùng thời điểm một dấu hiệu được phát hiện. Mục quản lý thực thể mối đe doạ (5.7.4) ở mức khuyến khích cho phép quản lý tác nhân đe doạ, chiến dịch tấn công, họ mã độc, kỹ thuật tấn công và liên kết chúng với dấu hiệu, cảnh báo, tình huống.
Mục cuối cùng, ban hành biện pháp phòng vệ (5.7.5), khép lại vòng tuần hoàn từ phát hiện tới hành động: cho phép ban hành dấu hiệu tấn công xuống các nền tảng tích hợp để chặn lọc thông qua kịch bản có cơ chế phê duyệt; và cho phép thu hồi biện pháp chặn lọc đã ban hành, đồng thời ghi nhận trạng thái ban hành của từng dấu hiệu trên từng nền tảng tích hợp. Yêu cầu thu hồi và theo dõi trạng thái theo từng nền tảng là chi tiết thực tế: khi chặn lọc nhầm một địa chỉ của đối tác, việc biết chính xác dấu hiệu nào đã được đẩy xuống hệ thống nào là điều kiện để khắc phục nhanh.
18. Doanh nghiệp và tổ chức cần chuẩn bị gì
Với nhà sản xuất và đơn vị cung cấp sản phẩm, dịch vụ SOAR, cần rà soát theo bốn lớp: bộ mười hai loại tài liệu, đặc biệt là tài liệu kiến trúc và yêu cầu hạ tầng theo từng mức tải, ma trận tương thích phiên bản và chính sách hỗ trợ; nhóm quản trị và an toàn, chú ý các yêu cầu khó như TLS từ phiên bản 1.2 trở lên có thể vô hiệu hoá bộ thuật toán cũ, nhật ký kiểm toán bất khả sửa kể cả với quản trị viên, không để lộ thông tin xác thực trong tệp tin xuất kịch bản; nhóm chức năng nghiệp vụ, chú ý phần kiểm soát thực thi và xử lý ngoại lệ kịch bản; và nhóm hiệu năng theo ngưỡng cố định cùng Phụ lục A.
Với tổ chức triển khai, dù là trung tâm điều hành an ninh nội bộ hay đơn vị cung cấp dịch vụ giám sát, nên chuẩn bị trước các nội dung mà tiêu chuẩn sẽ đòi: danh mục nguồn cảnh báo và cách phân nhóm; bộ trạng thái và kết quả xử lý cảnh báo, tình huống dùng thống nhất; quy tắc khử trùng lặp, quy tắc nhóm tình huống và quy tắc loại trừ có thời hạn, lý do, người phê duyệt; quy trình phê duyệt kịch bản với nguyên tắc tách biệt người tạo và người phê duyệt; chính sách lưu giữ và tiêu huỷ bằng chứng; quy trình xử lý dữ liệu cá nhân trong cảnh báo và bằng chứng; và cách theo dõi thời hạn báo cáo sự cố theo quy định pháp luật.
Với phòng thử nghiệm và tổ chức đánh giá sự phù hợp, bản dự thảo này là bản có sẵn đề cương đánh giá, nên công việc chuẩn bị tập trung vào ba việc: xây dựng tập dữ liệu tham chiếu theo khối lượng tối thiểu mà dự thảo nêu, chuẩn bị kịch bản mô phỏng gửi cảnh báo đồng thời từ nhiều nguồn, và thiết kế thử nghiệm chuyển đổi dự phòng để xác nhận ngưỡng RTO mà nhà cung cấp công bố. Với chủ hệ thống, dự thảo nên được dùng làm danh mục câu hỏi đánh giá nhà cung cấp trong giai đoạn này, đặc biệt ở phần bằng chứng số và vòng đời sản phẩm, vì đây là hai phần ảnh hưởng trực tiếp tới rủi ro pháp lý và rủi ro vận hành dài hạn.
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 trong 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 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 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 viện dẫn.
Bản SOAR khác gì hai bản SIEM và TIP?
Ba bản dành cho ba loại sản phẩm trong cùng một hệ sinh thái: SIEM phát hiện trên dữ liệu nhật ký, TIP quản lý tri thức về mối đe dọa đa nguồn, SOAR thực thi và điều phối ứng phó. Bản SOAR cũng là bản duy nhất có phụ lục quy định phương pháp đánh giá kèm phương pháp đo lường hiệu năng.
Phụ lục A của bản SOAR có phải nội dung tham khảo?
Không giống Phụ lục A của bản TIP. Phụ lục A của bản SOAR nêu phương pháp đánh giá và không ghi là tham khảo, nên cần đọc như một phần của bộ yêu cầu, đặc biệt khi chuẩn bị hồ sơ đánh giá.
Ngưỡng hiệu năng nêu trong bài có phải giá trị cuối cùng?
Không. Bài chỉ ghi lại các ngưỡng đang có trong bản dự thảo; khi tiêu chuẩn được ban hành, cần đối chiếu 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
- Thông tư 125/2026/TT-BCA: camera giám sát vào danh mục rủi ro trung bình
- Thông tư 14/2026/TT-BKHCN: 8 phương thức chứng nhận và cách chọn
- Chọn phòng thử nghiệm phù hợp để tuân thủ pháp luật Việt Nam
21. Tài liệu tham khảo
- Dự thảo TCVN XXXXX:2026 “An ninh mạng – Sản phẩm điều phối, tự động hoá và phản ứng an ninh 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, Bộ Khoa học và Công nghệ công bố. Dự thảo chưa có hiệu lực; 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 trích nguyên văn điều khoản.
- Quyết định số 1907/QĐ-BTTTT ngày 02/12/2021 của Bộ trưởng Bộ Thông tin và Truyền thông ban hành yêu cầu kỹ thuật cơ bản đối với sản phẩm điều phối, tự động hóa và phản ứng an toàn thông tin.
- Tài liệu tham khảo được dự thảo liệt kê: hướng dẫn thị trường của Gartner về các giải pháp điều phối, tự động hoá và phản ứng an ninh mạng tháng 11/2023; NIST SP 800-61r3 về các khuyến nghị và lưu ý ứng cứu sự cố trong quản lý rủi ro an ninh mạng.
- Hai dự thảo cùng loạt đã phân tích: TCVN XXXXX:2026 về SIEM và TCVN XXXXX:2026 về nền tảng tri thức mối đe dọa an ninh mạng (TIP).
22. Liên hệ
Nhà sản xuất sản phẩm và đơn vị cung cấp dịch vụ SOAR, trung tâm điều hành an ninh và tổ chức đang chuẩn bị hồ sơ đánh giá nền tảng có thể gửi yêu cầu qua biểu mẫu dưới đây để trao đổi về phạm vi đánh giá, phương pháp đo lường và hồ sơ cần chuẩn bị trước khi 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ế văn bản tiêu chuẩn và không phải tư vấn kỹ thuật hay pháp lý cho một 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 nêu trong bài là số liệu đang có trong bản 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 hiện hành.
