Ang hakbang ng pag-restore na walang naglalagay sa runbook

Sinusukat ang bawat recovery plan na nabasa namin batay sa kung gaano kabilis bumabalik ang data. Recovery time objective, recovery point objective, mga oras ng downtime, kita na nawawala kada oras. Iyan ang mga numerong nasa slide ng board, at tama ang mga numerong iyon para sa karamihan ng kailangang gawin ng recovery.

Sila rin ang dahilan kung bakit may isang hakbang na nawawala sa halos bawat runbook sa rehiyon.

Ang dalawang petsa

Magsimula sa timeline, dahil ang timeline ang buong mekanismo.

Na-compromise ka sa isang araw. Nalaman mo ito sa mas huling araw, dahil iyon ang ibig sabihin ng dwell time: ang pagitan sa pagdating ng isang intruder at sa may nakapansin. Sukatin ito sa mga araw o linggo sa halip na mga minuto. Nag-iiba ang eksaktong bilang depende sa insidente at mas hindi mahalaga kaysa sa hugis nito.

Ngayon itanong kung aling backup ang kukunin ng recovery team. Kukunin nila ang pinakabagong restore point na pinaniniwalaang malinis. Sa praktika, ibig sabihin nito ang pinakabagong restore point na kinuha bago nadetect ang insidente, dahil ang detection lang ang pangyayaring may timestamp na pinagkakasunduan ng lahat.

Magkaibang petsa ang mga iyon. Lahat ng ginawa, natanggap, o binago sa agwat sa pagitan nila ay nasa loob ng backup, at ang malisyosong dokumentong nagsimula ng insidente ay halos tiyak na nalikha bago may nakapansin ng anuman. Ang backup ay tapat na kopya. Tapat din ito sa payload.

Ang metrikang nag-aalis ng hakbang

Narito ang bahaging mas kaunti ang nakukuhang atensyon, at hindi ito problema sa teknolohiya.

Ang recovery ay sinusukat batay sa lumipas na oras. Bawat oras na down ang estate ay binibilang, madalas ng mga taong tumitingin sa revenue figure. Ang pag-inspect o pag-reprocess sa bawat na-restore na dokumento ay nagdaragdag ng mga oras sa mismong numerong hinuhusgahan sa recovery lead, at idinadagdag pa ang mga ito sa pinakamasamang sandali, kapag pinakamataas ang pressure na i-deklarang tapos na ang insidente.

Walang nagsusulat ng "we skipped file hygiene" sa isang runbook. Hindi ganoon iyon nangyayari. Hindi kailanman kasama sa runbook ang hakbang, walang metrikang humiling nito, at ang recovery ay natapos sa iskedyul. Tahimik na ginawa ng insentibo ang trabaho.

Kaya nauulit ang pattern: mga server na muling binuo mula sa malilinis na image, mga credential na ni-rotate, mga endpoint na muling in-imaging, network na maayos na na-segment sa pagkakataong ito. Pagkatapos, ang mga fileshare, mailbox, at document repository ay bumabalik nang eksakto kung paano sila dati. Hindi nagalaw. Ang tanging layer na walang nagre-reconstruct ay ang layer na nagdala ng bagay papasok.

Bakit maling instrumento ang muling pag-scan

Ang malinaw na sagot ay i-scan ang backup bago ito i-restore, at mahalagang maging tumpak kung bakit mas mahina iyon kaysa sa tunog nito.

Nabigo ang iyong detection stack na matukoy ang file na ito nang isang beses na, noong araw na dumating ito. Sa oras ng restore, itinuturo mo ang parehong klase ng engine sa parehong file, naghahanap ng parehong katalogo ng mga kilalang masamang bagay. Maaaring nakaabot na ang mga signature kung maingay ang campaign at malawakan itong naiulat. Kung hindi, o kung ang dokumento ay ginawa para sa iyo mismo, hindi pa.

May kaugnay na limitasyon ang sandbox: kasinghusay lang ito ng pagkakadisenyo rito. Ang payload na naghihintay ng interaksyon ng user, ng partikular na locale, o ng petsang hindi pa dumarating ay kumikilos nang walang kapintasan sa panahon ng detonation, at kumikilos nang walang kapintasan sa eksaktong haba ng panahong kailangan nito.

May mas tahimik na pagkabigo rin. Ang muling pag-scan ay nagbubunga ng verdict, at ang verdict ay hindi ebidensya. Ang "Nothing found" ay pahayag tungkol sa saklaw ng iyong detection, hindi tungkol sa file.

Ano ang hitsura ng restore-hygiene step

Ang praktikal na bersyon ay itinuturing ang file na lumalabas sa backup na parang file na dumarating mula sa isang estranghero, dahil sa panahon ng recovery, iyon mismo ang pinagmulan nito.

Sa konkretong paraan, isang hakbang na inilalagay sa pagitan ng restore at pagbabalik sa serbisyo:

1. Muling buuin kaysa siyasatin. Hatiin ang bawat dokumento sa mga sangkap nito, beripikahin ang bawat isa laban sa inilathalang specification para sa format na iyon, pagkatapos ay gumawa ng isang panibagong file mula sa intermediate representation na iyon: ang recipe, hindi ang orihinal na bytes. Mas mahalaga ang pagkakaibang ito kaysa sa tunog nito. Ang pagkopya sa mga bahagi na itinuring ng isang engine na maayos ay isa pa ring paghatol tungkol sa kung ano ang mukhang ligtas, na detection na nakasuot ng ibang damit, at ang orihinal na file pa rin ang siyang dumarating. Ang isang rebuild ay hindi kailanman ipinapadaan ang orihinal sa anumang yugto, kaya walang nakaliligtas sa pamamagitan ng hindi nakikilala. Ito ang ginagawa ng deterministic Content Disarm and Reconstruction; iniulat ng Glasswall na 100% ng mga malicious file ang na-neutralize sa 8.27 milyong nasubukan, at inilalarawan ng case study ng government research centre nito ang isang recovery na isinunod sa ganitong paraan.
2. Panatilihin ang record per file. Para sa bawat dokumento, kung ano ang inalis, sa ilalim ng aling policy, at sa anong oras. Ito ang artefact na kailangan ng iyong incident report at ang artefact na hinihingi ng isang assessor, at hindi na ito maaaring muling buuin sa kalaunan.
3. Unahin ayon sa blast radius, hindi ayon sa alpabeto. Unahin ang shared drives, mailboxes at anumang kinakain ng isang automated pipeline. Ang isang finance share na nagpapakain sa isang buwanang macro-driven process ay mas mataas ang antas ng problema kaysa sa isang archive na walang nagbubukas.
4. Ipagpalagay na ang estate ay naka-island pa rin. Sa kalagitnaan ng recovery, madalas ay walang network para maipadala ang mga file, kaya mahalaga rito ang desktop-resident processing sa paraang hindi ito mahalaga sa steady state. Ang Glasswall Meteor ay nagpapatakbo ng engine nang lokal, online, offline o air-gapped.

Walang glamor sa alinman dito, at wala ring bago sa engineering. Isa itong hakbang at isang desisyon na gugulin ang mga oras.

Ang kalahati ng ebidensya

Ang ikalawang dahilan para idagdag ang hakbang ay na sa rehiyong ito, nakasulat na ang obligasyon, at obligasyon ito sa ebidensya gaya rin ng sa control.

Tahasan itong inilalatag ng Singapore's Cybersecurity Code of Practice for Critical Information Infrastructure sa clause 6.1.4: mga log na itinatago nang hindi bababa sa labindalawang buwan matapos ang pangyayaring nire-record nila, protektado laban sa hindi awtorisadong pagbabago at pagbura, at "governed by a log retention policy to facilitate investigations into cybersecurity incidents". Retention na ang nakasaad na layunin ay ang imbestigasyon, hindi ang archive.

Itinatakda ng MAS Technology Risk Management Guidelines ang katulad na inaasahan para sa mga financial institution: ang mga hindi pinagkakatiwalaang file na dumarating sa pamamagitan ng mail, upload portal o third-party exchange ay hinahawakan sa boundary sa halip na tanggapin batay lamang sa detection verdict.

Basahin ang mga iyon nang magkasama pagkatapos ng isang insidente at ang tanong na dala ng assessor ay hindi "what did you block". Ito ay "show me what happened to this document". Ang control na nagre-record lang ng exceptions ay hindi makasasagot doon, dahil ang mga file na pinadaan nito ay walang per-file record na nalikha. Ang rebuild step ay lumilikha ng isa para sa bawat file na hinawakan nito, kabilang ang mga lumabas na ayos na ayos, na siyang dahilan kung bakit nagagamit ang record bilang ebidensya sa halip na history ng alert.

Ang tanong na sulit itanong

Ang mga recovery plan ay nire-rehearse. Ang restore-hygiene steps ay idinadagdag pagkatapos ng ikalawang insidente, na isang magastos na lugar para matutuhan iyon.

Kung ang iyong lagda ang nasa recovery sign-off, ang tanong para sa iyong team ay hindi kung gaano kabilis bumalik ang data. Ito ay kung ano ang ibinalik natin, at paano natin nalaman.

Para sa buong larawan ng obligasyon sa Singapore, kabilang ang Cybersecurity (Amendment) Act 2024 at ang CCoP update na inanunsyo noong July 2026, tingnan ang aming Singapore compliance page.