Đánh giá rủi ro an toàn thông tin: Phương pháp nhận diện, phân tích và xác định mức ưu tiên.

Chuẩn bị tiêu chí và phạm vi trước khi chấm

Tổ chức cần biết đang đánh giá phần nào, để phục vụ quyết định gì và dùng tiêu chí nào. Phạm vi nên khớp ISMS hoặc hoạt động được chọn, cùng các giao diện liên quan. Nếu mỗi nhóm tự mở ranh giới và thang đo, kết quả sẽ khó so hoặc tổng hợp thành ưu tiên.

Tiêu chí tác động cần phản ánh mất bí mật, toàn vẹn và sẵn sàng đối với công việc. Các mức phải có ý nghĩa đủ rõ, như nhóm bị ảnh hưởng, điều kiện gián đoạn hoặc hậu quả thông tin sai. Không nên chỉ dùng những từ nhẹ, vừa, nghiêm trọng mà không biết người đánh giá hiểu thế nào.

Cũng cần tiêu chí về khả năng và mức chấp nhận. Khả năng có thể dựa trên dấu hiệu, điều kiện, lịch sử phù hợp và hiểu biết chuyên môn, nhưng phải ghi giới hạn. Không có sự cố đã biết chưa chứng minh rủi ro thấp nếu tổ chức chưa có khả năng quan sát đủ.

Năng lực xây phương pháp và diễn giải có thể được phát triển qua chương trình Quản trị rủi ro IT. Khi áp dụng, lãnh đạo và chủ nghiệp vụ cần cùng xác nhận ý nghĩa tiêu chí, để thang đo phục vụ quyết định doanh nghiệp chứ không chỉ ý kiến kỹ thuật.

Nhận diện bằng kịch bản thay vì tên mối đe dọa

Một dòng rủi ro nên giải thích điều gì có thể xảy ra, với thông tin hoặc hoạt động nào, trong điều kiện nào và gây hệ quả gì. “Mất dữ liệu” quá rộng nếu không biết dữ liệu nào, cơ chế và tác động. Cách viết kịch bản giúp chọn kiểm tra và biện pháp phù hợp hơn danh sách tên đe dọa.

Có thể nhìn từ tài sản, luồng thông tin, sự cố, thay đổi hoặc điều kiện kiểm soát. Điểm yếu là một yếu tố, nhưng không tự là toàn bộ rủi ro. Một cấu hình yếu cần được nối với khả năng bị tác động và hậu quả; một hành vi chia sẻ cần nhìn quyền, mục đích và người nhận.

Tình huống giả định: dữ liệu chào giá được xuất vào thư mục có quyền rộng. Kịch bản cần nêu khả năng người không có nhu cầu truy cập hoặc sử dụng thông tin trong quá trình phối hợp, cùng hậu quả với hoạt động thương lượng. Chủ dữ liệu xác nhận ý nghĩa, còn nhóm kỹ thuật xác nhận điều kiện quyền và khả năng quan sát.

Người sở hữu rủi ro cần được xác định theo trách nhiệm và quyền. Họ không nhất thiết tự làm mọi biện pháp, nhưng phải có khả năng nhận lựa chọn và tổ chức xử lý theo cơ chế. Không nên giao toàn bộ bảng rủi ro cho một chuyên viên chỉ vì họ là người tổng hợp.

Phân tích kiểm soát cùng độ chắc chắn

Đánh giá phải phản ánh trạng thái kiểm soát được xác nhận. Một chính sách hoặc công cụ tồn tại chưa chứng minh kiểm soát có hiệu lực. Cần xem việc thực hiện, phạm vi, ngoại lệ và bằng chứng phù hợp trước khi kết luận tác động hoặc khả năng đã được giảm.

Phân biệt rủi ro ở điều kiện hiện tại với mức dự kiến sau xử lý giúp tránh nhầm. Nếu biện pháp chưa được thực hiện hoặc kiểm tra, phần giảm chỉ là dự báo có giả định. Đừng đưa mức dự kiến vào cột hiện tại để báo cáo rủi ro thấp hơn trước khi có căn cứ.

Mức nghiêm trọng kỹ thuật cần được diễn giải trong bối cảnh. Một điểm yếu có thể tác động khác khi nằm ở dịch vụ, dữ liệu hoặc điều kiện khác. Không nên dùng điểm kỹ thuật làm đại diện duy nhất cho ưu tiên doanh nghiệp; nó là một đầu vào cần nối với tác động cùng khả năng.

Bảng là công cụ đánh giá đề xuất, không phải phương pháp chấm điểm bắt buộc của ISO/IEC 27001. Nhóm phải chọn cách phù hợp, giữ tiêu chí cùng bằng chứng và có khả năng tạo kết quả so sánh được. Không cần biến mọi nhận định thành số chính xác nếu dữ liệu không hỗ trợ.

Năng lực tổ chức kiểm soát và bằng chứng có thể được phát triển qua chương trình Quản lý Bảo mật Thông tin. Trong thực hành, người phân tích cần thông tin từ chủ kiểm soát và chủ nghiệp vụ, để kết luận không chỉ dựa vào việc một tính năng đã được bật.

Xác định ưu tiên theo điều kiện cần quyết định

Kết quả được đối chiếu tiêu chí để biết rủi ro nào cần xử lý hoặc xem thêm. Một ma trận có thể hỗ trợ, nhưng không nên che yêu cầu quan trọng bằng cách cộng điểm. Các nghĩa vụ đã xác định hoặc điều kiện không được chấp nhận cần được xử lý theo cơ chế phù hợp.

Hai rủi ro cùng điểm có thể cần thứ tự khác vì thời hạn, mức không chắc chắn hoặc phụ thuộc. Một việc tạo điều kiện cho nhiều biện pháp khác có thể cần làm trước. Người quản lý nên trình lý do bổ sung thay vì chỉ sắp thứ tự từ lớn xuống nhỏ rồi xem đó là kế hoạch đầy đủ.

Cần phân biệt ưu tiên xử lý với ưu tiên kiểm chứng. Một kịch bản có tác động lớn nhưng thiếu dữ liệu có thể cần đánh giá bổ sung sớm. Sự thiếu chắc chắn không nên tự làm mức thấp, cũng không khiến mọi việc đều cao mà không có bước tiếp theo.

Năng lực tổ chức ưu tiên và kế hoạch có thể được phát triển qua chương trình Trưởng Phòng IT – IT Manager. Trong doanh nghiệp, người quản lý phải nhìn nguồn lực và phụ thuộc thực, để danh sách ưu tiên không trở thành nhiều việc cùng khẩn nhưng không có khả năng thực hiện.

Một mức rủi ro được sửa sau kiểm chứng

Trong tình huống dữ liệu chào giá giả định, nhóm ban đầu đánh mức thấp vì tin rằng chỉ người trong dự án có quyền. Kiểm tra cho thấy nhóm truy cập dùng chung có phạm vi rộng và một số tài khoản cũ vẫn còn. Nhận định về kiểm soát không khớp trạng thái thực.

Nhóm cập nhật kịch bản, tác động và điều kiện cùng chủ dữ liệu. Các biện pháp dự kiến như thu hẹp quyền, xác nhận nhu cầu và rà định kỳ được tách khỏi kiểm soát hiện có. Mức sau xử lý được trình với giả định, chờ thực hiện và kiểm chứng trước khi xem là trạng thái đã đạt.

Trường hợp này không có nghĩa mọi tài liệu trong doanh nghiệp đều có cùng mức rủi ro. Kết luận phải giữ phạm vi và dẫn tới kiểm tra phù hợp nếu cần mở rộng. Một phát hiện quan trọng là đầu vào quản lý, không phải lý do đưa ra nhận định toàn tổ chức thiếu căn cứ.

Lãnh đạo nhận những lựa chọn về thời điểm, nguồn lực và rủi ro còn lại. Góc nhìn trong chương trình Lãnh đạo IT – CIO là hướng tham khảo để phát triển cách trình này. Điều cần giữ là người có quyền hiểu căn cứ và giới hạn khi lựa chọn, không chỉ nhận một ô màu.

Duy trì đánh giá khi môi trường đổi

Đánh giá cần được rà ở thời điểm phù hợp và khi có thay đổi đáng kể. Dữ liệu, quyền, dịch vụ, đối tác hoặc bằng chứng kiểm soát mới có thể làm kết luận khác. Không nên chỉ giữ bảng đầu tiên rồi thay ngày rà trong khi các giả định đã lỗi thời.

ISO/IEC 27005 cung cấp hướng dẫn quản lý rủi ro an toàn thông tin, còn ISO/IEC 27001 đặt yêu cầu cho ISMS. Tổ chức có thể dùng hướng dẫn phù hợp để xây phương pháp, nhưng không nên trình một bảng đề xuất như phương pháp duy nhất tiêu chuẩn bắt buộc. Cần giữ cách làm có căn cứ và được sử dụng nhất quán.

Những sai lệch giữa đánh giá và thực tế cần được phản hồi vào tiêu chí, dữ liệu hoặc cách kiểm tra. Nếu rủi ro thường bị đánh thấp vì tin vào tài liệu, tăng kiểm chứng; nếu mọi việc đều cao vì tiêu chí quá mơ hồ, làm rõ ý nghĩa. Cải tiến phương pháp giúp lựa chọn đáng tin hơn qua thời gian.

Đánh giá rủi ro có giá trị khi kịch bản, bằng chứng và tiêu chí dẫn tới một bước tiếp theo rõ. Tổ chức biết điều cần xử lý, điều cần kiểm chứng và người chịu trách nhiệm. Khi mức rủi ro có thể giải thích, ma trận trở thành công cụ quyết định thay vì một bảng điểm khó sử dụng.

Bài viết liên quan

• An toàn thông tin không phải việc riêng của IT: Đưa rủi ro lên bàn lãnh đạo
• Kiểm kê và phân loại tài sản thông tin: Nền tảng để xác định yêu cầu bảo vệ.
• Lập kế hoạch xử lý rủi ro: Khi nào cần giảm thiểu, tránh, chia sẻ hoặc chấp nhận rủi ro?
• Xây dựng Statement of Applicability: Liên kết rủi ro với các biện pháp kiểm soát.

Nguồn tham khảo

1. ISO — ISO/IEC 27005:2022: Guidance on managing information security risks
2. NIST — SP 800-30 Rev. 1: Guide for Conducting Risk Assessments
3. NIST — IR 8286D, updated: Using Business Impact Analysis to Inform Risk Prioritization and Response