Tôi Giải Thích Phát Hiện Của Mình Trong Một Buổi Thuyết Trình SOC Như Thế Nào?

Kỹ năng kỹ thuật giúp bạn phân tích. Khả năng giao tiếp giúp bạn được tin cậy, nhận tài trợ và được thuê. Những người phân tích có thể giải thích điều gì đã xảy ra, tại sao nó lại quan trọng, và phải làm gì tiếp theo luôn vượt trội so với những người có kiến thức công cụ sâu hơn nhưng không thể truyền đạt thông điệp hiệu quả.

Cấu trúc một buổi thuyết trình sự cố

Sử dụng hình kim tự tháp ngược: mở đầu với kết luận, sau đó hỗ trợ nó. Một người quản lý hoặc trưởng ca trực cần có câu trả lời cho "chúng ta có bị xâm phạm không và tôi có cần hành động không" trong mười giây đầu tiên khi vào buổi thuyết trình của bạn, không phải bị lẩn sau chi tiết packet capture ở phút thứ sáu.

Một cấu trúc khả dụng:

1. Điều gì đã xảy ra — một câu. "Một máy trạm trong phòng tài chính thực thi một macro độc hại và kết nối đến một địa chỉ IP bên ngoài."
2. Tác động cho đến nay — phạm vi, các hệ thống bị ảnh hưởng, dữ liệu đã hoặc chưa bị chạm vào.
3. Những gì chúng tôi đã làm — các bước cách ly, chặn, kiểm soát đã được thực hiện.
4. Những gì chúng tôi cần — quyết định, tài nguyên hoặc phê duyệt từ những người trong phòng.
5. Dòng thời gian — một danh sách theo thứ tự thời gian ngắn cho bất kỳ ai muốn chi tiết, giữ riêng biệt với tiêu đề chính.

Tránh kể lại quá trình điều tra của bạn ("đầu tiên tôi kiểm tra bảng điều khiển EDR, sau đó tôi chuyển sang nhật ký DNS") trừ khi ai đó cụ thể hỏi cách bạn tìm ra. Đó là phương pháp của bạn, không phải vấn đề của họ. Hãy dành nó cho báo cáo viết hoặc cuộc theo dõi với chuyên gia.

Viết bàn giao không mất đi bối cảnh

Bàn giao ca làm việc thất bại vì một lý do nhiều hơn bất kỳ lý do nào khác: người phân tích sắp hết ca giả định rằng người sắp bắt đầu ca nhớ bối cảnh chỉ tồn tại trong đầu của họ. Hãy viết bàn giao như thể người đọc không có bất kỳ ký ức nào về ca làm việc.

Một ghi chú bàn giao tốt bao gồm:

• ID vé/hộp thoại và trạng thái hiện tại (mở, giám sát, chờ phản hồi)
• Điều gì kích hoạt cuộc điều tra
• Điều gì đã được xác nhận so với vẫn là giả thuyết
• Hành động cụ thể tiếp theo và ai sở hữu nó
• Bất kỳ chướng ngại nào (chờ thay đổi tường lửa, chờ cuộc gọi lại từ người dùng)

Ví dụ về một dòng bàn giao yếu: "Điều tra cảnh báo trên HOST-2231, có vẻ đáng ngờ, sẽ kiểm tra ngày mai."

Ví dụ về một dòng mạnh: "HOST-2231 kích hoạt quy tắc Sigma để truy cập LSASS bằng nhị phân không ký (proc: update.exe, hash: 3f2c...). Xác nhận với EDR rằng không có xảy ra xả bộ nhớ. Người dùng sắp có lúc đến 9 giờ sáng — chưa có cuộc phỏng vấn. Bước tiếp theo: rút các tạo phẩm prefetch và sched task, nâng cấp lên IR nếu nhị phân khớp với biến thể Mimikatz đã biết."

Phiên bản thứ hai cho phép người phân tích tiếp theo hành động ngay lập tức mà không cần lặp lại công việc của bạn.

Câu hỏi kịch bản phỏng vấn: chúng thực sự đang kiểm tra cái gì

Khi người phỏng vấn nói "hãy hướng dẫn tôi cách bạn sẽ điều tra một cảnh báo lừa đảo", họ không chấm điểm liệu bạn có biết tên công cụ đúng hay không. Họ đang kiểm tra liệu bạn có một quy trình có thể lặp lại được hay không và liệu bạn có thể kể lại lý luận của mình to tiếng dưới áp lực nhẹ — đó chính xác là những gì một ca làm việc thực tế yêu cầu.

Cấu trúc câu trả lời của bạn theo cách bạn sẽ cấu trúc chính sự cố:

• Nêu ưu tiên phân loại của bạn trước tiên (điều này có được kiểm soát không, nó có đang lan rộng không, nó có phải là ứng cử viên dương tính giả không)
• Đặt tên các tạo phẩm cụ thể bạn sẽ rút (tiêu đề email, danh tiếng người gửi, xả URL sandbox, thay đổi quy tắc hộp thư)
• Nói điều gì sẽ thay đổi bước tiếp theo của bạn ("nếu xả sandbox cho thấy một trang thu thập thông tin xác thực, tôi sẽ ngay lập tức kiểm tra xem có xác thực thành công từ người dùng đó trong 24 giờ qua không")
• Kết thúc bằng tiêu chí nâng cấp — điều gì làm cho bạn gọi đây là một sự cố đã xác nhận so với đóng nó lại như vô hại

Những người phỏng vấn chú ý khi các ứng cử viên nói một cách tuyệt đối mà không có logic phân nhánh. Các cuộc điều tra thực tế là có điều kiện: "nếu X, thì Y; nếu không, thì Z." Thể hiện rằng phân nhánh này có giá trị hơn là liệt kê từng nguồn nhật ký mà bạn từng nghe nói..

Dịch cho các bên liên quan không phải kỹ thuật

Một CFO không cần nghe "chuyển động bên trong thông qua pass-the-hash nhắm tới trình điều khiển miền." Họ cần "một kẻ tấn công sử dụng thông tin xác thực bị đánh cắp để cố gắng tiếp cận một hệ thống kiểm soát truy cập cho toàn bộ công ty; chúng tôi đã chặn nó trước khi nó thành công." Giữ phiên bản kỹ thuật có sẵn trong một phụ lục hoặc tài liệu theo dõi cho những người hỏi, nhưng dẫn cuộc hội thoại bằng tác động kinh doanh bằng ngôn ngữ đơn giản: tiền, thời gian ngừng hoạt động, phơi bày dữ liệu, phơi bày quy định.

Một thói quen giúp ích trong cả ba bối cảnh — thuyết trình, bàn giao và phỏng vấn — là viết một tóm tắt một câu trước khi bạn viết bất cứ điều gì khác. Nếu bạn không thể nén tình huống thành một câu, bạn chưa hiểu nó đủ tốt để giải thích cho ai khác.

Để tìm hiểu thêm về cấu trúc bài viết sự cố và chuẩn bị phỏng vấn cụ thể cho các vai trò blue team, hãy xem các phân đoạn Korra Studio liên quan về viết báo cáo và thực hành phỏng vấn nhà phân tích SOC.