ແຜນຕອບໂຕ້ເຫດການທາງໄຊເບີ ທີ່ໃຊ້ໄດ້ແທ້ຕອນ 2 ໂມງເຊົ້າ

ໂທລະສັບດັງຕອນ 2 ໂມງເຊົ້າ. ພະນັກງານກະກາງຄືນບອກວ່າໜ້າຈໍທຸກເຄື່ອງມີຂໍ້ຄວາມຮຽກຄ່າໄຖ່. ຄຳຖາມທຳອິດທີ່ທ່ານຈະຖາມຕົວເອງ: ໃຜມີລະຫັດ Admin ຂອງ Firewall? ເບີຂອງຜູ້ສະໜອງ Backup ຢູ່ໃສ? ໃຜມີສິດສັ່ງປິດລະບົບທັງໝົດ?

ຖ້າຄຳຕອບຢູ່ໃນ Server ທີ່ຫາກໍຖືກເຂົ້າລະຫັດ, ທ່ານບໍ່ມີແຜນ. ບົດນີ້ອະທິບາຍວິທີຂຽນແຜນທີ່ສັ້ນພໍທີ່ຈະໃຊ້ໄດ້ແທ້.

ສີ່ໄລຍະ

ແບບຈຳລອງຂອງ NIST SP 800-61 ທີ່ໃຊ້ກັນມາດົນ ແບ່ງເປັນສີ່ໄລຍະ. ສະບັບ Revision 3 (ປີ 2025) ຈັດໃໝ່ໃຫ້ກົງກັບ NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) ແຕ່ວຽກທີ່ຕ້ອງເຮັດໃນທາງປະຕິບັດຍັງຄືເກົ່າ:

ສິ່ງທີ່ຕ້ອງມີໃນແຜນ

1. ອັນໃດເອີ້ນວ່າເຫດການ ແລະ ຮຸນແຮງປານໃດ

2. ໃຜເຮັດຫຍັງ. ຫົວໜ້າເຫດການ (ປະສານງານ, ບໍ່ຈຳເປັນຕ້ອງເປັນຄົນເກັ່ງເຕັກນິກທີ່ສຸດ), ຫົວໜ້າດ້ານເຕັກນິກ, ຜູ້ບໍລິຫານທີ່ມີສິດຕັດສິນໃຈປິດລະບົບ ຫຼື ຈ່າຍຄ່າບໍລິການສຸກເສີນ, ຜູ້ສື່ສານກັບລູກຄ້າ ແລະ ພະນັກງານ, ທີ່ປຶກສາດ້ານສັນຍາ ແລະ ຄວາມສ່ຽງຂອງອົງກອນ ແລະ ຜູ້ໃຫ້ບໍລິການພາຍນອກ. ແຕ່ລະບົດບາດມີຄົນສຳຮອງ.

3. ລາຍຊື່ຕິດຕໍ່. ພິມເປັນເຈ້ຍ, ເກັບໃນໂທລະສັບຂອງທີມ ແລະ ເກັບສຳເນົາໄວ້ນອກລະບົບຂອງອົງກອນ. ລວມເບີສ່ວນຕົວ, ຜູ້ໃຫ້ບໍລິການ Internet, ຜູ້ສະໜອງ Firewall ແລະ Backup, ທະນາຄານ ແລະ ບໍລິສັດປະກັນໄພ (ຖ້າມີ).

4. ຊ່ອງທາງສື່ສານສຳຮອງ. ຖ້າຜູ້ໂຈມຕີຢູ່ໃນ Microsoft 365 ຂອງທ່ານ ເຂົາອ່ານ Email ແລະ Teams ໄດ້. ກຽມກຸ່ມ WhatsApp ຫຼື LINE ໄວ້ລ່ວງໜ້າ.

5. ການແຈ້ງພາຍນອກ. ລາຍການວ່າຈະແຈ້ງໃຜ ໃນກໍລະນີໃດ: ທະນາຄານເມື່ອມີການໂອນເງິນທີ່ບໍ່ຖືກຕ້ອງ, ລູກຄ້າເມື່ອຂໍ້ມູນຂອງເຂົາອາດຮົ່ວ, ບໍລິສັດປະກັນໄພ ແລະ ຜູ້ອື່ນທີ່ຜູ້ບໍລິຫານຕົກລົງໄວ້ລ່ວງໜ້າ. ຂຽນໄວ້ວ່າໃຜເປັນຜູ້ອະນຸມັດຂໍ້ຄວາມກ່ອນສົ່ງ.

6. Playbook ສຳລັບເຫດການທີ່ພົບເລື້ອຍ: Ransomware, ບັນຊີ Email ຖືກຍຶດ, Laptop ຫາຍ, ການໂອນເງິນຫຼອກລວງ.

7. ຫຼັກຖານ. ບໍ່ລຶບ Log, ບໍ່ Format ເຄື່ອງກ່ອນເກັບຫຼັກຖານ, ຖ່າຍຮູບໜ້າຈໍ ແລະ ບັນທຶກເວລາທຸກການກະທຳ.

Playbook ຕົວຢ່າງ: ບັນຊີ Email ຖືກຍຶດ

ນີ້ແມ່ນເຫດການທີ່ພົບເລື້ອຍທີ່ສຸດ ແລະ ມັກນຳໄປສູ່ການຫຼອກໂອນເງິນ.

1. Reset ລະຫັດຜ່ານ ແລະ Revoke Session ທັງໝົດ (ລວມທັງ Refresh Token).
2. ກວດ ແລະ ລຶບ Inbox Rule ທີ່ Forward ອອກນອກ ຫຼື ຍ້າຍ Email ໄປ Folder ທີ່ບໍ່ມີໃຜເບິ່ງ. ຜູ້ໂຈມຕີມັກສ້າງ Rule ເພື່ອເຊື່ອງຄຳຕອບຈາກຄູ່ຄ້າ.
3. ກວດວິທີ MFA ທີ່ລົງທະບຽນໃໝ່ ແລະ ແອັບ OAuth ທີ່ໄດ້ຮັບອະນຸຍາດ. ລຶບອັນທີ່ບໍ່ຮູ້ຈັກ.
4. ກວດ Email ທີ່ສົ່ງອອກຈາກບັນຊີ ໃນຊ່ວງທີ່ຖືກຍຶດ. ຖ້າມີການຂໍເງິນ ຫຼື ປ່ຽນເລກບັນຊີ ໃຫ້ໂທແຈ້ງຄູ່ຄ້າທັນທີ.
5. ຊອກ Email Phishing ຕົ້ນເຫດ ແລະ ລຶບອອກຈາກທຸກ Mailbox.
6. ກວດ Sign-in Log ວ່າມີບັນຊີອື່ນຖືກ Login ຈາກ IP ດຽວກັນບໍ່.

Playbook ຕົວຢ່າງ: Ransomware ໃນຊົ່ວໂມງທຳອິດ

1. ຕັດເຄື່ອງທີ່ຕິດເຊື້ອອອກຈາກເຄືອຂ່າຍ (ຖອດສາຍ, ປິດ Wi-Fi), ແຕ່ຍັງບໍ່ຕ້ອງປິດເຄື່ອງ. ໜ່ວຍຄວາມຈຳ ແລະ ໂປຣແກຣມທີ່ກຳລັງແລ່ນ ອາດບອກໄດ້ວ່າຜູ້ໂຈມຕີເຂົ້າມາທາງໃດ.
2. ຕັດການເຂົ້າໃຊ້ຈາກທາງໄກ: ປິດບັນຊີ VPN ແລະ Remote Desktop ທີ່ບໍ່ຈຳເປັນ, ແລະ ບລັອກ Traffic ຂາອອກຈາກ Server ທີ່ບໍ່ຕ້ອງການ.
3. ກວດ Backup ກ່ອນແຕະສິ່ງອື່ນ. ສຳເນົາແບບ Offline ຫຼື Immutable ຍັງຄົບບໍ? ຖ້າໜ້າຈໍຈັດການ Backup ເຂົ້າໄດ້ຈາກເຄືອຂ່າຍທີ່ຕິດເຊື້ອ, ໃຫ້ຕັດອອກຈາກເຄືອຂ່າຍທັນທີ.
4. ຈາກເຄື່ອງທີ່ສະອາດ, ປ່ຽນລະຫັດຜ່ານ Domain Admin, Backup ແລະ Admin ຂອງ Firewall. ໃຫ້ຖືວ່າທຸກລະຫັດຜ່ານທີ່ເຄີຍພິມໃນເຄື່ອງທີ່ຕິດເຊື້ອ ຜູ້ໂຈມຕີຮູ້ແລ້ວ.
5. ຊອກຫາເຄື່ອງທຳອິດທີ່ຕິດເຊື້ອ ແລະ ເວລາທີ່ເກີດ. ຈຸດກູ້ຄືນຕ້ອງມາຈາກກ່ອນເວລານັ້ນ, ບໍ່ແມ່ນພຽງແຕ່ກ່ອນຂໍ້ຄວາມຮຽກຄ່າໄຖ່ປາກົດ.
6. ການຕັດສິນໃຈເລື່ອງຂໍຄວາມຊ່ວຍເຫຼືອຈາກພາຍນອກ ແລະ ການແຈ້ງພາຍນອກ ໃຫ້ເຮັດໃນລະດັບຜູ້ບໍລິຫານ ໂດຍໃຊ້ລາຍຊື່ຜູ້ຕິດຕໍ່, ບໍ່ແມ່ນຄິດເອົາເອງໃນຄືນນັ້ນ.

ລາຍການກວດກາປ້ອງກັນ Ransomware ຂອງພວກເຮົາ ບອກສິ່ງທີ່ຄວນກຽມໄວ້ລ່ວງໜ້າ.

ຕົວຢ່າງການຄິດໄລ່: ກູ້ຂໍ້ມູນຄືນຈະໃຊ້ເວລາດົນປານໃດ?

File Server ຂອງບໍລິສັດໜຶ່ງມີຂໍ້ມູນ 2 TB. Backup ດຽວທີ່ມີຢູ່ໃນ Cloud ແລະ ຫ້ອງການມີອິນເຕີເນັດ 100 Mbps. 2 TB ເທົ່າກັບປະມານ 16,000,000 Megabit; ທີ່ 100 Mbps ຈະໃຊ້ 160,000 ວິນາທີ, ປະມານ 44 ຊົ່ວໂມງ ຍັງບໍ່ນັບ Overhead ແລະ ຕ້ອງບໍ່ມີຫຍັງອື່ນໃຊ້ສາຍນັ້ນ. ການກູ້ຄືນແບບດຽວກັນຈາກ NAS ໃນຫ້ອງການ ຜ່ານເຄືອຂ່າຍ 1 Gbps ໃຊ້ເວລາປະມານ 4.5 ຊົ່ວໂມງ ຕາມທິດສະດີ. ນີ້ແມ່ນເຫດຜົນທີ່ພວກເຮົາແນະນຳໃຫ້ມີສຳເນົາໃນບ່ອນ ແລະ ນອກບ່ອນ ຕາມ ກົດ Backup 3-2-1, ແລະ ທົດສອບກູ້ຄືນພ້ອມຈັບເວລາ ຢ່າງໜ້ອຍປີລະຄັ້ງ. ຕົວເລກທີ່ວັດໄດ້ແທ້ ແມ່ນຕົວເລກທີ່ຄວນຂຽນໃສ່ແຜນ.

ຊ້ອມແຜນ

ແຜນທີ່ບໍ່ເຄີຍຊ້ອມ ມັກລົ້ມໃນຈຸດທີ່ບໍ່ຄາດຄິດ: ເບີໂທທີ່ປ່ຽນແລ້ວ, ຄົນທີ່ລາອອກ, Backup ທີ່ບໍ່ມີໃຜຮູ້ລະຫັດ.

ຈັດ Tabletop Exercise ປີລະ 1–2 ຄັ້ງ. ສອງຊົ່ວໂມງ ຮອບໂຕະດຽວ, ກັບຜູ້ບໍລິຫານ, IT, ການເງິນ ແລະ HR. ຜູ້ນຳອ່ານສະຖານະການເທື່ອລະຂັ້ນ:

• "ວັນສຸກ 18:30, ພະນັກງານບັນຊີແຈ້ງວ່າໄຟລ໌ໃນ Shared Drive ເປີດບໍ່ໄດ້."
• "19:15, ເຄື່ອງອີກສາມເຄື່ອງມີຂໍ້ຄວາມຮຽກຄ່າໄຖ່."
• "21:00, ມີ Email ຈາກຜູ້ໂຈມຕີບອກວ່າລັກຂໍ້ມູນລູກຄ້າໄປແລ້ວ."

ແຕ່ລະຂັ້ນ ຖາມວ່າ: ໃຜເຮັດຫຍັງ? ໃຜຕັດສິນໃຈ? ຂໍ້ມູນທີ່ຕ້ອງການຢູ່ໃສ? ບັນທຶກທຸກບ່ອນທີ່ຄົນລັງເລ, ນັ້ນແມ່ນສິ່ງທີ່ຕ້ອງແກ້ໃນແຜນ.

ກຽມສິ່ງເຫຼົ່ານີ້ໄວ້ ກ່ອນເກີດເຫດ

1. ແຜນ ແລະ ລາຍຊື່ຜູ້ຕິດຕໍ່ ພິມອອກມາ ແລະ ເກັບໄວ້ນອກລະບົບຂອງບໍລິສັດ.
2. ກຸ່ມສື່ສານສຳຮອງ ຕັ້ງໄວ້ ແລະ ທົດສອບແລ້ວ.
3. Log ຈາກ Firewall, Email ແລະ ເຄື່ອງຜູ້ໃຊ້ ເກັບໄວ້ຢ່າງໜ້ອຍ 90 ມື້ ໃນບ່ອນທີ່ຜູ້ໂຈມຕີລຶບບໍ່ໄດ້.
4. ສຳເນົາ Backup ຢ່າງໜ້ອຍໜຶ່ງຊຸດ ທີ່ເປັນແບບ Offline ຫຼື Immutable, ພ້ອມບັນທຶກການທົດສອບກູ້ຄືນທີ່ຈັບເວລາໄວ້.
5. MFA ໃນ Email, VPN ແລະ ທຸກບັນຊີ Admin (ເບິ່ງ ຄູ່ມືລະຫັດຜ່ານ ແລະ MFA).
6. ບັນຊີ Admin ສຸກເສີນ (Break-glass) ທີ່ລະຫັດຜ່ານຖືກຜະນຶກ ແລະ ເກັບໄວ້ກັບຜູ້ບໍລິຫານ.
7. ມີຜູ້ບໍລິຫານທີ່ຖືກລະບຸຊື່ ທີ່ມີສິດອະນຸມັດປິດລະບົບ.
8. ໄດ້ຊ້ອມ Tabletop ພາຍໃນ 12 ເດືອນທີ່ຜ່ານມາ ແລະ ແກ້ຈຸດອ່ອນທີ່ພົບແລ້ວ.

ສິ່ງທີ່ເຮັດໃຫ້ເຫດການຮ້າຍແຮງຂຶ້ນ

• ແຜນຢູ່ແຕ່ໃນ File Server ທີ່ຖືກເຂົ້າລະຫັດ.
• Format ເຄື່ອງທັນທີ ຈົນບໍ່ຮູ້ວ່າຜູ້ໂຈມຕີເຂົ້າມາທາງໃດ, ແລ້ວເຂົາກັບມາອີກຜ່ານຊ່ອງທາງເກົ່າ.
• ກູ້ຄືນຈາກ Backup ທີ່ຖືກເຮັດໃນຂະນະທີ່ຜູ້ໂຈມຕີຢູ່ໃນລະບົບແລ້ວ.
• ປະສານງານຜ່ານ Email ຂອງອົງກອນທີ່ຜູ້ໂຈມຕີກຳລັງອ່ານ.
• ບໍ່ມີໃຜມີອຳນາດສັ່ງປິດລະບົບ, ສະນັ້ນລໍຖ້າຜູ້ອຳນວຍການທີ່ກຳລັງເດີນທາງ.

ການສື່ສານກັບພະນັກງານ ແລະ ລູກຄ້າ

ກຳນົດຜູ້ເວົ້າແທນບໍລິສັດພຽງຄົນດຽວ. ຄົນອື່ນໃຫ້ເວົ້າພຽງວ່າ "ພວກເຮົາກຳລັງກວດກາ ແລະ ຈະແຈ້ງໃຫ້ຮູ້" ເທົ່ານັ້ນ. ກຽມຂໍ້ຄວາມສັ້ນໄວ້ລ່ວງໜ້າ: ເກີດຫຍັງຂຶ້ນ ໃນໜຶ່ງປະໂຫຍກ, ລູກຄ້າຄວນເຮັດຫຍັງ (ເຊັ່ນ ບໍ່ສົນໃຈ Email ທີ່ຂໍໃຫ້ປ່ຽນບັນຊີທະນາຄານ) ແລະ ຈະແຈ້ງຄັ້ງຕໍ່ໄປເມື່ອໃດ. ຢ່າເດົາຈຳນວນຂໍ້ມູນທີ່ຮົ່ວ ຫຼື ສາເຫດ ໃນຊົ່ວໂມງທຳອິດ; ຕົວເລກໄລຍະທຳອິດມັກຜິດ ແລະ ຖອນຄືນຍາກ. ແຈ້ງພະນັກງານກ່ອນທີ່ລູກຄ້າຈະໄດ້ຍິນຈາກບ່ອນອື່ນ.

ແບບຟອມບັນທຶກເຫດການ

ຂຽນໃຫ້ສັ້ນ ແລະ ເປັນພາສາຂອງທີມ

ແຜນ 5–10 ໜ້າທີ່ທຸກຄົນອ່ານແລ້ວ ດີກວ່າແຜນ 80 ໜ້າທີ່ບໍ່ມີໃຜເປີດ. ຂຽນເປັນພາສາລາວ ຫຼື ໄທ ຕາມທີ່ທີມໃຊ້ ແລະ ຮັກສາຄຳສັບເຕັກນິກເປັນພາສາອັງກິດ. ສຳລັບສາຂາຕ່າງແຂວງ ກຳນົດຜູ້ປະສານງານທ້ອງຖິ່ນໜຶ່ງຄົນທີ່ຮູ້ວິທີຖອດສາຍ Network ຂອງສາຂາ ແລະ ໂທແຈ້ງທັນທີ. ຖ້າບໍ່ມີທີມຄວາມປອດໄພພາຍໃນ ໃຫ້ຕົກລົງກັບຜູ້ໃຫ້ບໍລິການລ່ວງໜ້າ; ການຊອກຫາຜູ້ຊ່ວຍໃນຄືນທີ່ເກີດເຫດ ເສຍເວລາຫຼາຍຊົ່ວໂມງທີ່ສຳຄັນທີ່ສຸດ.

ເລີ່ມດ້ວຍ Tabletop ໜຶ່ງຄັ້ງ

ຖ້າຍັງບໍ່ມີແຜນ, ການຊ້ອມໜຶ່ງຄັ້ງຈະບອກທ່ານວ່າຕ້ອງຂຽນຫຍັງ. ພວກເຮົາສາມາດມາດຳເນີນ Tabletop ສອງຊົ່ວໂມງເປັນພາສາລາວ ຫຼື ໄທ ໂດຍໃຊ້ສະຖານະການທີ່ກົງກັບລະບົບຂອງທ່ານ, ແລ້ວສົ່ງຮ່າງແຜນ ແລະ ລາຍການຊ່ອງວ່າງທີ່ພົບໃຫ້ພາຍໃນໜຶ່ງອາທິດ.