Sau khi một sự cố an ninh mạng được kiểm soát, đội SOC thường có thể nhanh chóng đưa ra một báo cáo ban đầu.
Họ biết tài khoản nào bị compromise, endpoint nào bị ảnh hưởng, thời điểm attacker đăng nhập, cùng các kỹ thuật đã được sử dụng.
Trong nhiều trường hợp, họ thậm chí có thể dựng lại gần như toàn bộ chuỗi tấn công (attack timeline).
Nhưng khi ban lãnh đạo đặt một câu hỏi khác, cuộc điều tra thường chậm lại đáng kể.
“Vậy dữ liệu nào đã bị truy cập?”
Đây là câu hỏi tưởng chừng đơn giản nhưng lại là một trong những nội dung khó trả lời nhất trong quá trình điều tra sự cố.
Chúng ta có rất nhiều log, nhưng không phải log nào cũng trả lời được câu hỏi về dữ liệu
Trong nhiều năm qua, các chương trình Detection & Response đã đầu tư rất nhiều vào khả năng quan sát hạ tầng. Log có thể được tao ra từ endpoint, firewall, indentity, cloud workload… và Microsoft 365, AWS hay Google Cloud đều cung cấp hàng loạt audit log để phục vụ điều tra. Nhờ đó, doanh nghiệp có thể biết một người dùng đã đăng nhập từ đâu, vào thời điểm nào, sử dụng thiết bị gì và thực hiện những hành động nào trên hệ thống.
Đây là những thông tin rất quan trọng để hiểu cuộc tấn công đã diễn ra như thế nào, nhhưng chúng chưa chắc giúp trả lời điều gì đã xảy ra với dữ liệu.
Ví dụ, một tài khoản bị đánh cắp thông tin xác thực và đăng nhập thành công vào Microsoft 365.
Hệ thống có thể ghi nhận:
- Thời điểm đăng nhập.
- Địa chỉ IP.
- Thiết bị sử dụng.
- Phương thức xác thực.
- Các thao tác như mở SharePoint, OneDrive hoặc Exchange.
Tuy nhiên, từ những thông tin đó, doanh nghiệp vẫn còn nhiều điều chưa biết.
- Những tài liệu nào thực sự đã được mở?
- Trong số đó, tài liệu nào chứa dữ liệu nhạy cảm?
- Người dùng đó vốn đã có quyền truy cập hay quyền đã bị lạm dụng?
- Có bao nhiêu dữ liệu có giá trị kinh doanh bị ảnh hưởng?
Khoảng trống không nằm ở việc thiếu log, mà nằm ở việc thiếu ngữ cảnh của dữ liệu.
Một file không chỉ là một file
Đối với hệ thống CNTT, một file thường chỉ là một đối tượng được truy cập.
Nhưng đối với doanh nghiệp, giá trị của file lại phụ thuộc vào nội dung bên trong.
Một file PowerPoint giới thiệu sản phẩm và một file chứa kế hoạch mua bán – sáp nhập có thể tạo ra cùng một sự kiện “File Accessed” trong log.
Một bảng tính tổng hợp doanh thu nội bộ và một danh sách khách hàng chứa hàng chục nghìn thông tin cá nhân cũng có thể được ghi nhận theo cùng một cách.
Từ góc nhìn của telemetry truyền thống, chúng gần như không có sự khác biệt.
Từ góc nhìn kinh doanh, mức độ rủi ro lại hoàn toàn khác.
Đó là lý do vì sao hai sự cố có cùng số lượng endpoint bị ảnh hưởng hoặc cùng số lượng file được truy cập chưa chắc có cùng mức độ nghiêm trọng.
Điều quan trọng không chỉ là bao nhiêu dữ liệu, mà là dữ liệu gì.
Điều tra attacker khác với điều tra tác động
Trong nhiều cuộc điều tra, hai mục tiêu này thường bị nhầm lẫn với nhau.
Mục tiêu thứ nhất là hiểu attacker.
- Họ xâm nhập bằng cách nào?
- Họ đã leo thang đặc quyền chưa?
- Họ di chuyển ngang qua những hệ thống nào?
- Họ sử dụng kỹ thuật gì?
Đây là nhiệm vụ cốt lõi của Detection & Response.
Nhưng còn một mục tiêu khác.
Hiểu tác động đối với tài sản của doanh nghiệp.
- Dữ liệu nào đã bị truy cập?
- Dữ liệu đó có chứa thông tin nhạy cảm không?
- Có dữ liệu nào thuộc phạm vi tuân thủ như dữ liệu khách hàng, tài chính hoặc sở hữu trí tuệ?
- Quy mô ảnh hưởng đến hoạt động kinh doanh là bao nhiêu?
Hai nhóm câu hỏi này liên quan chặt chẽ với nhau nhưng không giống nhau.
Một cuộc điều tra có thể mô tả rất chi tiết hành vi của attacker mà vẫn chưa đủ để đánh giá rủi ro đối với doanh nghiệp.
Thiếu ngữ cảnh về dữ liệu dẫn đến những quyết định thiếu cơ sở
Khi không biết dữ liệu nào đã bị ảnh hưởng, nhiều quyết định quan trọng phải được đưa ra trong điều kiện thiếu thông tin.
Ban điều hành khó đánh giá tác động kinh doanh.
Bộ phận pháp chế khó xác định nghĩa vụ thông báo vi phạm dữ liệu.
Đội bảo mật không biết nên ưu tiên điều tra khu vực nào.
Ngay cả việc truyền thông với khách hàng hoặc đối tác cũng trở nên khó khăn khi doanh nghiệp không thể trả lời một câu hỏi rất cơ bản:
Chúng tôi có mất dữ liệu hay không?
Trong thực tế, nhiều tổ chức chỉ có thể trả lời bằng những cụm từ như:
“Hiện chưa phát hiện dấu hiệu.”
hoặc
“Cuộc điều tra vẫn đang tiếp tục.”
Điều này không phải vì đội điều tra thiếu năng lực.
Đơn giản là họ đang thiếu khả năng quan sát trực tiếp đối với dữ liệu.
Quan sát dữ liệu cần nhiều hơn các sự kiện truy cập
Để hiểu tác động thực sự của một sự cố, doanh nghiệp cần bổ sung thêm những thông tin mà các telemetry truyền thống thường không cung cấp.
Chẳng hạn:
- Dữ liệu đang nằm ở đâu?
- Dữ liệu nào được phân loại là nhạy cảm?
- Ai thực sự cần quyền truy cập?
- Quyền nào đang bị cấp quá mức?
- Một hành vi truy cập có phù hợp với vai trò của người dùng hay không?
Khi những thông tin này được đặt cạnh các tín hiệu từ EDR, XDR hoặc SIEM, bức tranh điều tra sẽ đầy đủ hơn nhiều.
Lúc đó, doanh nghiệp không chỉ biết attacker đã làm gì, mà còn biết điều đó ảnh hưởng đến tài sản nào.
Kết luận
Detection & Response đã giúp doanh nghiệp hiểu các cuộc tấn công tốt hơn rất nhiều so với trước đây.
Nhưng khả năng quan sát attacker không đồng nghĩa với khả năng quan sát dữ liệu.
Trong điều tra sự cố, câu hỏi “Ai đã xâm nhập?” và “Họ đã làm gì?” vẫn rất quan trọng.
Tuy nhiên, để đánh giá đầy đủ mức độ rủi ro, doanh nghiệp cần trả lời thêm một câu hỏi khác:
“Chính xác thì họ đã truy cập những dữ liệu nào?”
Đó là điểm khác biệt giữa việc điều tra một cuộc tấn công và đánh giá tác động của một sự cố. Và cũng là lý do vì sao ngữ cảnh về dữ liệu đang trở thành một thành phần không thể thiếu trong các chương trình Detection & Response hiện đại.
