7 ข้อสำรวจระบบของตัวเอง จากบทเรียนของ รพ.สระบุรี



ตัวอย่างของความพังพินาศของระบบงานไอที ที่โรงพยาบาลสระบุรี น่าจะได้กระตุ้นให้อีกหลาย ๆ โรงพยาบาล เริ่มตื่นตัวเรื่อง Ransomware และตอนนี้ ก็เป็นช่วงเวลาที่ตลาดไอที ก็จะเริ่มคึกคักกันอีกครั้ง เข็นกองทัพสินค้าไอทีออกมานำเสนอ และเคลมว่า สินค้าของฉันสามารถป้องกัน Ransomware ได้นะจ๊ะ
 
ก่อนอื่นเลย รอง ผอ.ของ รพ.สระบุรีได้ออกมาแถลงว่า โดน Ransomware ชื่อ VoidCrypt เข้าไป

คลิกเพื่อดูคลิปวิดีโอ

เอาครับ…ใครที่ยังหมกมุ่นกับการหา “ของ”
แล้วคิดว่าจะป้องกัน Ransomware ได้
เอาชื่อนี้ไปถามคนขายได้เลยครับ “VoidCrypt”
แล้วก็ไปหาซื้อ “ของ” ที่มันป้องกัน VoidCrypt ได้
แล้วไม่ต้องอ่านต่อครับ และตอนซื้อของ เขาไม่ได้แถมโชคมาช่วยด้วย มามะ ผมจะแจกโชคให้ไป
 
….เตรียมอ้าแขนรับโชคนะ…..ตะเอง นึง ส่ออองงง ส้าาามมม
ผมเคยเขียนบทความแนะนำไปนานแล้ว เรื่องที่ว่า สินค้าตัวไหนที่ป้องกัน Ransomware ได้ ซึ่งคำตอบก็คือ “ไม่มี” การป้องกัน Ransomware มันต้องใช้ “ขบวนการ” เท่านั้น ทำตามทุกข้อเหล่านี้ จะลดโอกาสการโดน Ransomware ไปได้เกือบหมด อ่านตามไปทีละข้อ แล้วผมก็จะวิเคราะห์แต่ละข้อ เปรียบเทียบไปกับเคสของ รพ.สระบุรีด้วย
 

1. Ransomware มาทาง e-mail ดังนั้น ถามผู้ให้บริการ Mail เขาต้องมี 3 อย่างนี้
– Spam filter ที่ทำงานโดยอ้างอิง Cloud database
– Antivirus ที่ทำงานโดยอ้างอิง Cloud database ที่วิเคราะห์ Malware ด้วย Sandbox หรือ VM environment
– Antivirus ที่ทำงานโดยอ้างอิง Cloud database ที่วิเคราะห์ Malware ด้วย AI engine

ถ้าเราตั้ง Mail server ใช้เอง ก็ต้องเพิ่ม Spam filter และ Antivirus engine เข้าไปให้กับ Mail server ของเราด้วย
ถ้าผู้ให้บริการไม่มีกลไกเหล่านี้ เปลี่ยนเจ้าครับ จบง่าย ๆ แค่นี้ อย่าทนใช้ต่อ ภัยจะมาเยือนเอาง่าย ๆ
เท่าที่เช็คดูจาก MX record พบว่า Mail server ของ รพ.สระบุรี เป็น IP ของ CAT จะตั้งเองหรือใช้บริการของผู้ให้บริการรายไหนไม่ทราบได้ จะมีระบบป้องกันหรือเปล่าก็ไม่รู้ เพราะตอนที่เขียนเรื่องอยู่นี้ Mail server ของ รพ. ติดต่อไม่ได้ครับ อาจจะถูกตั้งใจปิดไปชั่วคราว….มั้ง
 

2. อบรมผู้ใช้ในองค์กร ให้รู้จักแยกแยะ Phishing mail

อบรมกันจริงจังแบบ Class training ไม่ใช่เอากระดาษไปแปะแล้วมีแค่ Info Graphic ติดกันข้ามเดือนข้ามปีจนกลายเป็นอินโฟซีด
ต้องอบรมสด เน้นให้ผู้ใช้รู้ว่า ผู้ร้ายหลอกเราด้วยทุกวิธี ทั้งส่งไฟล์แนบ, ส่ง Link ให้คลิก, ส่งไฟล์ให้เปิดแล้วคลิก Link ในไฟล์, ส่งรูปแทน link คลิกเปิดได้เหมือนกัน ฯลฯ สอนผู้ใช้ให้รู้กลโกงของผู้ร้าย ยกตัวอย่างให้ดู เปลี่ยน User ให้กลายเป็น Super Secured User ขึ้นมา อัดวิดีโอไว้ เก็บเอาไว้ให้พนักงานใหม่ ๆ ได้ดูตอนปฐมนิเทศด้วย
ผู้ให้บริการ Mailbox จะเก่งแค่ไหน จะใช้ระบบสแกนดีแค่ไหน ยังไง ๆ e-mail จากผู้ร้ายก็จะหลุดเข้ามาหาผู้ใช้ได้บ้าง และ Ransomware ก็มีโอกาสจะมาถึง Mailbox ของผู้ใช้ในที่สุด ถ้าผู้ใช้ให้ความร่วมมือกับผู้ร้าย คลิกตามที่โดนหลอก ก็จบครับ ระบบพัง รพ.สระบุรี อาจมีจุดเริ่มต้นง่าย ๆ แค่นี้
อ่ะ…ลองหลับตานึกภาพของหมอและพยาบาลและเจ้าหน้าที่ Back office ของรพ.สระบุรี เดินเรียงแถวกันเข้าห้องอบรมในหัวข้อ “อ่าน e-mail อย่างไร ไม่ให้ถูกโจรหลอกเปิด Ransomware” จัดอบรมครึ่งวัน บรรยายโดยแผนกไอที เรานึกภาพนั้นออกกันมั้ยครับ……..เอิ่มมมมมม
 

3. Firewall ต้องเปิดฟีเจอร์ป้องกัน Malicious website หรือ Compromised website และต้องมีผู้ดูแลที่มีความเข้าใจในคุณค่าของ Firewall ต่อความปลอดภัยของธุรกิจ

Ransomware มากับ e-mail ที่แนบ link ให้ผู้ใช้คลิกเพื่อไป Download Ransomware มาที่เครื่องอีกที Website เหล่านี้ส่วนใหญ่ถูก Black list เอาไว้แล้ว Firewall ป้องกันไม่ให้ผู้ใช้เข้าถึง website เหล่านี้ได้ แต่ทำไมยังโดนกันอยู่ (วะ)
ผมอยากถาม 2 คำถามนี้ให้เราได้คิดกันดูครับ
– ผู้ขายที่ชนะการประมูลโครงการจัดซื้อ Firewall และภาระตาม TOR ในการ “ส่งมอบฮาร์ดแวร์” ที่ไม่ได้มีการระบุใน TOR ว่าจะต้อง config อะไรบ้าง ซึ่งงานสำคัญที่ทั้งผู้ขายและแผนกไอทีเห็นพ้องต้องกันคือ ต้อง config Firewall นั้นให้ผู้ใช้ออกเน็ตได้และใช้แอพโรงพยาบาลได้ Firewall จึงมักจะถูกเซ็ตเอาไว้ด้วยใจบาง ๆ เพียงเท่านี้…..จริงมั้ย จะเปิดฟีเจอร์ให้เสี่ยงกับ Warning เยอะแยะทำไม ทำไปก็ไม่ได้ตังเพิ่ม
– ในอีกแบบ…สมมติว่า ผู้ขายไฟแรง เปิดฟีเจอร์เอาไว้ครบถ้วนเลย เยี่ยมมากจุ๊บจุ๊บ แต่ในไม่นานหลังจากเริ่มใช้ Firewall ผู้ใช้ก็แจ้งว่า “เฮ้ย ๆ เปิดเวบของกรมนั้นไม่ได้ เข้าเวบกระทรวงนี้ไม่ได้ ใช้แอพของกรมนั้นไม่ได้” แน่นอนว่าการแก้ปัญหาขั้นต้นคือการ Bypass ปลด Security บน Firewall ออก ก่อนที่ผู้ใช้จะโวยไปมากกว่านี้
จะมีโอกาสมากแค่ไหนที่คนเซ็ต Firewall จะมานั่งจ้ำจี้จ้ำไช มาคอยเตือนผู้ใช้ว่า มันอันตรายนะ คำเตือนของ Firewall มันไม่ใช่เรื่องเล่น ๆ นะ ถ้าติดต่อหน่วยงานต้นสังกัดดีมั้ย แจ้งไปว่า website ของเขามีปัญหาเรื่อง Security นะ หรือ App ของเขาไม่ปลอดภัยนะ
คนขายหรือผู้ให้บริการดูแล Firewall ที่เข้มแข็งในด้าน Security โดยไม่ย่อหย่อน จะคอยเตือนแผนกไอทีทุกครั้งที่มีคำเตือนจาก Firewall องค์กรต้องควานหาผู้ให้บริการดี ๆ แบบนี้มารับงานดูแล Firewall
รพ.สระบุรีได้ให้ความสำคัญในเรื่องของการจัดการ Firewall ร่วมกับผู้เชี่ยวชาญหรือเปล่า ซึ่งค่าบริการผู้เชี่ยวชาญ ที่จะมาจัดการ Firewall ให้สร้างความปลอดภัยอย่างต่อเนื่อง ตลอดปีหรือตลอดอายุงานของ Firewall เรื่องแบบนี้จะถูกเขียนใน TOR ด้วยหรือเปล่า เป็นเรื่องน่าคิด……
มี Firewall ไม่ได้แปลว่า ป้องกัน Ransomware ได้ และมี Firewall ก็ไม่ได้แปลว่า ป้องกันไม่ได้ มันสำคัญที่ คนที่นั่งอยู่หลัง Firewall ว่า เขาคือใคร รู้จักวิธีดึงความสามารถของ Firewall ออกมาสร้างความปลอดภัยให้องค์กรได้หรือเปล่า รพ.สระบุรีได้ตระหนักถึงตรงนี้หรือเปล่า
 

4. ถ้ายังเปิด Remote access แบบที่ไม่ใช่ VPN อยู่ ก็ปิดซะ ใช้ VPN เท่านั้น

ซอฟต์แวร์ของ รพ.ที่มีใช้อยู่ ก็มีอยู่ไม่กี่ค่ายหรอกครับ และไม่มีแผนกไอทีของ รพ.ไหนที่สามารถจะแก้ปัญหาซอฟต์แวร์ได้หมด ยังไงก็ต้องให้ทางคนทำซอฟต์แวร์เขา Remote มาให้บริการ
การเปิด Remote ให้บริษัทเข้ามาแก้เรื่องซอฟต์แวร์ เป็นสิ่งที่ตามมาติด ๆ ก็มีทั้งวิธีการเปิด Remote access แบบที่ปลอดภัย ก็คือต่อ VPN เข้ามาก่อน แล้วค่อย Remote access ใน VPN tunnel และ มีอีกแบบคือ “เปิดอ้าซ่า” ใครก็เข้าได้ ผู้ร้ายก็เข้าได้
 
แต่ช้าแต่ อย่าเพิ่งคิดไปไกล…….มาดูฝั่งบริษัทที่ขายซอฟต์แวร์ให้ รพ. ครับ
เขาให้บริการ รพ.หลายสิบแห่ง ถ้าเขาจะต้องต่อ VPN ไปที่นู่นที ที่นี่ที เขาก็รำคาญใข่มั้ยครับ บริษัทซอฟต์แวร์ก็มักจะเรียกร้องอะไรที่ง่าย ๆ คือขอให้ฝั่ง รพ.เปิด RDP Remote access แบบ อ้าซ่า จากอินเตอร์เน็ตก็ขอต่อตรงเข้าไปที่เซิร์ฟเวอร์เลย และถ้าเซิร์ฟเวอร์เป็น Linux ก็จะขอให้เปิด SSH ต่อตรงได้จากเน็ตเหมือนกัน ไม่ต้องเสียเวลาต่อ VPN ให้วุ่นวาย ส่วนฐานข้อมูลนั้นเหรอครับ ก็จะง่ายมาก แค่เปิด MySQL หรือ Postgres อ้าซ่าเอาไว้บนเน็ตอีกเหมือนกัน ทางบริษัทจะได้เข้าไปดูแลได้ง่าย ๆ
และโจรก็จะเข้าได้ง่าย ๆ ด้วย
** Ransomware แบบตรงเข้าไปที่ DB engine เลย อย่าคิดว่าไม่มีนะครับ ลองไปเซิร์ชดูก่อน มีถมไป
ในวงการ Security เราถือว่า การเปิด admin port เช่น RDP, SSH, Telnet, DB admin port, และ Backdoor อย่าง FTP ของ Web server ไม่แตกต่างจากการ นอนแก้ผ้ากลางสี่แยกอย่างสบายใจ แล้วคิดว่าตัวเองไม่โป๊ เพราะมีผ้าผูกตาผืนนึง มันแย่ขนาดนั้นเลยนะครับ
ผมจะบอกว่า หลาย ๆ บริษัทที่ให้บริการซอฟต์แวร์ของ รพ. ก็ขอให้แผนกไอทีของ รพ.เปิด Remote access แบบอ้าซ่าทั้งนั้นแหละ
ทางแผนกไอทีของ รพ.สระบุรี จะตั้งมั่นบนเงื่อนไขว่า “ต่อตรงไม่ได้โว้ย ต้องผ่าน VPN เข้ามาเท่านั้น” ชนกับบริษัทซอฟต์แวร์หรือเปล่า หรือว่าจะยอมผ่อนเงื่อนไข เปิดอ้าซ่าให้ทั้งบริษัทซอฟต์แวร์ “และโจร” เข้าถึงเซิร์ฟเวอร์และฐานข้อมูลได้โดยง่าย จนกระทั่งโจรสามารถเข้าถึงเซิร์ฟเวอร์ได้ และมาให้เกียรติมาฝัง Ransomware กับมือเลยหรือเปล่า……น่าคิด
 

5. งบน้อย คือที่มาของ Ransomware….เชื่อป่าว

พองบซื้อซอฟต์แวร์ไม่มี หรือไม่ได้รับอนุมัติ การดิ้นรนหาซอฟต์แวร์ฟรีมาใช้ก็เริ่มขึ้น ผู้ใช้ดิ้นเองบ้าง ไอทีช่วยดิ้นให้ก็มี ดิ้นรนกันไปในที่สุดก็หาโหลดซอฟต์แวร์ที่ต้องการมาได้สมใจ แถม Ransomware มาใช้งานด้วยพร้อมกัน ผมเคยเขียนบทความไปแล้วเรื่อง Too Good To Be True ไปหาอ่านดู อะไรได้มาง่าย ๆ มักลงท้ายกลายเป็นความสูญเสียอันใหญ่หลวง
แผนกไอทีกับฝ่ายบริหาร ต้องทำงานร่วมกัน คือฝ่ายบริหารต้องหัดพูดภาษาไอที (บ้าง) พยายามฟังให้เข้าใจ ไม่แตกต่างจากเครื่องมือวิศวกรรมอื่น ๆ เท่าไหร่ ในขณะที่ฝ่ายไอทีต้องมีมุมมองในเชิงการบริหาร เชิงงบประมาณ เข้าใจบัญชีและการเงินบ้าง และทำระบบไอทีให้เกิดคุณค่าทางธุรกิจ (Business Value) มากกว่าการตอบโจทย์แค่ประสิทธิภาพและราคา (Price/Performance) ถ้าสองฝ่าย ไม่สามารถคุยกันเป็นภาษาเดียวกันได้ ก็หาที่ปรึกษา ที่พูดทั้ง 2 ภาษาได้ มาเป็นคนแปลภาษาให้ครับ
สำหรับภาคเอกชน ผมไม่เชื่อเรื่องไม่มีงบ แต่ผมเข้าใจเรื่องไม่คุ้มจ่าย หรือการลงทุนที่อธิบายผลตอบแทนไม่ได้ ซึ่งพอแผนกไอทีไม่สามารถผูกการขอเสนอซื้อเข้ากับผลตอบแทนทางธุรกิจ โอกาสการได้รับอนุมัติก็เลยต่ำมาก
ส่วนภาครัฐ เรื่องการของบ มีเขียนทั้งในระเบียบและกฎหมายตามตำรา และปฏิบัติกันตามธรรมเนียมนอกตำรา ก็ดิ้นรนให้ได้งบกันไปครับ งบไม่มี ความปลอดภัยไม่เกิด Ransomware ก็จะมาเยือน สรุปง่าย ๆ แบบนี้
 

อ่านมาถึงตรงนี้เป็นอย่างไรกันบ้างครับ
อ่ะ................มาต่อกันดีกว่า อีก 2 ข้อติดตามอ่านต่อได้ด้านล่างครับ ****
แก้ไขข้อความเมื่อ

แสดงความคิดเห็น
Preview
โปรดศึกษาและยอมรับนโยบายข้อมูลส่วนบุคคลก่อนเริ่มใช้งาน อ่านเพิ่มเติมได้ที่นี่