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

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

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

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