ตัดการเชื่อมต่ออินเทอร์เน็ตเสีย
(computer.rip)- หลังเหตุการณ์ความปลอดภัยครั้งใหญ่แบบกรณี CrowdStrike มักมีเสียงตอบรับว่า “ไม่ควรเชื่อมต่อกับอินเทอร์เน็ตตั้งแต่แรก” แต่ระบบงานจำนวนมากมี การแลกเปลี่ยนข้อมูล เป็นฟังก์ชันหลัก จึงไม่สามารถแก้ปัญหาได้ด้วยการตัดการเชื่อมต่ออย่างง่ายๆ
- ระบบที่ข้ามขอบเขตขององค์กรและภูมิภาค เช่น ระบบจองและจัดตารางการบิน มีลักษณะใกล้เคียงกับ โครงสร้างพื้นฐานการสื่อสาร ที่มาแทนโทรศัพท์และโทรเลข การเอาเครือข่ายออกจึงทำให้คุณค่าเดิมของระบบหายไปด้วย
- คำว่า “ไม่เชื่อมต่อกับอินเทอร์เน็ต” อาจหมายรวมตั้งแต่อุปกรณ์เดี่ยว, air gap แบบเข้มงวด, data diode, private WAN, VPN tunnel, การ routing แบบจำกัด, ไปจนถึง AWS private VPC ทำให้ โมเดลภัยคุกคาม แตกต่างกันมาก
- ในสภาพแวดล้อมออฟไลน์หรือเชื่อมต่อแบบจำกัด ทั้งการอัปเดต OS, package manager, internal repository, TLS trust store, cloud license, การอัปเดตคอนเทนต์, ไปจนถึงการจัดการ Docker image ล้วนเพิ่มทั้ง เวลาและต้นทุน
- เราสามารถใช้ policy เครือข่ายแบบจำกัดกับระบบให้มากขึ้น และสร้างซอฟต์แวร์โดยคำนึงถึงการทำงานแบบออฟไลน์ได้ แต่ระบบนิเวศซอฟต์แวร์ในปัจจุบันก็ยังถือว่า การเชื่อมต่ออินเทอร์เน็ต เป็นค่าปริยาย
ข้อจำกัดของคำว่า “อย่าเชื่อมต่ออินเทอร์เน็ต”
- ทุกครั้งที่เหตุการณ์ความปลอดภัยขนาดใหญ่กลายเป็นข่าว ก็มักมีปฏิกิริยาซ้ำๆ ว่า “ระบบแบบนี้ไม่ควรเชื่อมต่อกับอินเทอร์เน็ต”
- มุมมองนี้มีเสน่ห์ในเชิงสัญชาตญาณทั้งด้านความปลอดภัยและเสถียรภาพ แต่ในความเป็นจริงกลับมีสภาพแวดล้อมที่เดินระบบแบบนั้นไม่มากนัก
- ปัญหาสำคัญคือคำว่า “ไม่เชื่อมต่อกับอินเทอร์เน็ต” เพียงอย่างเดียว ไม่เพียงพอที่จะระบุการออกแบบจริง ต้นทุนการปฏิบัติการ และโมเดลภัยคุกคามได้อย่างชัดเจน
ระบบงานสมัยใหม่ใกล้เคียงกับอุปกรณ์สื่อสาร
- ในเชิงนามธรรม คอมพิวเตอร์สามารถสร้างคุณค่าผ่านการคำนวณได้ แต่ระบบในภาคอุตสาหกรรมจริงมักมีลักษณะเป็น เทคโนโลยีสารสนเทศ มากกว่าการคำนวณ
- เทคโนโลยีสารสนเทศต้องรับและส่งข้อมูล และวิธีแบบในอดีตที่ให้ผู้ปฏิบัติงานใส่เทปเข้าไปนั้นแพงและช้ากว่าการสื่อสารแบบเรียลไทม์
- คอมพิวเตอร์สำหรับงานธุรกิจสมัยใหม่ส่วนใหญ่ทำหน้าที่เป็น อุปกรณ์สื่อสาร
- ระบบที่สร้างคุณค่าได้โดยไม่เชื่อมต่อกับระบบงานอื่นมีอยู่ไม่มาก
- การเชื่อมต่อเหล่านี้มักข้ามทั้งขอบเขตองค์กรและขอบเขตทางภูมิศาสตร์
- ระบบจองและจัดตารางการบินมีจุดเริ่มต้นจากระบบที่มาแทนโทรศัพท์และโทรเลข และเครือข่ายก็เป็นส่วนหนึ่งของฟังก์ชันโดยตรง
การบำรุงรักษาและการปฏิบัติการก็ต้องการเครือข่าย
- แม้ระบบที่การสื่อสารแบบเรียลไทม์ไม่ใช่สิ่งจำเป็นต่อเป้าหมายทางธุรกิจ การเชื่อมต่อเครือข่ายก็ยังมีคุณค่ามากในเชิงปฏิบัติการ
- หากไม่มีการเชื่อมต่ออินเทอร์เน็ต ก็จะติดขัดตั้งแต่เรื่องจะนำซอฟต์แวร์อัปเดตเข้ามาอย่างไร ไปจนถึงจะมอนิเตอร์ระบบอย่างไร
- ต่อให้กำหนดว่าระบบ “เสร็จสมบูรณ์” แล้วและไม่ต้องอัปเดตหรือมอนิเตอร์แบบเรียลไทม์ ความต้องการทางธุรกิจก็ยังเปลี่ยนไปตามกาลเวลา
- การเชื่อมต่อเครือข่ายช่วยลดต้นทุนในการรองรับการเปลี่ยนแปลงเหล่านี้ได้มาก
“ไม่เชื่อมต่ออินเทอร์เน็ต” มีหลายระดับ
- สถานะ “ไม่เชื่อมต่อกับอินเทอร์เน็ต” ไม่ได้มีความหมายเดียว แต่เป็นกลุ่มของวิธีติดตั้งใช้งานหลายแบบ
- รูปแบบที่เป็นไปได้กระจายกว้างตั้งแต่การตัดขาดโดยสมบูรณ์ไปจนถึงการเชื่อมต่อแบบจำกัด
- อุปกรณ์เดี่ยว ที่ไม่มีการเชื่อมต่อเครือข่ายเลย
- air gap แบบเข้มงวดที่ไม่มีการเชื่อมต่อใดนอกจาก private LAN และข้อมูลไม่ข้ามขอบเขตความปลอดภัย
- air gap ที่นำข้อมูลเข้าข้ามขอบเขตความปลอดภัยด้วย DVD-R
- โครงสร้างที่ย้ายข้อมูลจากเครือข่ายความปลอดภัยต่ำไปยังเครือข่ายความปลอดภัยสูงด้วย cross-domain solution หรือ data diode
- โครงสร้างที่ใช้ cross-domain solution ที่ไม่มีการรับรองจาก NSA
- แม้แต่เครือข่าย WAN ส่วนตัวก็ยังแบ่งได้หลายระดับ
- private WAN ที่มีโครงสร้างพื้นฐานทางกายภาพแยกขาดโดยสมบูรณ์และมีมาตรการป้องกันการงัดแงะ
- รูปแบบที่ใช้ท่อร้อยสายร่วมกัน, leased dark fiber, หรือ wavelength บน lit fiber
- virtual private ethernet ที่อิงกับ MPLS
- virtual private ethernet แบบอิง tunneling ที่มีการเข้ารหัสและการยืนยันตัวตน
- ทราฟฟิกส่วนตัวบนโครงข่ายสื่อสารสาธารณะก็มีบางกรณีที่ถูกเรียกว่า “ไม่เชื่อมต่อ” เช่นกัน
- รูปแบบที่อุปกรณ์ฮาร์ดแวร์สร้าง tunnel แบบเข้ารหัสและยืนยันตัวตนบน common-carrier network อย่างอินเทอร์เน็ต
- รูปแบบที่ใช้อุปกรณ์ที่ไม่มีการรับรองจาก NSA
- software tunnel ที่ผ่านการตรวจสอบแล้ว โดยตั้งค่า network stack ของระบบปฏิบัติการในระดับต่ำเพื่อป้องกันการเลี่ยง tunnel
- software tunnel ที่มีระดับการตรวจสอบต่ำกว่า
- รูปแบบที่ผสม WireGuard กับสคริปต์ iptables
- แม้แต่การเชื่อมต่ออินเทอร์เน็ตแบบจำกัดก็ถูกรวมอยู่ในคำเดียวกัน
- private network ที่อนุญาตเฉพาะ flow ทราฟฟิกที่แคบมากผ่าน policy-based routing เป็นต้น
- โครงสร้างที่ flow ที่อนุญาตถูกทิ้งไว้ใน Jira ticket เก่า และบางรายการถูกเพิ่มเข้าไปเพียงเพื่อ “ให้มันทำงานได้”
- โครงสร้างที่อิง firewall โดยค่อนข้างผ่อนปรน outbound แต่เข้มงวดกับ inbound
- ในคลาวด์เอง ขอบเขตก็ยังไม่นิ่ง
- AWS private VPC ที่ไม่มีการ routing ออกภายนอก
- VPC ที่สื่อสารกับ private VPC อื่นผ่าน PrivateLink เป็นต้น
- โครงสร้างที่ VPC บางส่วนที่เชื่อมต่อกันมีการ routing ออกสู่อินเทอร์เน็ต
- โครงสร้างที่มีทั้ง NAT Gateway และ Internet Gateway แต่ตั้ง security group แบบเข้มงวดทั้งขาเข้าและขาออก
- รูปแบบทั้งหมดนี้เคยถูกเรียกรวมว่า “ไม่เชื่อมต่อกับอินเทอร์เน็ต” แต่พื้นผิวการโจมตีและความเสี่ยงของแต่ละแบบแตกต่างกัน
- เมื่อมีคนบอกว่าระบบจองการบิน “ไม่ควรเชื่อมต่อกับอินเทอร์เน็ต” หากไม่ได้หมายถึงสภาวะไม่มีเครือข่ายเลยจริงๆ ก็แปลว่าแท้จริงแล้วกำลังหมายถึงหนึ่งในระดับกลางเหล่านี้ และแต่ละระดับก็มีข้อพิจารณาเชิงปฏิบัติที่ต่างกัน
สภาพแวดล้อมออฟไลน์เพิ่มต้นทุนและระยะเวลาอย่างมาก
- การรันซอฟต์แวร์บนเครือข่ายที่ไม่มีอินเทอร์เน็ตหรือจำกัดอย่างมาก ทำให้การประเมินเวลาและต้นทุนพุ่งสูงขึ้นมาก
- แบบอ่อนอย่าง AWS private VPC อาจประเมินไว้ราว 3–5 เท่า
- แบบเข้มที่ใกล้เคียงการตัดขาดโดยสมบูรณ์อาจสูงถึง 10 เท่าหรือมากกว่านั้นมาก
- ระบบนิเวศซอฟต์แวร์แทบทั้งหมดถูกออกแบบโดยตั้งสมมติฐานว่า มีการเชื่อมต่ออินเทอร์เน็ต
- ระบบปฏิบัติการพยายามดึงอัปเดตจากเซิร์ฟเวอร์ออนไลน์
- ผู้ขาย OS เชิงพาณิชย์อาจมีโครงสร้างพื้นฐานอัปเดตภายในเครือข่ายส่วนตัวให้ แต่คิดค่าไลเซนส์แยก
- OS ฟรีอาจแก้เองได้ แต่ถ้าใช้เทคโนโลยีใหม่ก็อาจเกิดความยุ่งยากมาก
- ในกระบวนการพัฒนาและดีพลอย ปัญหาเรื่อง package manager และ internal repository หลายตัวจะเกิดซ้ำๆ
- package manager แต่ละตัวรองรับ internal repository ส่วนตัวไม่เท่ากัน
- เมื่อ package manager หลายตัว วิธีเรียกใช้งาน และสภาพแวดล้อมรันถูกนำมาผสมกัน ความซับซ้อนก็เพิ่มขึ้น
- ใบรับรอง TLS ของบริการภายในก็สร้างงานที่ต้องทำซ้ำเช่นกัน
- บริการภายในเครือข่ายส่วนตัวมักไม่ใช้ใบรับรองที่อยู่ใน root program ของ CA สาธารณะ
- มีองค์ประกอบอย่าง JRE ที่มี trust store แยกต่างหาก และในบาง technology stack พฤติกรรมก็เปลี่ยนไปตามไลบรารีที่ใช้
- ต่อให้ระบบปฏิบัติการมี trust store อยู่แล้ว หากเครื่องมือแต่ละตัวใช้ที่เก็บของตัวเอง ก็ยังต้องปรับแยกเพิ่มเติม
- การตรวจสอบ cloud license และ entitlement ก็เป็นอุปสรรคอีกอย่าง
- ซอฟต์แวร์บางตัวพยายามออกไปเชื่อมต่อภายนอกเพื่อตรวจสอบ cloud license
- วิธีแก้มีตั้งแต่การเพิ่มข้อยกเว้น firewall จำนวนมาก ไปจนถึงการออกระบบไลเซนส์แบบกำหนดเอง ซึ่งอาจใช้เวลานาน
- การอัปเดตคอนเทนต์แบบออฟไลน์อาจซับซ้อนเพียงเพราะกระบวนการของผู้ขาย
- ในกรณีของซอฟต์แวร์องค์กรรายหนึ่ง ต้องผ่านทั้ง customer support portal แบบเก่าและ entitlement portal แยกต่างหาก
- ใช้เวลากว่า 3 เดือนในการเปิดบัญชีและไต่ระดับเรื่อง และพอร์ทัลสุดท้ายยังมีใบรับรอง TLS ที่ไม่ถูกต้อง
- ขั้นตอนอัปเดตที่มีเอกสารไว้ไม่สามารถใช้งานได้อีกต่อไป จนต้องมีการโต้ตอบอีเมลยาวๆ กับวิศวกร
- จ่ายเงินระดับ 5 หลักสำหรับไลเซนส์ 1 ปี แต่กว่าจะพร้อมใช้งานก็ใกล้หมดอายุ และความล่าช้าในการออกไลเซนส์ต่ออายุยังทำให้ CI pipeline หยุดชะงัก
- ความยากของการปฏิบัติการแบบออฟไลน์ไม่ได้อยู่ที่มีงานใดงานหนึ่งทำไม่ได้โดยสิ้นเชิง แต่อยู่ที่ทุกงานยากขึ้นทีละนิด จนใกล้เคียงกับ death by a thousand cuts
- ผลิตภัณฑ์ที่ไม่ได้คำนึงถึงสภาพแวดล้อมออฟไลน์มักต้องรับมือด้วยสคริปต์ชั่วคราวและการปะผุ และหนี้ทางเทคนิคนั้นก็มักตกไปอยู่กับลูกค้าที่ต้องเดินระบบออฟไลน์
- Red Hat รับมือกับพื้นที่นี้ได้ค่อนข้างดี แต่เวลาที่ประหยัดได้ก็มักต้องจ่ายคืนเป็นต้นทุนจริง
สภาพแวดล้อมแบบนี้พบไม่บ่อยและกระจุกตัวในบางอุตสาหกรรม
- สภาพแวดล้อมแบบไม่เชื่อมต่ออินเทอร์เน็ตชนิดเข้มมักพบใน กลาโหมและหน่วยข่าวกรอง
- ธนาคารบางแห่งก็มีแนวปฏิบัติเรื่องการแยกเครือข่ายที่เข้มงวดเช่นกัน
- กลาโหม หน่วยข่าวกรอง และธนาคาร ยังเป็นอุตสาหกรรมที่ขึ้นชื่อว่าต้นทุนสูงและใช้เวลานาน ซึ่งก็ไม่ใช่เรื่องที่ไม่เกี่ยวข้องกับวิธีปฏิบัติการแบบนี้
- สภาพแวดล้อมเชื่อมต่อแบบจำกัดชนิดอ่อนมักพบใน อุตสาหกรรมที่มีการกำกับดูแลสูง เช่น การเงินและการแพทย์
- บางครั้งก็มีบริษัทซอฟต์แวร์ทั่วไปที่ให้ความสำคัญกับความปลอดภัยอย่างมากจนล็อกเครือข่ายแน่นมากเช่นกัน
แนวทางปฏิบัติที่ทำได้ตอนนี้
- การมุ่งไปสู่ทิศทางที่มีระบบเชื่อมต่ออินเทอร์เน็ตน้อยลง ไม่ใช่ความคิดที่แย่ในตัวเอง
- แต่ต้องยอมรับว่าอุตสาหกรรมซอฟต์แวร์ปัจจุบันยังไม่ได้เตรียมพร้อมให้ใช้งานได้สะดวกในสภาพแวดล้อมที่ไม่มีหรือมีการเชื่อมต่อจำกัด
- แนวทางที่เป็นจริงจึงใกล้เคียงกับการเพิ่มการเชื่อมต่อแบบจำกัดและความพร้อมสำหรับออฟไลน์ มากกว่าการเรียกร้องให้ตัดขาดโดยสมบูรณ์
-
จำกัด policy เครือข่ายให้มากที่สุด
- ควรใช้ policy เครือข่ายแบบจำกัด กับระบบให้ได้มากที่สุด
- ผู้ให้บริการคลาวด์ทำให้การสร้างโครงสร้างแบบนี้ง่ายขึ้นกว่าสมัยก่อน
- ใน AWS การเดินระบบในสภาพแวดล้อม routing แบบไม่ออกสู่อินเทอร์เน็ตที่ใช้งานได้จริงอาจไม่ถึงกับง่ายมาก แต่ก็ไม่ได้ยากจนเป็นไปไม่ได้
- หากอยู่ภายในขอบเขตของ AWS managed service โดยรวมแล้วมักเจ็บตัวน้อยกว่า แต่ก็ต้องจ่ายต้นทุน
-
สร้างซอฟต์แวร์โดยคำนึงถึงสภาพแวดล้อมออฟไลน์
- ฟังก์ชันที่ต้องเชื่อมต่อออกภายนอกควรถูกปิดใช้งานได้ถ้าเป็นไปได้
- หากปิดใช้งานได้ยาก อย่างน้อยลูกค้าควรเปลี่ยน endpoint ที่ใช้ได้
- หากเปิดให้เปลี่ยน endpoint ได้ ก็ต้องมีวิธีให้ลูกค้าสามารถรัน endpoint ของตัวเองได้ด้วย
- ถ้าเป็นเพียงไฟล์สแตติก ก็อาจให้บริการได้ง่ายด้วย nginx และไดเรกทอรี
- หากเป็น API ก็อาจต้องแจกจ่าย implementation ภายในให้ลูกค้า และเกิดภาระการบำรุงรักษาตามมา
-
ลดสมมติฐานเรื่อง TLS และ dependency
- ในสภาพแวดล้อมออฟไลน์ สมมติฐานเล็กๆ ว่าสามารถเชื่อมต่อกับบริการอื่นได้จะกลายเป็นเรื่องซับซ้อน
- ไม่ควรสมมติว่าสามารถเข้าถึง Let’s Encrypt ได้
- สภาพแวดล้อมออฟไลน์แทบจะมาพร้อมหน่วยรับรองภายในเสมอ
- ควรใช้ system trust store
- ไม่ควรดึง requirement หรือ dependency เข้ามาในตอนดีพลอย
- Docker เคยมีข้อดีด้านการทำให้แพ็กเกจเป็นแบบ self-contained แต่ก็มีคอนเทนเนอร์ที่เริ่มทำงานไม่ได้หากเข้าถึง npm repository เป็นต้นไม่ได้
- บางครั้งต้องแก้ TLS trust store แยกในแต่ละ Docker container ทำให้ในสภาพแวดล้อมออฟไลน์ Docker อาจทำให้การจัดการยากขึ้นเสียอีก
ความสัมพันธ์ระหว่างเหตุการณ์ CrowdStrike กับการเชื่อมต่ออินเทอร์เน็ต
- แม้จะมีเสียงถามซ้ำๆ หลังเหตุการณ์ CrowdStrike ว่า “ทำไมถึงเชื่อมต่อกับอินเทอร์เน็ต” แต่การมีหรือไม่มีอินเทอร์เน็ตแทบตั้งฉากกับปัญหาที่เกิดขึ้นในครั้งนั้น
- การอัปเดตคอนเทนต์ของ CrowdStrike เป็นการอัปเดตประเภทที่ในสภาพแวดล้อมอุดมคติควรถูกส่งถึงสภาพแวดล้อมออฟไลน์ได้อย่างรวดเร็วเช่นกัน
- ในสภาพแวดล้อมออฟไลน์แบบเข้มจริงๆ internal mirror สำหรับอัปเดต CrowdStrike อาจตามหลังอยู่เป็นวัน เป็นสัปดาห์ เป็นเดือน หรือเป็นปี
- ความล่าช้าเช่นนั้นอาจทำให้หลีกเลี่ยงปัญหาได้ แต่ก็ใกล้เคียงกับสถานการณ์ที่ความผิดพลาดสองอย่างมาทับซ้อนกันโดยบังเอิญมากกว่า
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ผมทำงานด้านความปลอดภัย/ระบบ/ปฏิบัติการ แต่โดยพื้นฐานแล้วไม่เห็นด้วยกับสมมติฐานนี้ เข้าใจและเห็นด้วยเต็มที่ที่ผู้เขียนบอกว่า “มันไม่ได้ง่ายขนาดนั้น” แต่ไม่ได้แปลว่านั่นคือการทำงานได้ดี
น่าเสียดายที่คนส่วนใหญ่ทำงานได้ไม่ดี และทั้งอุตสาหกรรมถูกออกแบบมาให้ทนอยู่ได้แม้ทำงานไม่ดี แต่กลับทำให้งานที่ดีทำได้ยาก
ถ้าจะ deploy digital signage การเข้าถึงเครือข่ายควรถูกทำเป็น allowlist ให้เฉพาะที่อยู่ IP ของเซิร์ฟเวอร์ผมเท่านั้น และควรรับเฉพาะการเชื่อมต่อที่ทำผ่าน signed updates กับ certificate pinning เท่านั้น
แบบนี้จะทำให้ผู้โจมตีระยะไกลแทบแตะต้องไม่ได้ เมื่อดูอุตสาหกรรมความปลอดภัยที่โตขึ้นจากการแพร่หลายของ Internet of Things (IoT) ก็ชัดเจนว่ามี signage หรืออุปกรณ์ IoT/SCADA/อุปกรณ์ deploy อื่น ๆ ที่ยังเปิดพอร์ตทิ้งไว้และใช้รหัสผ่านเริ่มต้นอยู่
IoT ก็เป็นแค่คอมพิวเตอร์ แต่ก็เป็นคอมพิวเตอร์ที่ถูกปล่อยทิ้งมากกว่าเซิร์ฟเวอร์หรือ virtual machine ที่เราก็บริหารจัดการกันไม่ดีอยู่แล้ว
มีบางที่ที่ทำได้ดี แต่มีน้อยมาก เพราะโครงสร้างไม่ได้ให้รางวัลกับการทำให้ดี การทำตาม “best practices” หรือคำแนะนำของ vendor ไม่ได้แปลว่าทำได้ดี แต่มักแปลว่าแค่ทำถึงระดับที่ vendor จะช่วย support ให้ และในหลายกรณีก็หมายถึงการเข้าถึงเครือข่ายแบบไม่จำกัด
คุณยังต้องกังวลเรื่องบั๊กของเครือข่าย ช่องโหว่ของ crypto การตั้งค่าผิดพลาด และปัญหาอื่น ๆ ที่ผู้โจมตีระยะไกลอาจใช้โจมตีระบบได้ ถ้าจะยืนยันประเด็นนี้ ต้องยกตัวอย่างที่ไม่ได้เชื่อมต่ออินเทอร์เน็ตจริง ๆ ไม่ใช่แค่ตัวอย่างที่ล็อกแน่นขึ้น
ผมไม่ค่อยเห็นว่าคุณเห็นต่างจากผู้เขียนบล็อกตรงไหน หรือหมายความว่าโดยพื้นฐานแล้วเป็นไปไม่ได้ที่จะปรับปรุงความปลอดภัยของระบบที่เชื่อมต่ออินเทอร์เน็ต เพราะคนไม่มีความสามารถพอ?
ในสวีเดนมีเครือข่ายส่วนตัว Sjunet ที่แยกจากอินเทอร์เน็ต และผู้ให้บริการด้านสาธารณสุขใช้งาน จุดประสงค์คือทำให้คอมพิวเตอร์เป็นอุปกรณ์สื่อสารที่มีคุณค่า แต่ไม่เปิด IT ของโรงพยาบาลออกสู่ทั้งอินเทอร์เน็ต
คาดหวังว่าสมาชิก Sjunet ต้องรู้จักเครือข่ายของตนเองและควบคุม IT อย่างเข้มงวด
อาจมอง Sjunet เป็นสภาพแวดล้อมแบบ air gap ระดับอุตสาหกรรมก็ได้ ผมมองว่ามันช่วยปรับปรุงความปลอดภัย และมีต้นทุนน้อยกว่าการที่แต่ละองค์กรต้องดูแลเครือข่าย air gap ของตัวเองพร้อม allowlist ขนาดมหึมา
มันให้ความอุ่นใจปลอม ๆ และยังกลายเป็นข้ออ้างของนโยบายความปลอดภัยที่แย่ แบนด์วิดท์ก็ต่ำและแพง
เป็นเครือข่ายที่เชื่อมหน่วยงานอย่างสำนักงานเขตและศาลากลาง เพื่อให้เข้าถึงฐานข้อมูลกลางที่เก็บข้อมูลส่วนบุคคลของประชาชน ใช้กับงานอย่างการเปลี่ยนที่อยู่ ออกบัตรประจำตัวใหม่ การจดทะเบียนเกิดและสมรส
เท่าที่ทราบ แอป “Źródło” ทำงานบนคอมพิวเตอร์ “air gap” แยกต่างหาก ไม่มีอินเทอร์เน็ต แต่เข้าถึงเครือข่ายภายในได้ และยืนยันตัวตนด้วย ใบรับรองไคลเอนต์เชิงเข้ารหัส ผ่าน smart card
ทุกเครื่องติดตั้งแพตช์ล่าสุดแล้วหรือยัง? รู้ได้อย่างไรว่าผู้คนจะไม่เสียบอุปกรณ์ USB อะไรก็ได้เข้าไป?
อยากให้คล้าย Tor แต่ไม่มีของน่าสงสัยพวกนั้น
ในฐานะวิศวกรควบคุม เคยสร้างเครื่องจักรมาหลายร้อยเครื่อง มีสาย Ethernet สำหรับเครือข่าย fieldbus แต่ห้ามเชื่อมต่ออินเทอร์เน็ตโดยเด็ดขาด
ในเวิร์กช็อปเครื่องมือและแม่พิมพ์ทุกแห่งในนิคมอุตสาหกรรมแถวบ้าน มีเครื่อง CNC ที่มีพอร์ต Ethernet ซึ่งไม่ควรถูกนำขึ้นอินเทอร์เน็ต โรงงานผลิตทุกแห่งที่มีอุปกรณ์สั่งทำพิเศษ สายพานลำเลียง เครื่องปั๊ม หุ่นยนต์ CNC สถานีปั๊ม ฯลฯ ล้วนใช้ Ethernet แต่ก็ใช้ระบบ PLC และ HMI ที่ไม่เหมาะกับการเปิดให้เข้าถึงจากอินเทอร์เน็ต
บทความบอกว่าคอมพิวเตอร์สำหรับงานสมัยใหม่แทบจะเป็นอุปกรณ์สื่อสารเป็นหลัก และมีระบบปฏิบัติงานจริงไม่มากนักที่สร้างคุณค่าโดยไม่เชื่อมกับระบบงานอื่น แต่กำลังมองข้ามภาคการผลิตทั้งหมด รวมถึงอุปกรณ์อิเล็กทรอนิกส์ที่ภาคการผลิตนั้นสร้างขึ้น
ระบบฝังตัวและ PLC หลายล้านตัวตรวจสอบทุก ๆ 1 มิลลิวินาทีว่าสถานะอินพุตดิจิทัลทั้งทางกายภาพและเชิงตรรกะเปลี่ยนไปหรือไม่ และถ้าเปลี่ยน ก็จะเปลี่ยนสถานะเอาต์พุตดิจิทัลทั้งทางกายภาพและเชิงตรรกะไปพร้อมกัน สร้างคุณค่าตลอดทั้งวัน
ไม่มีความจำเป็นต้องใส่ระบบความปลอดภัยรุ่นปี 2024 ลงในเครื่องเชื่อมความต้านทานที่โครงหล่อทำขึ้นเมื่อกว่า 100 ปีก่อน และอัปเดตครั้งล่าสุดเมื่อปี 2003 ด้วยการติด PLC สำหรับตั้งค่าสูตรกับจอขาวดำ แค่ถือคลิปบอร์ดเดินไป ป้อนค่าเป้าหมาย แล้วหลอมเหล็กให้แม่นยำก็พอ
โดยปกติถ้าจะเชื่อมต่อกับเครื่องพวกนี้ ต้องถือแล็ปท็อปกับสาย Ethernet patch เดินไปหน้าเครื่องเอง ถ้าต้องการมากกว่านั้น ก็จะคาดหวังให้ลูกค้าเอาไปไว้ในเครือข่ายเทคโนโลยีปฏิบัติการ (OT) ที่มีไฟร์วอลล์ หรือเชื่อมระหว่างเทคโนโลยีสารสนเทศ (IT) กับ OT ด้วยอุปกรณ์ SCADA/VPN อย่าง Tosibox, Ixon
สิ่งที่คุณดูแลอยู่อาจไม่ใช่เป้าหมายที่ใครอยากนำไปใช้ในทางที่ผิด แต่ PLC พบได้บ่อยในโครงสร้างพื้นฐานสำคัญและโรงงานผลิตขั้นสูง จึงเป็นเป้าหมายที่น่าดึงดูดสำหรับผู้ไม่หวังดี พวกเขาอาจพยายามโจมตีโครงสร้างพื้นฐานสำคัญ หรือสักวันหนึ่งอาจพยายามติดมัลแวร์ให้อุปกรณ์ที่ความปลอดภัยหละหลวม ซึ่งปลายทางมูลค่าสูงอย่างแล็ปท็อปวิศวกรอาจเชื่อมต่อโดยตรงได้
https://www.cisa.gov/news-events/cybersecurity-advisories/aa... - Water Infra
https://claroty.com/team82/research/evil-plc-attack-using-a-...
ผมยังไม่เห็นด้วยกับข้ออ้างที่ว่าไม่ควรทำระบบให้เป็น air gap เพราะจะใช้แนวปฏิบัติการพัฒนาที่เน้นอินเทอร์เน็ตเป็นศูนย์กลางไม่ได้ ผมว่าข้ออ้างนี้ไร้เหตุผล
ถ้าเป็นระบบที่ถึงขั้นต้องเอาอีพ็อกซีอุดพอร์ต Ethernet ไว้ ตั้งแต่แรกก็ไม่ควรถูกเขียนโปรแกรมด้วย แนวปฏิบัติการพัฒนาที่เน้นอินเทอร์เน็ตเป็นศูนย์กลาง อยู่แล้ว เครื่อง MRI ดึง dependency ของ JS จาก NPM ตอนบูตงั้นหรือ? เข้าคุกทันที ไม่ใช่เปรียบเทียบนะ แต่ควรเป็นจริง ๆ
หลังจากดูวิดีโอคนไปกดตู้คีออสก์ของ McDonald’s ผมก็เริ่มลองทำแบบเดียวกันกับอุปกรณ์ที่เห็นตามที่ต่าง ๆ
ในฟู้ดคอร์ตแห่งหนึ่งมีคีออสก์ที่ลง Windows และเข้าถึงอินเทอร์เน็ตได้เต็มรูปแบบ ใครสักคนสามารถดาวน์โหลดมัลแวร์มาขโมยข้อมูลบัตรเครดิตได้เลย ทุกครั้งที่ใช้ ผมจะปิดเครื่องหรือทิ้งข้อความไว้บนหน้าจอ สุดท้ายพวกเขาก็เริ่มเปิดโหมดคีออสก์
อีกเครื่องเป็นคีออสก์ที่จอดรถ ซึ่งไม่ได้ถูก harden เลย ดูเหมือนอาชญากรยังไม่รู้ตัว
เครื่องที่สามเป็นจออินเทอร์แอกทีฟของแบรนด์เบียร์ ไม่ใช่ของที่จะก่อความเสียหายใหญ่โต แต่การเปิด Notepad แล้วทิ้งข้อความว่า “Drink water” ไว้ก็ดี สุดท้ายพวกเขาปิดมันทิ้ง ซึ่งก็เป็นทางแก้อย่างหนึ่ง
“อย่าแจกเงินให้คนเดินผ่านแบบสุ่ม” น่าจะอยู่ค่อนข้างสูงในรายการข้อกำหนด แต่ความจริงกลับไม่ใช่
ส่วนนี้เห็นด้วยจริง ๆ เคยพยายามทำให้ trust store ของ JRE ใน IntelliJ เข้าใจว่าต้องใช้ใบรับรองใหม่สำหรับ zscaler มี JDK ให้เลือกสองสามตัว และผมก็ใส่ใบรับรองใหม่เข้าไปใน trust store ของแต่ละตัวแล้ว แต่ก็ยังไม่ทำงาน และไม่รู้ด้วยว่าทำไม
ยังมี hamnet ด้วย บนบล็อก IP ของ 44Net บางส่วน route ออกอินเทอร์เน็ตได้ บางส่วนไม่ได้
https://hamnetdb.net/map.cgi
เพราะใช้ย่านความถี่วิทยุสมัครเล่น จึงมีข้อจำกัดที่น่าสนใจ ห้ามใช้เชิงพาณิชย์โดยสิ้นเชิง
นั่นคือสัญญาทางสังคมของย่านความถี่เหล่านั้น ทำให้เข้าถึงย่านจำนวนมากตั้งแต่ 136kHz ถึง 241GHz ได้ในราคาถูก แต่หาเงินจากมันไม่ได้
มีแพร่หลายพอสมควรแค่ในเนเธอร์แลนด์กับเยอรมนี: https://hamnetdb.net/map.cgi . ที่สเปน ไม่มีที่ไหนใกล้ผมที่ใช้ได้เลย
ดูค่อนข้างชัดเจนว่าระบบจองของสายการบินอย่างน้อยก็ต้องเชื่อมต่อเครือข่าย และผมไม่ค่อยได้ยินใครอ้างว่าทุกอย่างควรออฟไลน์ทั้งหมด แต่ก็ได้ยินตัวอย่างว่าเครื่องกลึงในเวิร์กช็อปหยุดทำงานเพราะเหตุการณ์นี้
ต้องลองคิดดูว่ามันจำเป็นต้องออนไลน์จริง ๆ หรือไม่ แน่นอนว่าคงมีเหตุผล แต่เหตุผลนั้นต้องชั่งน้ำหนักเทียบกับความเสี่ยง
นอกจากนี้ยังมีตัวอย่างที่น่าขันกว่านั้นอีกมาก เช่น ตู้เย็น กาต้มน้ำ ประตูโรงรถที่เชื่อมอินเทอร์เน็ต ผมไม่รู้ว่าสิ่งเหล่านี้ได้รับผลกระทบจากเหตุการณ์ CrowdStrike หรือไม่ แต่ถึงไม่ใช่ ครั้งหน้าก็เป็นแค่เรื่องของเวลา
สำหรับข้ออ้างว่าระบบที่ไม่ได้เชื่อมต่อนั้น “น่ารำคาญมาก ๆ” จากประสบการณ์ในฐานะผู้ใช้ ความปลอดภัยทุกอย่างก็ “น่ารำคาญมาก ๆ” ทั้งนั้น ทั้งการยืนยันตัวตนสองขั้นตอน การบังคับเปลี่ยนรหัสผ่าน อุปกรณ์ที่ถูกล็อก ตัวสแกนมัลแวร์ ไปจนถึงตัวทำความสะอาดลิงก์ บางอย่างจำเป็น บางอย่างก็ไร้สาระ แต่ผมไม่มีคุณสมบัติพอจะแยกว่าอะไรเป็นอะไร และที่แน่ ๆ คือทั้งหมดสร้าง แรงเสียดทาน
ข้อสรุปใหญ่ที่ผมได้ไม่ใช่ “ระบบทั้งหมดนี้ไม่ควรเชื่อมต่อกับอินเทอร์เน็ต” แต่เป็นประเด็นอื่น ๆ อีกไม่กี่ข้อ
ข้อแรก ระบบแบบนี้ไม่ควรอนุญาตให้มี ทราฟฟิกเครือข่ายขาออก แบบนั้นจะทำให้การอัปเดตอัตโนมัติทั้งหมดถูกบล็อก และหลังจากนั้นก็จัดการผ่านช่องทางกระจายภายในได้
ข้อที่สอง ถึงจะไม่ทำแบบนั้น ซอฟต์แวร์สำหรับองค์กรหลายตัวก็สามารถปิดการอัปเดตอัตโนมัติได้ Windows เป็นตัวอย่างที่ชัดเจน และ CrowdStrike เองก็เช่นกัน ได้ยินมาว่าในบรรดาลูกค้า CS มีบางรายที่ปิดการอัปเดตอัตโนมัติแล้วกระจายแบบแมนนวล จึงหลีกเลี่ยงความเสียหายได้
ข้อที่สาม ต่อจากข้อ 2 ควรค่อย ๆ ปล่อยอัปเดตที่ผ่านการทดสอบแบบสโมกเทสต์เล็กน้อยแล้ว เผื่อไว้ก่อน ได้ยินมาเช่นกันว่าในบรรดาลูกค้า CS มีบางรายที่ใช้การทยอยปล่อย ทำให้จำกัดผลกระทบไว้ได้แค่บางเครื่อง
เป็นบทความที่สรุปช่วงที่เคยส่งมอบโซลูชัน AI ล้ำสมัยให้ลูกค้าทางทหารได้ค่อนข้างดี 80% ของความพยายามหมดไปกับการทำให้ เครื่องมือที่ตั้งสมมติฐานว่ามีอินเทอร์เน็ต ทำงานได้อย่างราบรื่นในสภาพแวดล้อมแบบ air-gap