การจัดการบันทึก PCI DSS

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

นอกเหนือจากการกำหนดมาตรฐานอุตสาหกรรมสำหรับข้อมูลผู้ถือบัตร (CD) แล้ว มาตรฐานความปลอดภัยของข้อมูลอุตสาหกรรมบัตรชำระเงินหรือ PCI-DSS ยังบังคับใช้มาตรฐานเหล่านี้ด้วยบทลงโทษสำหรับการละเมิด

PCI-DSS เกี่ยวข้องอะไรกันแน่?

ย้อนกลับไปในช่วงต้นปี 2000 ผู้นำระดับโลกทั้งห้าในการทำธุรกรรมด้วยบัตรชำระเงิน: American Express, MasterCard, Discover Financial Services, Visa Inc. และ JCB International ได้พบกันเพื่อเปิดตัว Payment Card Industry-Security Standards Council หรือ PCI-SSC สภาได้กำหนดมาตรฐานความปลอดภัยของข้อมูลสำหรับการประมวลผลการชำระเงินโดยมีเป้าหมายสองประการ:

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

จากการพิจารณาของ PCI-SSC สิ่งที่เรารู้ในปัจจุบันว่าเป็น "แนวทางปฏิบัติที่ดีที่สุด" ของอุตสาหกรรมการ์ดในการปกป้องข้อมูลและข้อมูลการชำระเงินของลูกค้า ในไม่ช้าก็ถูกทำให้เป็นมาตรฐานใน PCI-DSS

บทลงโทษสำหรับการไม่ปฏิบัติตาม PCI-DSS

แม้ว่า PCI-DSS ถูกกำหนดให้เป็น "มาตรฐานอุตสาหกรรม" เท่านั้น แทนที่จะเป็นข้อบังคับ การปฏิบัติตามมาตรฐานนั้นยังห่างไกลจากตัวเลือก การไม่ปฏิบัติตามข้อกำหนดสามารถเป็นการทำลายล้างที่สำคัญต่อธุรกิจของคุณในฐานะผู้ขายได้ บริษัทบัตรและธนาคารที่รับบัตรอาจถูกปรับระหว่าง 5,000 ถึง 100,000 ดอลลาร์ต่อเดือน หากไม่ปฏิบัติตาม ค่าปรับดังกล่าวอาจเป็นโทษประหารชีวิตสำหรับ SMEs

การปฏิบัติตาม PCI-DSS นั้นบังคับ หรือไม่

ใช่แล้ว! ไม่ว่าคุณจะอยู่ในธุรกิจขนาดใดหรืออยู่ในอุตสาหกรรมใดก็ตาม หากคุณยอมรับ ส่ง หรือจัดเก็บข้อมูลผู้ถือบัตร การปฏิบัติตาม PCI-DSS ก็เป็นสิ่งจำเป็น

ข้อกำหนด PCI-DSS 10: มันคืออะไร?

ข้อกำหนดนี้เกี่ยวข้องกับการตรวจสอบการเข้าถึงทั้งเครือข่ายและข้อมูล มันระบุ: ติดตามและตรวจสอบการเข้าถึงทรัพยากรเครือข่ายและข้อมูลผู้ถือบัตรทั้งหมด

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

ด้วย 39 ส่วนย่อยที่ระบุความต้องการ ข้อกำหนด 10 เน้นว่าคุณจะตรวจสอบการเข้าถึงของผู้ใช้และกิจกรรมในสภาพแวดล้อมของคุณอย่างต่อเนื่อง การควบคุมการเข้าถึงของผู้ใช้ช่วยให้คุณมั่นใจได้ถึงสภาพแวดล้อมข้อมูลผู้ถือบัตรที่ปลอดภัย (CDE) นอกจากนี้ เนื่องจาก PCI-DSS เป็นชุดมาตรฐานที่มีการกำหนดไว้ล่วงหน้า จึงกำหนดรายการขั้นตอน กระบวนการ และเอกสารที่จำเป็นต่อการปฏิบัติตามข้อกำหนดอย่างละเอียด

การปฏิบัติตามข้อกำหนด 10: ต้องมีบันทึกอะไรบ้าง

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

• ออกแบบระบบ/กระบวนการที่เชื่อมต่อผู้ใช้เข้ากับส่วนต่างๆ ของระบบที่เข้าถึงได้ และมั่นใจได้ว่าคุณสามารถติดตามกิจกรรมที่น่าสงสัยไปยังแหล่งที่มาได้
• สร้างเส้นทางการตรวจสอบที่แสดงให้เห็นว่าผู้ดูแลระบบสามารถรับการแจ้งเตือนกิจกรรมที่น่าสงสัยและตอบสนองได้อย่างไร
• บันทึกรายการการเข้าถึงแต่ละรายการใน CDE เพื่อพิสูจน์ว่าไม่มีผู้ใช้ที่ไม่ได้รับอนุญาตเข้าถึงระบบ เครือข่าย และข้อมูล
• ตรวจสอบให้แน่ใจว่าคุณได้บันทึกกิจกรรมทั้งหมดที่ดำเนินการโดยบัญชี "ผู้ดูแลระบบ/รูท" ที่แสดงการใช้สิทธิ์ในทางที่ผิดอย่างชัดเจนและติดตามการละเมิดไปยังแหล่งที่มาเฉพาะ
• รักษาความสมบูรณ์ของไฟล์ของบันทึกการตรวจสอบโดยใช้วิธีการเพื่อระบุการเปลี่ยนแปลง เพิ่มเติม หรือการลบไฟล์เหล่านั้น
• จดบันทึกความพยายามเข้าสู่ระบบที่ไม่ถูกต้อง/ผิดกฎหมายเพื่อติดตามการเดารหัสผ่านและการโจมตีด้วยการแฮ็กแบบเดรัจฉาน
• เอกสารที่ให้คุณติดตามการจัดการกิจกรรมการรับรองความถูกต้องที่พยายามเลี่ยงการควบคุม
• บันทึกการหยุดชั่วคราว/รีสตาร์ทไปยังกระบวนการบันทึกการตรวจสอบของระบบของคุณ
• เก็บบันทึกเพื่อแสดงให้เห็นว่าอ็อบเจ็กต์ระดับระบบเช่นฐานข้อมูลหรือกระบวนงานที่เก็บไว้ไม่ได้ถูกสร้าง/ลบผ่านบัญชีผู้ใช้ที่ไม่ได้รับอนุญาต
• สร้างบันทึกเหตุการณ์เพื่อบันทึก ID ผู้ใช้ ประเภทเหตุการณ์ การประทับเวลา ตัวบ่งชี้ความสำเร็จ/ความล้มเหลว การเกิดเหตุการณ์ ข้อมูลที่ได้รับผลกระทบ องค์ประกอบของระบบที่ได้รับผลกระทบ และเอกลักษณ์/ชื่อทรัพยากร
• ซิงโครไนซ์นาฬิกาในส่วนประกอบของระบบเพื่อเก็บแท็บของลำดับเหตุการณ์ที่แน่นอนสำหรับทีมนิติเวช
• ใช้ "หลักการของสิทธิ์น้อยที่สุด" ในการเข้าถึงบันทึกการตรวจสอบเพื่อให้มั่นใจในความสมบูรณ์และความปลอดภัยของข้อมูล
• สำรองข้อมูลบันทึกไปยังเซิร์ฟเวอร์/สื่อแบบรวมศูนย์ที่รับประกันความสมบูรณ์ของข้อมูล
• เขียนบันทึกโดยตรงหรือถ่าย/คัดลอกจากแหล่งภายนอกไปยังระบบภายในที่ปลอดภัย
• รวมการตรวจสอบความสมบูรณ์ของไฟล์และกลไกการตรวจจับการเปลี่ยนแปลงเพื่อตรวจจับการเปลี่ยนแปลงบันทึกการตรวจสอบในกรณีที่มีช่วงวันที่ไม่ตรงกัน
• ตรวจสอบบันทึกเป็นประจำ ไม่ว่าจะด้วยตนเองหรือผ่านการเก็บเกี่ยวบันทึก การแยกวิเคราะห์ และเครื่องมือแจ้งเตือน
• ตรวจสอบการควบคุมความปลอดภัยทุกวันสำหรับการแจ้งเตือนเกี่ยวกับบันทึกองค์ประกอบของระบบที่สำคัญ เช่น กิจกรรมที่น่าสงสัย
• กำหนดเวลาการตรวจสอบเป็นประจำสำหรับส่วนประกอบระบบทั้งหมดที่เปิดเผยปัญหาที่อาจเกิดขึ้นหรือความพยายามในการเข้าถึงระบบที่ละเอียดอ่อนโดยไม่ได้รับอนุญาตผ่านระบบที่มีความละเอียดอ่อนน้อยกว่า
• ติดตามการตรวจสอบข้อยกเว้น/ความผิดปกติ
• เก็บรักษาบันทึกทั้งหมดเป็นเวลาอย่างน้อยหนึ่งปี
• ตรวจสอบให้แน่ใจว่าพนักงานตระหนักถึงนโยบายความปลอดภัยและการตรวจสอบของพวกเขา

ข้อกำหนดเพิ่มเติมสำหรับผู้ให้บริการ

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

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

มีความคิดเกี่ยวกับเรื่องนี้หรือไม่? แจ้งให้เราทราบด้านล่างในความคิดเห็นหรือดำเนินการสนทนาไปที่ Twitter หรือ Facebook ของเรา

คำแนะนำของบรรณาธิการ:

• กำหนดขอบเขตการตรวจสอบ SOC2
• ข้อกำหนดในการตรวจสอบ – บริษัทเอกชนในสหรัฐอเมริกา
• แผนการจัดการความเสี่ยง – มีไว้เพื่ออะไร?
• กลยุทธ์การวิเคราะห์ข้อมูลประสิทธิภาพการตรวจสอบภายใน
• จัดลำดับความสำคัญความเสี่ยงในการจัดการโครงการ