Tư vấn

Risk Management - Quản lý rủi ro (P4)

(KHCN) - Rủi ro trong lĩnh vực IT được định nghĩa là khả năng (xác suất) một vấn đề nào đó xảy ra gây hư hỏng, phá hủy hay làm lộ thông tin. Quản lý rủi ro là một quy trình chi tiết để xác định các yếu tố này, đánh giá so sánh giá trị của dữ liệu với chi phí bảo vệ và triển khai các giải pháp hiệu quả để loại bỏ hay giảm thiểu các rủi ro.


Phân tích định tính

Thay vì sử dụng giá trị thực (tính bằng dollar) để xác định các mất mát xảy ra, phân tích định tính xếp hạng các đe dọa dựa vào một thước đo tỉ lệ để đánh giá rủi ro, chi phí, và hiệu quả.

Phương pháp phân tích định tính sử dụng óc phán đoán, trực giác và kinh nghiệm để thực hiện phân tích rủi ro. Các kỹ thuật sử dụng để thực hiện phân tích định tính bao gồm

Brainstorming
Delphi technique
Storyboarding
Focus groups
Surveys
Questionnaires
Checklists
One-on-one meetings
Interviews

Kịch bản

Công việc căn bản nhất của các kỹ thuật trên là việc tạo ra các Kịch bản. Một kịch bản là một miêu tả được viết ra của một đe dọa chính. Kịch bản tập trung vào việc miêu tả làm thế nào để một Đe dọa xảy ra và ảnh hưởng của nó đối với tổ chức, hạ tầng CNTT hay tài sản cụ thể. Thông thường, kịch bản nên giới hạn trong vòng 1 trang A4 để dễ dàng quản lý. Đối với mỗi kịch bản, cần có một hoặc nhiều phương pháp bảo vệ hoàn toàn hoặc một phần Đe dọa đã được miêu tả. Phân tích viên sau đó gán cho mỗi kịch bản một thread level (mức độ đe dọa), một loss potential (khả năng mất mát) và các lợi ích của mỗi phương pháp bảo vệ. Việc gán thread level có thể đơn giản như High, Medium, Low, hoặc là con số từ 1 – 10, 1- 100, …

Tính hữu ích và hợp lệ của quá trình phân tích định tính phụ thuộc vào số lượng và sự đa dạng của các cá nhân tham gia quá trình. Nếu có thể, nên sử dụng 1 hoặc 2 người ở các bộ phận khác nhau của tổ chức tham gia vào quá trình phân tích định tính này, từ cấp lãnh đạo đến nhân viên thông thường nhằm tăng sự chính xác của kết quả phân tích.

Kỹ thuật Delphi (Delphi Technique)

Trong các kĩ thuật phân tích định tính trên thì có kỹ thuật Delphi là mới mẻ và có thể là xa lạ. Kỹ thuật Delphi thực chất là một quy trình nhận xét và trả lời nặc danh. Mục tiêu chính của nó là giữ được tính nhiệt tình và không bị tác động lẫn nhau giữa các đối tượng tham gia quy trình trong quá trình phân tích. Thông thường tất cả những người tham gia sẽ được vào ngồi chung một phòng, đối với mỗi vấn đề cần được nhận xét, mỗi người sẽ tự viết ra ý kiến của mình một cách nặc danh (không biết ai viết) và sau đó từng ý kiến sẽ được nêu lên để cả nhóm đánh giá. Quy trình cứ thế thực hiện cho đến khi có kết quả chấp nhận được.

Cả 2 phương pháp phân tích rủi ro định lượng và định tính đều cho các kết quả hữu ích trong việc phân tích rủi ro đối với một tài sản. Tuy nhiên mỗi phương pháp đều có điểm mạnh và điểm yếu của nó như trong liệt kê dưới đây

Sau khi phân tích rủi ro, việc quan trọng tiếp theo là quản lý (xử lý) các rủi ro đó.  Dựa trên kết quả của phân tích rủi ro bao gồm

– Chi tiết giá trị tài sản

– Danh sách vét cạn các đe dọa và rủi ro, tần suất xuất hiện và giá trị mất mát khi các đe dọa và rủi ro xảy ra

– Danh sách các phương pháp phòng thủ và bảo vệ kèm với hiệu quả của nó (đồng thời là giá trị ALE sau khi triển khai các phương pháp đó)

– Bảng phân tích chi phí / lợi ích của mỗi phương pháp bảo vệ

Các thông tin trên hỗ trợ cho người quản lý có thể đưa ra các quyết định sáng suốt về việc lựa chọn các phương pháp bảo vệ hay chỉnh sửa chính sách bảo mật của tổ chức cho phù hợp.

Sau khi phân tích rủi ro được hoàn tất, việc tiếp theo là phải xử lý rủi ro. Có 4 cách để xử lý rủi ro như sau

– Giảm thiểu (reduce): Đây là cách xử lý phổ biến nhất. Có thể sử dụng các cơ chế bảo vệ để giảm thiểu rủi ro xuống mức có thể chấp nhận được.

– chuyển (transfer hay Assign): Chuyển rủi ro sang các đối tượng khác. Ví dụ như thuê ngoài (oursourcing) hay mua bảo hiểm để chuyển rủi ro sáng các tổ chức khác

– Chấp nhận (accept): Chấp nhận rủi ro là việc tổ chức có thể nhận thấy chi phí để xây dựng các phương pháp bảo vệ lớn hơn những mất mát có thể có do tài sản đó bị tấn công. Do đó, nếu những hậu quả của việc mất mát này là có thể chấp nhận được, tổ chức có thể chấp nhận rủi ro và không triển khai một phương pháp bảo vệ nào.

– Từ chối (reject hay ignore): Là lựa chọn cuối cùng. Có nghĩa là tổ chức bỏ qua sự tồn tại của rủi ro này và hy vọng nó sẽ không xảy ra

Sau khi triển khai các phương pháp bảo vệ thì không phải là có thể loại bỏ hết mọi rủi ro. Những rủi ro còn tồn tại được gọi là Rủi ro còn lại (residual risk). Rủi ro còn lại là tất cả những đe dọa đối với các tài sản mà lớp quản lý chấp nhận nó mà không thực hiện các phương pháp để giảm thiểu hay loại bỏ nữa. Trong hầu hết các trường hợp thì Rủi ro còn lại là thước đo chính để đánh giá quá trình phân tích rủi ro hiệu quả đến mức độ nào.

Tổng số rủi ro(Total risk) được xác định là tất cả các rủi ro mà tổ chức phải đối mặt nếu không có một cơ chế bảo mật nào được triển khai. Tổng số rủi ro được tính theo công thức

total risk = threats * vulnerabilities * asset value

Sự khác nhau giữa Tổng số rủi ro và rủi ro còn lại được gọi là Độ che phủ của quản lý (Control gap) liên quan với Tổng số rủi ro và Rủi ro còn lại theo công thức

total risk – controls gap = residual risk

Lựa chọn các phương pháp bảo vệ / phòng thủ

Khi lựa chọn các phương pháp bảo vệ hay phòng thủ, cần chú ý đến các vấn đề

– Chi phí phòng thủ / bảo vệ nên nhỏ hơn chi phí của tài sản được bảo vệ

– Chi phí phòng thủ / bảo vệ nên thấp hơn những lợi ích mà nó mang lại

– Kết quả của việc triển khai cơ chế phòng thủ / bảo vệ nên làm cho chi phí để hacker có thể tấn công chiếm tài sản lớn hơn giá trị mà hacker có thể lấy được
– Cơ chế phòng thủ / bảo vệ nên phục vụ cho một vấn đề thực tế nào đó (đã được xác nhận) chứ không nên triển khai nó chỉ vì … có nó (hay nghe quảng cáo, nghe đồn, …)

– Cơ chế phòng thủ / bảo vệ không phải mạnh vì nó … bí mật. Nghĩa là tránh việc “bảo mật tù mù”.

– Những cơ chế phòng thủ / bảo mật cần phải kiểm chứng được

– Hướng đến việc đồng bộ và thống nhất các cơ chế bảo vệ trong toàn bộ hệ thống.

– Các “cửa” bảo vệ nên ít hoặc không phụ thuộc vào nhau để tránh đổ vỡ hàng loạt

– Tránh việc can thiệp của con người vào trong các hệ thống bảo vệ trong vận hành (sau khi triển khai và cấu hình)

– Bản thân hệ thống bảo vệ phải an toàn (không có backdoor, không bị xâm nhập, …)

– Chỉ có nhân viên có đặc quyền mới được có quyền thay đổi trên các hệ thống bảo vệ
– Nên đặt chế độ fail-safe hay fail-secure tại các hệ thống bảo vệ (cơ chế này giúp cho việc nếu hệ thống bảo vệ có sự cố thì nó sẽ deny all).

TH

Thông tin website

Chuyên trang Bản tin khoa học công nghệ.
Thực hiện : Phòng Khoa học - Công nghệ, Trung Tâm CNTT, BộVăn hoá,Thể thao & Du lịch.
Người chịu trách nhiệm chính: Nguyễn Thanh Liêm - Giám đốc.

Địa chỉ: Ngõ 2 số 20, Vân Hồ, Hoa Lư, Hà Nội;
Tel: 0243 9745845
Email: khoahoccongnghe@cinet.gov.vn
Ghi rõ nguồn khi phát lại thông tin từ website này.

Liên hệ Tòa soạn