Langkah pemulihan yang tiada siapa masukkan dalam runbook

Setiap pelan pemulihan yang kami baca diukur berdasarkan seberapa cepat data kembali. Objektif masa pemulihan, objektif titik pemulihan, jam masa henti, hasil hilang per jam. Itulah nombor pada slaid lembaga, dan itulah nombor yang tepat untuk kebanyakan perkara yang perlu dilakukan oleh pemulihan.

Ia juga sebab satu langkah hilang daripada hampir setiap runbook di rantau ini.

Dua tarikh

Mula dengan garis masa, kerana garis masa ialah keseluruhan mekanisme.

Anda terjejas pada satu hari. Anda mengetahuinya pada hari yang kemudian, kerana itulah apa itu dwell time: selang antara penceroboh tiba dan seseorang menyedarinya. Ukurnya dalam hari atau minggu dan bukannya minit. Angka yang tepat berbeza mengikut insiden dan jauh kurang penting daripada bentuknya.

Sekarang tanya sandaran mana yang diambil oleh pasukan pemulihan. Mereka akan mengambil titik pemulihan yang paling terkini yang dipercayai bersih. Dalam amalan, ini bermaksud titik pemulihan paling terkini yang diambil sebelum insiden itu dikesan, kerana pengesanan ialah satu-satunya peristiwa yang mempunyai cap masa yang dipersetujui oleh semua orang.

Itu ialah dua tarikh yang berbeza. Segala-galanya yang dicipta, diterima atau diubah suai dalam jurang antara kedua-duanya berada di dalam sandaran, dan dokumen berniat jahat yang memulakan insiden itu hampir pasti dicipta sebelum sesiapa menyedari apa-apa. Sandaran ialah salinan yang setia. Ia juga setia terhadap muatan.

Metrik yang memadamkan langkah

Inilah bahagian yang kurang diberi perhatian, dan ia langsung bukan masalah teknologi.

Pemulihan dinilai berdasarkan masa berlalu. Setiap jam aset tidak beroperasi dikira, selalunya oleh orang yang memerhati angka hasil. Memeriksa atau memproses semula setiap dokumen yang dipulihkan menambah jam kepada tepat nombor yang ketua pemulihan sedang dinilai, dan ia menambahnya pada saat yang paling buruk, apabila tekanan untuk mengisytiharkan insiden telah tamat berada pada tahap tertinggi.

Tiada siapa menulis "kami melangkau kebersihan fail" ke dalam runbook. Bukan begitu ia berlaku. Langkah itu tidak pernah ada dalam runbook, tiada metrik pernah memintanya, dan pemulihan selesai mengikut jadual. Insentif itu melakukan kerja secara senyap.

Jadi coraknya berulang: pelayan dibina semula daripada imej bersih, kelayakan diputar, endpoint diimej semula, rangkaian dibahagikan dengan betul kali ini. Kemudian file share, peti mel dan repositori dokumen kembali tepat seperti asalnya. Tidak disentuh. Satu-satunya lapisan yang tiada siapa bina semula ialah lapisan yang membawa benda itu masuk.

Mengapa imbasan semula ialah instrumen yang salah

Jawapan yang jelas ialah mengimbas sandaran sebelum memulihkannya, dan penting untuk tepat tentang sebab itu lebih lemah daripada yang kedengaran.

Tumpukan pengesanan anda telah gagal mengenal pasti fail ini sekali lagi, pada hari ia tiba. Pada masa pemulihan, anda menghalakan kelas enjin yang sama ke fail yang sama, mencari katalog perkara buruk yang diketahui yang sama. Tandatangan mungkin telah mengejar jika kempen itu bising dan dilaporkan secara meluas. Jika tidak, atau jika dokumen itu dibina khusus untuk anda, ia belum.

Sebuah sandbox mempunyai had yang berkaitan: ia hanya sebaik reka bentuknya. Satu payload yang menunggu interaksi pengguna, locale tertentu, atau tarikh yang belum tiba lagi akan berkelakuan dengan sempurna semasa detonation, dan berkelakuan dengan sempurna untuk tempoh yang tepat selama mana ia perlu.

Ada juga kegagalan yang lebih senyap. Imbas semula menghasilkan keputusan, dan keputusan bukan bukti. "Tiada ditemui" ialah pernyataan tentang liputan pengesanan anda, bukan tentang fail itu.

Seperti apa langkah restore-hygiene

Versi yang praktikal menganggap fail yang keluar daripada sandaran seperti anda akan menganggap fail yang tiba daripada orang asing, kerana semasa pemulihan itulah asal usulnya.

Secara konkrit, satu langkah disisipkan antara restore dan kembali ke perkhidmatan:

1. Bina semula daripada memeriksa. Pecahkan setiap dokumen kepada bahan-bahannya, sahkan setiap satu terhadap spesifikasi yang diterbitkan untuk format itu, kemudian hasilkan fail baharu daripada perwakilan perantaraan itu: resipi, bukan bait asal. Perbezaan ini lebih penting daripada yang kedengaran. Menyalin bahagian yang dinilai baik oleh enjin masih merupakan penilaian tentang apa yang kelihatan selamat, yang merupakan pengesanan dengan pakaian berbeza, dan fail asal masih yang tiba. Binaan semula tidak pernah melepaskan asal sama sekali, jadi tiada apa yang bertahan kerana tidak dikenali. Inilah yang dilakukan oleh Content Disarm and Reconstruction yang deterministik; Glasswall melaporkan 100% fail berniat jahat dineutralkan merentas 8.27 juta yang diuji, dan kajian kes pusat penyelidikan kerajaan mereka menerangkan pemulihan yang disusun dengan cara ini.
2. Simpan rekod bagi setiap fail. Bagi setiap dokumen, apa yang dibuang, di bawah policy yang mana, pada masa bila. Ini ialah artifak yang diperlukan oleh laporan insiden anda dan artifak yang diminta oleh penilai, dan ia tidak boleh dibina semula kemudian.
3. Utamakan mengikut blast radius, bukan mengikut abjad. Pemacu kongsi, peti mel dan apa sahaja yang digunakan oleh saluran paip automatik didahulukan. Kongsi kewangan yang memberi makan proses bulanan dipacu makro ialah masalah tahap lebih tinggi daripada arkib yang tiada siapa buka.
4. Anggap estate masih terasing. Di pertengahan pemulihan, selalunya tiada rangkaian untuk menghantar fail ke sana sini, sebab itulah pemprosesan yang berada pada desktop penting di sini dengan cara yang tidak penting dalam keadaan stabil. Glasswall Meteor menjalankan enjin secara tempatan, dalam talian, luar talian atau air-gapped.

Tiada satu pun daripada ini glamor, dan tiada satu pun daripadanya kejuruteraan baharu. Ia hanyalah satu langkah dan keputusan untuk meluangkan masa.

Separuh bukti

Sebab kedua untuk menambah langkah ini ialah di rantau ini kewajipan itu sudah pun ditulis, dan ia merupakan kewajipan bukti sama seperti kewajipan kawalan.

Cybersecurity Code of Practice for Critical Information Infrastructure Singapura menyatakannya dengan jelas dalam klausa 6.1.4: log disimpan sekurang-kurangnya dua belas bulan selepas peristiwa yang direkodkan, dilindungi daripada pengubahsuaian dan pemadaman tanpa kebenaran, dan "dikawal oleh log retention policy untuk memudahkan penyiasatan terhadap insiden cybersecurity". Retention yang tujuan dinyatakannya ialah penyiasatan, bukan arkib.

MAS Technology Risk Management Guidelines menetapkan jangkaan selari untuk institusi kewangan: fail tidak dipercayai yang tiba melalui mel, portal muat naik atau pertukaran pihak ketiga dikendalikan di sempadan dan bukannya diterima hanya berdasarkan keputusan pengesanan.

Baca kedua-duanya bersama selepas insiden dan soalan yang dibawa oleh penilai bukanlah "apa yang anda sekat". Ia ialah "tunjukkan kepada saya apa yang berlaku kepada dokumen ini". Kawalan yang hanya merekod pengecualian tidak dapat menjawab itu, kerana fail yang dibenarkan lalu tidak menghasilkan rekod bagi setiap fail langsung. Langkah bina semula menghasilkan satu untuk setiap fail yang disentuhnya, termasuk yang ternyata baik-baik sahaja, dan itulah yang menjadikan rekod itu boleh digunakan sebagai bukti dan bukannya sebagai sejarah amaran.

Soalan yang berbaloi ditanya

Pelan pemulihan dilatih semula. Langkah restore-hygiene ditambah selepas insiden kedua, yang merupakan tempat yang mahal untuk mempelajarinya.

Jika tandatangan anda berada pada kelulusan pemulihan, soalan untuk pasukan anda bukanlah seberapa cepat data kembali. Ia ialah apa yang telah kita letakkan semula, dan bagaimana kita tahu.

Untuk gambaran kewajipan penuh di Singapura, termasuk Cybersecurity (Amendment) Act 2024 dan kemas kini CCoP yang diumumkan pada Julai 2026, lihat Singapore compliance page kami.