Runbook-д хэн ч оруулдаггүй сэргээх алхам

Бидний уншсан recovery plan бүр өгөгдөл хэр хурдан буцаж ирж байгаагаар хэмжигддэг. Recovery time objective, recovery point objective, downtime-ийн цаг, орлого цаг тутамд алдагдах. Эдгээр нь board slide дээрх тоонууд бөгөөд recovery-ийн хийх ёстой ихэнх зүйлд зөв тоонууд юм.

Тэд мөн энэ бүс нутгийн бараг бүх runbook-оос нэг алхам яагаад алга байгаагийн шалтгаан юм.

Хоёр огноо

Цагийн шугамаас эхэл, учир нь цагийн шугам нь бүх механизм юм.

Та нэг өдөр эвдэгдсэн байна. Та дараагийн өдөр нь үүнийг мэднэ, учир нь dwell time гэдэг нь яг энэ юм: халдагч ирэхээс хэн нэгэн анзаарах хүртэлх завсар. Үүнийг минут биш, өдөр эсвэл долоо хоногоор хэмж. Яг тоо нь тухайн инцидентээс хамаарч өөр байдаг бөгөөд түүний хэлбэрээс хавьгүй бага ач холбогдолтой.

Одоо сэргээх баг аль нөөц хуулбарыг сонгохыг асуу. Тэд хамгийн сүүлд цэвэр гэж үзэж буй сэргээх цэгийг сонгодог. Практикт энэ нь осол илэрсэнээс өмнө авсан хамгийн сүүлийн сэргээх цэг гэсэн үг, учир нь илрүүлэлт нь хүн бүр санал нийлдэг цагийн тэмдэгтэй цорын ганц үйл явдал юм.

Эдгээр нь хоёр өөр огноо. Тэдгээрийн хоорондох завсарт үүссэн, хүлээн авсан эсвэл өөрчлөгдсөн бүх зүйл backup дотор орсон байдаг бөгөөд инцидентыг эхлүүлсэн malicious document нь бараг лав хэн нэгэн ямар нэгэн зүйл анзаарахаас өмнө үүссэн байдаг. Backup бол үнэнч хуулбар. Payload-ын хувьд ч мөн үнэнч.

Алхамыг устгадаг metric

Илүү бага анхаарал татдаг хэсэг нь энэ бөгөөд энэ нь огт технологийн асуудал биш.

Сэргээх ажиллагааг өнгөрсөн хугацаагаар үнэлдэг. Байгууллагын орчин зогссон цаг бүрийг тооцдог бөгөөд ихэвчлэн орлогын тоо харж буй хүмүүс үүнийг анзаардаг. Сэргээгдсэн баримт бүрийг шалгах эсвэл дахин боловсруулах нь сэргээх ажлыг удирдаж буй хүнийг үнэлж буй яг тэр тоон дээр хэдэн цаг нэмж, мөн энэ нь хамгийн тохиромжгүй мөчид, өөрөөр хэлбэл осол дууссан гэж зарлах дарамт хамгийн өндөр үед, тэр цагуудыг нэмдэг.

Хэн ч runbook-д "бид file hygiene-г алгассан" гэж бичдэггүй. Тийм биш. Тэр алхам runbook-д хэзээ ч байгаагүй, ямар ч metric түүнийг шаардаагүй, харин recovery төлөвлөсөн хугацаандаа дууссан. Урамшууллын бүтэц ажлыг чимээгүйхэн хийсэн.

Тиймээс хэв маяг давтагдана: серверүүдийг цэвэр image-үүдээс дахин бүтээнэ, credential-уудыг солино, endpoint-үүдийг дахин image-лэнэ, энэ удаа network-ийг зөв сегментчилнэ. Дараа нь fileshare-ууд, mailbox-ууд болон document repository-ууд яг байсан шигээ буцаж ирнэ. Хөндөгдөөгүй. Хэн ч дахин бүтээдэггүй цорын ганц давхарга нь дотор нь тэр зүйлийг авчирсан давхарга юм.

Яагаад дахин скан хийх нь буруу хэрэгсэл вэ

Илэрхий хариулт нь backup-ыг сэргээхээс нь өмнө scan хийх явдал бөгөөд яагаад энэ нь сонсогдож байгаагаасаа сул болохыг нарийн тайлбарлах нь зүйтэй.

Таны detection stack энэ файлыг нэгэнтээ, ирсэн өдөр нь, таньж чадсангүй. Restore хийх үед та ижил төрлийн engine-ийг ижил файл дээр чиглүүлж, мэдэгдэж буй муу зүйлсийн ижил каталогийг хайж байна. Хэрэв campaign нь шуугиантай, өргөн мэдээлэгдсэн байсан бол signatures нь гүйцэж ирсэн байж магадгүй. Тийм биш байсан бол, эсвэл document нь танд тусгайлан бүтээгдсэн бол, тэгээгүй.

Sandbox-д мөн төстэй хязгаарлалт бий: энэ нь зөвхөн өөрт нь хэр сайн design хийснээсээ л сайн байдаг. User interaction, тодорхой locale, эсвэл хараахан ирээгүй date-ийг хүлээдэг payload нь detonation үед өөгүй ажиллаж, яг хэрэгтэй хугацаандаа өөгүй хэвээр байдаг.

Илүү нам гүм failure ч бас бий. Re-scanning нь verdict гаргадаг, харин verdict нь evidence биш. "Nothing found" гэдэг нь file-ийн тухай биш, таны detection coverage-ийн тухай өгүүлж буй statement юм.

Restore-hygiene step ямар харагддаг вэ

Ажил хэрэгч хувилбар нь backup-аас гарч ирж буй file-ийг танихгүй хүнээс ирж буй file мэт авч үздэг, учир нь recovery-ийн үед энэ нь яг түүний provenance юм.

Тодруулбал, restore болон service-д буцаахын хооронд оруулах нэг step:

1. Шалгахаас илүүтэйгээр дахин бүтээ. Тус бүрийн баримт бичгийг бүрэлдэхүүн хэсгүүдэд нь задлан, тухайн форматын нийтлэгдсэн specification-тай бүр бүрийг нь тулган баталгаажуулж, дараа нь тэр завсрын representation-оос цоо шинэ файл үйлдвэрлэ: эх bytes-ийг биш, жорыг. Энэ ялгаа сонсогдож байгаагаасаа илүү чухал. Engine-ийн хувьд сайн гэж дүгнэсэн хэсгүүдийг хуулж авах нь ч гэсэн аюулгүй мэт харагдаж буйг дүгнэж байгаа хэрэг бөгөөд энэ нь detection өөр хувцас өмссөнтэй адил, харин эх файл нь ирсээр л байдаг. Дахин бүтээх үед эх файлыг огт дамжуулдаггүй тул танигдалгүй үлдэх зүйл гэж үгүй. Энэ бол deterministic Content Disarm and Reconstruction яг хийдэг зүйл; Glasswall нь 8.27 сая туршсан хортой файлын 100%-ийг саармагжуулсан гэж мэдээлдэг бөгөөд түүний government research centre case study-д сэргээх ажиллагааг ийм дарааллаар хийснийг тайлбарласан байдаг.
2. Бүртгэлийг файл тус бүрээр нь хадгал. Баримт бичиг бүрийн хувьд, юу устгагдсан, ямар policy-ийн дор, хэдийд. Энэ бол таны incident report-д хэрэгтэй artefact бөгөөд assessor-ийн шаарддаг artefact мөн, түүнийг дараа нь дахин сэргээх боломжгүй.
3. Цагаан толгойн дарааллаар биш, blast radius-аар нь эрэмбэл. Shared drive-ууд, mailbox-ууд болон automated pipeline хэрэглэдэг бүх зүйл эхэнд орно. Сар бүр macro-driven process тэжээдэг finance share нь хэн ч нээдэггүй archive-оос илүү өндөр эрсдэлтэй асуудал юм.
4. Estate нь одоо ч islanded хэвээр гэж үз. Сэргээх явцын дунд файлуудыг дамжуулах network ихэвчлэн байдаггүй, тиймээс desktop-resident processing энд steady state үеийнхээс өөрөөр чухал болдог. Glasswall Meteor нь engine-ийг local дээр, online, offline эсвэл air-gapped байдлаар ажиллуулдаг.

Энэ бүхэнд гоёмсог зүйл үгүй, мөн энэ нь шинэ engineering ч биш. Энэ бол нэг step бөгөөд цаг зарцуулах шийдвэр юм.

Evidence тал

Хоёр дахь шалтгаан нь энэ step-ийг нэмэхэд оршдог: энэ region-д үүрэг нь аль хэдийн бичигдсэн бөгөөд энэ нь control-ынх шигээ evidence-ийн үүрэг мөн.

Singapore-ийн Cybersecurity Code of Practice for Critical Information Infrastructure нь clause 6.1.4-д үүнийг тодорхой заасан байдаг: event-ээс хойш дор хаяж арван хоёр сарын турш хадгалсан logs, unauthorized modification болон deletion-ээс хамгаалагдсан, мөн "governed by a log retention policy to facilitate investigations into cybersecurity incidents". Тодорхойлсон зорилго нь archive биш, investigation юм.

MAS-ийн Технологийн Эрсдэлийн Удирдлагын Заавар нь санхүүгийн байгууллагуудад ижил хүлээлтийг тогтоодог: шуудан, upload portal эсвэл гуравдагч талын exchange-ээр ирж буй итгэлгүй файлуудыг зөвхөн detection verdict дээр үндэслэн хүлээн зөвшөөрөхийн оронд trust boundary дээр нь боловсруулна.

Incident-ийн дараа эдгээрийг хамтад нь уншихад assessor-ын асуух асуулт нь "та юуг block хийсэн бэ" биш. Энэ нь "энэ document-д юу тохиолдсоныг надад харуул" юм. Зөвхөн exception-уудыг бүртгэдэг control үүнд хариулж чадахгүй, учир нь түүний зөвшөөрч нэвтрүүлсэн file-ууд per-file record огт үүсгээгүй байдаг. Rebuild step нь хүрсэн file бүрт нэг record үүсгэдэг, бүр төгс зүгээр байсан file-уудыг ч хамруулдаг; энэ нь record-ийг alert history биш, evidence болгон ашиглах боломжтой болгодог.

Асуухад үнэ цэнтэй асуулт

Recovery plan-уудыг давтдаг. Restore-hygiene step-үүдийг хоёр дахь incident-ийн дараа нэмдэг бөгөөд энэ нь түүнийг сурах өртөг өндөртэй газар юм.

Хэрэв таны signature recovery sign-off дээр байвал, танай team-д тавих асуулт нь data хэр хурдан буцаж ирсэн тухай биш. Энэ нь бид юу буцааж тавьсан бэ, мөн үүнийг яаж мэдэж байна вэ гэсэн асуулт юм.

Singapore дахь бүрэн үүргийн зураглалыг, Cybersecurity (Amendment) Act 2024 болон 2026 оны 7-р сард зарласан CCoP update-ийг оролцуулан, манай Singapore compliance page-аас үзнэ үү.