Điều tra sự cố là làm gì?

Calif được gầy dựng từ một vụ tấn công mạng. An và tôi được yêu cầu điều tra một sự cố bảo mật. Chúng tôi đến Hà Nội làm việc không ngừng nghỉ suốt 3 tháng.

Nhờ may mắn, chúng tôi đã tìm ra nguyên nhân, giúp phát hiện một đường dây tội phạm. Trải nghiệm thú vị và ý nghĩa này khiến chúng tôi quyết định rời bỏ công việc để làm Calif.

Tuy nhiên, khi dự án ở Hà Nội mới bắt đầu, tôi cảm thấy rất lo lắng. Trước khi gia nhập Google, tôi làm việc tại một ngân hàng và có chút kinh nghiệm về xử lý sự cố. Nhưng sau 10 năm tập trung vào an toàn sản phẩm và mật mã hóa, tôi gần như không còn am hiểu gì về các công cụ và kỹ thuật điều tra hiện đại.

May mắn làm sao, tôi học được từ sự cố đó và những sự cố khác rằng các công cụ và kỹ thuật chỉ chiếm 20%. 80% thành công nằm ở khả năng suy luận logic và giữ bình tĩnh. Phần kỹ thuật quyết định chiến thuật điều tra từng manh mối, trong khi tư duy logic sẽ định hướng chiến lược, quyết định thành bại toàn bộ dự án.

Điều tra một sự cố giống như đua marathon mà không có lộ trình cho trước. Người chơi phải tự tìm đường. Nếu tốn quá nhiều thời gian cho những ngã rẽ vào đường cụt, đội điều tra sẽ kiệt sức trước khi đến đích.

Trong những sự cố lớn, từng chi tiết nhỏ đều quan trọng, nhưng nếu không tỉnh táo thì nhìn đâu cũng thấy nghi ngờ, chết chìm trong một biển bằng chứng.

Ví dụ nếu chúng ta biết:

1. Sự kiện A luôn dẫn đến sự kiện B

2. Không tìm thấy sự kiện B

Có thể suy ra ngay A không xảy ra. Nhưng tôi đã gặp tình huống đội điều tra vẫn cố tìm A. Những sai lầm như vầy cộng dồn rất nhanh, khiến ngay cả khi bạn nhận ra mình đã sai thì cũng không biết quay lại sửa từ đâu.

Nói tóm lại, phải suy nghĩ tìm hướng điều tra trước (why), rồi mới quyết định điều tra thế nào (how). Trong một mô tả công việc rất hay, Uber cũng nhấn mạnh vào khả năng xác định hướng đi cho vị trí chỉ huy điều tra:

Part Fire Captain, part Air Traffic Controller, and part NTSB investigator, you will be a master at controlling chaos, seeing through the fog and charting a path forward no matter how ambiguous the situation is.

Một sai lầm tôi cũng hay gặp là confirmation bias (thiên kiến khẳng định). Quá trình điều tra có những bước như sau:

1. Lập ra danh sách câu hỏi chưa trả lời được, ví dụ như làm thế nào hacker xâm nhập hệ thống, đánh cắp tiền, v.v.

2. Với mỗi câu hỏi, liệt kê những giả thuyết có thể giúp trả lời, ví dụ như hacker có thể đã xâm nhập qua đường máy chủ, qua đường công cụ quản lý nội bộ, hay qua máy tính của người dùng cuối, v.v.

3. Với mỗi giả thuyết, tìm bằng chứng để kiểm chứng, ví dụ như dấu vết hacker khai thác lỗ hổng trên máy chủ, dấu vết đăng nhập vào công cụ quản lý, hay dấu vết mã độc trên máy tính của người dùng cuối, v.v.

4. Dựa vào bằng chứng tìm được, đưa ra kết luận cho từng câu hỏi.

5. Lập lại cho đến khi trả lời được tất cả câu hỏi và hiểu rõ chuyện gì đã diễn ra.

Tôi phát hiện ở bước #3 mình rất dễ mắc phải confirmation bias, tức chỉ đi tìm bằng chứng ủng hộ giả thuyết mình tin là đúng. Đây là xu hướng chung của con người. Chúng ta nhấn "like" những gì chúng ta đồng ý với và bỏ qua mọi thứ khác.

Người điều tra tỉnh táo phải hiểu bằng chứng quyết định giả thuyết, chứ không phải ngược lại. Nếu chỉ chăm chăm đưa ra giả thuyết rồi tìm bằng chứng ủng hộ, chúng ta có thể vô tình nhét một con voi xuyên qua lỗ kim.

Điều tra sự cố do đó là quá trình đi tìm sự thật bằng cách loại bỏ giả thuyết sai. Với mỗi giả thuyết, mục tiêu điều tra không phải là tìm bằng chứng ủng hộ, mà ngược lại: tìm bằng chứng phủ nhận.

Sau khi đã loại bỏ các giả thuyết sai, giả thuyết còn lại phải là câu trả lời, dẫu có khó tin đến cỡ nào, như tác giả Sherlock Holmes đã từng nói:

Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.

(Phần 1: Kể chuyện săn hacker giữa đại dịch)