Cách phân định trách nhiệm bảo mật hệ thống giữa nhiều bên

Nguyên tắc thực tế hơn là phân định trách nhiệm đến từng tài sản, lớp kỹ thuật, kiểm soát bảo mật và hoạt động trong vòng đời hệ thống. Với mỗi nhiệm vụ, cần xác định rõ bên thực hiện, bên chịu trách nhiệm cuối cùng, bên phải được tham vấn và bên cần nhận thông tin. Quyền hạn, quyền truy cập, nghĩa vụ cung cấp bằng chứng và cơ chế xử lý khi các bên không thống nhất cũng phải được xác lập cùng lúc.

Phân định theo quyền kiểm soát thay vì theo tên đơn vị

Điểm khởi đầu của phân định trách nhiệm bảo mật là xác định bên nào thực sự có khả năng tác động đến từng thành phần của hệ thống.

Một đơn vị chỉ có thể chịu trách nhiệm vận hành một kiểm soát khi họ có đủ quyền để thực hiện kiểm soát đó. Chẳng hạn, nếu đội ứng dụng không có quyền quản trị hệ điều hành, việc giao cho đội này trách nhiệm vá lỗ hổng hệ điều hành sẽ tạo ra trách nhiệm trên giấy nhưng không tạo ra khả năng kiểm soát thực tế.

Có thể phân tích hệ thống thành các phạm vi như:

·         Hạ tầng vật lý hoặc hạ tầng điện toán

·         Hệ điều hành và nền tảng

·         Mạng và kết nối

·         Ứng dụng

·         Cơ sở dữ liệu

·         Danh tính và quyền truy cập

·         Dữ liệu

·         Nhật ký và giám sát

·         Sao lưu và phục hồi

·         Quản lý lỗ hổng

·         Quản lý cấu hình và thay đổi

·         Ứng phó sự cố

Sau đó, với từng phạm vi, cần trả lời ba câu hỏi: ai có quyền thay đổi, ai có khả năng thực hiện kiểm soát và ai có quyền chấp nhận rủi ro nếu kiểm soát không được thực hiện.

Ba câu trả lời có thể thuộc ba bên khác nhau. Vì vậy, quyền vận hành không đồng nghĩa với quyền chấp nhận rủi ro, và quyền quản trị kỹ thuật cũng không mặc nhiên đồng nghĩa với trách nhiệm cuối cùng về bảo mật.

Các mô hình quản trị an ninh mạng như NIST Cybersecurity Framework nhấn mạnh việc xác lập, truyền đạt và thực thi rõ vai trò, trách nhiệm và thẩm quyền. Ý nghĩa thực tế của nguyên tắc này là trách nhiệm chỉ có giá trị khi đi kèm quyền hạn tương ứng.

Mỗi kiểm soát cần có một đầu mối chịu trách nhiệm cuối cùng

Một kiểm soát có thể cần nhiều bên tham gia nhưng không nên rơi vào tình trạng tất cả đều “cùng chịu trách nhiệm” mà không xác định được người chịu trách nhiệm cuối cùng.

Ví dụ, việc quản lý bản vá cho một ứng dụng có thể liên quan đến:

·         Nhà cung cấp thông báo và phát hành bản vá

·         Đội hạ tầng triển khai bản vá hệ điều hành

·         Đội ứng dụng kiểm thử tương thích

·         Đội an toàn thông tin đánh giá mức độ nghiêm trọng của lỗ hổng

·         Chủ hệ thống phê duyệt thời gian gián đoạn cần thiết

Các bên đều tham gia, nhưng từng nhiệm vụ vẫn cần một đầu mối chịu trách nhiệm rõ ràng.

Mô hình RACI có thể được sử dụng để biểu diễn quan hệ này:

Điểm quan trọng nhất không nằm ở việc sử dụng đúng tên “RACI”, mà ở việc loại bỏ hai tình trạng: một nhiệm vụ không có người chịu trách nhiệm cuối cùng và một nhiệm vụ có nhiều bên cùng cho rằng bên khác phải xử lý.

Trong một số tổ chức, Responsible và Accountable có thể thuộc cùng một đơn vị. Trong hệ thống thuê ngoài hoặc có nhiều nhà cung cấp, hai vai trò này thường tách biệt. Bên vận hành có thể thực hiện công việc kỹ thuật, trong khi chủ hệ thống hoặc chủ rủi ro vẫn giữ trách nhiệm phê duyệt và giám sát.

Ma trận trách nhiệm phải đi đến từng hoạt động bảo mật

Phân công ở mức “đội IT phụ trách hạ tầng, đội bảo mật phụ trách an ninh” vẫn quá rộng. Một ma trận trách nhiệm có giá trị vận hành phải thể hiện được các hoạt động cụ thể.

Ví dụ:

Đây chỉ là một cấu trúc minh họa. Ma trận thực tế phải phản ánh kiến trúc, quyền truy cập và mô hình vận hành của chính hệ thống.

Một lỗi thường gặp là sao chép ma trận trách nhiệm từ hệ thống khác. Hai hệ thống sử dụng cùng công nghệ vẫn có thể cần phân công khác nhau nếu quyền quản trị, hợp đồng dịch vụ hoặc cấu trúc tổ chức khác nhau.

Các vùng giao nhau phải được phân định chi tiết hơn

Rủi ro lớn nhất thường không nằm ở những phần có chủ sở hữu rõ ràng mà nằm tại điểm giao giữa hai hoặc nhiều bên.

Quản lý danh tính là ví dụ điển hình. Bộ phận nghiệp vụ có thể quyết định người dùng nào cần quyền truy cập, đội IAM cấp quyền, đội ứng dụng định nghĩa vai trò kỹ thuật, còn đội bảo mật giám sát quyền đặc biệt. Nếu chỉ ghi “IAM chịu trách nhiệm quản lý truy cập”, câu hỏi ai phê duyệt quyền và ai phải thu hồi quyền khi nhân sự thay đổi vẫn chưa được giải quyết.

Quản lý lỗ hổng cũng có nhiều điểm giao. Bên bảo mật có thể phát hiện lỗ hổng nhưng không có quyền cài bản vá. Đội vận hành có quyền cài nhưng không quyết định được thời điểm dừng hệ thống. Chủ hệ thống có thể chấp nhận trì hoãn nhưng cần hiểu rủi ro phát sinh. Vì vậy, trách nhiệm phải bao phủ cả chuỗi phát hiện → đánh giá → giao xử lý → kiểm thử → triển khai → xác minh → chấp nhận ngoại lệ.

Ứng phó sự cố cần mức phân định tương tự. Phải xác định trước:

·         Bên nào có quyền cô lập máy chủ hoặc tài khoản

·         Bên nào quyết định dừng dịch vụ

·         Bên nào bảo toàn và thu thập bằng chứng

·         Bên nào điều phối trao đổi giữa các đơn vị

·         Bên nào liên hệ nhà cung cấp

·         Bên nào xác nhận hệ thống đủ điều kiện hoạt động trở lại

Nếu các quyền này chỉ được thảo luận sau khi sự cố xảy ra, thời gian xử lý sẽ phụ thuộc vào việc thương lượng trách nhiệm trong chính thời điểm cần phản ứng nhanh nhất.

Trách nhiệm phải gắn với quyền hạn và bằng chứng thực hiện

Giao trách nhiệm mà không giao quyền tạo ra một mô hình không thể thực thi. Ngược lại, trao quyền quản trị nhưng không xác định trách nhiệm giám sát làm tăng nguy cơ thay đổi không được kiểm soát.

Với từng trách nhiệm quan trọng cần kiểm tra bốn yếu tố:

Quyền hạn: Bên được giao có quyền truy cập, quyền phê duyệt hoặc quyền ra quyết định cần thiết hay không.

Nguồn lực: Bên đó có nhân lực, công cụ và quy trình để thực hiện nhiệm vụ hay không.

Bằng chứng: Có thể kiểm tra việc thực hiện bằng ticket, nhật ký, báo cáo quét, lịch sử phê duyệt, kết quả kiểm thử hoặc tài liệu tương đương hay không.

Cơ chế giám sát: Có bên nào độc lập kiểm tra rằng nhiệm vụ đã hoàn thành đúng yêu cầu hay không.

Ví dụ, quy định “đội vận hành phải vá lỗ hổng nghiêm trọng trong thời hạn quy định” chưa đầy đủ nếu tổ chức không xác định thời điểm bắt đầu tính thời hạn, cách xử lý trường hợp bản vá gây xung đột và ai có quyền phê duyệt ngoại lệ.

Không tồn tại một thời hạn vá lỗi hoặc phản ứng sự cố duy nhất phù hợp cho mọi hệ thống. Các ngưỡng này phải được xác định theo mức độ rủi ro, mức quan trọng của tài sản, khả năng khai thác, yêu cầu nghiệp vụ và các nghĩa vụ áp dụng đối với tổ chức.

Nhà cung cấp không làm mất trách nhiệm quản trị của chủ hệ thống

Khi một thành phần được thuê ngoài, trách nhiệm thực hiện có thể chuyển cho nhà cung cấp nhưng trách nhiệm quản trị không tự động biến mất.

Ví dụ, nhà cung cấp có thể chịu trách nhiệm vận hành hạ tầng, sao lưu hoặc cập nhật một thành phần. Tuy nhiên, tổ chức sử dụng hệ thống vẫn cần biết chính xác:

·         Nhà cung cấp thực hiện kiểm soát nào

·         Kiểm soát nào vẫn thuộc phía khách hàng

·         Bằng chứng nào chứng minh nghĩa vụ đã được thực hiện

·         Sự cố phải được thông báo bằng cơ chế nào

·         Trách nhiệm thay đổi thế nào khi dịch vụ hoặc kiến trúc thay đổi

Hợp đồng và SLA chỉ là một lớp của cơ chế này. Nếu hợp đồng nói nhà cung cấp “bảo đảm an ninh hệ thống” nhưng không xác định phạm vi kỹ thuật, thời gian thông báo, quyền truy cập log, trách nhiệm khắc phục và bằng chứng kiểm soát thì khoảng trống trách nhiệm vẫn tồn tại.

Một trường hợp cần đặc biệt chú ý là chuỗi nhà cung cấp. Nhà cung cấp chính có thể tiếp tục sử dụng dịch vụ của bên thứ ba. Khi đó, tổ chức cần xác định trách nhiệm được kế thừa như thế nào và ai vẫn là đầu mối chịu trách nhiệm nếu sự cố xảy ra ở lớp dịch vụ phía sau.

Thiết lập cơ chế xử lý khi trách nhiệm xung đột

Không phải mọi vấn đề đều có thể giải quyết bằng ma trận trách nhiệm. Một số tình huống cần quyền quyết định và quy trình leo thang rõ ràng.

Ví dụ, đội bảo mật muốn khẩn cấp vá một lỗ hổng nhưng đội nghiệp vụ cho rằng việc dừng dịch vụ tạo ra rủi ro vận hành lớn hơn. Đây không đơn thuần là tranh chấp giữa hai phòng ban mà là một quyết định chấp nhận và xử lý rủi ro.

Quy trình cần xác định trước:

1.    Ai cung cấp đánh giá rủi ro kỹ thuật

2.    Ai đánh giá tác động nghiệp vụ

3.    Ai có thẩm quyền chấp nhận rủi ro còn lại

4.    Ngoại lệ có hiệu lực trong điều kiện và thời gian nào

5.    Biện pháp bù trừ nào phải được áp dụng

6.    Khi nào quyết định phải được xem xét lại

Nhờ đó, trách nhiệm không bị chuyển dịch bằng trao đổi miệng hoặc email không chính thức. Quyết định có chủ thể, phạm vi, thời hạn và bằng chứng rõ ràng.

Rà soát trách nhiệm theo thay đổi của hệ thống

Ma trận trách nhiệm không phải tài liệu tạo một lần rồi giữ nguyên. Kiến trúc, nhà cung cấp, quyền quản trị và quy trình vận hành đều có thể thay đổi, làm cho phân công cũ không còn phù hợp.

Việc rà soát nên được kích hoạt khi có thay đổi làm thay đổi quyền kiểm soát hoặc rủi ro, chẳng hạn:

·         Chuyển một thành phần sang nhà cung cấp mới

·         Thay đổi mô hình vận hành hoặc đội quản trị

·         Bổ sung kết nối với hệ thống bên ngoài

·         Thay đổi cơ chế xác thực hoặc quản lý đặc quyền

·         Phát sinh loại dữ liệu mới cần bảo vệ

·         Xảy ra sự cố cho thấy trách nhiệm hiện tại có khoảng trống

·         Thay đổi hợp đồng làm thay đổi phạm vi dịch vụ

Một dấu hiệu thực tế cho thấy mô hình trách nhiệm có vấn đề là khi một cảnh báo, yêu cầu vá lỗi hoặc sự cố phải được chuyển qua nhiều đơn vị chỉ để xác định “ai xử lý”. Khi đó, vấn đề không chỉ thuộc quy trình vận hành mà còn là vấn đề quản trị trách nhiệm.

Phân định trách nhiệm bảo mật hệ thống giữa nhiều bên hiệu quả khi mỗi kiểm soát và hoạt động quan trọng đều có chủ thể thực hiện, chủ thể chịu trách nhiệm cuối cùng, quyền hạn tương ứng và bằng chứng có thể kiểm tra. Những khu vực có nhiều bên cùng tham gia cần được phân tách theo từng bước của quy trình thay vì gán trách nhiệm chung cho một phòng ban.

Mục tiêu cuối cùng không phải tạo một ma trận phân công thật chi tiết, mà là bảo đảm tại bất kỳ thời điểm nào cũng có thể trả lời rõ: ai phải làm, ai được quyết định, ai chịu trách nhiệm khi không làm, và trách nhiệm được chuyển giao như thế nào khi hệ thống hoặc mô hình quản lý thay đổi.