Unlimited Design & Technology

Bảo mật và quyền riêng tư

Mô hình hóa nguy cơ theo quy trình trước khi dùng checklist bảo mật

Checklist chung không giải thích được điểm hỏng trong một luồng phê duyệt hay bàn giao dữ liệu cụ thể. Bắt đầu từ một quy trình, xác định ranh giới tin cậy và chuyển nguy cơ hợp lý thành kiểm soát có chủ sở hữu.

UDT Insights12/06/2024
Một đồng nghiệp lập ranh giới nguy cơ trên quy trình trước khi xem danh sách kiểm tra. Người điều phối giơ bàn tay mở.

Rà soát bảo mật hữu ích hơn khi mọi người cùng nhìn vào một quy trình nghiệp vụ. Bắt đầu với luồng quan trọng như tiếp nhận nhà cung cấp hoặc duyệt thanh toán. Mô tả thành công nghĩa là gì, ai có thể tác động từng bước và dữ liệu đi qua đâu giữa người với hệ thống. Sau đó chọn kiểm soát cho đúng mối lo thực tế.

Vẽ điều nhóm cần bảo vệ

OWASP mô tả mô hình hóa nguy cơ theo bốn câu hỏi: đang làm với hệ thống nào, điều gì có thể sai, cần làm gì và kết quả đã phù hợp chưa.[7] Dùng các câu hỏi này để giữ buổi rà soát gắn với quyết định, không biến thành danh sách tên sản phẩm.

Sơ đồ luồng dữ liệu thể hiện thành phần, chuyển động dữ liệu và tương tác bên ngoài. OWASP xem đây là kỹ thuật mô hình hóa phổ biến.[7] Bản đầu có thể đơn giản. Cần có người dùng, kho dữ liệu, dịch vụ ngoài và ranh giới tin cậy, nơi một bên quyết định có tin đầu vào hay thẩm quyền từ bên khác không.

Trao đổi lỗi bằng ngôn ngữ nghiệp vụ

Mời nhân viên vận hành mô tả kết quả sai trông như thế nào. Người không đúng quyền có thể duyệt thay đổi nhà cung cấp không? Tệp đính kèm có thể tới người duyệt không liên quan không? Thử lại có thể tạo thao tác trùng không? Đây là câu hỏi cần khảo sát, không phải khẳng định hệ thống đang có các lỗi đó.

Nên xếp ưu tiên theo khả năng tiếp cận hợp lý, tác động nghiệp vụ và kiểm soát hiện hữu. Ghi giả định tách khỏi hành vi đã xác minh. Mô hình ngắn nêu rõ điều chưa biết hữu ích hơn sơ đồ chi tiết ngầm cho rằng mọi dịch vụ ngoài luôn hoạt động đúng.

Ví dụ giả định: đổi ngân hàng nhà cung cấp

Trong luồng mua sắm giả định, nhà cung cấp gửi thông tin thanh toán mới. Người duyệt chấp thuận rồi tích hợp chuyển sang tài chính. Buổi làm việc xác định ranh giới tin cậy giữa yêu cầu đã gửi và thẩm quyền của người duyệt.

Phương án đề xuất tách gửi với duyệt, xác minh thay đổi đã duyệt tại bước bàn giao và ghi sự kiện kiểm toán không chứa dữ liệu không cần thiết. Nhóm tiếp tục hỏi các kiểm soát hoạt động thế nào khi đổi người xử lý hoặc thử lại tích hợp. Mô hình giả định không chứng minh triển khai sau này thực thi được quy tắc đề xuất.

Chuyển mô hình thành việc nghiệm thu

Quy trình OWASP có cả biện pháp xử lý và bước rà soát, xác nhận.[7] Với từng mối lo ưu tiên, quyết định giảm, tránh, chuyển giao hay chấp nhận rủi ro rõ ràng. Giữ lựa chọn chưa giải quyết ở trạng thái dễ nhìn thấy.

  • Xác định tài sản và kết quả không chấp nhận được cho từng mối lo ưu tiên.
  • Đánh dấu đầu vào ngoài và nơi đổi thẩm quyền trên quy trình.
  • Giao chủ sở hữu cho từng kiểm soát và giả định chưa giải quyết.
  • Viết cách kiểm thử hoặc rà soát cho từng phương án đã chọn.
  • Xem lại mô hình sau khi thêm tích hợp hoặc đường phê duyệt.

Giữ phạm vi đủ nhỏ để hoàn tất

Một buổi làm việc không thể chứng minh không còn nguy cơ. Phạm vi quá lớn dễ tạo tài liệu không ai duy trì. Bắt đầu từ một đường nghiệp vụ có giá trị và ghi rõ phần nằm ngoài. Dùng checklist sau đó để tìm kiểm soát còn thiếu, thay vì xem hoàn thành checklist là bằng chứng quy trình đã được rà soát có ý nghĩa.

Tài liệu tham khảo

Trao đổi về dự án của bạn

Cùng UDT xác định nhu cầu và bước triển khai tiếp theo.

Liên hệ UDT
Zalo