Một mô hình mối đe dọa hữu ích giải thích những gì bạn bảo vệ, ai hoặc điều gì có thể ảnh hưởng đến nó, niềm tin thay đổi ở đâu và cách bạn sẽ giảm thiểu và kiểm tra những rủi ro quan trọng nhất. Hãy bắt đầu với dự án thực tế thay vì một danh sách công cụ chung chung.
Xác định phạm vi đủ nhỏ để có thể lý giải
Bắt đầu với một dịch vụ đang hoạt động: cổng thông tin khách hàng, trang xuất bản hoặc ứng dụng nội bộ. Ghi lại các thành phần bạn vận hành và các hệ thống bên ngoài bạn phụ thuộc. Một mô hình mối đe dọa nên làm cho các giả định trở nên rõ ràng, không gợi ý rằng mọi cuộc tấn công có thể đã được giải quyết. Giữ phiên bản đầu tiên đủ nhỏ để những người triển khai ứng dụng có thể giải thích nó mà không cần một chuyên gia tư vấn riêng diễn giải sơ đồ.
Liệt kê các kết quả và tài sản có giá trị. Chúng có thể bao gồm dữ liệu khách hàng, quyền truy cập quản trị, trạng thái thanh toán, nội dung đã xuất bản và khả năng khôi phục dịch vụ. Tính khả dụng có thể là một tài sản ngay cả khi thông tin là công khai. Xác định những thất bại nào sẽ gây bất tiện và những thất bại nào sẽ gây tổn hại cho con người hoặc tổ chức. Sự phân biệt đó giúp bạn ưu tiên các kiểm soát thay vì đối xử với mọi cảnh báo như nhau.
Vẽ ra những nơi niềm tin thay đổi
Hướng dẫn mô hình mối đe dọa của OWASP sử dụng luồng dữ liệu và ranh giới tin cậy để làm cho thiết kế dễ hiểu. Đối với một ứng dụng lưu trữ nhỏ, hãy vẽ trình duyệt, tiến trình web, cơ sở dữ liệu, quản trị viên, đích sao lưu và các tích hợp bên ngoài. Đánh dấu thông tin di chuyển giữa chúng. Một yêu cầu đi từ máy khách không đáng tin cậy vào một hoạt động máy chủ có đặc quyền cần được xác thực và ủy quyền rõ ràng.
Đừng cho rằng việc nằm trong cùng một máy làm cho mọi thành phần đều đáng tin cậy như nhau. Một quy trình tải lên công khai không nên có cùng quyền như quản trị cơ sở dữ liệu. Một tác vụ sao lưu có thể cần quyền đọc mà không có khả năng sửa đổi các bản ghi ứng dụng đang hoạt động. Việc tách các vai trò đó giúp dễ dàng hạn chế ảnh hưởng của một thành phần bị xâm phạm và dễ dàng xem xét các quyền cần thiết hơn.
Chọn các kịch bản thất bại cụ thể
Sử dụng một số sự kiện hợp lý để thách thức thiết kế. Kẻ tấn công đánh cắp mật khẩu quản trị viên; người dùng yêu cầu bản ghi của người dùng khác; một tệp tải lên làm đầy đĩa; một lần triển khai làm lộ tệp cấu hình; một bản sao khôi phục không thể khôi phục được. Mô tả điều kiện ban đầu, thành phần bị ảnh hưởng và hậu quả. Một kịch bản cụ thể dễ kiểm tra hơn một chỉ dẫn chung chung là cải thiện bảo mật.
Bao gồm cả sai sót và lạm dụng quy trình hợp pháp cũng như xâm nhập từ bên ngoài. Một lần thử lại có thể tạo ra hai hoạt động có giá trị, hoặc hai yêu cầu có thể chạy đua để thay đổi cùng một đối tượng. Hướng dẫn về logic nghiệp vụ của OWASP nhấn mạnh những giả định quy trình này. Kiểm tra ai được phép chuyển một quy trình sang trạng thái tiếp theo và liệu việc lặp lại hoặc sắp xếp lại một yêu cầu có thay đổi kết quả một cách bất ngờ không.
| Tình huống | Kiểm soát cần điều tra | Bằng chứng cần thu thập |
|---|---|---|
| Thông tin đăng nhập quản trị bị đánh cắp | Quyền truy cập hạn chế và yếu tố thứ hai khi được hỗ trợ | Đăng nhập trái phép không thể hoàn tất |
| Đối tượng của người dùng khác được yêu cầu | Ủy quyền đối tượng phía máy chủ | Một thử nghiệm biệt lập trả về kết quả bị từ chối |
| Đĩa bị cạn kiệt do tải lên | Kiểm soát kích thước, hạn ngạch và lưu giữ | Một giới hạn được thực thi trước khi dịch vụ gặp sự cố |
| Yêu cầu quy trình trùng lặp | Tính bất biến và ranh giới giao dịch | Một yêu cầu lặp lại tạo ra một kết quả |
Ưu tiên theo tác động và con đường khả thi
Đối với mỗi kịch bản, hãy ghi lại tác động tiềm tàng và các điều kiện cần thiết để nó xảy ra. Tránh giả vờ rằng một điểm số ước đoán là một xác suất chính xác. Bạn vẫn có thể phân biệt một mật khẩu yếu bị lộ ra internet với một sự kiện cục bộ có điều kiện cao. Gán một chủ sở hữu và một bước tiếp theo thiết thực cho các rủi ro quan trọng để mô hình tạo ra công việc mà ai đó thực sự có thể hoàn thành.
Xem xét vòng đời thông tin cũng như việc xâm phạm ứng dụng. Một hoạt động xuất chẩn đoán có thể tiết lộ dữ liệu không cần thiết trong quá trình hoạt động bình thường. Một trường tài khoản được lưu giữ có thể tạo ra rủi ro phơi bày rất lâu sau khi mục đích của nó kết thúc. Do đó, đánh giá quyền riêng tư có thể loại bỏ thông tin hoặc rút ngắn thời gian lưu giữ, trong khi đánh giá bảo mật hạn chế quyền truy cập vào những gì còn lại. Cả hai thay đổi đều thuộc mô hình khi chúng bảo vệ dự án.
Kiểm tra các kiểm soát trong môi trường được ủy quyền
Tạo một môi trường thử nghiệm với quyền đại diện và bản ghi giả. Kiểm tra quyền truy cập bị từ chối, giới hạn yêu cầu, thử lại quy trình và khôi phục. Không sử dụng dữ liệu khách hàng thực khi dữ liệu tổng hợp có thể chứng minh hành vi. Mục tiêu là xác minh kiểm soát, không phải tạo ra lưu lượng tấn công ấn tượng. Hãy ở trong các hệ thống bạn sở hữu hoặc được ủy quyền đánh giá rõ ràng.
Ghi lại những gì đã đạt, những gì đã thất bại và những gì còn chưa biết. Kết quả quét có thể đóng góp bằng chứng nhưng không thay thế việc kiểm tra các quy tắc nghiệp vụ của ứng dụng. Tương tự, một tùy chọn bảo vệ mạng không xác minh ủy quyền đối tượng hoặc xử lý tệp bí mật. Đính kèm các kết quả hữu ích vào kịch bản để những người bảo trì trong tương lai hiểu tại sao một kiểm soát cụ thể tồn tại.
Giữ mô hình gắn kết với thay đổi
Xem xét các phần liên quan khi bạn thêm một tích hợp, công khai một điểm cuối mới, thay đổi đặc quyền hoặc di chuyển dữ liệu đến một đích khác. Bạn không cần vẽ lại toàn bộ kiến trúc cho một chỉnh sửa văn bản nhỏ. Yếu tố kích hoạt là một giả định đã thay đổi về quyền truy cập, thông tin hoặc hành vi hệ thống. Giữ mô hình bên cạnh tài liệu triển khai và khôi phục thay vì để nó như một kết quả hội thảo một lần.
SwissOctet cung cấp một danh mục các lựa chọn cơ sở hạ tầng, không phải một mô hình mối đe dọa ứng dụng hoàn chỉnh. Chọn cấu hình và tùy chọn hỗ trợ các kiểm soát của bạn, sau đó xác minh triển khai bạn xây dựng. Một mô hình nhỏ, được duy trì với các hành động đã được kiểm tra hữu ích hơn một bộ sưu tập lớn các sản phẩm bảo mật mà không có giải thích rõ ràng về các rủi ro chúng giải quyết.
Danh sách kiểm tra thực tế của bạn.
- Liệt kê tài sản và hậu quả của thất bại.
- Vẽ luồng dữ liệu và ranh giới tin cậy.
- Chọn các kịch bản xâm nhập, sai sót và quy trình cụ thể.
- Gán kiểm soát và chủ sở hữu cho các rủi ro quan trọng.
- Kiểm tra bằng dữ liệu tổng hợp trong môi trường được ủy quyền.
- Xem xét mô hình khi một giả định liên quan thay đổi.
Những chi tiết quan trọng.
Tôi có cần một khuôn khổ chính thức để bắt đầu không?+
Không. Một sơ đồ nhỏ và một bộ kịch bản được ghi lại có thể hữu ích. Một khuôn khổ giúp đảm bảo bạn xem xét rủi ro một cách nhất quán.
Trình quét lỗ hổng có thay thế mô hình mối đe dọa không?+
Không. Trình quét có thể tìm thấy điểm yếu kỹ thuật, trong khi mô hình mối đe dọa cũng xem xét các giả định thiết kế, quyền và quy trình nghiệp vụ.
Tôi nên cập nhật mô hình bao lâu một lần?+
Cập nhật các phần bị ảnh hưởng khi luồng dữ liệu, tích hợp, đặc quyền hoặc chức năng được công khai thay đổi, và xem xét các rủi ro chưa được giải quyết thường xuyên.
Đến nguồn.
Các tài liệu tham khảo này hỗ trợ các khái niệm kỹ thuật trong hướng dẫn này. Hãy theo dõi tài liệu hiện hành trước khi thay đổi hệ thống sản xuất.
- OWASP: Bảng ghi nhớ về mô hình mối đe dọa cheatsheetseries.owasp.org
- OWASP: Mô hình mối đe dọa trong thực tế devguide.owasp.org
- OWASP: Bảo mật logic nghiệp vụ cheatsheetseries.owasp.org
Hướng dẫn biên tập bởi SwissOctet. Các ví dụ chỉ mang tính minh họa. Thông số dịch vụ, tùy chọn có sẵn và điều kiện hợp đồng phải được xác minh riêng.