ความปลอดภัยทางไซเบอร์ในยุคฟินเทค: การปกป้องข้อมูลทางการเงินจากภัยคุกคามสมัยใหม่

บริษัทฟินเทคตั้งอยู่บนจุดตัดที่ละเอียดอ่อนเป็นพิเศษ: พวกเขาเคลื่อนย้ายเงิน เก็บรักษาข้อมูลส่วนบุคคล เปิดเผย API พึ่งพาบริการคลาวด์ และมักเชื่อมต่อกับธนาคาร ผู้ประมวลผลการชำระเงิน เครือข่ายบัตร ผู้ให้บริการยืนยันตัวตน และแพลตฟอร์มวิเคราะห์ข้อมูล นั่นทำให้ความปลอดภัยทางไซเบอร์ไม่ใช่แค่การควบคุมเพียงอย่างเดียว แต่เป็นระบบของการตัดสินใจเกี่ยวกับตัวตน ข้อมูล ซอฟต์แวร์ ผู้ให้บริการ การตรวจจับ และการกู้คืน

ตัวอย่างประกอบ:ตลอดบทความนี้ ลองจินตนาการถึงบริษัทสมมติชื่อ Northstar Pay บริษัทนี้ให้บริการกระเป๋าเงินดิจิทัล การชำระเงินด้วยบัตร การโอนเงินผ่านธนาคาร และบัญชีค่าใช้จ่ายทางธุรกิจ Northstar Pay ไม่ใช่บริษัทจริง และเหตุการณ์ด้านล่างเป็นเพียงตัวอย่างสมมติที่ใช้เพื่อแสดงให้เห็นว่าการเลือกเชิงป้องกันทำงานอย่างไรในทางปฏิบัติ

เหตุใดการรักษาความปลอดภัยทางไซเบอร์ของ FinTech จึงแตกต่างจากการรักษาความปลอดภัยแอปพลิเคชันทั่วไป?

การถูกโจมตีในแอปพลิเคชันสำหรับผู้บริโภคทั่วไปอาจทำให้ข้อมูลส่วนตัวรั่วไหลหรือทำให้บริการหยุดชะงัก แต่ในแพลตฟอร์มทางการเงิน ความผิดพลาดด้านการยืนยันตัวตนแบบเดียวกันนี้อาจนำไปสู่การโอนเงินโดยไม่ได้รับอนุญาต การเปลี่ยนแปลงบัญชีโดยฉ้อฉล การเข้าถึงข้อมูลที่อยู่ภายใต้การกำกับดูแล หรือการใช้สถาบันที่เชื่อมต่อในทางที่ผิด คำเตือนของ FBI เกี่ยวกับการเข้ายึดบัญชีในปี 2025 ระบุถึงอาชญากรที่แอบอ้างเป็นสถาบันการเงินเพื่อขโมยเงินหรือข้อมูลโดยเฉพาะ และรายงานว่ามีข้อร้องเรียนที่เกี่ยวข้องมากกว่า 5,100 รายการ และความเสียหายมากกว่า 262 ล้านดอลลาร์สหรัฐ ตั้งแต่เดือนมกราคม 2025 ดูคำเตือนของ FBI เกี่ยวกับการเข้ายึดบัญชีได้ที่นี่

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

การปฏิบัติจริง:จัดทำรายการสินทรัพย์ที่มีมูลค่าสูงและกิจกรรมทางธุรกิจ ไม่ใช่แค่เซิร์ฟเวอร์เท่านั้น รวมถึงข้อมูลส่วนบุคคลของลูกค้า ข้อมูลลับการตรวจสอบสิทธิ์ ข้อมูลผู้ถือบัตร ข้อมูลบัญชีธนาคาร คีย์ API คีย์ลงนาม คอนโซลผู้ดูแลระบบ ฟังก์ชันการจ่ายเงิน และความสามารถในการแก้ไขข้อมูลผู้รับผลประโยชน์หรือการกู้คืน

การโจมตีบริษัทฟินเทคในยุคปัจจุบันจะมีลักษณะอย่างไร?

ในตัวอย่างของ Northstar Pay ผู้โจมตีไม่ได้เริ่มต้นด้วยการ "ถอดรหัส" แต่ผู้โจมตีจะปลอมตัวเป็นฝ่ายสนับสนุนภายใน ชักชวนให้พนักงานอนุมัติการเข้าสู่ระบบ และเข้าถึงบัญชีที่ถูกต้อง จากนั้น ผู้โจมตีจะพยายามเข้าถึงเครื่องมือบริหารจัดการระบบคลาวด์ ค้นหาข้อมูลประจำตัวที่สามารถนำกลับมาใช้ใหม่ได้ และเริ่มกิจกรรมการจ่ายเงินที่เป็นการฉ้อโกง การโจมตีด้วยแรนซัมแวร์ในขั้นตอนที่สองใช้เพื่อเพิ่มแรงกดดันต่อการดำเนินงาน

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

แนวทางปฏิบัติ:สร้างแบบจำลองเส้นทางการโจมตีแบบครบวงจรอย่างน้อยสามเส้นทางสำหรับธุรกรรมทางการเงินที่สำคัญที่สุดของคุณ สำหรับแต่ละเส้นทาง ให้ระบุมาตรการป้องกัน การตรวจจับ การควบคุม และการกู้คืน หากบัญชีที่ถูกขโมยสามารถทะลุผ่านห่วงโซ่ทั้งหมดได้ สถาปัตยกรรมจำเป็นต้องมีขอบเขตที่แข็งแกร่งยิ่งขึ้น

การยืนยันตัวตนแบบหลายปัจจัยเพียงพอหรือไม่?

ไม่ การยืนยันตัวตนแบบหลายปัจจัย (MFA) นั้นจำเป็น แต่รูปแบบวิธีการนั้นสำคัญ CISA เตือนว่า MFA บางรูปแบบยังคงมีความเสี่ยงต่อการโจมตีแบบฟิชชิง การโจมตีแบบพุชแฟตตี้ การสลับซิม และการดักฟัง คำแนะนำของ CISA ระบุว่า MFA ที่ป้องกันฟิชชิงได้เป็นแนวทางที่แข็งแกร่งที่สุดและสามารถนำไปใช้ได้อย่างกว้างขวาง และแนะนำให้องค์กรต่างๆ ใช้ MFA ที่ใช้ FIDO/WebAuthn เป็นหลัก ดูคำแนะนำเกี่ยวกับ MFA ของ CISAได้ที่นี่

สำหรับ Northstar Pay นั่นหมายความว่า ผู้ดูแลระบบ นักพัฒนาที่มีสิทธิ์เข้าถึงระบบการผลิต เจ้าหน้าที่ฝ่ายการเงิน และเจ้าหน้าที่ฝ่ายช่วยเหลือด้านเทคนิค ไม่ควรพึ่งพารหัสผ่านและรหัสที่ถูกแฮ็กได้ง่าย หากมีวิธีการที่แข็งแกร่งกว่านั้น การกระทำที่มีความเสี่ยงสูงควรต้องได้รับการอนุญาตใหม่ทุกครั้ง แทนที่จะคิดว่าการเข้าสู่ระบบสำเร็จเมื่อไม่กี่ชั่วโมงก่อนหน้านี้พิสูจน์ได้ว่าผู้ใช้ยังคงน่าเชื่อถืออยู่

แนวทางปฏิบัติ:ให้ความสำคัญกับการยืนยันตัวตนแบบหลายปัจจัย (MFA) ที่ป้องกันการโจมตีแบบฟิชชิ่งสำหรับบัญชีที่มีสิทธิ์พิเศษและบัญชีที่เกี่ยวข้องกับการทำธุรกรรมทางการเงิน ลดระยะเวลาของเซสชันสำหรับคอนโซลที่มีความเสี่ยงสูง กำหนดให้มีการยืนยันตัวตนเพิ่มเติมเมื่อมีการเปลี่ยนแปลงข้อมูลที่ละเอียดอ่อน และตรวจสอบเหตุการณ์ MFA ที่ล้มเหลวหรือถูกปฏิเสธว่าเป็นสัญญาณด้านความปลอดภัย แทนที่จะเป็นเพียงสัญญาณรบกวนที่ไม่เป็นอันตราย

ในแวดวงฟินเทค คำว่า "ความไว้วางใจเป็นศูนย์" หมายความว่าอย่างไรกันแน่?

Zero Trust มักถูกเข้าใจผิดว่าเป็นผลิตภัณฑ์หรือกฎที่บอกว่า "อย่าไว้ใจใคร" NIST อธิบายไว้ชัดเจนกว่านั้นว่า: ความไว้วางใจไม่ควรได้รับโดยปริยายเพียงเพราะผู้ใช้ อุปกรณ์ หรือบริการนั้นอยู่ในเครือข่ายหรือเป็นขององค์กร การตรวจสอบสิทธิ์และการอนุญาตควรเน้นที่ผู้ใช้ ทรัพย์สิน และทรัพยากร เอกสารอ้างอิงพื้นฐานคือNIST SP 800-207, Zero Trust Architecture

เมื่อนำไปใช้กับ Northstar Pay วิศวกรที่เชื่อมต่อผ่านเครือข่ายขององค์กรจะไม่ได้รับสิทธิ์การเข้าถึงฐานข้อมูลอย่างกว้างขวางโดยอัตโนมัติ ไมโครเซอร์วิสจะไม่ได้รับความไว้วางใจเพียงเพราะมันทำงานอยู่ในคลัสเตอร์เดียวกัน สิทธิ์การเข้าถึงของผู้ดูแลระบบจะขึ้นอยู่กับตัวตน สถานะของอุปกรณ์ บทบาท บริบท และทรัพยากรเฉพาะที่ร้องขอ

แนวทางปฏิบัติ:ขจัดความไว้วางใจในวงกว้างที่อิงตามเครือข่าย แยกตัวตนของมนุษย์และบริการ บังคับใช้สิทธิ์ขั้นต่ำสุด หมดอายุการเข้าถึงที่ไม่ได้ใช้งานเป็นประจำ และกำหนดให้มีการอนุญาตอย่างชัดเจนระหว่างบริการที่มีความอ่อนไหว

การเข้ารหัสสามารถแก้ปัญหาการปกป้องข้อมูลทางการเงินได้หรือไม่?

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

หลักการออกแบบที่ดีกว่าคือการลดปริมาณข้อมูล: เก็บรวบรวมให้น้อยลง เก็บรักษาไว้ในระยะเวลาที่สั้นลง แปลงข้อมูลที่มีความอ่อนไหวเป็นโทเค็นหรือแยกส่วนเมื่อทำได้ และจำกัดว่าใครและอะไรสามารถถอดรหัสได้ สำหรับสภาพแวดล้อมการชำระเงินด้วยบัตร องค์กรควรพิจารณาว่า PCI DSS มีผลบังคับใช้กับขอบเขตของตนหรือไม่ ณ เดือนกันยายน 2026 เอกสารทางการของสภามาตรฐานความปลอดภัย PCI ระบุ PCI DSS v4.0.1 และข้อกำหนด v4.x ที่กำหนดในอนาคตมีผลบังคับใช้ตั้งแต่วันที่ 31 มีนาคม 2025 ดูเอกสารในคลังเอกสารของ PCI SSC

การปฏิบัติจริง:สร้างแผนผังการไหลของข้อมูลที่แสดงว่าข้อมูลสำคัญเข้ามาจากที่ใด จัดเก็บไว้ที่ใด บริการใดบ้างที่สามารถอ่านได้ เก็บรักษาไว้นานเท่าใด และลบออกอย่างไร จากนั้นลบสำเนาที่มีอยู่เพื่อความสะดวกเท่านั้น

เหตุใด API จึงเป็นขอบเขตด้านความปลอดภัยที่สำคัญยิ่ง?

ผลิตภัณฑ์ฟินเทคพึ่งพา API มากขึ้นเรื่อยๆ สำหรับการรวมบัญชี การชำระเงิน การตรวจสอบตัวตน การเชื่อมต่อกับพันธมิตร และระบบแบ็กเอนด์บนมือถือ นั่นทำให้ตรรกะการอนุญาตมีความสำคัญพอๆ กับความปลอดภัยในการรับส่งข้อมูล API อาจเข้ารหัสอย่างสมบูรณ์แบบด้วย TLS แต่ก็ยังอาจเปิดเผยข้อมูลของลูกค้ารายอื่นได้หากการอนุญาตในระดับวัตถุไม่ถูกต้อง ในทำนองเดียวกัน คีย์ API ที่รั่วไหลอาจกลายเป็นความเสี่ยงทางการเงินหากคีย์นั้นมีสิทธิ์การใช้งานกว้างขวางและไม่มีการจำกัดจำนวนธุรกรรม

ในกรณีของ Northstar Pay การออกแบบที่ปลอดภัยกว่าคือการให้สิทธิ์แก่แต่ละบริการเฉพาะที่จำเป็นเท่านั้น ใช้ข้อมูลประจำตัวที่มีอายุสั้นเมื่อทำได้ ตรวจสอบความถูกต้องของการอนุญาตในทุกคำขอที่มีความละเอียดอ่อน และใช้การควบคุมระดับธุรกิจ เช่น ขีดจำกัดจำนวนเงิน การตรวจสอบความเร็ว การป้องกันการเปลี่ยนแปลงผู้รับผลประโยชน์ และการตรวจจับความผิดปกติ

การดำเนินการเชิงปฏิบัติ:ทดสอบ API เพื่อตรวจสอบการละเมิดสิทธิ์ การเปิดเผยข้อมูลมากเกินไป ความเสี่ยงจากการโจมตีซ้ำ การจัดการความลับที่ไม่รัดกุม และการยกระดับสิทธิ์ พิจารณาการเคลื่อนย้ายเงินเป็นปัญหาด้านการควบคุมทางธุรกิจเช่นเดียวกับปัญหาด้านความปลอดภัยของแอปพลิเคชัน

การพัฒนาซอฟต์แวร์ที่ปลอดภัยควรเปลี่ยนแปลงไปอย่างไรสำหรับ FinTech?

การตรวจสอบความปลอดภัยที่ดำเนินการก่อนการวางจำหน่ายนั้นสายเกินไปสำหรับซอฟต์แวร์ทางการเงินที่มีการเปลี่ยนแปลงอย่างรวดเร็ว กรอบการพัฒนาซอฟต์แวร์ที่ปลอดภัยของ NIST แนะนำให้บูรณาการแนวทางการพัฒนาที่ปลอดภัยเข้ากับวงจรชีวิตของซอฟต์แวร์ เพื่อป้องกันช่องโหว่ ค้นพบช่องโหว่ได้เร็วขึ้น และแก้ไขที่ต้นเหตุ ปัจจุบันเอกสารฉบับสมบูรณ์คือNIST SP 800-218, SSDF เวอร์ชัน 1.1 NIST ได้เผยแพร่ฉบับแก้ไขเวอร์ชัน 1.2 เป็นฉบับร่างสาธารณะเบื้องต้นในเดือนธันวาคม 2025 ดังนั้นทีมงานควรแยกแยะความแตกต่างระหว่างเอกสารฉบับร่างกับเอกสารเวอร์ชัน 1.1 ฉบับสมบูรณ์

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

แนวทางปฏิบัติ:เพิ่มด่านตรวจสอบความปลอดภัยในขั้นตอนการพัฒนาโดยพิจารณาจากผลกระทบ การเปลี่ยนแปลงรูปลักษณ์ภายนอกของส่วนติดต่อผู้ใช้ไม่ควรต้องได้รับการตรวจสอบอย่างเข้มงวดเท่ากับการเปลี่ยนแปลงระบบการตรวจสอบสิทธิ์ ตรรกะการจ่ายเงิน การเข้ารหัส การควบคุมการเข้าถึง หรือข้อจำกัดในการทำธุรกรรม

ผู้ให้บริการภายนอกอาจกลายเป็นจุดอ่อนด้านความปลอดภัยของคุณได้หรือไม่?

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

สิ่งนี้สะท้อนให้เห็นในกฎระเบียบด้วยเช่นกัน กฎการคุ้มครองข้อมูลของคณะกรรมการการค้าแห่งสหรัฐอเมริกา (FTC) กำหนดให้สถาบันการเงินที่อยู่ภายใต้เขตอำนาจของ FTC ต้องมีมาตรการคุ้มครองข้อมูลลูกค้าและดำเนินการเกี่ยวกับผู้ให้บริการที่จัดการข้อมูลดังกล่าว กฎนี้ไม่ได้ใช้กับองค์กรฟินเทคทุกแห่งในทุกเขตอำนาจ ดังนั้นควรตรวจสอบความเหมาะสมกับกฎหมายหรือผู้เชี่ยวชาญด้านการปฏิบัติตามกฎระเบียบที่เกี่ยวข้อง ดูรายละเอียดเพิ่มเติมได้ที่กฎการคุ้มครองข้อมูลของ FTC

แนวทางปฏิบัติที่เป็นรูปธรรม:จัดประเภทผู้ให้บริการตามข้อมูลและสิทธิ์ที่พวกเขาได้รับ ไม่ใช่ตามมูลค่าของสัญญา กำหนดให้มีการตรวจสอบความปลอดภัยก่อนเริ่มงาน กำหนดความคาดหวังเกี่ยวกับการแจ้งเตือนการละเมิดข้อมูล ตรวจสอบผู้ให้บริการที่สำคัญ และวางแผนวิธีการดำเนินการต่อหรือปิดระบบอย่างปลอดภัยหากผู้ให้บริการไม่สามารถใช้งานได้

นอกเหนือจากการสำรองข้อมูลแล้ว การรับมือกับแรนซัมแวร์ในรูปแบบอื่น ๆ มีลักษณะอย่างไรบ้าง?

การสำรองข้อมูลมีความสำคัญ แต่การรับมือกับแรนซัมแวร์ยังต้องอาศัยการแบ่งส่วนเครือข่าย การปกป้องข้อมูลส่วนบุคคล การบันทึกข้อมูล การเสริมความแข็งแกร่ง การตอบสนองต่อเหตุการณ์ และการฝึกซ้อมการกู้คืนข้อมูล คำแนะนำ StopRansomware ของ CISA แนะนำให้แบ่งส่วนเครือข่ายและรักษาแผนผังเครือข่ายให้เป็นปัจจุบันอยู่เสมอ รวมถึงมาตรการอื่นๆ ดูรายละเอียดเพิ่มเติมได้ที่คู่มือStopRansomware ของ CISA

ในตัวอย่างของ Northstar Pay เป้าหมายไม่ใช่เพียงแค่การกู้คืนไฟล์ บริษัทต้องรู้ว่าข้อมูลประจำตัวการชำระเงินรั่วไหลหรือไม่ ข้อมูลลับที่ใช้ในการผลิตถูกเปลี่ยนแปลงหรือไม่ ข้อมูลธุรกรรมน่าเชื่อถือหรือไม่ และผู้โจมตียังคงสามารถเข้าถึงระบบได้หลังจากกู้คืนแล้วหรือไม่ การกู้คืนต้องฟื้นฟูความเชื่อมั่น ไม่ใช่แค่เวลาในการใช้งานระบบเท่านั้น

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

การบันทึกข้อมูลมากแค่ไหนถึงจะเพียงพอ?

การบันทึกข้อมูลควรตอบคำถามด้านความปลอดภัยทางธุรกิจ ไม่ใช่แค่คำถามด้านโครงสร้างพื้นฐาน โปรแกรมตรวจจับด้านเทคโนโลยีทางการเงิน (FinTech) ที่มีประโยชน์สามารถเชื่อมโยงเหตุการณ์ด้านการระบุตัวตน การเปลี่ยนแปลงอุปกรณ์ การเรียกใช้ API การเปลี่ยนแปลงผู้รับผลประโยชน์ การรีเซ็ตรหัสผ่าน การให้สิทธิ์ การสร้างโทเค็น การพยายามชำระเงิน ความเร็วในการจ่ายเงิน และกิจกรรมการบริหารจัดการที่ผิดปกติได้

ระบบ Northstar Pay ควรจะสามารถตรวจสอบการโอนเงินที่น่าสงสัยได้โดยไม่ต้องรวบรวมหลักฐานจากระบบต่างๆ สิบระบบด้วยตนเองหลังจากนั้น บันทึกข้อมูลยังต้องมีความสมบูรณ์ การเก็บรักษา การควบคุมการเข้าถึง และการซิงโครไนซ์เวลาที่แม่นยำ การบันทึกข้อมูลมากเกินไปอาจสร้างปัญหาด้านความเป็นส่วนตัวและค่าใช้จ่าย ดังนั้นเป้าหมายจึงอยู่ที่การมองเห็นข้อมูลที่มีคุณค่าสูงมากกว่าการรวบรวมทุกอย่างไว้ตลอดไป

การดำเนินการเชิงปฏิบัติ:กำหนดคำถามสำคัญ 10 ข้อที่ผู้ตรวจสอบต้องตอบเกี่ยวกับเหตุการณ์ และตรวจสอบว่าระบบข้อมูลทางไกลที่มีอยู่สามารถตอบคำถามเหล่านั้นได้ภายในไม่กี่นาที หากไม่สามารถทำได้ ให้อุดช่องโหว่ด้านการมองเห็นก่อนที่จะเพิ่มกฎการแจ้งเตือนเพิ่มเติม

บริษัทฟินเทคควรใช้กรอบการรักษาความปลอดภัยทางไซเบอร์แบบใด?

กรอบงานความปลอดภัยทางไซเบอร์ NIST เวอร์ชัน 2.0 (NIST Cybersecurity Framework 2.0) เป็นแบบจำลองการจัดระเบียบที่มีประโยชน์ เนื่องจากเน้นที่ผลลัพธ์มากกว่าการกำหนดชุดเทคโนโลยีใดชุดหนึ่ง CSF 2.0 ซึ่งเผยแพร่ในเดือนกุมภาพันธ์ 2024 ได้เพิ่มความสำคัญมากขึ้นในด้านการกำกับดูแลและความเสี่ยงในห่วงโซ่อุปทาน และมีจุดประสงค์สำหรับองค์กรทุกขนาดและทุกภาคส่วน หน้าที่หลักหกประการ ได้แก่ การกำกับดูแล (Governance), การระบุ (Identify), การป้องกัน (Protect), การตรวจจับ (Detect), การตอบสนอง (Respond) และการกู้คืน (Recover) ดูรายละเอียดเพิ่มเติมได้ที่กรอบงานความปลอดภัยทางไซเบอร์ NIST เวอร์ชัน 2.0

สำหรับ Northstar Pay นั้น CSF 2.0 สามารถเป็นแผนที่นำทางได้ ในขณะที่มาตรฐานเฉพาะเจาะจงและข้อผูกพันด้านกฎระเบียบจะให้รายละเอียดเพิ่มเติม PCI DSS อาจควบคุมสภาพแวดล้อมข้อมูลผู้ถือบัตร กฎ FTC Safeguards Rule อาจใช้กับสถาบันการเงินบางแห่ง หน่วยงานทางการเงินที่อยู่ภายใต้การกำกับดูแลของรัฐนิวยอร์กอาจมีข้อผูกพันภายใต้ 23 NYCRR Part 500 ศูนย์ทรัพยากรด้านความปลอดภัยทางไซเบอร์ของกรมบริการทางการเงินแห่งรัฐนิวยอร์กมีแหล่งข้อมูลด้านกฎระเบียบและการปฏิบัติตามอย่างเป็นทางการ

แนวทางปฏิบัติ:สร้างแผนผังควบคุมเดียวที่เชื่อมโยงความเสี่ยงทางธุรกิจเข้ากับการควบคุมภายในหลักเพียงหนึ่งเดียว จากนั้นจึงกำหนดแผนผังควบคุมนั้นให้สอดคล้องกับกรอบการทำงานหรือข้อบังคับที่เกี่ยวข้องทั้งหมด หลีกเลี่ยงการดำเนินงานด้านความปลอดภัยที่แยกต่างหากและไม่เชื่อมโยงกันสำหรับแต่ละข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ

ผู้นำควรวัดผลอะไรบ้าง?

การนับเฉพาะจำนวนการโจมตีที่ถูกบล็อกหรือช่องโหว่ที่เปิดอยู่เพียงอย่างเดียวอาจทำให้ผู้บริหารเข้าใจผิดได้ ตัวชี้วัดที่ดีกว่าจะแสดงให้เห็นว่าองค์กรสามารถป้องกัน ตรวจจับ ควบคุม และฟื้นตัวจากเหตุการณ์ที่มีผลกระทบทางการเงินได้หรือไม่ ตัวอย่างเช่น เปอร์เซ็นต์ของบัญชีผู้ใช้ที่มีสิทธิ์พิเศษที่ใช้ MFA ที่ป้องกันการฟิชชิ่ง เวลาในการยกเลิกเซสชันที่ถูกบุกรุก เปอร์เซ็นต์ของบริการที่สำคัญที่มีการกู้คืนที่ผ่านการทดสอบ ช่องโหว่ที่มีความเสี่ยงสูงที่เกิน SLA บัญชีผู้ใช้ที่มีสิทธิ์พิเศษที่ไม่ได้ใช้งาน ความครอบคลุมด้านความปลอดภัยของผู้จำหน่ายที่สำคัญ และเวลาเฉลี่ยในการตรวจจับพฤติกรรมทางการเงินที่ผิดปกติ

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

แนวทางปฏิบัติ:รายงานตัวชี้วัดด้านความปลอดภัยจำนวนเล็กน้อยควบคู่ไปกับกระบวนการทางการเงินที่ตัวชี้วัดเหล่านั้นปกป้อง ระบุผู้รับผิดชอบอย่างชัดเจน: การควบคุมที่มีความเสี่ยงสูงทุกตัวควรมีผู้รับผิดชอบทางธุรกิจ ผู้รับผิดชอบทางเทคนิค และหลักฐานที่แสดงว่าการควบคุมนั้นใช้งานได้จริง

รูปแบบความปลอดภัยที่ใช้งานได้จริงสำหรับยุคฟินเทค

กรณีของ Northstar Pay แสดงให้เห็นถึงบทเรียนที่สำคัญกว่านั้น นั่นคือ ความปลอดภัยทางไซเบอร์ทางการเงินสมัยใหม่ขึ้นอยู่กับการตัดสินใจเรื่องความไว้วางใจหลายชั้น รหัสผ่านที่ถูกขโมยควรได้รับการตรวจสอบโดย MFA ที่ป้องกันการฟิชชิ่ง เซสชันที่ถูกขโมยควรมีการอนุญาตที่จำกัดและสิทธิ์การใช้งานที่สั้น บริการที่ถูกบุกรุกควรมีการแบ่งส่วนและการควบคุมเอกลักษณ์ของบริการ การโอนเงินที่ฉ้อโกงควรมีการตรวจสอบและติดตามตามกฎทางธุรกิจ เหตุการณ์แรนซัมแวร์ควรมีการกู้คืนแบบแยกส่วนและการตอบสนองต่อเหตุการณ์ที่ได้รับการฝึกฝนมาแล้ว

ไม่มีกรอบการทำงาน อัลกอริทึมการเข้ารหัส ใบรับรองการปฏิบัติตามข้อกำหนด หรือผลิตภัณฑ์รักษาความปลอดภัยใด ๆ ที่สามารถรับประกันได้ว่าแพลตฟอร์มฟินเทคจะไม่ถูกเจาะระบบ สิ่งที่องค์กรสามารถทำได้คือลดโอกาสที่จะเกิดการบุกรุก จำกัดขอบเขตความเสียหายเมื่อระบบควบคุมล้มเหลว ตรวจจับการละเมิดได้เร็วขึ้น และกู้คืนระบบพร้อมหลักฐานที่แสดงให้เห็นว่าระบบและบันทึกทางการเงินสามารถเชื่อถือได้อีกครั้ง

การลงมือปฏิบัติจริง:เริ่มต้นด้วยเส้นทางการใช้งานของลูกค้าที่สำคัญที่สุดเส้นหนึ่ง เช่น การกู้คืนบัญชีหรือการโอนเงิน และตรวจสอบทุกข้อมูลประจำตัว API ที่เก็บข้อมูล ผู้ขาย สิทธิ์ สัญญาณการตรวจจับ และการพึ่งพาการกู้คืนที่เกี่ยวข้อง การตรวจสอบแบบนี้มักจะเปิดเผยความเสี่ยงที่สามารถนำไปปฏิบัติได้มากกว่ารายการตรวจสอบความปลอดภัยทั่วไปอีกรายการหนึ่ง