Khắc phục theo đề xuất: tự hành mà bạn phê duyệt được

Vì sao ngăn chặn tự động phản tác dụng

Phản ứng tự động thường được nối thẳng vào phát hiện: khi một rule loại nào đó kích hoạt với mức nghiêm trọng cao thì cô lập host, chặn địa chỉ hoặc khoá tài khoản. Trên giấy, cách này lấp khoảng trống giữa phát hiện và hành động. Thực tế nó thừa hưởng mọi điểm yếu của chính phát hiện đã kích hoạt nó.

Rất nhiều thứ trông đáng ngờ trong telemetry endpoint và mạng chỉ là vận hành bình thường. Một database engine xoá file backup cũ qua command shell trông như hành vi phá huỷ. Một bản cập nhật phần mềm ghi hàng loạt file trong một giây trông như dropper. Quản trị viên dùng công cụ quản trị từ xa trông như lateral movement. Khi các đội rà lại những hành động ngăn chặn mà hệ thống tự động đã đề xuất, họ thường thấy phần lớn sẽ rơi vào công việc hợp lệ.

Cái giá ở đây không cân xứng. Chậm vài phút vì một người xem đề xuất hiếm khi là điều quyết định một sự cố. Cô lập database production, khoá tài khoản cả phòng tài chính lúc chốt quý hay chặn gateway của đối tác có thể gây gián đoạn lớn hơn chính mối đe doạ, và làm xói mòn niềm tin vào tự động hoá trong nhiều năm.

Điều gì sai ở bên dưới

Nhìn vào các phản ứng tự động thất bại, cùng một số mẫu cứ lặp lại. Hành động bị kích hoạt bởi một alert đơn lẻ thay vì một câu chuyện đã xác nhận. Chỉ riêng mức nghiêm trọng được coi là lý do để hành động. Tên rule trùng tên công cụ tấn công đã biết được tin ngay cả khi ngữ cảnh cho thấy đó là việc dùng được phép. Hành vi lặp lại thường ngày, diễn ra mỗi đêm suốt nhiều tháng, không được nhận ra là thường ngày. Và đôi khi mục tiêu của hành động còn không được xác định chính xác, nên hành động nhắm vào một nhóm chung chung thay vì một host hay tài khoản cụ thể.

Không điều nào trong đó là lỗi của công cụ phản ứng. Chúng là lỗi phán đoán ở phía trước công cụ. Vì vậy cách sửa không chỉ là playbook tốt hơn, mà là một hợp đồng khác giữa hệ thống ra quyết định và hệ thống hành động.

Tách bên quyết định khỏi bên hành động

Một nguyên tắc thiết kế hữu ích là thành phần đưa ra kết luận không bao giờ là thành phần thay đổi hệ thống. Phân tích, model và logic tương quan chỉ tạo đề xuất. Một lớp phản ứng riêng, hẹp, là nơi duy nhất được thực thi, và chỉ thực thi hành động đã duyệt, qua các hợp đồng chuẩn: đầu vào, kiểm tra trước, chạy thử, thực thi, kiểm tra sau, hoàn tác và audit.

Sự tách bạch này có lợi ích thực tế. Credential có quyền ghi nằm ở một chỗ nhỏ, dễ audit. Mọi hành động, bất kể ai hay cái gì đề xuất, đều đi cùng một đường. Và tích hợp với firewall, EDR, hệ thống định danh và email có thể xây một lần, kiểm thử bằng mock, rồi bật từng loại hành động một.

Nới quyền tự hành một cách an toàn

Đề xuất trước không có nghĩa là thủ công mãi mãi. Nó nghĩa là quyền tự hành phải được giành lấy, từng loại hành động một:

• Bắt đầu ở chế độ quan sát: ghi lại những gì lẽ ra sẽ được đề xuất và so với việc đội đã thực sự làm.
• Bật trước các hành động rủi ro thấp nhất, dễ hoàn tác nhất, như chặn có thời hạn những địa chỉ rõ ràng là bên ngoài.
• Mỗi loại hành động mới bật đều bắt đầu bằng một đợt thử nhỏ, có trần, trước khi mở rộng.
• Giữ danh sách hệ thống và tài khoản được bảo vệ, không bao giờ bị hành động tự động.
• Mọi hành động đã bật phải dễ tắt, mọi hành động đã chạy phải dễ hoàn tác.
• Báo cáo rõ hành động đã được áp, bị lỗi hay bị từ chối.

ApexAI tiếp cận thế nào

ApexAI Drawbridge là năng lực khắc phục theo đề xuất của ApexAI. Hiện nay nó chuẩn bị đề xuất phản ứng có bằng chứng, điều kiện tiên quyết, tác động dự kiến và cách hoàn tác ở chế độ quan sát, để đội của bạn đánh giá hệ thống lẽ ra sẽ làm gì. Đề xuất được dựng từ câu chuyện đã xác nhận chứ không từ alert đơn lẻ, và các vận hành thường ngày như backup hay scanner được phép đã biết đều được nhận ra. Phần thực thi hành động đã duyệt qua EDR, firewall và hệ thống định danh hiện có đang được phát triển, mặc định tắt và chỉ bật theo từng loại hành động khi bạn quyết định, mọi bước đều có audit.

Câu hỏi thường gặp