สี่การตั้งค่า firewall ที่ผิดพลาดซึ่งเปิดทางให้ผู้ไม่ประสงค์ดีเข้าถึงระบบ

ตอนที่ Jody Brazil ก่อตั้ง FireMon ขึ้นมาครั้งแรก เหตุผลคือความจำเป็นในการบันทึกการเปลี่ยนแปลง firewall policy เพื่อป้องกันการเข้าถึงที่ไม่ได้ตั้งใจ ผ่านมากว่ายี่สิบปี ปัญหาการตั้งค่า firewall ที่ผิดพลาดซึ่งมีต้นเหตุจาก policy แบบเดิม ๆ ก็ยังคงพบได้ทั่วไป โดยเฉพาะเมื่อ cybersecurity posture ในปัจจุบันซับซ้อนขึ้นเรื่อย ๆ และบางครั้งก็อ่อนแอ

“ไม่ว่า firewall จะเป็นต้นเหตุของปัญหาหรือไม่ก็ตาม เมื่อเกิดเหตุระบบล่ม firewall มักถูกชี้นิ้วก่อนเสมอ” Tim Woods ตำแหน่ง VP of Technology Alliances ของ FireMon กล่าว และเมื่อ firewall เป็นต้นเหตุจริง สาเหตุส่วนใหญ่คือการตั้งค่า firewall ที่ผิดพลาดจนเปิดช่องให้ผู้โจมตีเข้าถึงระบบโดยไม่ได้ตั้งใจ

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

หลายครั้งกฎถูกปลดข้อจำกัดหรือ “เปิดกว้าง” ไว้ชั่วคราว เพื่อให้เข้าถึงได้ตามความจำเป็นทางธุรกิจที่ยอมรับได้ เช่น การ deploy แอปพลิเคชันใหม่ให้พนักงานใช้งาน ผู้ดูแลระบบอาจผ่อนข้อจำกัดของ firewall เพื่อให้สิทธิ์แก่แอปพลิเคชันนั้น

“เจตนาจริง ๆ คือจะกลับมาปรับกฎนั้นให้รัดกุมในภายหลัง” Woods กล่าว “แต่ปัญหาคือ มีงานสำคัญอีก 15 เรื่องโผล่เข้ามา และไม่มีใครย้อนกลับไปแก้กฎนั้น”

ทุกอย่างดูเหมือนทำงานได้ปกติ แต่ผู้ดูแลระบบได้ทิ้งช่องโหว่ไว้ให้ผู้ไม่ประสงค์ดีใช้โจมตี

สี่การตั้งค่า firewall ที่ผิดพลาดซึ่งพบบ่อย

Woods ได้อธิบายเพิ่มเติมถึงการตั้งค่า firewall ที่ผิดพลาดสี่รูปแบบ ซึ่งนำไปสู่สภาพแวดล้อมที่เปิดกว้างเกินความจำเป็น

1. การปลดระวางฮาร์ดแวร์

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

2. กฎที่ซ้ำซ้อน

กฎที่ซ้ำซ้อนคือกฎที่ทำซ้ำเส้นทางการเข้าถึงเชิงตรรกะที่มีอยู่แล้ว ซึ่งไม่ได้ก่อปัญหาร้ายแรงในทันที แต่เมื่อเวลาผ่านไปและกฎซ้ำซ้อนสะสมมากขึ้น ก็จะเพิ่มความซับซ้อนที่ไม่จำเป็นให้กับ security enforcement policy

3. Shadowed firewall rules

Shadowed rule คล้ายกับกฎที่ซ้ำซ้อน แต่ให้ผลลัพธ์ตรงกันข้าม กล่าวคือ มีกฎหนึ่งอนุญาตการเข้าถึง ขณะที่อีกกฎหนึ่งปฏิเสธการเข้าถึง ผู้ดูแล firewall ที่ตรวจสอบ security policy ด้วยตนเองอาจตีความพฤติกรรมที่แท้จริงของ policy ผิดไป เพราะเห็นกฎ deny แต่มองข้ามกฎ allow ที่อยู่เหนือขึ้นไป ทำให้กฎที่ถูก “บดบัง” ไม่เคยถูกสังเกตเห็น

“นั่นคือความผิดพลาดเชิงเทคนิค” Woods กล่าว “คุณจะได้กฎที่ซ้อนทับกัน หรือกฎที่ไปค้างอยู่ล่างสุด” ผู้ดูแลระบบอาจไม่รู้ว่าควรวางกฎนั้นไว้ตรงไหนใน policy จึงวางไว้ล่างสุดเป็นค่าเริ่มต้น Woods กล่าว โดยไม่ทราบว่ามีกฎที่คล้ายกันหรือขัดแย้งกันถูกใช้งานอยู่ในลำดับที่สูงกว่า พฤติกรรมของกฎใน policy จึงถูกตีความผิดได้ง่าย

4. Policy bloat

“เป็นเรื่องปกติที่องค์กรขนาดใหญ่จะมี firewall policy ถึง 30-40% ที่ไม่ได้ใช้งาน” Woods กล่าว

เมื่อ 20 ปีก่อน กฎมีอยู่ราว 200-300 บรรทัด แต่ policy ในปัจจุบันอาจมีตั้งแต่ 10,000 ถึง 100,000 บรรทัด เมื่อคูณด้วยจำนวน firewall ทั้งหมด ปริมาณกฎที่เกิดขึ้นก็ยากจะควบคุม policy bloat ส่วนใหญ่เกิดจากการสะสมของกฎที่ไม่ได้ใช้งาน กฎที่ซ้ำซ้อน shadowed rules และกฎที่เปิดกว้างเกินความจำเป็น ภาวะนี้บั่นทอนสุขอนามัยโดยรวมของ security enforcement policy

การทำงานแบบไซโลของทีมความปลอดภัยทำให้เกิดการตั้งค่าที่ผิดพลาด

นอกเหนือจากเหตุผลข้างต้น ในช่วงไม่กี่ปีที่ผ่านมายังเกิดการกระจัดกระจายของความรับผิดชอบด้านความปลอดภัย จนองค์กรไม่มีศูนย์กลางในการดูแลความปลอดภัยอีกต่อไป

จากเดิมที่เคยมีทีมความปลอดภัยส่วนกลางดูแลการควบคุมทั้งหมด ปัจจุบันกลับมีทั้ง business owner, stakeholder, ทีม DevOps, ทีม cloud security และทีม IT security ที่ต่างรับผิดชอบการ deploy security control เมื่อเปิดใช้งานแอปพลิเคชัน workload และทรัพยากรต่าง ๆ ในภูมิทัศน์ “hybrid enterprise” ที่ใหญ่ขึ้นในวันนี้ ความรับผิดชอบด้านความปลอดภัยจึงกลายเป็นพื้นที่สีเทา Woods กล่าว

“เราไม่ได้เล่นจากโน้ตเพลงแผ่นเดียวกันอีกต่อไปแล้ว” Woods กล่าว “และไซโลเหล่านี้ ความกระจัดกระจายที่เกิดขึ้นนี้ ก่อให้เกิดช่องโหว่ด้านความปลอดภัย”

เมื่อเวลาผ่านไป ช่องว่างของความซับซ้อนก็ยิ่งกว้างขึ้น เมื่อจำนวนกฎเพิ่มขึ้น กฎที่ไม่ได้ใช้งาน กฎที่ซ้ำซ้อน และกฎที่เปิดกว้างเกินความจำเป็นก็เพิ่มขึ้นตามไปด้วย

ยิ่งช่องว่างนั้นกว้างขึ้นเท่าใด โอกาสที่ความผิดพลาดของมนุษย์จะแทรกเข้ามาก็ยิ่งสูงขึ้น และโอกาสที่จะเกิดการตั้งค่าที่ผิดพลาดจนส่งผลกระทบต่อระบบก็สูงขึ้นเช่นกัน Woods กล่าว

การบริหารจัดการ security policy แบบอัตโนมัติช่วยแก้ปัญหาการตั้งค่าที่ผิดพลาด

เพื่อรับมือกับปัญหาการตั้งค่าที่ผิดพลาดตั้งแต่ต้นทาง Woods แนะนำให้ใช้โซลูชัน network security policy managementที่สามารถระบุและติดป้ายกำกับการเปลี่ยนแปลง firewall policy ได้ทุกรายการ

“มีคำถามหนึ่งที่ต้องตอบให้ได้ทุกครั้งที่เกิดการเปลี่ยนแปลง” Woods กล่าว “คำถามนั้นคือ ‘การเปลี่ยนแปลงที่เพิ่งเกิดขึ้นบนเครือข่ายของผมสร้างความเสียหายหรือไม่ ใช่หรือไม่ใช่’”

พูดอีกอย่างคือ การเปลี่ยนแปลง policy นั้นส่งผลเสียต่อ security posture ขององค์กรหรือไม่ การติดป้ายกำกับความซับซ้อนคือก้าวแรกที่ช่วยลดความซับซ้อนลงได้ Woods กล่าว ความสามารถในการวิเคราะห์การเปลี่ยนแปลงตั้งแต่เกิดขึ้นจะสร้าง visibility แต่ผู้ดูแลระบบที่เป็นมนุษย์ไม่อาจตามปริมาณการแจ้งเตือนมหาศาลได้ทัน จุดนี้เองที่แพลตฟอร์มระบบอัตโนมัติซึ่งออกแบบมาเพื่องานนี้โดยเฉพาะเข้ามาช่วย ทุกครั้งที่เกิดการเปลี่ยนแปลง แอปพลิเคชันจะเปรียบเทียบกับกฎเดิม สร้างบันทึกการเปลี่ยนแปลง และประเมินกฎนั้นในบริบทของ policy โดยรวม

สรุป

การตั้งค่า firewall ที่ผิดพลาดเกิดขึ้นได้จากหลายสาเหตุ Tim Woods จาก FireMon ได้ระบุสาเหตุที่พบบ่อยสี่ประการ พร้อมอธิบายบริบทเรื่องความซับซ้อนของโครงสร้างบุคลากรด้านความปลอดภัยที่อาจนำไปสู่ความผิดพลาดในการตั้งค่าเหล่านี้ และสุดท้าย เพื่อแก้ปัญหาการตั้งค่า firewall policy ที่ผิดพลาด Woods แนะนำแพลตฟอร์ม network security policy management ที่ออกแบบมาเพื่องานนี้โดยเฉพาะ ซึ่งทำให้ visibility และการวิเคราะห์การเปลี่ยนแปลง firewall policy ทั้งหมดเป็นระบบอัตโนมัติ สำหรับคู่มือฉบับสมบูรณ์ว่าด้วยการติดตั้ง firewall อย่างถูกต้องเพื่อหลีกเลี่ยงข้อผิดพลาดที่พบบ่อยเหล่านี้ โปรดดูFirewall Implementation: คู่มือทีละขั้นตอนของเรา