20 ตุลาคม 2560

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 ของผม

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

17 ตุลาคม 2560

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

07 ตุลาคม 2560

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