* การจับคู่ลำดับหมายเลขบัตรเครดิต
* การจัดการกับผลบวกลวง (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
ไม่มีความคิดเห็น:
แสดงความคิดเห็น