INFOCHIEF ACADEMY · INFORMATION SECURITY KNOWLEDGE SERIES

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.

SoA nối các kiểm soát cần thiết với căn cứ lựa chọn và tình trạng triển khai. Đi từ rủi ro, yêu cầu và quyết định xử lý giúp doanh nghiệp giữ tài liệu đúng với phạm vi, trách nhiệm và hoạt động thực tế.

Biên soạn: Infochief Academy · Chuyên đề: Quản lý an toàn thông tin

← Trở về thư viện bài viết

Minh họa biên tập: nhóm chuyên gia đối chiếu rủi ro và kiểm soát cần thiết trên sơ đồ phục vụ xây dựng SoA.

Khi chuẩn bị hệ thống quản lý an toàn thông tin, nhiều doanh nghiệp bắt đầu Statement of Applicability bằng một bảng có sẵn rồi đánh dấu áp dụng hoặc không áp dụng. Tài liệu nhanh chóng đầy các dòng kiểm soát, nhưng người đọc vẫn khó biết vì sao tổ chức cần chúng và phần nào thực sự đang vận hành.

SoA, thường được gọi là bản tuyên bố áp dụng, cần thể hiện các kiểm soát cần thiết cùng căn cứ lựa chọn. Để làm được điều đó, doanh nghiệp phải nối bối cảnh, nghĩa vụ và rủi ro với quyết định xử lý. Bảng biểu là cách trình bày; chất lượng của những quyết định phía sau mới làm tài liệu có giá trị.

Đi từ quyết định xử lý tới kiểm soát cần thiết

Một rủi ro về người đã chuyển vị trí vẫn truy cập dữ liệu không tự động dẫn tới việc mua một phần mềm cụ thể. Nhóm cần xem quyền được cấp như thế nào, thông tin thay đổi nhân sự đến đâu và ai xác nhận thu hồi. Kiểm soát cần thiết có thể gồm quy trình, trách nhiệm, cấu hình ứng dụng và bước kiểm tra chéo. Nếu bỏ qua phân tích này, SoA dễ chỉ phản ánh danh mục công cụ.

Theo ISO/IEC 27001:2022, tổ chức xác định các kiểm soát cần thiết cho xử lý rủi ro, đối chiếu với Annex A để tránh bỏ sót, rồi lập SoA với thông tin cần có. SoA ghi các kiểm soát cần thiết, lý do đưa vào, tình trạng đã triển khai hay chưa và lý do loại trừ các kiểm soát Annex A được xác định là không cần thiết.

Không nên đảo chuỗi đó thành chọn mọi kiểm soát trong Annex A rồi tìm lý do cho đủ. Annex A là bộ tham chiếu để đối chiếu; nhu cầu kiểm soát phải có căn cứ từ tổ chức. Các kiểm soát cần thiết được thiết kế riêng hoặc chọn từ nguồn khác cũng cần được phản ánh trong SoA, thay vì bị bỏ ngoài vì không khớp tên trên bảng mẫu.

Việc chuẩn bị vì thế cần người hiểu cả rủi ro lẫn hoạt động. Nội dung quản lý bảo mật thông tin có thể hỗ trợ đội ngũ thực hành cách chuyển mục tiêu bảo vệ thành trách nhiệm và biện pháp có thể kiểm tra. Biểu mẫu nên phục vụ quá trình này, không quyết định thay cho nó.

Phân biệt SoA với sổ rủi ro và kế hoạch xử lý

Sổ rủi ro mô tả các kịch bản, mức đánh giá, chủ rủi ro và thông tin liên quan. Kế hoạch xử lý nêu công việc để thay đổi mức phơi nhiễm cùng nguồn lực, người thực hiện và lịch theo dõi. SoA tập trung vào các kiểm soát cần thiết và căn cứ áp dụng. Ba tài liệu liên kết với nhau nhưng trả lời những câu hỏi khác nhau.

Chẳng hạn, một rủi ro về lộ thông tin qua chia sẻ tài liệu có thể cần phân loại dữ liệu, giới hạn quyền và hướng dẫn sử dụng. Ngược lại, một kiểm soát về quyền truy cập có thể phục vụ nhiều rủi ro trên các quy trình khác nhau. Cố ép mỗi dòng SoA chỉ tương ứng một dòng rủi ro sẽ làm tài liệu cồng kềnh và khó giữ nhất quán.

Một cách thực hành là duy trì mã tham chiếu ổn định giữa các hồ sơ. Người xem có thể lần từ kiểm soát về những căn cứ chính, đồng thời mở kế hoạch để biết việc còn thiếu đang được xử lý thế nào. Không cần sao chép toàn bộ nội dung đánh giá vào từng ô SoA; việc sao chép thường khiến một thay đổi nhỏ phải sửa nhiều nơi.

Các yêu cầu hợp đồng, pháp luật và những nhu cầu bảo vệ khác đã được xác định cũng có thể là căn cứ lựa chọn. Đầu mối chuyên môn cần xác nhận nghĩa vụ áp dụng trước khi ghi lý do. Một liên kết tới sổ rủi ro không thay thế việc hiểu yêu cầu đó, cũng không chứng minh doanh nghiệp đã đáp ứng toàn bộ nghĩa vụ liên quan.

Nhóm có thể vận dụng cách phân tích trong quản lý rủi ro IT để giữ các mối liên hệ rõ. Khi kịch bản thay đổi, người phụ trách biết phải xem lại kiểm soát nào; khi kiểm soát không còn hiệu lực, họ biết những quyết định rủi ro nào cần được đánh giá lại.

Thiết kế bảng để người điều hành đọc được

ISO/IEC 27001 xác định nội dung cần có của SoA, không ấn định một cấu trúc bảng duy nhất. Tổ chức có thể bổ sung chủ kiểm soát, liên kết bằng chứng hoặc thời điểm rà soát để thuận tiện sử dụng. Những trường bổ sung đó là lựa chọn quản lý; cần phân biệt với thông tin cốt lõi mà tiêu chuẩn yêu cầu.

Lý do áp dụng nên nói rõ nhu cầu tổ chức. Cụm từ “theo yêu cầu bảo mật” thường quá chung để hỗ trợ quyết định. Một lý do như “hạn chế người không còn nhiệm vụ đọc hồ sơ nhân sự” tạo được điểm kiểm tra. Người phụ trách có thể xem phạm vi quyền và bằng chứng thu hồi có đáp ứng đúng nhu cầu này hay không.

Bảng minh họa dưới đây đề xuất cách viết ngắn gọn cho thảo luận nội bộ. Tên nhóm và trạng thái là ví dụ giả định; bảng không thay thế SoA đầy đủ và không phải cấu trúc bắt buộc của ISO/IEC 27001. Khi sử dụng thật, doanh nghiệp cần đối chiếu đủ với bộ tham chiếu và quản lý các thông tin cốt lõi đã nêu.

Kiểm soát cần thiết minh họa	Căn cứ lựa chọn	Tình trạng và điểm cần kiểm chứng
Thu hồi quyền khi đổi vai trò	Hạn chế quyền không còn phục vụ nhiệm vụ	Đã có quy trình; cần kiểm tra thực tế trên ứng dụng
Giới hạn chia sẻ hồ sơ nhân sự	Bảo vệ dữ liệu trong luồng gửi cho đối tác	Mới áp dụng một phần; còn thiếu phạm vi thư mục
Kiểm thử khôi phục dữ liệu	Duy trì khả năng phục hồi công việc quan trọng	Có lịch kiểm thử; cần xác nhận kết quả theo nhu cầu

Các trạng thái chi tiết có thể giúp điều hành, nhưng phải đủ rõ để trả lời kiểm soát đã được triển khai hay chưa. Không nên dùng “đang thực hiện” cho cả việc mới có kế hoạch lẫn việc đã vận hành một phần. Khi chưa phủ đủ phạm vi, tài liệu cần thể hiện khoảng trống và liên kết hành động khắc phục.

Loại trừ cần căn cứ, thuê ngoài vẫn cần trách nhiệm

Lý do không áp dụng không thể chỉ là “chưa mua”, “không có ngân sách” hoặc “nhà cung cấp chịu trách nhiệm”. Nếu kiểm soát vẫn cần thiết, thiếu nguồn lực là khoảng trống phải xử lý; nó không làm nhu cầu bảo vệ biến mất. Lý do loại trừ cần bám phạm vi, bối cảnh và đánh giá về sự cần thiết của kiểm soát tham chiếu.

Đặc biệt, một kiểm soát có thể được thực hiện bên ngoài ranh giới đơn vị nhưng vẫn cần cho ISMS. Bộ phận nhân sự dùng chung có thể cung cấp thông tin nghỉ việc; nhà cung cấp có thể vận hành một phần dịch vụ. Doanh nghiệp cần thể hiện kiểm soát cần thiết và cách quản lý phần phụ thuộc, thay vì xóa dòng đó vì không trực tiếp thao tác.

Ví dụ, với dịch vụ thuê ngoài, tổ chức có thể cần thỏa thuận trách nhiệm, đầu mối xác nhận, bằng chứng thực hiện và cơ chế xử lý khi cam kết không đạt. Cách tiếp cận phụ thuộc loại dịch vụ và mức rủi ro. Một báo cáo của nhà cung cấp cần được xem phạm vi, thời điểm và giới hạn trước khi dùng làm bằng chứng cho hoạt động của doanh nghiệp.

Để tránh những khoảng trống này, người quản lý IT cần thống nhất với nghiệp vụ và đối tác về đầu ra kiểm soát. Người thực hiện có thể khác chủ chịu trách nhiệm; hồ sơ cần cho thấy tổ chức biết mình đang dựa vào ai và sẽ xác nhận phần đó như thế nào.

Một tình huống: tài liệu đủ dòng nhưng thiếu điểm giao nhận

Trong tình huống giả định, một công ty đưa quy trình thu hồi tài khoản vào SoA với trạng thái đã triển khai. IT có hướng dẫn khóa tài khoản khi nhận yêu cầu, và bộ phận nhân sự có danh sách nghỉ việc. Tuy nhiên, hai bên không có bước xác nhận rằng thông tin đã đến đúng đầu mối trước thời điểm nhân viên ngừng nhiệm vụ.

Khi đối chiếu một trường hợp thực tế, nhóm thấy tài khoản trung tâm đã khóa nhưng quyền tại ứng dụng do đối tác quản trị vẫn tồn tại. SoA chỉ mô tả phần IT trực tiếp làm, nên cả điểm giao nhận nhân sự và quyền ở ứng dụng thuê ngoài đều không được nhìn đầy đủ. Vấn đề không nằm ở việc thiếu thêm một dòng tên sản phẩm.

Nhóm sửa cách mô tả kiểm soát: làm rõ sự kiện nhân sự, danh sách hệ thống cần xử lý, trách nhiệm gửi nhận và bước xác nhận kết quả. Trạng thái cũng được chỉnh theo phạm vi thực sự đã đạt. Các hành động còn thiếu được đưa sang kế hoạch xử lý với người phụ trách, thay vì ghi trong ô chú thích rồi để đó.

Sau đó, doanh nghiệp kiểm tra lại bằng một tình huống có phạm vi tương tự. Bằng chứng là yêu cầu đã được chuyển đúng, quyền liên quan đã được xử lý và bên có trách nhiệm đã xác nhận. Câu chuyện giả định cho thấy SoA hữu ích khi giúp phát hiện mối liên hệ còn thiếu giữa lý do lựa chọn và hoạt động đang vận hành.

Duy trì SoA như hồ sơ của những lựa chọn hiện hành

SoA cần được xem lại khi phạm vi, quy trình, rủi ro hoặc yêu cầu liên quan thay đổi. Nếu doanh nghiệp thêm dịch vụ mới nhưng vẫn dùng căn cứ cũ, tài liệu có thể đúng về hình thức mà sai với hiện trạng. Chủ tài liệu cần phối hợp với chủ rủi ro và người vận hành để nhận các thay đổi có ý nghĩa.

Trạng thái triển khai cũng không tự chứng minh hiệu lực lâu dài. Kiểm soát có thể đã được cấu hình nhưng người dùng đổi cách làm, dữ liệu tăng phạm vi hoặc nhà cung cấp thay quy trình. Theo dõi và kiểm tra cần cho biết kết quả bảo vệ có còn phù hợp. Khi phát hiện sai lệch, cập nhật hồ sơ phải đi cùng hành động sửa hoạt động.

Mối liên hệ với quản lý dịch vụ IT giúp SoA nhận thông tin từ thay đổi, vận hành và sự cố. Đây là cách để quyết định bảo mật tiếp tục bám dịch vụ đang cung cấp, thay vì chỉ được rà vào thời điểm chuẩn bị đánh giá.

Một SoA tốt không cần dùng những lời khẳng định lớn. Nó cần cho người đọc hiểu kiểm soát nào là cần thiết, tại sao, đang được thực hiện ở đâu và còn điểm nào phải làm. Với các câu trả lời có căn cứ, tài liệu trở thành nơi nối quyết định xử lý với trách nhiệm thực tế của doanh nghiệp.