Network Segmentation ใน PCI DSS: Flat Network ดูดทั้งองค์กรเข้า Scope

สารบัญ

เดือนนี้ที่ใดสักแห่งในเอเชียตะวันออกเฉียงใต้ ธนาคารแห่งหนึ่งกำลังบอกกับ assessor ว่าเซิร์ฟเวอร์ส่วนใหญ่ ของตนอยู่นอก PCI DSS scope เพราะไม่ได้เก็บ ส่งต่อ หรือประมวลผล (SToP) เลขบัตร ทั้งที่เซิร์ฟเวอร์เหล่านั้นนั่งอยู่บน subnet เดียวกับ payment switch ความเชื่อนี้ฟังดูสมเหตุสมผลสำหรับทีม infrastructure แต่มันผิดในแบบที่จะกำหนดทั้ง assessment ทั้งหมดของพวกเขา

ความเข้าใจผิดแบบนี้พบบ่อย และแพงพอที่ควรมีบทความอธิบายไว้สักบท network segmentation แปลกที่ไม่ใช่ requirement ของ PCI DSS แต่ก็เป็น control ที่มีผลที่สุดตัวหนึ่งที่ควรทำก่อน assessment เพราะมันคือกลไก ที่ตัดสินว่ามาตรฐานนี้จะยืดเข้าไปถึงส่วนไหนขององค์กรคุณ

PCI DSS scope ทำงานอย่างไรจริง ๆ #

คนส่วนใหญ่อ่าน PCI DSS เป็นมาตรฐานเกี่ยวกับข้อมูลบัตร ซึ่งถูกแล้ว แต่นิยามของ scope ในตัวมาตรฐาน กว้างกว่าระบบที่แตะเลขบัตร scope ประกอบด้วยสองกลุ่ม:

System component ที่เก็บ ประมวลผล หรือส่งต่อ cardholder data หรือ sensitive authentication data
System component บุคลากร และกระบวนการที่ ส่งผลต่อความมั่นคงปลอดภัยของข้อมูลนั้นได้

กลุ่มที่สองคือส่วนที่องค์กรมักลืม logging server ที่ไม่เคยเห็นเลขบัตรก็อยู่ใน scope ถ้าระบบชำระเงิน พึ่งพามัน DNS server ก็เข้า scope ถ้า lookup ที่โดน manipulate สามารถเปลี่ยนทาง payment flow ได้ และทุก desktop กับเซิร์ฟเวอร์ที่แชร์ network segment เดียวกับ cardholder data environment (CDE) ก็อยู่ใน scope เพราะเครื่องที่โดน compromise บน segment นั้นมีเส้นทาง network ตรงเข้าระบบชำระเงิน

PCI DSS v4.0.1 เขียนเกณฑ์การตัดออกจาก scope ไว้ชัดเจน: จะถือว่าอยู่นอก scope system component ต้องถูก isolate จาก CDE จนกระทั่งมันส่งผลต่อความมั่นคงปลอดภัยของ cardholder data ไม่ได้ แม้ตัวมันเองจะโดน compromise ไปแล้วก็ตาม คำถามไม่เคยเป็นว่าระบบนั้นแตะ PAN หรือไม่ คำถามคือถ้าระบบนั้นล่ม ผู้โจมตีจะไปถึงอะไรได้จากมันบ้าง

Requirement ที่ไม่ใช่ requirement #

นี่คือส่วนที่แปลกที่สุด scoping guidance ของ PCI DSS v4.0.1 เขียนไว้แทบจะตรงตัว: segmentation ของ CDE จาก network ส่วนที่เหลือขององค์กร “ไม่ใช่ requirement ของ PCI DSS” แต่แนะนำอย่างยิ่ง (strongly recommended) เพราะช่วยลดขอบเขตของ assessment ลดค่าใช้จ่ายของ assessment ลดต้นทุน และความยากในการรักษา compliance control และลดความเสี่ยงขององค์กรโดยรวมข้อมูลบัตรไว้ในจุดที่น้อยลง แต่ควบคุมได้ดีขึ้น

อ่าน trade-off นี้อีกครั้ง ผู้เขียนมาตรฐานเลือกที่จะไม่บังคับ segmentation แต่เขียนย่อหน้าทั้งย่อหน้า อธิบายว่าทำไมคุณควรทำอยู่ดี requirement บอกว่า assessor ต้องตรวจอะไร แต่ scoping guidance บอกว่าอะไรจะตัดสินว่า requirement เหล่านั้นจะกิน 3 ระบบหรือ 300 ระบบ

คำเดียวกันนั้นมีประโยคที่ผู้นำ infrastructure ทุกคนควรติดไว้ข้างโต๊ะ: ถ้าไม่มี segmentation ที่เพียงพอ (sometimes called a flat network) network ทั้งเครือข่ายจะอยู่ใน scope ของ PCI DSS assessment

Flat network ทำอะไรกับ assessment #

แผนภาพ: flat network ดูด PC สำนักงาน เซิร์ฟเวอร์ HR และ backup เข้า PCI DSS scope ส่วน segmentation ย่อ scope เหลือแค่ cardholder data environment

บน flat network scope ไม่ได้มาจากการต่อรอง แต่มาจากการสืบทอดทุกเซิร์ฟเวอร์ ทุก PC ทุกปริ้นเตอร์ และทุกเครื่อง backup ที่แชร์ segment เดียวกัน สืบทอดมาตรฐานความปลอดภัยเดียวกับระบบที่จับข้อมูลบัตร หมายความว่า hardening เดียวกัน vulnerability management cadence เดียวกัน logging แบบเดียวกัน access control discipline เดียวกับที่คุณทำกับ payment application ต้องใช้กับ laptop ของทีมบัญชีด้วย

องค์กรมักเข้าใจดีว่า PCI DSS คาดหวังอะไรกับ payment server แต่สิ่งที่ทำไม่ได้คือเอา regime นั้น ไปใช้กับทั้งออฟฟิศหรือ data centre ทั้งหลัง patch window ที่เคยเป็นเรื่องปกติกลายเป็นการเจรจา กับทุกหน่วยงาน change control ทำให้งานที่ไม่เกี่ยวกับ payment ช้าลง assessment ตัวมันเองก็โต ตาม: ระบบที่ต้อง sample เยอะขึ้น หลักฐานที่ต้องเตรียมเยอะขึ้น สัมภาษณ์เยอะขึ้น ค่าใช้จ่ายมากขึ้น และเส้นทางสู่ compliance ยาวขึ้น

ผมเคยเห็น environment ที่เก่งทางเทคนิค fail assessment ด้วยเหตุผลนี้ payment tier ถูกสร้างมาดี hardening ละเอียด แต่นั่งอยู่บน network ที่แยกมันออกจากอย่างอื่นไม่ได้ ความปลอดภัยของ CDE มีจริง แต่ขอบเขตที่จะพิสูจน์สิ่งนั้นไม่มีอยู่ assessment จึงต้องถือระบบที่ไม่เกี่ยวข้องนับร้อยราวกับเป็น ระบบ payment เทคนิคดี สถาปัตยกรรมผิด ผลลัพธ์แพง

เคสจากงานจริง #

งานหนึ่งที่กำลังทำอยู่เจอปัญหานี้ตรง ๆ เป็นธนาคารที่มีเซิร์ฟเวอร์อันเกี่ยวก้อยกับ payment กระจายอยู่ บน network เดียวกันทั้งหมด จุดยืนของพวกเขาเป็นแบบที่คนทั่วไปเข้าใจ: เซิร์ฟเวอร์พวกนี้ไม่ได้จับ PAN จึงควรออกจาก scope

คำตอบมาจากเกณฑ์ตัดออกในตัวมาตรฐานเอง ระบบจะออกจาก scope ได้ก็ต่อเมื่อมันส่งผลต่อความมั่นคง ปลอดภัยของ CDE ไม่ได้แม้ตัวมันจะโดน compromise office server ตัวหนึ่งบน subnet เดียวกับ ระบบชำระเงิน fail เกณฑ์นี้ทันทีสองชั้น: มันมีเส้นทาง route เข้า CDE อยู่แล้ว และใครก็ตามที่ยึดมันได้ ก็ได้เส้นทางนั้นไปด้วย lateral movement จาก desktop ที่โดน compromise ไปยัง payment switch ไม่ใช่สถานการณ์สมมติแบบ exotic แต่เป็น move เปิดเกมของ intrusion จริงเกือบทุกครั้ง

บทสนทนาที่เป็นประโยชน์จึงไม่ใช่ระบบเหล่านี้เก็บ PAN หรือไม่ แต่คือระบบใดบ้างที่ผู้โจมตีสามารถ pivot ผ่านได้ และควรมี network control ตัวใดที่ตัด pivot นั้น

Segmentation ถูกตรวจอย่างไร #

segmentation ที่ใช้ลด scope ต้องพิสูจน์ว่าลดได้จริง และ PCI DSS ระบุวิธีไว้:

ยืนยัน scope ประจำปี (Requirement 12.5.2) องค์กรต้องยืนยัน scope ทุกสิบสองเดือน ระบุ data flow ทั้งหมดและทุกระบบที่เชื่อมต่อกับหรือส่งผลต่อ CDE ได้ assessor จะรีวิวงานนี้ segment ที่ไม่มีเอกสารจึงกลายเป็น finding ไม่ใช่ช่องโหว่ที่ลอยผ่านไปได้
Segmentation penetration testing (Requirement 11.4.5) เมื่อใช้ segmentation ต้องทำ penetration test อย่างน้อยปีละครั้งและหลังเปลี่ยนแปลง control เพื่อยืนยันว่ามันทำงานจริง และ isolate CDE จากระบบนอก scope ได้จริง
ทุกหกเดือนสำหรับ service provider (Requirement 11.4.6) service provider ต้อง test segmentation control ปีละสองครั้ง เพราะ segmentation ของพวกเขาคือเส้นแบ่งที่ปกป้อง ข้อมูลบัตรของคนอื่น

สังเกตความสมมาตร: segmentation เป็นทางเลือก แต่ทันทีที่คุณอาศัยมันเพื่อลด scope การ test มัน กลายเป็นข้อบังคับ segmentation control ที่ไม่เคยถูก test คือ assumption เรื่อง scope และ assessor ไม่รับ assumption

เริ่มจากตรงไหน #

คุณไม่ต้องรื้อโครงสร้างทั้งหมด สิ่งที่ต้องมีคือ data-flow diagram ที่ซื่อสัตย์และขอบเขตหนึ่งเส้น ที่ hold ได้จริง หาว่าข้อมูลบัตรอยู่ที่ไหนจริง ๆ รวมมันให้อยู่จุดน้อยที่สุดเท่าที่ธุรกิจเปิดทางได้ ลากรั้วรอบจุดเหล่านั้น และ default deny ทุกอย่างข้ามรั้ว จากนั้นพิสูจน์ว่ารั้ว hold ด้วยวิธีเดียวกับ ที่ผู้โจมตีจะใช้ test มัน

ด้านการออกแบบ บทความเรื่อง network segmentation design ครอบคลุมการทำ zoning ที่จำกัด lateral movement โดยรวม ส่วน คู่มือ PCI DSS compliance ประเทศไทย เดินผ่าน เส้นทาง assessment ทั้งหมด

ไม่แน่ใจว่า PCI DSS scope ของคุณกว้างแค่ไหน หรือ segmentation ปัจจุบันจะรอดจาก penetration test ของ assessor หรือไม่? ติดต่อเพื่อรับการตรวจสอบแบบตรงไปตรงมา คุยได้ทาง LINE (@PureSecurity) หรืออีเมล (hello@puresecurity.com)

PCI DSS QSA audit ของเราถือ scoping เป็น deliverable แรก เพื่อตกลงขอบเขตก่อนเก็บหลักฐาน configuration and architecture assessment map traffic flow จริงให้เป็นแบบ segmentation ที่ทีมวิศวกร execute ได้ และ penetration testing ยืนยันว่า segment hold ภายใต้การโจมตีแบบเดียวกับที่ assessor จะนำมา