ครบรอบ 1 ปี WannaCry ความตระหนักที่กำลังเลือนหายไปตามกาลเวลา

13 พฤษภาคม 2017 เป็นวันที่เกิดการระบาดของ WannCry Ransomware แม้ว่าบางรายงานบอกว่าเป็นวันที่ 12 แต่เนื่องจากประเทศไทยตื่นมารับรู้ในวันที่ 13 เพราะ Time Zone ที่เร็วกว่ายุโรปที่ได้รับรายงานการระบาดเป็นจุดแรก ผมขอใช้วันนี้ก็แล้วกัน

อันที่จริงมัลแวร์ลูกผสมไม่ได้เป็นเรื่องที่น่าแปลกใจนักสำหรับผู้เชี่ยวชาญด้าน Information Security จำได้ว่าตอนที่เดินทางขึ้นไปขอนแก่นเพื่อร่วมงานแต่งงานของเจ้าของบริษัททำ Penetration Testing ท่านหนึ่ง บรรดาผู้เชี่ยวชาญหลายคนที่นั่งรถไปคันเดียวกับผมก็ได้วิเคราะห์เรื่องมัลแวร์ต่างๆ และหนึ่งในการทำนายถึงมัลแวร์ที่จะเกิดขึ้นก็คือลูกผสมของ Ransomware กับ Worm เพียงแค่ปีเดียวสิ่งที่ทำนายก็เกิดขึ้น

สำหรับผม มันเป็นความทรงจำที่ออกจะแปลกประหลาดไม่น้อย เพราะเป็นช่วงที่บินไปยังบาหลีเพื่อร่วมสัมมนา Cyber Security Exchange for FSI ซึ่งผมบินไปก่อน 2 วัน (วันเสาร์) เพื่อพักผ่อน ปกติแล้วผมจะอ่าน News Feed ทุกเช้าและเริ่มสัมผัสได้ว่าการระบาดของ WannaCry น่าจะสาหัส จึงได้ส่งข้อความลงไปใน Line กลุ่มของหัวหน้าทีม IT ของธนาคารก่อนขึ้นเครื่องบิน พร้อมบอกวิธีเตรียมการคร่าวๆ เพื่อรับมือวันจันทร์ที่เปิดงาน จากข้อมูลเท่าที่มีอยู่ตอนนั้น พอลงเครื่องมาก็เริ่มมีการคุยกันต่อเนื่องใน Line ตั้งแต่ยังไม่ออกจาก ตม. จนนั่งรถไปถึงโรงแรม ขอเล่าเพื่อไม่เสียเวลาสรุปว่าทีม Infrastructure และ IT Service เตรียมการทุกอย่างพร้อมในวันอาทิตย์ เพื่อรอการเปิดทำงานวันจันทร์ เป็นการคุยงานไป เดินชายหาดไป ว่ายน้ำไป ประมาณนี้

นอกจากงานของธนาคารตัวเองแล้ว ก็ยังต้องมาช่วยเกลาและเรียบเรียงเอกสารเผยแพร่ในนาม Information Sharing Group (ISG ซึ่งต่อมาเป็น TB-CERT) ร่วมกับเพื่อนๆ ตัวแทนของธนาคารต่างๆ ด้วย และน่าจะเป็นเอกสารเผยแพร่ฉบับแรกๆ ของทีม

เป็นการพักผ่อนที่ประหลาดดี

ผมขอรวบรวมเรื่องที่ประสบพบเจอในระหว่างการระบาดทั้งบทเรียนที่ผมได้รับ ทั้งเรื่องดีและไม่ดี รวมๆ กันไปนะครับ

1. ระหว่างช่วงชุลมุนและยังได้ข้อมูลไม่ครบ แต่จำเป็นต้องสั่งการ ผมเองเลือกที่สั่งเกินความจำเป็นไปนิด ในกรณีนี้ตอนที่ยังไม่มีข้อมูลที่ชัดเจนว่าโจมตีผ่านช่องโหว่ Ethernal Blue เท่านั้น (SMBv1) ด้วยความที่เป็น Ransomware ผมเลยสั่งให้ Monitor ช่องทาง Mail และ Web Site ไปด้วย อย่างไรก็ตามหลังจากมานั่งคิดว่าถ้าย้อนกลับไปสั่งการใหม่ จะเป็นแบบเดิมไหม คำตอบก็ยังเป็นแบบเดิมอยู่ดี 
2. หน่วยงาน Regulator ติดตามอย่างกับโดน Compromised ไปแล้ว เอิ่มสถานการณ์ Malware Outbreak จัดการคนละแบบกับการโดน Targeted Attacks นะขอรับ
3. บรรดากูรูเกิดขึ้นมาอย่างกับดอกเห็ด มั่วซะเป็นส่วนใหญ่ แถมตอน Spectre/Meltdown ก็ด้วย มีอะไรเกิดอีก ก็เดาได้เลยว่ามีกูรูเกิดขึ้นมาใหม่อย่างแน่นอน มีบางคนมาบอกผมว่ากูรูบางคนพูดออกทีวีอย่างดิบดีว่าทำอย่างนี้ป้องกันได้แน่นอน แต่ว่าเอกสาร WannaCry Analysis ในมือผมบอกว่า ทำอย่างที่กูรูบอกไม่มีประโยชน์อันใด ขอร้องกูรูอ่านเยอะๆ ดีกว่านะครับ
4. หน่วยงานรัฐออก Infographics ไม่ได้ฟังคำท้วงติงของผู้เชี่ยวชาญด้าน Information Security ที่มีข้อมูลอ้างอิงในมือว่าควรสื่อสารอย่างไร ผมก็ไม่แน่ใจว่าการสอบทานเป็นอย่างไร หวังว่าคงไม่ฟังคนที่ไม่มีข้อมูลที่แท้จริงในมือแล้วสื่อสารออกไปผิดๆ หรือตอนนั้นเพียงคิดว่านี่เป็น Ransomware ตัวหนึ่ง
5. อาจารย์มหาวิทยาลัยแห่งหนึ่งเขียนโปรแกรมเพื่อหลอก WannaCry ว่าเครื่องฉันติดแกแล้ว ไม่ต้อง Load ตัวเองขึ้นมาอีก มีการออกข่าวใหญ่โต สุดท้ายได้ประกาศเป็นผู้ทำงานด้าน Security ยอดเยี่ยมประจำปีที่แล้ว ในขณะที่ผู้เชี่ยวชาญ Information Security ทั่วโลกบอกว่า ลง Patch เถอะครับ ย้อนแย้งจริงๆ

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

ไว้นึกอะไรออกอีก จะมาใส่ไว้ก็แล้วกัน

Identity Proofing vs Authentication

Identity Proofing = การพิสูจน์อัตลักษณ์
Authentication = การพิสูจน์ตัวจริง (ศัพท์บัญญัติราชบัณฑิตยสถาน - เทคโนโลยีสารสนเทศ ๑๑ มี.ค. ๒๕๔๕)

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

Identity Proofing

Identity Proofing เป็นกระบวนการที่พิสูจน์ว่าบุคคลคนนั้นเป็นคนเดียวกันกับบุคคลที่กล่าวอ้างหรือไม่ ในที่นี้จะกล่าวถึงการทำ Identity Matching แบบ one to one เท่านั้น ไม่รวมไปถึงการพิสูจน์อัตลักษณ์ว่าบุคคลนี้เป็นใครซึ่งเป็นการทำ Identity Matching แบบ one to many

กระบวนการนี้เป็นกระบวนการที่สำคัญมากในการสร้างข้อมูลตัวตนใน Digital Identity Platform นอกจากนั้นยังเป็นกระบวนการเดียวกันกับการทำ KYC (Know Your Customer) อย่างไรก็ตาม Identity Proofing ทำได้หลายแบบซึ่งแต่ละแบบมีความแม่นยำถูกต้องไม่เท่ากัน แต่หลักการก็คือเป็นการพิสูจน์ข้อมูลเฉพาะบุคคลที่ได้รับการยืนยันจากบุคคลที่สาม

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

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

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

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

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

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

Authentication

Authentication เป็นกระบวนการที่ใช้ในการตรวจสอบผู้มีสิทธิ์เข้าใช้บริการ ทำธุรกรรม หรือใช้ทรัพยากรที่บุคคลนั้นเป็นเจ้าของ แต่ไม่ได้บอกว่าผู้มีสิทธิ์นั้นเป็นบุคคลใดหากไม่ได้ทำ Identity Proofing มาก่อน ตัวอย่างเช่น หากเราใช้บริการของ Google ที่ต้องใช้ทรัพยากรแยกตามบุคคลเช่น Gmail, Drive หรือ Play Store เราต้องสมัคร Google Account ซึ่งจะมีวิธี Authentication พื้นฐานโดยใช้ Gmail Address กับ Password การสมัครนั้นเราไม่จำเป็นให้ข้อมูลส่วนบุคคลที่ถูกต้อง เพราะ Google ไม่ได้ทำ Identity Proofing ดังนั้น Google Account โดยทั่วไปแล้วจึงไม่สามารถระบุอัตลักษณ์ได้ และนี่คือสาเหตุที่ Authentication ไม่สามารถทำการแทน Identity Proofing ได้

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

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

มีผู้นิยามเกี่ยวกับ Strong Authentication อยู่หลายหน่วยงาน สามารถอ่านได้จาก https://en.wikipedia.org/wiki/Strong_authentication แต่ผมขอจำแนกมิติของการตรวจสอบไว้ดังนี้

มิติแรกปัจจัยในการตรวจสอบ (Factor) ซึ่งตามตำราด้าน Information Security มี 3 ปัจจัยก็คือ สิ่งที่คุณรู้ (Something You Know) สิ่งที่คุณมี (Something You Have เช่นโทรศัพท์มือถือ Google Authenticator) และสิ่งที่คุณเป็น (Something You Are เช่น ลายนิ้วมือ ม่านตา หรือใบหน้า) ความแข็งแรงในการตรวจสอบก็คือ สิ่งที่คุณรู้ ด้อยกว่า สิ่งที่คุณมี และสิ่งที่คุณเป็นจะมีความแข็งแรงสูงสุด อย่างไรก็ตามการใช้สิ่งที่คุณเป็นในการตรวจสอบมีความเสี่ยงมากที่สุดหากมีการปลอมแปลงได้ เพราะเป็นกลุ่มเดียวที่คุณเปลี่ยนไม่ได้ ไม่ว่าจะเป็นลายนิ้วมือ (แม้จะเปลี่ยนนิ้วได้) ม่านตา หรือใบหน้า

มิติที่สองคือจำนวนของปัจจัยที่ใช้ในการตรวจสอบ (Number of Factor) จำนวนปัจจัยที่มากขึ้นย่อมทำให้ Authentication แข็งแรงมากขึ้น ยกตัวอย่างที่เราคุ้นเคยก็ได้แก่ 2-Factor Authentication ที่ใช้รหัสผ่านเป็นปัจจัยแรก และใช้ SMS OTP ส่งไปยังเบอร์โทรศัพท์มือถือที่เรามีเป็นปัจจัยที่สอง

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

ตัวอย่างของกระบวนการที่แข็งแรงและน่าเชื่อถือได้แก่ Challenge-Response Authentication ที่ใช้เทคนิคด้าน Cryptographics เข้ามาช่วยทำให้ไม่สามารถดักจับหรือขโมยข้อมูลเพื่อใช้ในการทำซ้ำได้ ซึ่งมีหลายวิธี หนึ่งในวิธีที่แพร่หลายได้แก่วิธีที่เสนอโดย FIDO (Fast IDentity Online) Alliance นอกจากนั้น Authentication แบบหลายปัจจัยที่ใช้ช่องทางในการสื่อสารแตกต่างกัน (Out of Band Authentication) ก็เป็นอีกกระบวนการหนึ่งทำให้ยากต่อการปลอมแปลงหรือหลอกลวงผู้ใช้งานเช่นกัน

ความน่าเชื่อถือของ Digital ID

เนื่องจาก Digital ID ต้องพึ่งพาทั้งกระบวนการ Identity Proofing และ Authentication ดังนั้นทั้งสองกระบวนการต้องน่าเชื่อถือทั้งคู่ ทั้งนี้ความน่าเชื่อถือขึ้นอยู่กับระดับความเสี่ยงที่ยอมรับได้ของผู้ที่เกี่ยวข้องในระบบอย่างไรก็ตามสามารถอธิบายให้เห็นภาพได้ดังนี้

หากกระบวนการ Identity Proofing ไม่มีความน่าเชื่อถือแม้ว่ากระบวนการ Authentication จะมีความน่าเชื่อถือมาก เราก็มีโอกาสที่จะได้ Digital ID ของตัวปลอม ที่น่าเชื่อถือทุกครั้งที่ทำธุรกรรม

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

ที่จริงแล้ว Identity Proofing และ Authentication ที่น่าเชื่อถือนั้นไม่เพียงพอ ยังต้องมีองค์ประกอบอื่นๆ เช่น ความสามารถในการป้องกันการหลอกลวงโดยที่เจ้าของ Identity ไม่รู้ตัวได้ (Identity Retention) เป็นต้น เพื่อเสริมความน่าเชื่อถือของ Digital ID

อย่างไรก็ตามเป้าหมายของบทความตอนนี้เพื่อจะปูพื้นฐานให้เข้าใจเรื่อง Identity Proofing และ Authentication เพื่อที่จะกล่าวถึงเรื่อง Identity Assurance Level (IAL) และ Authenticator Assurance Level (AAL) ในตอนต่อๆ ไป

National Digital Identity: Chapter 2 ความพยายามในการรวมโครงการที่เกี่ยวข้องมาอยู่ด้วยกัน

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

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

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

• การพัฒนาระบบกลางในการยืนยันตัวตนออนไลน์ (Digital Authentication) ที่เป็นส่วนหนึ่งในโครงการพัฒนาระบบอำนวยความสะดวกในการประกอบธุรกิจแบบครบวงจร (Doing Business Portal)
• โครงการ Cross verification ของธนาคารแห่งประเทศไทย (ธปท.)
• โครงการ e-Concent ของบริษัท ข้อมูลเครดิตแห่งชาติ จำกัด (National Credit Bureau - NCB)
• โครงการ eKYC ของกลุ่มตลาดทุนโดยมีคณะกรรมการกำกับหลักทรัพย์และตลาดหลักทรัพย์ (กลต.) เป็นผู้เริ่มต้น
• โครงการอื่นๆ อีกที่คล้ายกันซึ่งผมจำชื่อไม่ได้

ในการพูดคุยครั้งนั้นก็ได้เชิญหน่วยงานที่เข้ามาร่วมนอกจาก ETDA ก็คือตัวแทนจากกระทรวงการคลัง EGA ธนาคารต่างๆ ประมาณ 7-8 แห่ง กลต. ธปท. (มีหน่วยงานอื่นอีกแต่จำได้แค่นี้) ในการประชุมกว่าจะนิยามถึงเรื่อง Identity  และองค์ประกอบที่เกี่ยวข้องกับการพิสูจน์ตัวตน ของทุกคนให้ตรงกันก็ใช้เวลาไปสองสามครั้ง ใช้เวลาประมาณ 3 สัปดาห์ ก่อนที่จะตกลงกันที่จะใช้คำนิยามให้ตรงกัน ในวันที่ตกลงให้คำนิยามนั้นผมไม่ได้อยู่ด้วย แต่ดูเหมือนว่าจะอ้างมาจาก NIST SP 800-63 Digital Identity Guidelines (คนที่อยู่ในที่ประชุมช่วยมาแก้ให้ผมด้วยนะถ้าผิด) โดยจำแนกบทบาทที่สำคัญ ได้แก่

Relying Party (RP)
An entity that relies upon the subscriber’s authenticator(s) and credentials or a verifier’s assertion of a claimant’s identity, typically to process a transaction or grant access to information or a system.
หรือสรุปง่ายๆก็คือ ผู้ให้บริการทำธุรกรรมใดๆก็ตาม เช่น ให้กู้เงิน ขายของออนไลน์ เป็นต้น

Identity Provider (IdP)
The party that manages the subscriber’s primary authentication credentials and issues assertions derived from those credentials. This is commonly the CSP (Credential Service Provider) as discussed within this document suite.
ซึ่งก็คือผู้ให้บริการยืนยันตัวตน ถ้าเปรียบเทียบให้เห็นภาพ ก็เช่น Facebook หรือ Google ให้บริการยืนยันตัวตนกับเว็บไซต์อื่น แต่ในนิยามจริงๆ IdP ทำหน้าที่มากกว่านั้น

Authoritative Source (AS)
An entity that has access to, or verified copies of, accurate information from an issuing source such that a CSP (IdP) can confirm the validity of the identity evidence supplied by an applicant during identity proofing. An issuing source may also be an authoritative source. Often, authoritative sources are determined by a policy decision of the agency or CSP (IdP) before they can be used in the identity proofing validation phase.
คือผู้ที่มีข้อมูลที่เที่ยงตรงและเชื่อถือได้และพร้อมที่จะส่งให้ผู้อื่นเมื่อมีการตรวจสอบการยืนยันตัวตนของเจ้าของข้อมูลมาครบถ้วน ตามเงื่อนไขที่กำหนดไว้ ตัวอย่าง AS เช่น บริษัท ข้อมูลเครดิตแห่งชาติ จำกัดพร้อมที่จะส่งข้อมูลเครดิตของบุคคลเมื่อบุคคลนั้นได้ยืนยันตัวตนและยินยอมให้ส่งข้อมูลนั้น กับธนาคาร (ในที่นี้คือ RP) ที่บุคคลนั้นขอสินเชื่อ

โดยที่แต่ละหน่วยงานสามารถมีบทบาทใดบทบาทหนึ่งหรือมากกว่าก็ได้เช่น ธนาคารสามารถเป็น RP ให้บริการสินเชื่อ ในขณะเดียวกันก็เป็น IdP ให้บริการยืนยันตัวตนได้ และสามารถเป็น AS เพื่อให้ข้อมูล เช่นรายการเดินบัญชี (Bank Statement) เพื่อไปขอสินเชื่อกับธนาคารอื่น เป็นต้น

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

ส่วนสุดท้ายก็คือแพลตฟอร์มกลางที่จะเชื่อม หน่วยงานที่มีบทบาทต่างๆ ตามที่เขียนไว้ด้านบนนั้น ในเวลานั้นมีการตั้งชื่อว่า Universal Identity Platform ซึ่งภายหลังมาเปลี่ยนชื่อเป็น National Digital Identity Infrastructure

ความสัมพันธ์ระหว่าง Universal Identity Platform กับ RP, IdP, AS และ RA

จากนั้นดร.อนุชิต ก็พยายามที่จะให้ผู้ร่วมประชุมแสดงความคิดเกี่ยวกับการออกแบบโครงสร้าง Digital Identity แต่ก็เกิดปัญหาว่าแต่ละคนไม่สามารถที่จะเริ่มต้นอธิบายเพื่อแสดงความคิดไปในแนวทางเดียวกันได้ บ้างก็มีการนำเสนอที่ลอกแบบมาจากต่างประเทศ บางคนก็มีเฉพาะ Component Diagram ผมจึงได้เริ่มเขียน Business Process  เบื้องต้น รวมทั้ง Process ที่อยากเห็นให้กับดร.อนุชิต โดยมีรายการดังนี้

1. Identity Registration
• Individual Identity Registration
• Additional Authentication Provider
• Juristic Person Identity Registration/Change
2. Authentication
3. Information Request
4. Delegation
5. De-registration
6. Expiration
7. Renewal

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

ขอจบบทที่ 2 ตรงนี้ก่อน

National Digital Identity: Chapter 1 ผมมาเกี่ยวข้องกับโครงการนี้ได้อย่างไร

โครงการ Digital Identity ของประเทศไทย

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

ขอย้อนกลับไปตั้งแต่สมัยผมทำงานให้กับบริษัท IT ชั้นนำแห่งหนึ่ง ผมได้มีโอกาสไปงาน CeBIT ในเดือนมีนาคมปี 2010 ได้งานนั้นสิ่งที่ผมสนใจมากอย่างหนึ่งก็คือเรื่องของ e-ID ของประเทศเยอรมันและของประเทศอื่นๆในกลุ่มยุโรป เทคโนโลยีในตอนนั้นพึ่งพาเรื่องบัตรประชาชนที่เป็นสมาร์ทการ์ดเป็นหลักไม่ว่าจะเป็นอยู่ในรูปบัตรหรือเป็น USB Token เพื่อใช้ในการธุรกรรมต่างๆ ไม่แค่เพียงของรัฐ แต่ยังโยงไปถึงธุรกรรมเกี่ยวกับ ธนาคาร การเงินฯลฯ ในตอนนั้นก็กลับมาย้อนนึกว่าทำไมเราถึงไม่สามารถใช้บัตรประจำตัวประชาชนของเราซึ่งเป็นสมาร์ทการ์ดเช่นกันทำธุรกรรมแบบนั้นได้ แต่เนื่องจากไม่ได้เกี่ยวข้องกับเรื่องนี้โดยตรงก็ได้แต่คิดและเก็บเอาเรื่องนี้ไว้ในใจ

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

หลังจากนั้นกระแสเรื่องของการพิสูจน์ตัวตนผ่านทางอุปกรณ์ Mobile เช่น Smartphone ก็เริ่มมาถึงวงการธนาคารในกระบวนการเช่นการทำ E-KYC (Know Your Customer) การพิสูจน์ตัวตนลูกค้า E-Consent การให้ความยินยอมเปิดเผยข้อมูลด้วยวิธีการทางอิเล็กทรอนิกส์ ซึ่งกลายเป็นว่าความต้องการหลักเป็นเรื่องเดียวกันก็คือทำอย่างไรถึงจะพิสูจน์ทราบได้ว่าผู้ที่จะมาทำธุรกรรมนั้นเป็นบุคคลตามที่กล่าวอ้างจริงๆ

สิ่งที่เกิดขึ้นก็คือแค่เฉพาะในวงการธนาคารก็มีแนวคิดที่จะทำเรื่อง Digital Identity ออกไปหลายหลายรูปแบบ แต่ไม่ว่ารูปแบบไหนก็ต้องกลับมาเกี่ยวข้องกับผมซึ่งทำงานในสายงาน Information Security อยู่ดี ในรายการที่ผมต้องไปเกี่ยวข้อง หลายเรื่องนั้นก็มีวิธีการออกแบบที่ไม่ดีเลย

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

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

ทำให้ผมได้มาร่วมงานกับผู้เชี่ยวชาญท่านนั้น ที่ผมได้ติดรถกลับบ้านในเดือนกันยายนปี 2015

จบปฐมบทเรื่อง Digital Identity ของผม

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

WPA2 Key Reinstallation Attack (KRACK)

ช่องโหว่ WPA2 ของ Wireless LAN ทำให้ชีวิตดูเหมือนอยู่ยาก แต่อย่างไรก็ตามอาศัยความรู้อันน้อยนิด ให้ความกระจ่างได้ดังนี้

1. เนื่องจากต้องทำ Rouge Access Point in the Middle ดังนั้นถ้าบ้านคุณไม่ใหญ่จนคนมาทำ Access Point ปลอมในบ้านคุณได้ ก็ไม่ต้องวิตกกังวลอะไรนัก หรือแม้แต่ Pocket WiFi ก็ยังไม่น่ากังวล

2. คนที่ต้องกังวลคือคนที่ใช้ Wireless Access Point ในสถานที่ที่ควบคุมไม่ได้ เช่นที่ทำงาน (เวรล่ะ) วิธีแก้คือเดินไปหา Access Point แล้วนั่งทำงานใกล้ๆ ให้สัญญาณแรงๆ เข้าไว้ (ทำได้เรอะ)
แก้ไข: ไปนั่งกินเนื้อย่างคุยกับคนที่อ่าน Paper นี้ครบแล้ว สรุปว่าถ้า Attacker ตั้งใจโจมตีรายคน เอาเสาส่งแบบ Beam ไปยิงเพื่อเปลี่ยน Channel ทำ Man-In-The-Middle Rouge Access Point ได้ ดังนั้นอยู่ใกล้ Access Point ก็อาจไม่ช่วย

3. ส่วนคนที่ใช้ Public WiFi แบบไม่รู้สึกตะขิดตะขวงใจ ไม่ได้ผลกระทบอะไรเพิ่ม ไม่ปลอดภัยยังไง ก็ไม่ปลอดภัยเท่าเดิม

ทางแก้ ก็ Update WPA2 Patch ของ Wireless LAN Adapter ที่เครื่องตัวเอง ส่วนมือถือถ้าไม่มี WiFi Patch หรือ Update ออกนอกบ้านก็ 3G/4G โลด

Update: Ubuntu ออก WPA Package Update แล้วนะ แก้ Program ชื่อ wpa_supplicant (2.4-0ubuntu6.2) อย่าลืม Update กัน

KRACK Attacks: Bypassing WPA2 against Android and Linux

Security ใน DevOps ต่างจาก DevSecOps อย่างไร

มีคำถามเรื่อง DevSecOps ว่า Dev กับ Ops ก็มี Security อยู่แล้วไม่ใช่หรือ ทำไมต้องมี DevSecOps เพิ่มขึ้นมา คำตอบของคำถามแรกคือทั้งใช่และไม่ใช่ ส่วนคำถามหลังต้องอธิบายเพิ่มเติม

ในการทำ DevOps ในส่วน Security ที่ควรจะมีอยู่แล้วด้าน Dev ก็คือเรื่องของ Secure Design และ Secure Coding ซึ่งเป็น Practice ที่จำเป็นต้องมีในการ Implementation เช่นการปฏิบัติตาม OWASP Application  Security Verification Standard เป็นต้น อีกด้านคือฝั่ง Ops ที่ควรจะมีโดยพื้นฐานก็เช่นการทำ Hardening หรือ Secure Deployment Process เป็นต้น

แล้ว DevSecOps มาช่วยอะไร

ในการพัฒนา Software นั้นถ้าอ้างอิงตาม Microsoft Security Development Lifecycle (SDL ดู https://www.microsoft.com/en-us/sdl/) การทำ Automation ของ DevSecOps นั้นอยู่ที่ Implementation และ Verification

Microsoft Security Development Lifecycle

• 
  

ในขั้นตอนหลังจาก Implementation จะต้องมีการทำ Security Practice ก็คือตรวจสอบว่าใช้เครื่องมือในการพัฒนา (Tool Chain) และ Library ที่ได้รับการอนุมัติแล้วหรือเปล่า รวมทั้งการทำ Static Code Analysis  เป็นต้น นี่เป็นขั้นตอนก่อนการ Compile และ Build เพื่อทำ Automate Testing

ขั้นตอน Verification ประกอบด้วยการทำ Dynamic Analysis เช่นทำ Vulnerability Assessment Scanning ทำ Fuzz Testing โดยการลองป้อนข้อมูลที่ไม่อยู่ในรูปแบบที่ถูกต้อง (Malformed Data) เพื่อทดสอบว่าแอพพลิเคชั่นสามารถจัดการกับข้อมูลเหล่านี้ได้โดยไม่ก่อให้เกิดปัญหาทางด้าน Security ไปจนถึงการทํา Penetration Testing ซึ่งขั้นตอนนี้ควรทำหลังจากทำ Automate Testing เสร็จเรียบร้อยแล้ว และก่อน Deployment

นอกเหนือไปจากการตรวจสอบ Security แล้วยังมีส่วนที่ต้องทำการตรวจสอบเพิ่มเติมก็คือการตรวจสอบเพื่อเป็นไปตามการกำกับดูแล (Compliance) สิ่งต่างๆเหล่านี้รวมทั้งหมดแล้วไม่ได้ถูกเขียนไว้ในกระบวนการการทำ DevOps แบบที่ทำโดยทั่วไป

สำหรับท่านที่สนใจสามารถหาอ่านรายละเอียดได้จากเอกสาร White Paper ตามลิงค์ด้านล่าง

http://www.devseccon.com/wp-content/uploads/2017/07/DevSecOps-whitepaper.pdf

Secure Software Design 101: Fail-Safe / Fail-Secure

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

ตัวอย่างที่แสดงให้เห็นความแตกต่างของทั้งสองแบบเช่น ในการออกแบบประตูบริเวณศูนย์ข้อมูล (Data Center) ซึ่งใช้ Access Control ในการควบคุมการเข้าออกศูนย์ข้อมูล ในกรณีที่เกิดเหตุฉุกเฉินเช่นเพลิงไหม้ ในบริเวณที่พนักงานนั่งทำงานจะต้องออกแบบให้ Fail-Safe คือหากไฟดับประตูต้องเปิดทันทีเพื่ออพยพคนออก แต่ห้องเครื่องศูนย์ข้อมูลจะต้องออกแบบให้ Fail-Secure คือเมื่อตัดไฟต้องปิดประตูเสมอเพื่อป้องกันคนเข้าถึงเครื่องแม่ข่ายหรืออุปกรณ์เครือข่ายโดยไม่ได้รับอนุญาต

หรือในกรณีอุปกรณ์ Security บนเครือข่าย อุปกรณ์ Firewall จะมีโครงสร้างเป็นแบบ Fail-Secure คือเมื่อมีการขัดข้อง จะแยกเครือข่ายที่เชื่อมกันออกจากกัน ไม่ยอมให้เครือข่ายข้ามถึงกัน แต่ IPS (Intrusion Prevention System) ซึ่งวางขวางระบบเครือข่ายเช่นกันจะทำในทางตรงกันข้าม คือหากขัดข้องจะมีการ Bypass เครือข่ายอัตโนมัติ ซึ่งเป็นแนวทาง Fail-Safe

แล้วในกรณีการออกแบบซอฟต์แวร์ เราจะใช้หลักการ Fail-Safe หรือ Fail-Secure อย่างไร ขอให้หลักการไว้คร่าวๆ ดังนี้

• หากอยู่ในเงื่อนไขที่ต้องการ Availability มากกว่า Confidentiality หรือ Integrity ให้ออกแบบส่วนนั้นเป็น Fail-Safe เช่นการออกแบบ User Interface ต่างๆ บน Web Application เมื่อเกิด Error 4xx หรือ 5xx ก็ควรจะมี Landing Page ให้คำแนะนำกับผู้ใช้ และมีลิ้งค์ไปยังหน้าแรกที่เป็น Static Page หรือหน้า Login เพื่อป้องกันไม่ให้ผู้ใช้ดำเนินการที่ทำให้ระบบมีปัญหาเพิ่มขึ้นเช่นกดปุ่ม Refresh ของ Web Page เพื่อทำงานซ้ำ
• หากอยู่ในเงื่อนไขที่ต้องการ Confidentiality หรือ Integrity มากกว่า Availability ให้ออกแบบส่วนนั้นเป็น Fail-Secure เช่นการทำ Financial Transaction หากเกิดข้อผิดพลาดทางใดทางหนึ่งเช่นการโอนเงินจากบัญชีหนึ่งไปยังอีกบัญชีหนึ่งของอีกธนาคาร สามารถตัดบัญชีต้นทางได้แต่ไม่สามารถเอาเข้าบัญชีปลายทางได้ไม่ว่าจะเกิดจากระบบที่ใช้โอน ผู้ให้บริการโอน (Switching) การสื่อสารขัดข้อง หรือกรณีใดก็แล้วแต่ จะต้องทำการย้อนกลับ (Rollback) ทันที

สิ่งหนึ่งที่สำคัญในการออกแบบซอฟต์แวร์ที่มีลักษณะ Fail-Safe/Fail-Secure ให้ได้ดีคือการจำลองกรณีผิดพลาดให้ได้มากที่สุดว่าเกิดจากอะไรได้บ้าง แล้วหาเส้นแบ่งในการตรวจสอบข้อผิดพลาดนั้นๆ (Threshold) เพื่อตัดสินใจว่าจะเข้าสู่กระบวนการจัดการความล้มเหลวของระบบ

จำไว้เสมอว่าซอฟต์แวร์ที่ดี ต้องออกแบบให้มีการจัดการข้อผิดพลาดเมื่อระบบส่วนใดส่วนหนึ่งทำงานล่มไม่เป็นไปตามความต้องการ

ตอนที่เกี่ยวข้อง

Secure Software Design 101: Least Privilege

Secure Software Design 101: Need to Know

Secure Software Design 101: Need to Know

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

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

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

Need to Know มักจะถูกใช้สับสนกับ Least Privilege เนื่องจากเป็นเรื่องการควบคุมสิทธิ์เช่นเดียวกัน โดยข้อแตกต่างจะสรุปได้ดังนี้

ข้อเปรียบเทียบ	Need to Know	Least Privilege
การเข้าถึง	อ่านเท่านั้น	อ่าน เขียน สั่งให้ทำงาน เป็นต้น
Object	ข้อมูลเท่านั้น	ข้อมูล แฟ้ม บริการ กระบวนการ เป็นต้น
Security Foundation	Confidentiality	Confidentiality, Integrity
การควบคุมการเข้าถึงข้อมูล	ระดับ Record & Field	ระดับSchema (อาจถึงระดับ Field)
สิทธิ์	ตามที่ได้รับมอบหมาย(Assignment)	ตามบทบาท(Role)

จำไว้เสมอว่า Subject ควรได้รับข้อมูลเฉพาะที่จำเป็นต้องรู้เพื่อทำงานตามหน้าที่ที่ได้รับมอบหมายเท่านั้น

ตอนที่เกี่ยวข้อง

Secure Software Design 101: Least Privilege

Secure Software Design 101: Fail-Safe / Fail-Secure

Secure Software Design 101: Least Privilege

ในการออกแบบทางด้าน Security สิ่งหนึ่งที่มักจะพูดถึงก็คือเรื่องการให้สิทธิ (Authorization) เพื่อทำงานใดๆ ไม่ว่าจะเป็นระดับผู้ใช้ (User) หรือกระบวนการ (Process) ซึ่งเราเรียกรวมกันว่าประธานหรือผู้กระทำ (ขอใช้ทับศัพท์ว่า Subject or Actor) กระทำการใดๆ ต่อข้อมูล บริการ (Service) หรือแม้แต่กระบวนการ (Process) ด้วยกันเอง ซึ่งเรียกรวมๆ กันว่ากรรม (ขอใช้ทับศัพท์ว่า Object) ซึ่งสามารถเขียนเป็นตัวอย่างการรวมกันของ ประธาน กริยา กรรม ได้เช่น

ประธาน (Subject)	กริยา (Access)	กรรม (Object)
ผู้ใช้ (User) โปรแกรม (Program) กระบวนการ(Process)	อ่าน (Read) เขียน (Write) สั่งให้ทำงาน(Execute)	แฟ้มข้อมูล (File) ฐานข้อมูล(Database) บริการ (Service) กระบวนการ(Process) ทรัพยากร(Resource)

การออกแบบการให้สิทธินั้นมีแนวคิดเพื่อความมั่นคงปลอดภัยก็คือการให้สิทธิ Subject ดำเนินการต่อ Object น้อยที่สุดเท่าที่จะทำงานได้สำเร็จตามวัตถุประสงค์ หรือที่เรียกว่า Least Privilege เช่น Web Application ซึ่งทำงานกับ Database เพียงแค่ insert, select, update, delete ก็ควรจะสร้าง Database User ให้กับ Web Application นั้นให้มีสิทธิ์เท่าที่ทำงานดังกล่าวได้ ไม่ใช่ปล่อยให้ใช้ User ที่มีสิทธิ์สูงเช่น SA, root, SYS หรือ Schema Owner หรือ User ที่สามารถใช้คำสั่งจัดการ Schema ของข้อมูล (DDL: Data Definition Language) เช่น create, alter, drop เป็นต้น

สิทธิดังกล่าวข้างต้นเป็นสิทธิในเชิงวิธีการเข้าถึง แต่ยังมีในเชิงปริมาณที่ต้องคำนึงถึงคือจำนวนและชนิดของ Object ที่เข้าใช้งาน หลักการ Lease Privilege ก็ครอบคลุมในมิตินี้ด้วย กล่าวคือหาก Subject ไม่มีความจำเป็นที่ต้องทำงานกับ Object ใด ก็ควรห้ามการเข้าถึง Object นั้นๆ ด้วย

การให้สิทธิ์แก่ Subject มากเท่าไรก็เป็นการเพิ่มพื้นที่ในการโจมตี (Attack Surface) ต่อ Object มากเท่านั้นและเมื่อ Subject โดนยึดได้ (Compromised) Object ก็มีโอกาสถูกกระทำตามสิทธิที่ให้แก่ Subject ไว้

จำไว้เสมอว่า ให้ Subject มีสิทธิยิ่งน้อยเท่าไรความเสี่ยงในการที่ Subject จะถูกสวมรอยเพื่อใช้ทำงานผิดวัตถุประสงค์หรือทำงานผิดพลาดโดยไม่ตั้งใจ (User Error) จะมีน้อยเท่านั้น

ตอนที่เกี่ยวข้อง

Secure Software Design 101: Least Privilege

Secure Software Design 101: Need to Know

Secure Software Design 101: Fail-Safe / Fail-Secure

มัลแวร์ข้ามการตรวจ Hardware Token OTP ได้อย่างไร

การใช้ Hardware Token OTP (One Time Password) มักนิยมใช้กับการทำธุรกรรมที่มีความสำคัญสูง เพราะเชื่อว่ามีความปลอดภัยสูงกว่า SMS OTP แต่มีต้นทุนที่สูงกว่า อย่างไรก็ตามก็ไม่ได้หมายความว่าจะ Bypass การใช้ Token OTP ไม่ได้ แม้ว่าระหว่าง Web Browser กับ Server จะใช้ TLS (Transport Layer Security ที่มาแทน SSL เดิม) ทั้งนี้หากเครื่องที่ใช้งานด้านผู้ใช้ ติดมัลแวร์ที่เจาะจงโจมตีบริการของเราที่ป้องกันด้วย Token OTP

เราต้องเข้าใจก่อนว่ามัลแวร์เมื่อติดอยู่บนเครื่องที่เราใช้ทำธุรกรรม สามารถตรวจจับการเปิดโปรแกรมใดๆ บนเครื่องเราและเปลี่ยนคำสั่งการส่งข้อมูล Keyboard และ Mouse ที่ส่งไปยัง Window ของโปรแกรมต่างๆ ด้วย Windows API โดยการจัดการกับคำสั่งที่ส่งระหว่างแต่ละโปรแกรมกับ Operating System ด้วยวิธีที่เรียกว่า Hook ซึ่งรายละเอียดของ Windows API นี้สามารถดูได้ที่นี่

ดังนั้นมัลแวร์สามารถติดตามการเปิด Web Browser ความเคลื่อนไหวของ URL โดยการตรวจสอบ Address Bar รวมทั้งดักหรือยกเลิกข้อมูลจากการกด Keyboard หรือ Mouse Click ได้ แม้กระทั่งส่งข้อความแจ้งเตือนปลอม แก้ไขการวาดเว็บเพจเพื่อแทรกข้อความหรือรูปภาพอื่นเพื่อหลอกผู้ใช้ ตลอดจนส่ง HTTP Request โดยใช้ Session ขณะนั้นของ Browser ที่เชื่อมกับ Server เป้าหมายได้

การ Bypass Token OTP

แล้วมัลแวร์ Bypass Token OTP ได้อย่างไร ขอให้ดู Misuse Case Diagram ตามรูป

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

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

สิ่งผิดปกติที่จะสังเกตได้

ความผิดปกติฝั่งผู้ให้บริการก็คือจะเกิดการทำธุรกรรมที่ต้องใช้ Token OTP ติดกันในระยะเวลา 1-2 นาที ซึ่งไม่สามารถกระทำได้โดยการกระทำของมนุษย์ หากมีการใส่กฏเกณฑ์ตรวจจับการกระทำลักษณะนี้ในระบบตรวจจับการโกง (Fraud Detection) ก็จะพบได้โดยง่าย

อย่างไรก็ตามดร.ภูมิ ภูมิรัตน ได้ให้ความเห็นว่าหากมัลแวร์แจ้งเตือนในลักษณะ Server Error และบังคับไปเริ่มทำธุรกรรมใหม่ ระบบตรวจจับการโกงก็จะไม่สามารถตรวจจับได้เพราะเป็นพฤติกรรมปกติของการทำงานบนอินเทอร์เน็ต

ความผิดปกติฝั่งผู้ใช้ก็คือจะมีการแจ้งเตือนการทำธุรกรรมซ้ำสองครั้งในระยะเวลา 1-2 นาที ซึ่งหากตั้งค่าการแจ้งเตือนด้วย email ผู้ใช้ก็อาจมองข้ามไปโดยง่ายหากมีการทำธุรกรรมหลายครั้งต่อวัน แต่หากเป็นการแจ้งเตือนผ่าน SMS ก็จะเป็นแบบเดียวกัน ผู้ใช้อาจไม่อ่านและคิดว่าเป็นการส่งซ้ำโดยผู้ให้บริการ ตังนั้นในฐานะผู้ใช้บริการต้องระมัดระวังตัวตรวจสอบการแจ้งเตือนทุกครั้ง ไม่ปล่อยผ่านโดยคิดว่าเป็นข้อผิดพลาดของผู้ให้บริการ

มีอะไรใหม่ใน PCI-DSS 3.0

บทความนี้ผมได้เขียนลงนิตยสาร E-WORLD ฉบับธันวาคม 2556 เห็นว่ามีการจัดสัมมนาเกี่ยวกับ PCI-DSS ในช่วงนี้มากพอสมควรจึงนำมาให้อ่านกัน แม้ว่า Version 3.1 จะออกมาแล้วก็ตาม

สำหรับผู้ที่ให้บริการรับชำระเงินในการทำธุรกรรมอิเล็กทรอนิกส์ด้วยบัตรเครดิตหรือบัตรเดบิต คงจะคุ้นเคยกับมาตรฐาน PCI-DSS (Payment Card Industry - Data Security Standard) มากพอสมควร โดยมาตรฐาน PCI DSS ถูกกำหนดเพื่อเพิ่มการปกป้องข้อมูลผู้ถือบัตร (Cardholder Data) โดยครอบคลุมผู้ที่เกี่ยวข้องกับธุรกิจบัตรอันได้แก่ ร้านค้า ผู้ประมวลผลข้อมูล สถาบันการเงินผู้รับบัตร สถาบันการเงินผู้ออกบัตร รวมถึงผู้ให้บริการอื่นๆ รวมไปถึงทุกส่วนที่เกี่ยวข้องกับการเก็บ ประมวลผล และส่งข้อมูลของผู้ถือบัตร

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

มาตรฐาน PCI DSS ที่ใช้กันอยู่ในปัจจุบันเป็นรุ่น 2.0 ออกในเดือนตุลาคม 2553 และจะเริ่มถูกแทนที่โดย PCI-DSS 3.0 ตั้งแต่วันที่ 1 มกราคม 2557 เป็นต้นไป โดยที่ผู้ให้บริการที่จะรับการประเมินตามมาตรฐาน PCI-DSS ตั้งแต่ปี 2557 จะต้องถูกประเมินตามมาตรฐานใหม่ แต่ส่วนผู้ที่ได้รับการประเมินตามมาตรฐานนี้ก่อนสิ้นปี 2556 จะยังคงถูกการประเมินตามตาม PCI-DSS 2.0 ไปจนถึงสิ้นปี 2557 หลังจากนั้นจึงจะเริ่มถูกประเมินตามมาตรฐานใหม่เช่นกัน

อย่างไรก็ตามข้อกำหนดบางใหม่อย่างก็จะยังเป็นเพียงข้อแนะนำที่เป็น Best Practice และจะยังไม่ถูกบังคับใช้จนกว่าวันที่ 1 กรกฎาคม 2558 ทั้งนี้จะได้กล่าวถึงในส่วนถัดไป

สาเหตุของการเปลี่ยนแปลง

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

ประเด็นหลักในการเปลี่ยนแปลง

การเปลี่ยนแปลงในรุ่น 3.0 เพื่อช่วยองค์กรต่างๆ เพื่อดำเนินการปกป้องข้อมูลผู้ถือบัตรซึ่งมุ่งความสนใจไปที่เรื่องความมั่นคงปลอดภัยมากกว่าการปฏิบัติตามข้อกำหนด และทำให้ PCI DSS ถูกใช้งานเป็นปกติวิสัย (Business-as-Usual) ประเด็นหลักในการเปลี่ยนแปลงที่ถูกเน้นในรุ่น 3.0 ประกอบด้วย

การให้ความรู้และความตระหนักในมาตรฐาน (Education and Awareness)

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

ความยืดหยุ่นที่เพิ่มขึ้น (Increased Flexibility)

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

ความมั่นคงปลอดภัยที่ต้องรับผิดชอบร่วมกัน (Security as a Shared Responsibility)

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

ข้อกำหนดที่มีการปรับปรุง

ในมาตรฐาน PCI-DSS 3.0 มีการปรับปรุงขึ้นมาแบ่งได้ 3 กลุ่มคือ

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

ในบทความนี้จะกล่าวถึงเพียงการเปลี่ยนแปลงข้อกำหนดเพื่อรองรับภัยคุกคามและตลาดในปัจจุบันเท่านั้น ซึ่งถ้าแบ่งตามข้อกำหนดของ PCI-DSS จะพบว่าข้อกำหนดที่ไม่มีการเปลี่ยนแปลงประกอบด้วย

• ข้อกำหนด 3 การปกป้องข้อมูลผู้ถือบัตรที่ถูกบันทึกไว้
• ข้อกำหนด 4 การเข้ารหัสลับข้อมูลผู้ถือบัตรระหว่างการส่งข้อมูลผ่านเครือข่ายสาธารณะ
• ข้อกำหนด 7 การจำกัดการเข้าถึงข้อมูลผู้ถือบัตรเฉพาะผู้ที่จำเป็นต้องรู้เท่านั้น

เราจะมาพิจารณาในข้อต่างๆที่มีการเปลี่ยนแปลงดังนี้

ข้อกำหนด 1: การติดตั้งและดูแลรักษาค่าต่างๆของไฟร์วอลเพื่อปกป้องข้อมูลผู้ถือบัตร

ข้อกำหนดที่มีการเปลี่ยนแปลงในส่วนนี้คือการกำหนดให้ต้องมีแผนผังเพื่อแสดงการเคลื่อนที่ของข้อมูลผู้ถือบัตรไปยังส่วนต่างๆที่สำคัญในแผนผังเครือข่าย (Network Diagram) โดยในข้อ 1.1.2 กำหนดว่าต้องมีแผนผังเครือข่ายที่ระบุการเชื่อมต่อจากสภาพแวดล้อมของข้อมูลผู้ถือบัตร (Cardholder Data Environment) ไปยังเครือข่ายอื่นรวมทั้งเครือข่ายไร้สาย และในข้อ 1.1.3 กำหนดว่าต้องมีแผนผังการเคลื่อนที่ของข้อมูลผู้ถือบัตร (Cardholder Data Flows)ไปยังระบบและเครือข่ายต่างๆ ด้วย

ข้อกำหนด 2: การห้ามใช้ค่าตั้งต้นจากผู้ขายผลิตภัณฑ์สำหรับรหัสผ่านของระบบและค่าความมั่นคงปลอดภัยอื่นใด

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

ข้อกำหนด 5: การใช้และปรับปรุงโปรแกรมป้องกันไวรัสอย่างสม่ำเสมอ

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

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

ข้อกำหนด 6: การพัฒนาและดูแลรักษาระบบและแอพพลิเคชั่นต่าง ๆ ให้มีความมั่นคงปลอดภัย

ข้อกำหนดใหม่ที่เพิ่มขึ้นมาอยู่ในข้อ 6.5.10 คือเรื่อง Broken Authentication and Session Management ซึ่งเป็นเรื่องเกี่ยวกับการป้องกันช่องโหว่ของการพิสูจน์ตัวตนเข้าใช้งานและจัดการสถานะการใช้งานของผู้ใช้ เพื่อป้องกันไม่ให้บุคคลที่ไม่ได้รับอนุญาตเข้าถึงบัญชี กุญแจรหัส หรือข้อมูลรักษาสถานะการใช้งาน (Session Token) ซึ่งจะทำให้ผู้บุกรุกสามารถปลอมแปลงตัวตนเป็นผู้ใช้ที่ได้รับอนุญาต อย่างไรก็ตามข้อกำหนดนี้จะอยู่ในสถานะเป็น Best Practice จนกว่าจะถึงวันที่ 1 กรกฎาคม 2558 จึงจะเริ่มใช้จริง

นอกจากนี้คำแนะนำหลายส่วนในข้อกำหนด 6ได้ปรับให้สอดคล้องกับมาตรฐานทางด้านความมั่นคงปลอดภัยที่ใช้กันโดยทั่วไปเช่น OWASP, NIST, SANS เป็นต้น

ข้อกำหนด 8: การกำหนดบัญชีผู้ใช้หนึ่งบัญชีต่อหนึ่งคนในการใช้งานคอมพิวเตอร์

มีการปรับปรุงข้อ 8.2.3 โดยการรวมเรื่องความต้องการความซับซ้อนและความแข็งแรงของรหัสผ่านขั้นต่ำเป็นข้อเดียว และเพิ่มความยืดหยุ่นสำหรับทางเลือกอื่นที่ให้ความซับซ้อนและความแข็งแรงของรหัสผ่านที่เทียบเท่ากัน โดยมีคำแนะนำให้เลือกใช้ตามเอกสาร NIST SP 800-63-1 ที่กำหนดค่า “Entropy” เป็นค่าวัดความยากในการเดารหัสผ่านหรือกุญแจ ถ้ามีความยากเทียบเท่าหรือมากกว่าที่กำหนดไว้ในข้อนี้ก็ถือว่าใช้ได้

ข้อกำหนดใหม่ที่เพิ่มเข้ามาอีกก็คือข้อ 8.5.1 เป็นข้อกำหนดเพิ่มเติมสำหรับผู้ให้บริการ คือถ้าผู้ให้บริการต้องทำการเข้าใช้ระบบจากระยะไกลเพื่อช่วยเหลือ จะต้องใช้รหัสผ่านที่ไม่ซ้ำกันสำหรับลูกค้าแต่ละราย โดยมีคำแนะนำเช่นการใช้การพิสูจน์ตัวตนสองปัจจัย (Two-Factor Mechanism) ที่ให้ข้อมูลประจำตัวที่ไม่ซ้ำกันสำหรับแต่ละการเชื่อมต่อแต่ละครัง (ตัวอย่างเช่นผ่านทางรหัสผ่านแบบใช้ครั้งเดียว) ข้อกำหนดนี้จะอยู่ในสถานะเป็น Best Practice จนกว่าจะถึงวันที่ 1 กรกฎาคม 2558 จึงจะเริ่มใช้จริง

อีกข้อที่เพิ่มใหม่คือข้อ 8.6 กำหนดว่าหากมีการใช้กลไกการตรวจสอบอื่นๆ (ตัวอย่างเช่น Security Token ไม่ว่าจะอยู่ในรูปอุปกรณ์ที่สามารถจับต้องได้หรือรหัสดิจิทัล บัตรสมาร์ทคาร์ด, ใบรับรองดิจิทัล ฯลฯ ) การใช้กลไกเหล่านี้จะต้องกำหนดว่า การพิสูจน์ตัวตนนั้นจะต้องถูกกำหนดให้ใช้กับบัญชีรายบุคคล และต้องไม่ใช้ร่วมกันระหว่างหลายบัญชี นอกจากนั้นจะต้องมีการควบคุมทางกายภาพและ/หรือเชิงตรรกะ (Physical and/or Logical Control) เพื่อให้มั่นใจว่าบัญชีที่กำหนดเท่านั้นที่จะใช้งานได้

ข้อกำหนด 9: การจํากัดการเข้าถึงทางกายภาพยังข้อมูลผู้ถือบัตร

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

ข้อใหม่อีกข้อคือหัวข้อ 9.9 ปกป้องอุปกรณ์อ่านข้อมูลบัตรชำระเงินจากการถูกดัดแปลงหรือเอาเครื่องอื่นมาสวมรอยแทน ข้อกำหนดนี้นำไปประยุกต์ใช้กับอุปกรณ์อ่านบัตรที่ใช้ในการทำธุรกรรมที่ต้องแสดงบัตร (นั่นคือรูดหรือเสียบบัตร) ณ. จุดขาย ข้อกำหนด 9.9 นี้จะอยู่ในสถานะเป็น Best Practice จนกว่าจะถึงวันที่ 1 กรกฎาคม 2558 จึงจะเริ่มใช้จริง

ข้อกำหนด 10: การติดตามและเฝ้าดูการเข้าถึงทุกการใช้งานเครือข่ายและข้อมูลผู้ถือบัตร

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

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

ข้อกำหนด 11: การทดสอบระบบและขั้นตอนต่าง ๆ ในการรักษาความมั่นคงปลอดภัยอย่าง สม่ำเสมอ

ข้อกำหนด 11 เป็นข้อที่มีการปรับปรุงแก้ไขเพิ่มเติมค่อนข้างมาก ข้อกำหนดที่มีการปรับปรุงคือข้อ 11.1 โดยเพิ่มการทำบัญชีรายการจุดเชื่อมต่อไร้สาย (Wireless Access Point) ที่ได้รับอนุญาต รวมทั้งระบุเหตุผลทางธุรกิจของการใช้จุดเชื่อมต่อไร้สายนั้นๆไว้เป็นลายลักษณ์อักษร (11.1.1) เพื่อที่จะใช้อ้างอิงเวลาทำการตรวจสอบหาจุดเชื่อมต่อไร้สายที่ไม่ได้รับอนุญาต และเพิ่มข้อ 11.1.2 คือให้มีกระบวนตอบสนองต่อเหตุการณ์ในกรณีที่มีการตรวจพบจุดเชื่อมต่อไร้สายที่ไม่ได้รับอนุญาต

ส่วนข้อกำหนดที่มีการแก้ไขและเพิ่มเติมได้แก่ ข้อ 11.3 ให้ใช้วิธีการทดสอบเจาะระบบ (Methodology for Penetration Testing) ที่เป็นที่ยอมรับของอุตสาหกรรม เช่น NIST SP800-115 คลอบคลุมบริเวณที่เกี่ยวข้องกับข้อมูลผู้ถือบัตรและระบบที่สำคัญ มีการทดสอบจากทั้งภายในและภายนอกเครือข่าย รวมถึงกำหนดให้มีการทดสอบการเจาะระดับโปรแกรมเพื่อครอบคลุมช่องโหว่ที่ระบุไว้ในข้อกำหนด 6.5 เป็นอย่างน้อย กำหนดให้มีการทดสอบการเจาะเครือข่ายรวมถึงองค์ประกอบที่สนับสนุนการทำงานของเครือข่ายรวมทั้งระบบปฏิบัติการ รวมถึงการตรวจสอบและการพิจารณาภัยคุกคามและช่องโหว่ที่มีเกิดขึ้นในช่วง 12 เดือนที่ผ่านมา และระบุการเก็บรักษาของผลการทดสอบการเจาะและกิจกรรมในการแก้ไขช่องโหว่ด้วย

ทั้งนี้ยังคงให้ใช้ข้อกำหนดในการทดสอบเจาะระบบตาม PCI-DSS 2.0 ไปจนกว่าทุกหัวข้อที่กำหนดไว้เป็น Best Practice จะดำเนินการตามข้อกำหนด PCI-DSS 3.0 ครบถ้วน อย่างไรก็ตามจะมีการบังคับใช้ข้อบังคับใหม่นี้ตั้งแต่วันที่ 1 กรกฎาคม 2558

มีการเพิ่มข้อกำหนด 11.5.1 เพื่อสนับสนุนข้อ 11.5 โดยให้มีการใช้กระบวนการเพื่อตอบสนองต่อการแจ้งเตือนใดๆ ที่เกิดจากระบบการตรวจสอบการเปลี่ยนแปลง

ข้อกำหนด 12: การคงไว้ซึ่งนโยบายที่ระบุถึงความมั่นคงปลอดภัยสารสนเทศสำหรับพนักงานทุกคน

มีการย้ายเอาข้อกำหนด 12.1.2 ที่เกี่ยวกับกระบวนการประเมินความเสี่ยงประจำปีไปยังข้อ 12.2 และกำหนดว่าการประเมินความเสี่ยงต้องทำทุกปีและทุกครั้งที่มีการเปลี่ยนแปลงสภาวะแวดล้อมอย่างมีนัยสำคัญเป็นอย่างน้อย

ข้อกำหนดใหม่เพิ่มเข้ามาคือข้อ 12.8.5 ในเรื่องการรักษาข้อมูลเกี่ยวกับผู้ให้บริการแต่ละรายว่ามีจัดการตามข้อกำหนด PCI DSS ข้อใด และข้อใดที่มีการจัดการโดยองค์กร

ส่วนอีกข้อคือข้อ 12.9 ที่เพิ่มขึ้นมาคือข้อกำหนดเพิ่มเติมสำหรับผู้ให้บริการ โดยระบุว่าผู้ให้บริการรับทราบเป็นลายลักษณ์อักษรให้กับลูกค้าว่าพวกเขามีความรับผิดชอบในการรักษาความปลอดภัยของข้อมูลผู้ถือบัตรที่ผู้ให้บริการครอบครอง จัดเก็บ ดำเนินการ หรือส่งในนามของลูกค้า หรือกรณีใดก็ตามส่งผลกระทบต่อการรักษาความปลอดภัยของภาวะแวดล้อมข้อมูลผู้ถือบัตรของลูกค้า ข้อกำหนด 12.9 นี้จะอยู่ในสถานะเป็น Best Practice จนกว่าจะถึงวันที่ 1 กรกฎาคม 2558 จึงจะเริ่มใช้จริง

บทส่งท้าย

PCI-DSS 3.0 ได่มีการปรับปรุงแก้ไขเพิ่มเติมจาก PCI-DSS 2.0 โดยมุ่งเน้นไปที่การให้ความรู้และความตระหนักในมาตรฐาน ความยืดหยุ่นที่เพิ่มขึ้น และความมั่นคงปลอดภัยที่ต้องรับผิดชอบร่วมกันทั้งองค์กรและผู้ให้บริการที่เกี่ยวข้อง โดยจะเริ่มต้นใช้งานตั้งแต่วันที่ 1 มกราคม 2557 เป็นต้นไป และจะใช้งานอย่างสมบูรณ์ตั้งแต่วันที่ 1 กรกฎาคม 2558 ดังนั้นผู้ที่จะเริ่มปฏิบัติตามมาตรฐาน PCI-DSS รวมทั้งผู้ที่เคยผ่านการประเมินมาแล้ว จึงควรที่จะศึกษาข้อแตกต่างเพื่อที่จะรับการประเมินตามมาตรฐานใหม่ได้อย่างถูกต้อง

เอกสารอ้างอิง

• Payment Card Industry (PCI) Data Security Standard: Requirements and Security Assessment Procedures Version 3.0, PCI Security Standards Council, LLC., November 2013
• Payment Card Industry (PCI) Data Security Standard and Payment Application Data Security Standard Version 3.0 Change Highlights, PCI Security Standards Council, LLC., August 2013
• PCI DSS 3.0 – What’s New? An Infographic, Anthony M Freed, Tripwire Inc., December 5, 2013

บทความที่เกี่ยวข้อง

บัตรเครดิตกับ PCI-DSS

Java Zero-Day Exploited (CVE-2013-0422)

Java Zero-Day Exploited (CVE-2013-0422) ใน Java 7 Update 10 มีการใช้ใน Crimeware Kits ชื่อ Blackhole, Nuclear Pack, Cool Exploit Kit, Redkit เป็นต้น Metasploit กำลังจะเผยแพร่รายละเอียดนี้ ดังนั้นช่องโหว่นี้คงจะถูกใช้มากขึ้นเพื่อโจมตีในไม่ช้า และยังไม่มี Patch จาก Oracle

คำแนะนำคือ

1. ปิดการใช้งานถ้าไม่จำเป็น
2. ถ้าจำเป็นต้องใช้ใน Critical Application/Website ที่ต้องใช้ java ให้ใช้ web browser อื่นเข้าใช้โดย
   1. ปิดการใช้งาน Java Plug-in ใน Web Browser ที่ใช้งานทั่วไป
   2. เปิดใช้ Java Plug-in บน Web Browser อีกตัวที่ใช้สำหรับ Website ที่ต้องการใช้ Java จริงๆ เช่นใช้ Firefox ที่ปิด Java Plugin ที่ใช้งาน Internet ทั่วไป และใช้ Internet Explorer ที่เปิด Java Plug-in เพื่อใช้งาน Website ที่ต้องใช้ Java
3. ระมัดระวังลิ้งค์ที่ไม่รู้จัก เช่นจาก อีเมล์ โปรแกรมสื่อสารข้อความ หรือเครือข่ายสังคม เป็นต้น

http://malware.dontneedcoffee.com/2013/01/0-day-17u10-spotted-in-while-disable.html

แนวทางใหม่ของ Trojan ฝัง Code ไว้ที่ Font

ถึงแม้ว่าคนจะใช้ FreeType Font มีอยู่จำนวนน้อยกว่า TrueType, Adobe Type 1 และ OpenType ก็ตามแต่ช่องโหว่นี้ทำให้คนชอบของฟรีโดยที่คิดว่า ไม่ใช่โปรแกรม ก็ไม่ใช่มัลแวร์ โดน Trojan เข้าไปได้ ซึ่งขยายขอบเขตจาก Graphics File ไปเป็น Font File แล้ว ที่น่าสนใจกว่า Graphics File คือ ส่วนใหญ่เมื่อติดตั้ง Font แล้วก็จะไม่ค่อยลบออกและถูกดึงขึ้นมาใช้เสมอเมื่อเครื่องทำงาน

รายละเอียดของช่องโหว่นี้อยู่ด้านล่าง

26 December 2012
Severity: Medium

Description:

Several vulnerabilities were reported in FreeType. A remote user can cause arbitrary code to be executed on the target user's system.

A remote user can create a specially crafted font file that, when loaded by the target user, will execute arbitrary code on the target system. The code will run with the privileges of the target user or application.

A null pointer dereference can be triggered in bdf_free_font()
[CVE-2012-5668].

An out-of-bounds read in can be triggered in _bdf_parse_glyphs()
[CVE-2012-5669].

An out-of-bounds write can be triggered in _bdf_parse_glyphs()
[CVE-2012-5670].

Impact: 

A remote user can create a font file that, when loaded by the target user, will execute arbitrary code on the target user's system.

Affected OS: 

• Linux (Any),
• UNIX (Any)

Affected Version: 

• prior to 2.4.11

http://sourceforge.net/projects/freetype/files/freetype2/2.4.11/README/view 

การแสดงตัวตนเพื่อทำธุรกรรมอิเล็กทรอนิกส์อย่างปลอดภัย (Identity & E-Commerce)

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

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

บางท่านอาจบอกว่า “ถ้าอย่างนั้นขอไม่ใช้งาน E-Commerce ก็แล้วกัน ดูท่าจะปลอดภัยกว่า” คำถามที่ตามมาคือ แน่ใจหรือว่าแม้ไม่ใช้ E-Commerce จะทำให้บัญชีของท่านปลอดภัย

ธุรกรรมของเรามีโอกาสเสี่ยงขนาดนั้นเชียวหรือ

เรามีสิทธิ์เลือกที่จะใช้หรือไม่ใช้ อย่างไรได้บ้าง

และเราจะป้องกันให้เราปลอดภัยจากการทำธุรกรรมเองหรือถูกสวมรอยได้อย่างไร

Identification

identity (1) - N – ความเหมือนกัน (2) - N – บุคลิกลักษณะ
identification - N – การแสดงตัว (NECTEC's Lexitron Dictionary)

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

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

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

Derived Identification

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

Authentication กับ Identification

เมื่ออยู่บนอินเตอร์เน็ต Identification ก็ต้องเป็นแบบอิเล็กทรอนิกส์ สิ่งที่ใกล้เคียงกับ Identification ที่ใช้ในวิถีคอมพิวเตอร์มากที่สุดก็คือการทำ Authentication

authentication n. รับรอง (พจนานุกรมแปล อังกฤษ-ไทย อ.สอ เสถบุตร)

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

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

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

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

Authentication ความเหมือนที่แตกต่าง

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

การตั้งบัญชีผู้ใช้งาน

วิธีการตั้งบัญชีผู้ใช้งานมีได้หลายแบบซึ่งขอยกตัวอย่างบางวิธีที่เคยพบและข้อดีข้อเสียของแต่ละแบบดังนี้

1 ใช้เลขที่บัญชีเป็นชื่อบัญชีผู้ใช้งาน

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

2 ผู้ให้บริการกำหนดให้

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

3 ใช้ Email เป็นชื่อบัญชีผู้ใช้งาน

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

4 ตั้งชื่อบัญชีตามใจชอบ

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

นโยบายเกี่ยวกับรหัสผ่าน (Password Policies)

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

1 ความยาวของรหัสผ่าน

ผู้ให้บริการมักจะกำหนดความยาวขั้นต่ำในการตั้งรหัสผ่านและไม่เกินกี่ตัวอักษร ความยาวของรหัสผ่านมากทำให้ยากต่อการคาดเดา และแน่นอนยากต่อการจำและการพิมพ์ผิด ผู้ให้บริการบางรายที่ยอมให้ใช้รหัสผ่านได้ไม่เกิน 10 ตัวอักษรถือว่าเป็นความเสี่ยง เช่นการใช้ PIN ซึ่งอยู่ระหว่าง 4-6 ตัว

2 ชนิดอักขระที่ใช้เป็นรหัสผ่าน

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

3 จำนวนครั้งที่อนุญาตให้พิมพ์รหัสผ่านผิด

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

4 อายุรหัสผ่าน

เท่าที่เห็นในการทำธุรกรรมกับผู้ให้บริการ E-Commerce ในเมืองไทย ไม่ค่อยมีการจำกัดอายุรหัสผ่านเพื่อบังคับให้เปลี่ยนรหัส อาจเป็นเพราะการทำธุรกรรมมีไม่บ่อยเลยไม่จำกัดอายุการใช้งานรหัสผ่าน อย่างไรก็ตามเราก็ควรจะเปลี่ยนรหัสผ่านเองบ่อยๆ อาจเป็นทุก 3-6 เดือน

5 วิธีป้อนรหัสผ่าน

ผู้ให้บริการบางรายอาจเพิ่มวิธีการรักษาความปลอดภัยโดยการให้ป้อนรหัสผ่านด้วย On Screen Keyboard แทน Keyboard ปกติ ซึ่งการทำแบบนี้ก็จะใช้งานจากเครื่องสาธารณะหรือเครื่องที่อาจติด Malware ที่ดักจับรหัสผ่านได้อย่างปลอดภัยมากยิ่งขึ้น

ตัวอย่าง On-Screen Keyboard จาก CitiBank

การส่งชื่อบัญชีและรหัสผ่านผ่านเครือข่าย

การส่งชื่อบัญชีและรหัสผ่านผ่านเครือข่าย ต้องมั่นใจว่ามีการเข้ารหัสข้อมูล ซึ่งมาตรฐานการส่งข้อมูลผ่าน Web Browser คือ Transport Layer Securityi (TLS หรือเดิมเรียก SSL) ปัจจุบัน Web Browser ส่วนใหญ่ก็สนับสนุนการใช้ TLS/SSL อยู่แล้ว

จุดสังเกตว่า Internet Explorer 8 ใช้ TLS/SSL

จุดสังเกตว่า Firefox 3 ใช้ TLS/SSL

สิ่งสำคัญที่ต้องตรวจสอบก็คือ TLS/SSL ต้องมี Certificate จาก Certificate Authority เช่น VeriSign โดยจะต้องมีไอคอนที่จะตรวจสอบ Certificate นั้นได้ปรากฏอยู่ในหน้าใดหน้าหนึ่งของผู้ให้บริการ เพื่อให้มั่นใจว่าการเข้ารหัสข้อมูลปลอดภัยอย่างแท้จริง

5ตัวอย่างไอคอนที่ใช้ตรวจสอบ Certificate จากธนาคารกสิกรไทย

การยกเลิกและตั้งค่ารหัสผ่านใหม่ (Password Reset)

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

1. ยื่นคำร้องขอเปลี่ยนรหัสผ่าน วิธีนี้จะปลอดภัยที่สุดเพราะท่านต้องติดต่อกับผู้ให้บริการด้วยตัวเองโดยใช้การแสดงตัวของท่าน แต่แน่นอน ไม่สะดวกและเสียเวลา
2. ขอเปลี่ยนรหัสผ่านทางอินเตอร์เน็ตแต่อนุมัติผ่าน Call Center วิธีนี้ปลอดภัยในระดับรองลงมา สะดวกเพราะไม่ต้องเดินทาง แต่ก็สามารถถูกลักลอบใช้บัญชีได้โดยการปลอมแปลงตัวตนจากการได้ข้อมูลส่วนบุคคล (Identity) ของเรา แล้วให้ข้อมูลที่ถูกต้องต่อ Call Center
3. เปลี่ยนรหัสผ่านด้วยข้อมูลส่วนตัว วิธีนี้ปลอดภัยน้อยกว่าสองวิธีก่อนหน้า และเช่นเดียวกันกับการอนุมัติผ่าน Call Center ถ้ามีผู้ที่ทราบข้อมูลที่จำเป็นในการยกเลิกรหัสผ่าน ซึ่งมักจะเป็นคำถามพิเศษที่เราตั้ง เราก็โดนขโมยบัญชีไปใช้งานเช่นกัน
4. ยืนยันการยกเลิกและเปลี่ยนรหัสผ่านทาง Email วิธีนี้ปลอดภัยน้อยที่สุด โดยเฉพาะอย่างยิ่งถ้า Mail Server ที่เราใช้ไม่ปลอดภัยเพียงพอ เมื่อเราโดนยึด Email Address ไป การยกเลิกรหัสผ่านก็ทำได้โดยง่าย

Two-Factor Authentication รหัสผ่านสองชั้น

An authentication factor is a piece of information and process used to authenticate or verify the identity of a person or other entity requesting access under security constraints. Two-factor authentication (T-FA) or (2FA) is a system wherein two different factors are used in conjunction to authenticate. Using two factors as opposed to one factor generally delivers a higher level of authentication assurance. Two-factor authentication typically is a signing-on process where a person proves his or her identity with two of the three methods: "something you know" (e.g., password or PIN), "something you have" (e.g.,smartcard or token), or "something you are" (e.g., fingerprint or iris scan). From Wikipedia, the free encyclopedia

เมื่อข้อมูลทางการเงินเป็นสิ่งสำคัญ การเพิ่มระดับของการรักษาความปลอดภัยในการใช้บริการ โดยการเพิ่มการเข้าใช้ระบบนอกเหนือจากสิ่งที่เราต้องจำ (ชื่อบัญชีและรหัสผ่าน) ด้วยสิ่งที่เรามี (เช่นโทรศัพท์มือถือ อีเมล หรือ Token) โดยการใช้รหัสผ่านแบบใช้ครั้งเดียว (Single-Use หรือ OTP: One-Time Password) รหัสผ่านประเภทนี้ จะเป็นรหัสผ่านที่เปลี่ยนแปลงไปทุกครั้งที่มีการใช้งาน โดยเมื่อรหัสผ่านใดๆก็ตามได้ถูกใช้งานไปแล้ว จะไม่สามารถนำมาใช้งานได้อีกต่อไป ซึ่งจะสามารถลดความเสี่ยงที่อาจเกิดขึ้นจากการถูกเจาะขโมยข้อมูลรหัสผ่านที่ อาจกระทำได้โดยง่ายหากใช้รหัสผ่านประจำตัวแบบปกติเพียงอย่างเดียว OTP ที่ผู้ให้บริการส่วนใหญ่จะใช้อยู่ด้วยกัน 3 ประเภทคือ

1 SMS OTP

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

ตัวอย่างหน้าใส่รหัสผ่าน OTP ของธนาคารกรุงศรีอยุธยา

2 Email OTP

หลักการก็จะเป็นเช่นเดียวกับ SMS OTP เพียงแต่เปลี่ยนช่องทางการส่งข้อมูลไปยังโทรศัพท์ เป็น Email Address ที่ให้ไว้กับผู้ให้บริการ

3 Token OTP

ตัวอย่าง Token แบบต่างๆ

ตัวอย่างหน้า Token OTP ของธนาคาร HSBC

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

บริการที่ไม่ใช้ Authentication

Authentication ไม่ได้เป็นวิธีการเดียวในการแสดงตัวตน ในการทำธุรกรรมบนอินเตอร์เน็ต การใช้ข้อมูลส่วนบุคคลร่วมกับข้อมูลจาก Derived Identification เช่นการใช้บัตรเครดิตซื้อสินค้าบนอินเตอร์เน็ต ก็เป็นอีกวิธีในการแสดงตัวตน
โดยทั่วไปการใช้บัตรเครดิตซื้อสินค้าบนอินเตอร์เน็ต ในการทำการอนุมัติการทำรายการนั้น ร้านค้าจะทำการ Redirect ไปยัง Third Party Processor ซึ่งมีหลายประเภทเช่น Secure Payment Gateway Providerเพื่อทำรายการซื้อขาย Third Party Processor จะมีสัญญากับ Credit Card Processor เช่น VISA/Mastercard/AMEXหรือกับธนาคาร โดยมักจะทำการพิสูจน์การถือครองบัตรด้วยข้อมูลคือ

• หมายเลขบัตร
• ชื่อผู้ถือบัตร
• เดือนปีที่บัตรหมดอายุ
• Card Security Code (CSC) หรือบางครั้งเรียกว่า Card Verification Value (CVV or CV2), Card Verification Value Code (CVVC), Card Verification Code (CVC), Verification Code (V-Code or V Code), หรือ Card Code Verification (CCV) ซึ่งจะเป็นตัวเลข 3-4 หลัก พิมพ์อยู่ด้านหลังหรือด้านหน้าแล้วแต่ชนิดของบัตร (ไม่ใช่ตัวนูน)

ข้อควรระวัง:

• เพื่อให้มั่นใจว่าการดำเนินการชำระเงินผ่าน Third Party Processor ตรวจสอบดูว่า URL หน้านั้นเป็นของ Third Party Processor ไม่ใช่ของร้านค้า ใช้ HTTPS เสมอและมี Certificate จาก Certificate Authority
• ในกรณีที่ร้านค้าบนเว็บมี Merchant Account ซึ่งทำการตัดบัตรเครดิตจากธนาคารโดยตรง ต้องมั่นใจว่าร้านค้านั้นน่าเชื่อถือเพียงพอ ใช้ HTTPS เสมอและมี Certificate จาก Certificate Authority
• เนื่องจากข้อมูลที่ใช้ในการพิสูจน์การถือครองบัตรอยู่บนตัวบัตรทั้งหมด ดังนั้นไม่ควรให้ใครทำสำเนาบัตรเครดิตไป ไม่ว่าจะเป็นการถ่ายเอกสารหรือถ่ายภาพ

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

อุดช่องโหว่จากการลักลอบใช้บัญชีของเรา

จากข้อมูลที่กล่าวมาข้างต้นเราพบว่ามีช่องโหว่ที่เราต้องอุดอยู่หลายจุด ซึ่งช่องโหว่นั้นอาจเป็นช่องโหว่จากผู้ให้บริการเอง หรือจากเราซึ่งเป็นผู้ใช้ ข้อแนะนำในการป้องกันตัวเองจากภัยที่เกิดจากการใช้งาน E-Commerce มีดังนี้

1. เปิดบัญชีทำธุรกรรมกับสถาบันการเงิน กรุณาตรวจสอบเสียก่อนว่าการใช้งานผ่านอินเตอร์เน็ตต้องยื่นคำร้อง หรือใช้เอกสารที่สถาบันการเงินออกให้เปิดใช้ได้โดยตรง ถ้าเป็นกรณีหลัง กรุณาใช้สิทธิ์ของท่านก่อนที่คนอื่นจะมาใช้สิทธิ์แทน
2. ตั้งชื่อบัญชีใช้งานที่ไม่เกี่ยวกับชื่อและนามสกุลเรา หรือนามแฝง (Alias) อื่นๆที่เราใช้เพื่อป้องกันการรู้บัญชีผู้ใช้งาน
3. ใช้รหัสผ่านที่มีอักขระพิเศษถ้าเป็นไปได้ และให้มีความยาวมากเพียงพอมากกว่า 8 ตัวอักษร เปลี่ยนรหัสผ่านบ่อยๆ และบัญชีผู้ใช้ของผู้ให้บริการต่างๆ ใช้รหัสผ่านไม่เหมือนกัน (แน่นอนว่าเพิ่มความยุ่งยาก)
4. Email ที่ใช้ติดต่อทำธุรกรรมควรจะมีความปลอดภัยสูง เช่นใช้ POP3/IMAP/SMTP ที่เข้ารหัส TLS/SSL และ/หรือไม่ใช่พอร์ตมาตรฐาน ถ้าเป็น Web Mail ต้องเข้าด้วย HTTPS ถ้าไม่แน่ใจให้เปิด Email ไว้สำหรับทำธุรกรรมโดยเฉพาะ ควรใช้อีเมล์ขององค์กรและเลี่ยงพวกฟรีอีเมล์เพราะส่วนใหญ่แล้วจะเป็น Web Mail ที่ใช้ HTTPS เฉพาะหน้า login แต่หน้าอ่านเมล์ปกติไม่เข้ารหัส แต่หากไม่มีจริงๆ ให้ใช้ Gmail ผ่าน HTTPS หรือทาง POP3/IMAP/SMTP ซึ่ง Gmail รองรับการเข้ารหัสไว้
5. รักษาข้อมูลส่วนบุคคลให้เป็นความลับมากที่สุด โดยเฉพาะอย่างยิ่งข้อมูลที่ Call Center มักจะถามเช่น หมายเลขบัตรประชาชน หมายเลขบัตรเครดิต วันเกิด เบอร์โทรศัพท์ที่ใช้ติดต่อธนาคาร วงเงินสินเชื่อ ที่อยู่ในการจัดส่งใบแจ้งยอดบัญชี จำนวนบัตรเสริม ข้อมูลส่วนใหญ่ที่ใช้ทำธุรกรรมจะอยู่บนบัตรประชาชน บัตรเครดิต และใบแจ้งยอดบัญชีบัตรเครดิต และอย่านำข้อมูลดังกล่าวไปไว้ในอินเตอร์เน็ตโดยไม่จำเป็น
6. กรณีใช้บัตรเครดิต ข้อมูลสำคัญจะอยู่ที่ใบแจ้งยอดบัญชีบัตรเครดิต และจากใบแจ้งยอดบัญชีบัตรเครดิตจะทำให้หาข้อมูลอื่นๆ ได้ง่าย ถ้าผู้ไม่ประสงค์ดีได้ใบแจ้งยอดบัตรเครดิตไป สามารถแก้ไขข้อมูลเจ้าของบัตรได้โดยไม่รู้ตัว เช่น การยกเลิกรหัสผ่าน รวมไปถึงเปลี่ยนที่อยู่ในการจัดส่ง อายัดบัตร แล้วออกบัตรใหม่ ดังนั้นควรเก็บรักษาใบแจ้งยอดบัญชีบัตรเครดิตเป็นอย่างดี หรือทำลายให้เร็วที่สุด หรือเปลี่ยนไปใช้ Electronics Statement ในกรณีที่ผู้ออกบัตรเปิดให้บริการ จะปลอดภัยมากกว่า
7. ยกเลิกการใช้บริการ ถ้าไม่มั่นใจว่าผู้ให้บริการมีความปลอดภัยเพียงพอ อย่าเสี่ยง

บทส่งท้าย

เราคงได้เห็นแล้วว่าข้อมูลส่วนบุคคลของเราสำคัญอย่างไรในการทำธุรกรรมอิเล็กทรอนิกส์ และมีความจำเป็นอย่างยิ่งที่จะต้องปกปิดข้อมูลส่วนบุคคลของเราให้มากที่สุด เพื่อป้องกันไม่ให้ถูกนำไปใช้ทำธุรกรรม แม้ว่าเราเองจะต้องการทำธุรกรรมอิเล็กทรอนิกส์หรือไม่ก็ตาม ที่สุดแล้วขอฝากข้อคิดสั้นๆทิ้งท้ายไว้เพื่อเตือนใจคือ “ปกปิด Identity แล้ว E-Commerce จะปลอดภัย”