Bước khôi phục mà không ai đưa vào runbook

Mọi kế hoạch khôi phục mà chúng tôi đã đọc đều được đo bằng tốc độ dữ liệu quay trở lại. Mục tiêu thời gian khôi phục, mục tiêu điểm khôi phục, số giờ ngừng hoạt động, doanh thu mất mỗi giờ. Đó là những con số trên slide của ban lãnh đạo, và đó là những con số đúng cho phần lớn những gì khôi phục phải làm.

Chúng cũng là lý do khiến một bước bị thiếu trong gần như mọi runbook trong khu vực.

Hai mốc ngày

Hãy bắt đầu với dòng thời gian, vì dòng thời gian chính là toàn bộ cơ chế.

Bạn bị xâm nhập vào một ngày. Bạn phát hiện ra vào một ngày sau đó, vì đó chính là dwell time: khoảng thời gian giữa lúc kẻ xâm nhập xuất hiện và lúc ai đó nhận ra. Hãy đo bằng ngày hoặc tuần thay vì phút. Con số chính xác thay đổi theo từng sự cố và quan trọng ít hơn nhiều so với hình dạng của nó.

Bây giờ hãy hỏi bản sao lưu nào mà đội khôi phục sẽ chọn. Họ sẽ chọn điểm khôi phục gần nhất được cho là sạch. Trên thực tế, điều đó có nghĩa là điểm khôi phục gần nhất được tạo trước khi sự cố được phát hiện, vì phát hiện là sự kiện duy nhất có dấu thời gian mà mọi người đều đồng ý.

Đó là hai ngày khác nhau. Mọi thứ được tạo, nhận hoặc sửa đổi trong khoảng trống giữa hai mốc đó đều nằm trong bản sao lưu, và tài liệu độc hại đã khởi phát sự cố gần như chắc chắn được tạo trước khi bất kỳ ai nhận thấy điều gì. Bản sao lưu là một bản sao trung thực. Nó cũng trung thực với payload.

Chỉ số xóa bỏ bước này

Đây là phần ít được chú ý hơn, và hoàn toàn không phải là vấn đề công nghệ.

Khôi phục được chấm điểm theo thời gian đã trôi qua. Mỗi giờ hệ thống bị gián đoạn đều được tính, thường là bởi những người đang theo dõi một con số doanh thu. Việc kiểm tra hoặc xử lý lại mọi tài liệu đã khôi phục làm tăng thêm hàng giờ vào đúng chỉ số mà người phụ trách khôi phục đang bị đánh giá, và nó cộng thêm vào thời điểm tệ nhất có thể, khi áp lực tuyên bố sự cố đã kết thúc ở mức cao nhất.

Không ai viết "chúng tôi đã bỏ qua vệ sinh tệp" vào runbook. Không phải như vậy mà nó xảy ra. Bước đó chưa bao giờ có trong runbook, không có chỉ số nào từng yêu cầu nó, và việc khôi phục đã hoàn tất đúng lịch. Động lực đã âm thầm làm phần việc đó.

Vì vậy mô hình lặp lại: máy chủ được dựng lại từ image sạch, thông tin xác thực được xoay vòng, endpoint được cài lại image, mạng được phân đoạn đúng cách lần này. Sau đó các file share, hộp thư và kho tài liệu quay trở lại đúng như trước. Không bị đụng chạm. Lớp duy nhất không ai tái tạo là lớp đã mang thứ đó vào.

Vì sao quét lại là công cụ sai

Câu trả lời hiển nhiên là quét bản sao lưu trước khi khôi phục nó, và cần nói chính xác vì sao cách đó yếu hơn vẻ ngoài của nó.

Ngăn xếp phát hiện của bạn đã thất bại trong việc nhận diện tệp này một lần rồi, ngay vào ngày nó được đưa vào. Tại thời điểm khôi phục, bạn lại đang chĩa cùng một loại engine vào cùng một tệp, tìm kiếm cùng một danh mục các thứ xấu đã biết. Các chữ ký có thể đã bắt kịp nếu chiến dịch ồn ào và được báo cáo rộng rãi. Nếu không, hoặc nếu tài liệu được tạo riêng cho bạn, thì chúng chưa bắt kịp.

Một sandbox cũng có một giới hạn liên quan: nó chỉ tốt đúng như cách nó đã được thiết kế. Một payload chờ tương tác của người dùng, một locale cụ thể, hoặc một ngày chưa tới sẽ hoạt động hoàn hảo khi bị kích hoạt, và hoạt động hoàn hảo đúng trong khoảng thời gian nó cần.

Cũng có một kiểu thất bại âm thầm hơn. Quét lại tạo ra một phán quyết, và phán quyết không phải là bằng chứng. "Không tìm thấy gì" là một tuyên bố về phạm vi phát hiện của bạn, chứ không phải về tệp.

Bước restore-hygiene trông như thế nào

Phiên bản khả thi coi một tệp đi ra từ bản sao lưu giống như cách bạn sẽ coi một tệp đến từ người lạ, vì trong một lần khôi phục thì đó chính xác là nguồn gốc của nó.

Cụ thể, một bước được chèn vào giữa restore và đưa trở lại dịch vụ:

1. Xây dựng lại thay vì kiểm tra. Phân rã từng tài liệu thành các thành phần của nó, xác thực từng thành phần theo đặc tả đã công bố cho định dạng đó, rồi tạo một tệp hoàn toàn mới từ biểu diễn trung gian đó: công thức, không phải các byte gốc. Sự khác biệt này quan trọng hơn nghe có vẻ. Sao chép qua những phần mà engine đánh giá là tốt vẫn chỉ là một phán đoán về thứ trông an toàn, tức là phát hiện khoác áo khác, và tệp gốc vẫn là thứ được đưa vào. Một lần xây dựng lại không bao giờ chuyển tệp gốc qua cả, nên không có gì sống sót chỉ vì không bị nhận ra. Đây là điều mà Content Disarm and Reconstruction xác định làm; Glasswall báo cáo 100% tệp độc hại được vô hiệu hóa trên 8,27 triệu mẫu đã thử nghiệm, và nghiên cứu tình huống của trung tâm nghiên cứu chính phủ của hãng mô tả một quy trình khôi phục được sắp xếp theo cách này.
2. Giữ hồ sơ theo từng tệp. Với mỗi tài liệu, những gì đã bị loại bỏ, theo policy nào, vào thời điểm nào. Đây là artefact mà báo cáo sự cố của bạn cần và là artefact mà người đánh giá sẽ yêu cầu, và nó không thể được tái tạo lại sau này.
3. Ưu tiên theo blast radius, không phải theo thứ tự bảng chữ cái. Các ổ chia sẻ, hộp thư và bất cứ thứ gì một pipeline tự động tiêu thụ phải đi trước. Một share tài chính nuôi một quy trình hàng tháng dựa trên macro là vấn đề cấp cao hơn một kho lưu trữ mà không ai mở.
4. Giả định estate vẫn bị cô lập. Giữa quá trình khôi phục thường không có mạng để chuyển tệp qua lại, đó là lý do xử lý ngay trên desktop ở đây quan trọng theo một cách mà ở trạng thái ổn định thì không. Glasswall Meteor chạy engine cục bộ, trực tuyến, ngoại tuyến hoặc air-gapped. 8.27

Không có gì trong số này là hào nhoáng, và cũng không có gì là kỹ thuật mới. Nó chỉ là một bước và một quyết định dành thời gian cho nó.

Phần bằng chứng

Lý do thứ hai để thêm bước này là ở khu vực này, nghĩa vụ đã được ghi thành văn bản, và đó là một nghĩa vụ về bằng chứng cũng như về kiểm soát.

Cybersecurity Code of Practice for Critical Information Infrastructure của Singapore nêu rõ điều này trong điều 6.1.4: nhật ký được lưu giữ tối thiểu mười hai tháng sau sự kiện mà chúng ghi lại, được bảo vệ khỏi sửa đổi và xóa trái phép, và "được quản lý bởi policy lưu giữ nhật ký để tạo điều kiện cho việc điều tra các sự cố an ninh mạng". Việc lưu giữ mà mục đích được nêu ra là điều tra, chứ không phải lưu trữ.

MAS Technology Risk Management Guidelines đặt ra kỳ vọng tương tự cho các tổ chức tài chính: các tệp không đáng tin cậy đến qua thư, cổng tải lên hoặc trao đổi với bên thứ ba được xử lý tại ranh giới thay vì được chấp nhận chỉ dựa trên phán quyết phát hiện.

Đọc hai điều đó cùng nhau sau một sự cố, câu hỏi mà người đánh giá đưa ra không phải là "bạn đã chặn cái gì". Mà là "hãy cho tôi xem điều gì đã xảy ra với tài liệu này". Một kiểm soát chỉ ghi lại ngoại lệ không thể trả lời điều đó, vì những tệp mà nó cho đi qua không tạo ra hồ sơ riêng cho từng tệp nào cả. Một bước xây dựng lại tạo ra một hồ sơ cho mọi tệp mà nó chạm vào, kể cả những tệp hóa ra hoàn toàn ổn, và đó là điều khiến hồ sơ có thể được dùng làm bằng chứng thay vì chỉ là lịch sử cảnh báo.

Câu hỏi đáng để hỏi

Các kế hoạch khôi phục được diễn tập. Các bước restore-hygiene được bổ sung sau sự cố thứ hai, và đó là một cái giá đắt để học điều đó.

Nếu chữ ký của bạn nằm trên phần phê duyệt khôi phục, câu hỏi dành cho nhóm của bạn không phải là dữ liệu quay lại nhanh đến mức nào. Mà là chúng ta đã đưa cái gì trở lại, và làm sao chúng ta biết.

Để xem bức tranh nghĩa vụ đầy đủ ở Singapore, bao gồm Cybersecurity (Amendment) Act 2024 và bản cập nhật CCoP được công bố vào tháng 7 năm 2026, hãy xem trang tuân thủ Singapore.