ตามมาตรฐาน Payment Card Industry Data Security Standard (https://www.pcisecuritystandards.org/) ได้กำหนดห้ามไม่ให้มีการรับส่งหมายเลขบัตรเครดิตในรูปแบบที่ไม่ได้เข้ารหัส และไม่ได้อำพรางไว้ โดยปกติแล้วระบบเฝ้าดูเครือข่ายเช่น IDS หรือ IPS เป็นสเมือนระบบบังคับเพื่อให้มั่นใจได้ว่าข้อมูลดังกล่าวจะไม่ถูกส่งผ่าน เครือข่าย แต่จากการตรวจสอบอย่างละเอียดแสดงให้เห็นว่าปฏิบัติตามข้อบังคับอย่างถูก ต้องนั้นทำได้ไม่ง่าย ข้อเขียนนี้จะแสดงถึงแง่มุมต่าง ๆ ในการใช้ระบบเฝ้าดูเครือข่ายเพื่อตรวจจับการรั่วไหลของหมายเลขบัตรเครดิต และเพื่อสร้าง Signature ในการตรวจจับความผิดปกติของข้อมูลบนระบบเครือข่าย ดังต่อไปนี้คือ
* การจับคู่ลำดับหมายเลขบัตรเครดิต
* การจัดการกับผลบวกลวง (false positive) โดยการใช้ข้อยกเว้น (exceptions)
* ข้อควรพิจารณาอื่น ๆ รวมทั้งการหลบหลีกการตรวจจับ บันทึกเหตุการณ์ (logging) และรูปแบบอื่น ๆ ที่ล่อแหลม
1. การจับคู่หมายเลขบัตรเครดิต
1.1 การจับคู่ลำดับหมายเลขบัตรเครดิต
หมายเลขบัตรเครดิตประกอบด้วยตัวเลข 13 ถึง 16 ตัว นอกจากนี้ในการใช้งานจริงหมายเลขบัตรเครดิตยังมีตัวคั่นอย่างเช่น เครื่องหมายขีดหรือเว้นวรรคในตำแหน่งเฉพาะ regular expression ต่อไปนี้สามารถใช้เพื่อจับหมายเลขบัตรเครดิตได้
\d{4}[\- ]?\d{4}[\- ]?\d{2}[\- ]?\d{2}[\- ]?\d{1,4}
1.2 ขอบเขต
ลำดับตัวเลขยาว ๆ เป็นสิ่งที่เกิดขึ้นเป็นปกติในการจราจรในระบบเครือข่าย regular expression ที่กล่าวมาแล้วข้างต้นจะพบลำดับตัวเลขที่มีความยาวดังกล่าวจำนวนมาก เพื่อหลีกเลี่ยงเหตุการณ์นี้ เราจำเป็นต้องกำหนดตัวคั่น ตัวคั่นจะใช้ได้หรือไม่อาจขึ้นอยู่กับแอพพลิเคชั่นดังกล่าว ถ้าไม่ใช้ตัวคั่นเลยจะทำให้เกิดผลบวกลวงจำนวนมาก แต่ถ้าการใช้ตัวคั่นอาจนำไปสู้ผลลบลวงได้เช่นกัน ตัวอย่างเช่น เราควรอนุญาตให้มี “0″ นำหน้าหรือไม่ ?
ตัวเลือกที่มีเหตุผลสำหรับตัวคั่นคือตัวอักขระใด ๆ ที่ไม่ใช่ตัวเลข regular expression ที่ได้คือ ?
หรือถ้า regular expression ที่ไม่สนับสนุนการค้นหาแบบ look-ahead และ look-behind
(?:^|[^\d])(\d{4}[\- ]?\d{4}[\- ]?\d{2}[\- ]?\d{2}[\- ]?\d{1,4})(?:[^\d]|$)
1.3 การตรวจสอบหมายเลขโดยใช้อัลกอริทึม LUHN checksum
อย่างไรก็ตามลำดับของตัวเลข 13 ถึง 16 ตัวไม่จำเป็นต้องเป็นหมายเลขบัตรเครดิตเสมอไป มีตัวเลขยาว ๆ จำนวนมากในการจราจรในเครือข่ายปกติจำนวนมาก ตัวอย่างเช่น เรามักพบหมายเลขไอดี อย่างเช่นหมายเลขผลิตภัณฑ์ใช้ในเวบจำหน่ายสินค้าออนไลน์ใช้ตัวเลข 13 ถึง16 หลักด้วย โชคดีที่หมายเลขบัตรเครดิตสอดคล้องกับฟังค์ชั่น LUHN checksum ระบบเฝ้าดูเครือข่ายสามารถใช้อัลกอริทึมนี้และตรวจสอบลำดับตัวเลขเพื่อตรวจ สอบว่าเป็นหมายเลขบัตรเครดิตหรือไม่
มาตรการนี้เพียงพอสำหรับการหลีกเลี่ยงผลบวกลวงหรือไม่ ? ฟังค์ชั่น LUHN เป็นฟังค์ชั่นในการ checksum ที่สร้างตัวเลขเพิ่มเติมสำหรับแต่ละหมายเลข ดังนั้นมันจึงจับคู่ 1 ใน 10 หมายเลขที่ต่อเนื่องกัน เนื่องจากในกรณีส่วนใหญ่ หลาย ๆ แอพพลิเคชั่นใช้ตัวเลขที่มีความยาวขนาดนี้เป็นหมายเลขไอดี แอพพลิเคชั่นนั่นก็อาจใช้ตัวเลขต่อเนื่องกันหลายหมายเลข ดังนั้นหนึ่งในสิบของหมายเลขที่ใช้อาจเป็นหมายเลขบัตรเครดิตจริง ดังนั้นการตรวจสอบตัวเลขโดยใช้สูตร LUHN จึงลดจำนวนของผลบวกลวงลงได้ร้อยละ 90 แต่ไม่ได้กำจัดลงไปทั้งหมด
1.4 ตรวจสอบตัวเลขนำหน้า (prefixes)
เพื่อลดจำนวนของผลบวกลวง ระบบเฝ้าดูสามารถตรวจสอบได้ว่าหมายเลขบัตรเครดิตนั้นไม่เพียงแต่ถูกต้องแต่ ยังได้รับการกำหนดไว้แล้วด้วย โดยปกติระบบเฝ้าดูไม่อาจมีรายการของหมายเลขที่กำหนดไว้ได้ทั้งหมด แต่มันสามารถตรวจตัวเลขนำหน้า ว่าตัวเลขกลุ่มใดที่กำหนดให้กับสถาบันทางการเงินแห่งใด ตารางของตัวเลขนำหน้าสามารถค้นหาได้จาก Wikipedia (http://en.wikipedia.org/wiki/Credit_card_number)
ตัวเลขนำหน้าสามารถลดจำนวนของผลบวกลวงและสามารถตรวจสอบได้โดยอาศัย regular expression หมายเลขที่กำหนดไว้มีจำนวนร้อยละ 1 ถึง 17 ของหมายเลขบัตรเครดิตที่ใช้ได้ทั้งหมดโดยขึ้นอยู่กับความยาวของตัวเลข ตัวเลขนำหน้ามีประโยชน์ในการใช้เพื่อกำจัดตัวเลขความยาว 14 และ 15 หลักที่ไม่ค่อยมีการใช้กันมากนักออกไป ทำให้เรามีตัวเลขความยาว 13 ถึง 16 ตัว ยังคงไม่เป็นที่แน่ชัดว่า Visa ยังใช้ตัวเลข 13
หลักอยู่หรือไม่
ในแง่เสีย การใช้ตัวเลขนำหน้าอาจนำไปสู่ผลลบลวงและอาจจะต้องมีการปรับปรุงระบบเฝ้าดู เครือข่าย เช่น ช่วงหมายเลขที่ใช้สำหรับธนาคารในออสเตรเลียที่เวบ Wikipedia ระบุไว้ว่าไม่มีการใช้ แต่เรากลับเจอตัวเลขในช่วงดังกล่าวในการจราจรในระบบเครือข่าย
โดยการใช้สูตร LUHN และการตรวจสอบตัวเลขนำหน้า ทำให้สามารถลดอัตราการเกิดของผลบวกลวงลงได้ประมาณร้อยละ 1 จากข้อมูลทั้งหมดที่ได้จากการใช้หลักการของ pattern matching เท่านั้น
2. การจัดการกับผลบวกลวงโดยใช้กฏข้อยกเว้น
ในระบบที่ใช้อยู่จริง ร้อยละ 1 ยังถือว่าเป็นจำนวนที่สูง โดยเฉพาะอย่างยิ่งลำดับของตัวเลขเป็นสิ่งที่เกิดขึ้นเป็นปกติในการจราจรใน เครือข่าย ถ้ามนุษย์เป็นจำเป็นต้องตรวจสอบการแจ้งเตือนเป็นจำนวนร้อยข้อความต่อวัน ระบบเฝ้าดูก็จะไม่มีประโยชน์ เราสามารถทำให้ระบบตรวจจับมีความแม่นยำขึ้นได้อย่างไร
วิธีที่ทำได้คือการสร้างกฏข้อยกเว้นสำหรับการจราจรที่รู้ว่าจะสร้างผลบวก ลวง กฏข้อยกเว้นสามารถกำหนดได้ทั้งสำหรับลำดับตัวเลขที่ไม่ใช่หมายเลขบัตรเครดิต และการรับส่งข้อมูลหมายเลขบัตรเครดิตที่ตั้งใจ
กฏข้อยกเว้นดังกล่าวมีทั้งข้อดีและข้อเสีย การใช้มากเกินไปหรือกำหนดไว้อย่างกว้าง ๆ เกินไปจะทำให้เกิดช่องโหว่ความปลอดภัย เช่น ลำดับตัวเลข 16 ตัวที่ใช้เพื่อเป็นหมายเลขผลิตภัณฑ์ในเวบไซต์ ข้อยกเว้นที่ใช้กฏเหมือนกับไฟร์วอลที่สนับสนุนเฉพาะที่อยู่ไอพี (IP address) และพอร์ท (port) จะต้องปล่อยให้การจราจรทั้งหมดของเวบไซต์นั้นผ่านไปได้ ในอีกแง่หนึ่งระบบเฝ้าดูแอพพิลเคชั่น เช่น Web Application Firewall (WAF) สามารถกำหนดกฏข้อยกเว้นได้ละเอียดกว่า ในกรณีข้างต้นกฏของ WAF สามารถกำหนดให้ยกเว้นการตรวจจับหมายเลขบัตรเครดิตสำหรับเขตข้อมูลเฉพาะใน หน้าพิเศษที่ใช้สำหรับหมายเลขผลิตภัณฑ์
ตัวอย่างเช่นกฏของ SRAN Security Center โดยผสมผสาน Signature snort + ModSecurity โดยใช้ หมายเลข 955555 ตรวจพบหมายเลขบัตรเครดิตในข้อมูลที่ได้จากแอพพิลเคชั่นหนึ่ง แต่หน้า /support/manual_payment.php มีเพียงแต่เจ้าหน้าที่ของร้านเท่านั้นที่สามารถเข้าถึงได้ จะต้องแสดงหมายเลขบัตรเครดิต ข้อยกเว้นสำหรับ ModSecurity ต่อไปนี้อนุญาตให้หน้านี้ผ่านไปได้
SecRuleRemoveById 955555
เราสามารถกำหนดข้อยกเว้นให้ตรวจสอบต่อไปได้อีกว่ามีเพียงหมายเลขบัตร เครดิตเพียงหมายเลขเดียวที่แสดงในหน้านี้ และแสดงในเพียงบางส่วนของหน้านี้เท่านั้น
นอกจากนี้หมายเลขผลิตภัณฑ์ยังอาจมีคุณลักษณะอื่น ๆ อีกเช่นตัวเลขนำหน้าเฉพาะของมัน หรือข้อความอื่น ๆ ที่ช่วยในการทำให้ข้อยกเว้นแคบลง ตัวอย่างเช่น Google AdSense เวบไซต์ที่มี Google ads จำเป็นต้องเพิ่มโค้ดต่อไปนี้เข้าไปในแต่ละหน้าที่แสดงโฆษณาหลายครั้งที่หมายเลข 16 ตัวในพารามิเตอร์ google_ad_client เป็นหมายเลยบัตรเครดิตจริง regular expression
3. ข้อควรพิจารณาอื่น ๆ
3.1 การหลบหลีกการตรวจจับ
เทคนิคในการหลบหลีกการตรวจจับ (Evasion techniques) เป็นปัญหาร้ายแรงสำหรับระบบตรวจจับการบุกรุกและยิ่งมีปัญหามากขึ้นอีกสำหรับ การตรวจจับหมายเลขบัตรเครดิต แม้แต่ฟังค์ชั่นในการเปลี่ยนรูปแบบตัวเลขที่ง่ายที่สุดก็สามารถหลบหลีกการ ตรวจจับได้ ตัวอย่างเช่น ผู้โจมตีทำการโจมตีแบบ SQL injection เพื่อขโมยข้อมูลหมายเลขบัตรเครดิต เขาสามารถสร้าง SQL statement ที่ทำให้ตัวเลขของหมายเลขบัตรเครดิตแต่ละตัวคูณด้วยสอง มีผลให้ระบบเฝ้าดูไม่สามารถตรวจผลที่ได้ว่าเป็นหมายเลขบัตรเครดิต หลังจากที่ข้อมูลดังกล่าวรั่วไหลออกมาแล้ว ผู้โจมตีสามารถหารตัวเลขด้วยสองเพื่อให้ได้มาซึ่งหมายเลขบัตรเครดิตดังเดิม เพราะง่ายในการหลบหลีกระบบเฝ้าดูเครือข่ายหรือระบบตรวจจับอื่น ๆ จึงไม่เหมาะสมในการตรวจจับการขโมยหมายเลขบัตรเครดิต ดังนั้นการหลีกเลี่ยงการขโมยถึงต้องมุ่งเน้นที่การป้องกันสิ่งที่เข้ามา
แม้แต่ข้อมูลที่รั่วไหลออกไปโดยไม่ตั้งใจก็อาจหลบหลีกการตรวจจับอย่างไม่ ตั้งใจเช่นกัน ตัวอย่างที่ดีคือการเข้ารหัส เพื่อให้มึความปลอดภัยที่ดีขึ้น แอพพลิเคชั่นหลายตัวใช้การเข้ารหัสเมื่อต้องการรับส่งข้อมูลผ่านทางเครือ ข่าย การเข้ารหัสดังกล่าวซ่อนการจราจรจากระบบเฝ้าดู ในขณะที่ระบบ IDS ในระดับ network layer ไม่สามารถถอดรหัส SSL ได้ โซลูชั่นในระดับ web layer สามารถทำได้ คุณสามารถอ่านรายละเอียด
เพิ่มเติมเกี่ยวกับ SSL blind spot ได้จาก http://archives.neohapsis.com/archives/sf/ids/2007-q3/0084.html
อีกปัญหาหนึ่งคือระบบเข้ารหัสที่เพิ่มเข้าไปในโปรโตคอลด้านเครือข่าย เช่น Unicode หรือการบีบอัดการจราจร HTTP และการเข้ารหัสข้อความอีเมลที่เรียกว่า base64 ระบบเฝ้าดูเครือข่ายไม่สามารถตรวจจับการจราจรที่เข้ารหัสได้ แต่ระบบเฝ้าดูที่รู้จักแอพพลิเคชั่นสามารถถอดรหัส ก่อนการตรวจจับและตรวจหาการรั่วไหลของข้อมูลได้
3.2 บันทึกข้อมูล (logging)
การบันทึกข้อมูลเป็นสิ่งสำคัญเช่นเดียวกับการตรวจจับของระบบเฝ้าดูเครือ ข่าย สิ่งนี้มีความสำคัญอย่างมากกับการตรวจจับหมายเลขบัตรเครดิตในหลาย ๆ กรณีอาจสามารถบรรเทาความเสียหายที่เกิดจากการบุกรุกระบบรักษาความปลอดภัยได้ ถ้าองค์การดังกล่าวรู้ว่ามีข้อมูลข่าวสารใดบ้างที่รั่วไหลออกไป ตัวอย่างเช่น มีกฏหมายของสหรัฐ ฯ เช่น California SB-1386 ที่กำหนดให้องค์การต้องบอกให้ผู้ใช้ (client) ที่ได้รับผลกระทบจากการถูกบุกรุกรับทราบ ถ้าองค์การนี้ไม่รู้ว่ามีผู้ใช้คนไหนบ้างที่ได้รับผลกระทบ องค์การดังกล่าวจะต้องบอกให้ทุกคนรู้ ซึ่งจะเพิ่มความเสียหายที่เกิดขึ้นจากการถูกบุกรุกและทำให้เสียชื่อเสียงจาก การเผยแพร่ข่าวของสื่อมวลชนได้
โชคไม่ดีที่การบันทึกข้อมูลการรั่วไหลของหมายเลขบัตรเครดิตทำได้ไม่ง่าย PCI DSS ไม่อนุญาตให้มีการบันทึกหมายเลขบัตรเครดิตแต่ตัวบันทึกเองจะต้องมีข้อมูลที่ มีประโยชน์มากพอ ระบบบันทึกจะต้องมีการบันทึกในสองระดับดังนี้คือ
- บันทึกแจ้งเตือนที่สามารถใช้เพื่อวิเคราะห์ว่าอะไรเกิดขึ้น แต่จะต้องไม่มีหมายเลขบัตรเครดิตยู่ด้วย หรืออาจจะเป็นหมายเลขที่อำพรางไว้
- หมายเลขบัตรเครดิตที่เก็บอยู่ในรูปแบบที่เข้ารหัสไว้
3.3 สมรรถนะการทำงาน (Performance)
การใช้ regular expression เป็นวิธีการที่ไม่มีประสิทธิภาพเป็นอย่างมาก ดังนั้นระบบ IDS ส่วนใหญ่จึงหลีกเลี่ยงการทดสอบ payload ที่มี regular expression จำนวนมาก เพื่อให้บรรลุเป้าหมายนี้ IDS จึงจะต้องพยายามใช้อัลกอริทึมในการตรวจจับแบบคู่ขนานที่มีประสิทธิภาพ เช่น Aho-Corasick (http://en.wikipedia.org/wiki/Aho-Corasick_algorithm) ซึ่งทำงานได้อย่างรวดเร็วมากและใช้การตรวจสอบเพียงครั้งเดียว อย่างไรก็ตามการตรวจจับแบบคู่ขนานสามารถตรวจได้เพียงสายอักขระง่าย ๆ ถ้าพบสายอักขระง่าย ๆ จึงจะมีการทดสอบ regular expression อื่นตามมา เพื่อลดจำนวนของการทดสอบ regular expression อัลกอริทึมในการตรวจจับแบบคู่ขนานจึงต้องค้นหาสายอักขระที่ยาวที่สุดจากทุก ๆ regular expression
3.4 ข้อมูลอื่น ๆ ที่มีความสำคัญ
ไม่ได้มีเพียงแต่หมายเลขบัตรเครดิตเท่านั้นที่เป็นข้อมูลสำคัญที่ต้องให้ ความสนใจ Card Verification Code (CVV) เป็นตัวเลข 3 หรือ 4 หลักที่อยู่ด้านหลังบัตรเครดิตที่ใช้ในการทำธุรกรรมออนไลน์ด้วย CVV มีความล่อแหลมมากกว่าหมายเลขบัตรเครดิต แตในการตรวจจับเนื่องจากมันมีจำนวนสั้น ๆ และไม่มีตัวเลข checksum
วิธีหนึ่งในการตรวจจับหมายเลข CVV คือการค้นหาตัวเลขสามหรือสี่ตัวในเขตข้อมูลในฟอร์มหนึ่ง ที่พบหมายเลขบัตรเครดิต วิธีนี้ยังอาจพบผลบวกลวงได้ แต่ระบบที่มีความระมัดระวังอาจช่วยทำให้ผลข้อมูลบวกลวงน้อยลงได้
4. บทสรุป
การตรวจจับการขโมยข้อมูลบัตรเครดิตโดยการเฝ้าดูการจราจรในเครือข่ายทำได้ ยากมาก แต่การเฝ้าดูดังกล่าวอาจมีประโยชน์ในการใช้เพื่อตรวจจับการรั่วไหลของ หมายเลขบัตรเครดิตโดยไม่ได้ตั้งใจ ในการทำเช่นนี้ระบบเฝ้าดูจะต้องรู้จักกับแอพพลิเคชั่นและโปรโตคอล เพื่อชดเชยกับการเข้ารหัสที่ใช้กับข้อมูล และยังใช้เป็นเครื่องมือในการสร้างกฏ (Rule Base Signature) หรือข้อยกเว้นสำหรับหมายเลขบัตรเครดิตที่ถูกต้องหรือข้อมูลอื่น ๆ ที่อาจถูกตรวจจับอย่างผิดพลาดว่าเป็นหมายเลขบัตรเครดิต
5. อธิบายคำศัพท์
Regular Expression หมายถึง รูปแบบของลำดับ หรือกลุ่มของสัญลักษณ์ที่ใช้แทนลำดับ หรือกลุ่มของอักขระตามที่ต้องการ
checksum เป็นรูปแบบหนึ่งของ redundancy check (ข้อมูลพิเศษที่เพิ่มเข้าไปในข้อความเพื่อจุดประสงค์ในการตรวจจับผิดพลาดและ ทำให้ถูกต้อง) เป็นวิธีง่าย ๆ ในการป้องกันความครบถ้วนของข้อมูลโดยการตรวจจับความผิดพลาดในข้อมูลส่งผ่าน ทางระยะทาง (โทรคมนาคม) หรือเวลา (พื้นที่เก็บข้อมูล) ทำงานโดยการเพิ่มองค์ประกอบพื้นฐานของข้อความ โดยทั่วไปแล้วมักจะเป็นข้อมูลที่ใช้ยืนยันความถูกต้อง และเก็บค่าที่ได้ไว้ ทุกคนสามารถกระทำการอย่างเดียวกับข้อมูลนั้น และเปรียบเทียบผลที่ได้กับ checksum ของแท้และสรุปได้ว่าข้อความนั้นได้ถูกเปลี่ยนแปลงหรือไม่
LUHN algorithm หรือ LUHN formula เป็นสูตรในการ checksum เพื่อตรวจสอบความถูกต้องของหมายเลขไอดีต่าง ๆ เช่น หมายเลขบัตรเครดิตและหมายเลขประกันสังคมของแคนาดา สร้างขึ้นโดย Hans Peter Luhn นักวิทยาศาสตร์ของบริษัทไอบีเอ็ม
นนทวรรธนะ สาระมานNontawattana Saraman
SRAN Dev
ของเก่ามาเล่าใหม่ครับ เป็นบทความที่ดีนำมาเสนออีกครั้ง
อ่านเพิ่มเติม เรื่อง How .NET Regular Expressions Really Work
บทความ มาทำความรู้จักมาตรฐาน PCI DSS กับการรับรองมาตรฐานกับ Global Technology Integrated