SOC Architecture Blueprint สำหรับหน่วยงานภาครัฐ

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

เริ่มจากหน้าที่ตามกฎหมาย

พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 เป็นกฎหมายหลักที่ต้องยึดเป็นฐาน ประเด็นด้านล่างสรุปจากฉบับแปลภาษาอังกฤษที่ไม่เป็นทางการ หากจะใช้อ้างอิงอย่างเป็นทางการ ต้องตรวจจากตัวบทภาษาไทย

• มาตรา 44: หน่วยงานของรัฐ หน่วยงานควบคุมหรือกำกับดูแล และหน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CII) ต้องจัดทำประมวลแนวทางปฏิบัติและกรอบมาตรฐาน อย่างน้อยต้องมีแผนตรวจสอบและประเมินความเสี่ยงปีละหนึ่งครั้ง และแผนรับมือภัยคุกคามทางไซเบอร์
• มาตรา 45: หน่วยงานเดียวกันนี้ต้องป้องกัน รับมือ และลดความเสี่ยงจากภัยคุกคามให้เป็นไปตามประมวลแนวทางปฏิบัติของตน และขอความช่วยเหลือจากสำนักงาน (สกมช.) ได้
• มาตรา 46: ต้องแจ้งรายชื่อเจ้าหน้าที่ระดับบริหารและระดับปฏิบัติการที่ทำหน้าที่ประสานงานด้านความมั่นคงปลอดภัยไซเบอร์ให้สำนักงานทราบ
• มาตรา 58: เมื่อมีหรืออาจมีภัยคุกคามต่อระบบที่หน่วยงานของรัฐหรือ CII รับผิดชอบ ต้องตรวจสอบข้อมูลและระบบก่อน หากยืนยันได้ว่ามีภัยจริง ต้องป้องกัน รับมือ และลดความเสี่ยงตามประมวลแนวทางปฏิบัติ พร้อมแจ้งสำนักงานและหน่วยงานควบคุมหรือกำกับดูแลโดยเร็ว
• เฉพาะ CII ที่ได้รับการกำหนด (มาตรา 49 ระบุไว้ 8 ด้าน เช่น การเงินการธนาคาร พลังงาน และสาธารณสุข): ต้องประเมินความเสี่ยงและตรวจสอบด้านความมั่นคงปลอดภัยไซเบอร์อย่างน้อยปีละครั้ง แล้วส่งรายงานสรุปให้สำนักงานภายใน 30 วัน (มาตรา 54) ต้องมีกลไกเฝ้าระวังภัยคุกคามและเข้าร่วมการประเมินความพร้อม (มาตรา 56) และต้องรายงานภัยคุกคามที่มีนัยสำคัญ (มาตรา 57)

มีข้อสังเกตสองข้อ ข้อแรก กฎหมายไม่ได้กล่าวถึง SOC และไม่ได้กำหนดสถาปัตยกรรมไว้ สิ่งที่เชื่อมโยงกับ SOC ได้คือกลไกเฝ้าระวังในมาตรา 56 และหน้าที่ตรวจสอบและรับมือในมาตรา 58 ดังนั้นการออกแบบ SOC จึงเป็นการตัดสินใจของหน่วยงานเอง โดยอิงประมวลแนวทางปฏิบัติและมาตรฐานที่หน่วยงานกำกับดูแลกำหนด ข้อที่สอง หน่วยงานส่วนใหญ่อยู่ภายใต้มาตรา 44 ถึง 46 และ 58 ส่วนมาตรา 54 ถึง 57 ใช้กับ CII ที่ได้รับการกำหนดเท่านั้น คำว่า "โดยเร็ว" ในกฎหมายไม่ได้ระบุเป็นตัวเลข แต่ กกม. (คณะกรรมการกำกับดูแลด้านความมั่นคงปลอดภัยไซเบอร์) อาจกำหนดหลักเกณฑ์การรายงานได้ (มาตรา 57) จึงควรตรวจประกาศล่าสุดจาก สกมช.

สถาปัตยกรรมอ้างอิงหกชั้น

ให้มอง SOC เป็นหกชั้น โดยแต่ละชั้นต้องมีเจ้าของที่ระบุชื่อได้ ถ้าชั้นใดชั้นหนึ่งมีช่องว่าง ชั้นอื่นก็อ่อนแอลงไปด้วย

• 1. อำนาจหน้าที่และธรรมาภิบาล: ต้องมีกฎบัตรที่ผู้บริหารสูงสุดของหน่วยงานลงนาม มีขอบเขตชัดเจนว่า SOC ดูแลระบบและหน่วยงานใดบ้าง มีอำนาจแยกระบบและบล็อก มีเส้นทางส่งเรื่องถึงผู้บริหาร และเชื่อมโยงกับประมวลแนวทางปฏิบัติ
• 2. แหล่งข้อมูล: ข้อมูลจากตัวตนผู้ใช้ (ไดเรกทอรีและ single sign-on คือระบบ login ครั้งเดียวใช้ได้หลายระบบ) เครื่อง endpoint (EDR คือเครื่องมือเฝ้าระวังและตอบสนองบนตัวเครื่อง) เครือข่าย (ไฟร์วอลล์ proxy DNS และ NDR คือเครื่องมือตรวจจับความผิดปกติในทราฟฟิกเครือข่าย) เซิร์ฟเวอร์และแอปพลิเคชัน log ตรวจสอบของคลาวด์และ SaaS (บริการซอฟต์แวร์บนคลาวด์) ระบบรักษาความปลอดภัยอีเมล รวมถึงบัญชีรายการสินทรัพย์และเครื่องสแกนช่องโหว่ ให้จัดลำดับตามความเสี่ยง ไม่ต้องนำเข้าทุกอย่าง
• 3. การรวบรวมและจัดเก็บ: ตัวรวบรวมข้อมูล (collector) การแปลง log ให้อยู่ในรูปแบบเดียวกัน (normalization) โดย schema แบบเปิดอย่าง OCSF ช่วยลดการผูกติดกับผู้ผลิตรายเดียว การซิงก์เวลาที่เชื่อถือได้ ที่เก็บข้อมูลที่ป้องกันการแก้ไข การแบ่งชั้นการเก็บเป็นร้อน อุ่น และเย็น (จากข้อมูลใหม่ที่ค้นได้เร็ว ไปจนถึงข้อมูลเก่าที่เก็บประหยัด) และนโยบายว่า log เก็บไว้ที่ใดได้บ้าง
• 4. การตรวจจับและวิเคราะห์: กฎตรวจจับและการวิเคราะห์บน SIEM (ระบบรวบรวมและวิเคราะห์ log จากหลายแหล่ง) การตรวจจับบน endpoint และตัวตน threat intelligence (ข้อมูลข่าวกรองภัยคุกคาม) และ use case (สถานการณ์โจมตีที่ต้องการตรวจจับ) ที่จับคู่กับ MITRE ATT&CK (ฐานความรู้เรื่องเทคนิคการโจมตี) โดยดูแลเป็นวงจร คือเขียน ทดสอบ ปรับจูน และเลิกใช้เมื่อหมดประโยชน์
• 5. การตอบสนองและระบบอัตโนมัติ: ระบบจัดการเคส playbook (ขั้นตอนรับมือที่เขียนไว้ล่วงหน้าสำหรับแต่ละสถานการณ์) ระบบอัตโนมัติสำหรับขั้นตอนที่ทำซ้ำ อำนาจในการกักกัน (แยกระบบที่ถูกโจมตีออกมา) การจัดการหลักฐาน และการเชื่อมกับงานปฏิบัติการไอทีเพื่อออกแพตช์และเปลี่ยนแปลงระบบ
• 6. การรายงานและการปรับปรุง: การรายงานผู้บริหารตามระดับความรุนแรง การแจ้ง สกมช. และหน่วยงานกำกับเมื่อมีหน้าที่ต้องแจ้ง ตัวชี้วัดอย่าง MTTD และ MTTR (เวลาที่ใช้ตรวจพบและเวลาที่ใช้ตอบสนองต่อเหตุการณ์) การสรุปบทเรียน และการซ้อมสม่ำเสมอ

เครื่องมือของ SOC เองเป็นเป้าหมายที่มีคุณค่าสูงสำหรับผู้โจมตี จึงควรแยกเครือข่ายบริหารจัดการ SOC ออกมาต่างหาก บังคับใช้ MFA (การยืนยันตัวตนหลายขั้นตอน) ที่เข้มแข็ง ควบคุมสิทธิ์ระดับสูงของนักวิเคราะห์และผู้ดูแลระบบ และสำรองกฎตรวจจับที่เขียนไว้ หากต้องการเลือกเครื่องมือ ดู SIEM + SOAR กับ XDR: ข้อดี ข้อจำกัด และคำแนะนำ และ Zero Trust Architecture: องค์ประกอบและแผนเริ่มต้น

เลือกรูปแบบการดำเนินงาน

• ทำเอง (In-house): ควบคุมได้มากที่สุดและเข้าใจหน่วยงานลึกที่สุด แต่การจ้างและรักษาคนให้ครบ 24x7 (ตลอด 24 ชั่วโมงทุกวัน) ทำได้ยากและมีต้นทุนสูง
• จ้างภายนอก (MSSP หรือ MDR): จ้างผู้ให้บริการด้านความปลอดภัยมาเฝ้าระวังและตอบสนองแทน (MSSP คือผู้ให้บริการเฝ้าระวังความปลอดภัย MDR คือผู้ให้บริการตรวจจับและตอบสนองภัย) เริ่มได้เร็วและครอบคลุมทุกช่วงเวลา แต่ต้องมีสัญญาที่รัดกุม มีกฎชัดเจนว่าเก็บข้อมูลที่ใด และควบคุมสิทธิ์ที่ผู้ให้บริการมีในระบบของหน่วยงาน
• ผสม (Hybrid): นักวิเคราะห์ของหน่วยงานดูแลในเวลาทำการ และผู้ให้บริการดูแลนอกเวลา วิธีนี้ใช้ได้ผลเมื่อกำหนดวิธีส่งมอบงานระหว่างกันไว้ชัดเจนเท่านั้น
• บริการร่วมระดับกลุ่มหรือกระทรวง (Shared service): หลายหน่วยงานใช้ SOC ร่วมกัน ประหยัดจากขนาดและใช้เครื่องมือสอดคล้องกัน แต่ต้องมีธรรมาภิบาลกำกับเรื่องการแบ่งปันข้อมูล ลำดับความสำคัญ และงบประมาณ

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

ต้องใช้กี่คน: ตัวเลขสำหรับวางแผนกะงาน

หนึ่งตำแหน่งที่ต้องมีคนประจำต่อเนื่องไม่หยุด ต้องครอบคลุม 168 ชั่วโมงต่อสัปดาห์ แต่คนหนึ่งคนทำงานได้จริงประมาณ 36 ถึง 40 ชั่วโมงต่อสัปดาห์ หลังหักวันลา วันหยุด และเวลาอบรมแล้ว ดังนั้นหนึ่งตำแหน่ง 24x7 ต้องใช้คนประมาณ 4.2 ถึง 4.7 คน (นำ 168 หารด้วย 40 และหารด้วย 36) จึงควรวางแผนที่ประมาณ 5 คน ถ้าต้องการนักวิเคราะห์สองคนในทุกกะของ 24x7 จะต้องใช้นักวิเคราะห์ประมาณ 8.4 ถึง 9.3 คน จึงควรวางแผนที่ประมาณ 9 ถึง 10 คน ซึ่งยังไม่รวมหัวหน้ากะ วิศวกร และผู้จัดการ ตัวเลขนี้เป็นค่าประมาณสำหรับวางแผน ไม่ใช่มาตรฐาน ให้ปรับตามระเบียบด้านบุคลากรของหน่วยงาน

• ผู้จัดการ SOC: รับผิดชอบบริการโดยรวม การรายงาน และการส่งเรื่องต่อ
• นักวิเคราะห์ระดับ 1: คัดกรองการแจ้งเตือนตาม playbook
• นักวิเคราะห์ระดับ 2: สืบสวนเหตุการณ์ และดำเนินการกักกัน
• Detection engineer และ threat hunter: สร้าง ทดสอบ และปรับจูนการตรวจจับ
• วิศวกรแพลตฟอร์ม: ดูแล SIEM ตัวรวบรวมข้อมูล และระบบอัตโนมัติ
• ผู้ประสานงาน: ผู้ติดต่อในงานปฏิบัติการไอที ฝ่ายกฎหมาย และฝ่ายดูแลความเป็นส่วนตัว

กระบวนการที่ทำให้ SOC ทำงานได้จริง

• ระดับความรุนแรงและระดับบริการ: กำหนดนิยามระดับความรุนแรงที่ตกลงร่วมกัน พร้อมเวลาที่ต้องตอบสนองและส่งเรื่องต่อ
• วงจรการรับมือเหตุการณ์: ทำให้สอดคล้องกับ NIST SP 800-61 Rev. 3 และหน้าที่หลัก (function) ของ NIST Cybersecurity Framework 2.0
• Playbook: เขียนขั้นตอนรับมือสำหรับสถานการณ์ที่น่าจะเกิดมากที่สุด เช่น ฟิชชิง (phishing) แรนซัมแวร์ (มัลแวร์เข้ารหัสไฟล์เพื่อเรียกค่าไถ่) บัญชีผู้ใช้ถูกผู้โจมตียึด เว็บไซต์ถูกเปลี่ยนหน้า และข้อมูลรั่วไหล
• การจัดการหลักฐาน: เก็บ log และ image (ไฟล์สำเนาของดิสก์หรือเครื่อง) ไว้ให้ครบ เพื่อให้ข้อค้นพบใช้ในการสอบสวนหรือทางกฎหมายได้
• วงจรของการตรวจจับ: การตรวจจับทุกชุดต้องมีเจ้าของ มีการทดสอบ และมีวันทบทวน
• การซ้อม: ซ้อมแบบ tabletop (ประชุมจำลองสถานการณ์บนโต๊ะ) และซ้อมเชิงเทคนิค ดู Network & Cyber Security Simulator: ประเภทและการใช้งาน

วัดผลและพัฒนาต่อเนื่อง

ให้วัดสิ่งที่ SOC ทำได้สำเร็จ ไม่ใช่จำนวนการแจ้งเตือนที่ปิดได้ ตัวชี้วัดที่มีประโยชน์ ได้แก่ เวลาที่ใช้ตรวจจับและเวลาที่ใช้ตอบสนอง (ดู นำ AI มาใช้ใน SOC เพื่อลด MTTD และ MTTR), สัดส่วนระบบสำคัญที่มี log ครอบคลุม, สัดส่วนเทคนิค ATT&CK ที่สำคัญซึ่งมีการตรวจจับที่ทดสอบแล้ว, อัตราการแจ้งเตือนผิดพลาด (false positive) และผลการซ้อม จากนั้นนำตัวชี้วัดเหล่านี้มาระบุว่า SOC อยู่ที่ระดับวุฒิภาวะ (ความพร้อมและความก้าวหน้า) ใด และใช้ประกอบการขอลงทุนขั้นถัดไป

เขียน TOR ให้ได้ผลลัพธ์ ไม่ใช่แค่ผลิตภัณฑ์

ใน TOR ควรระบุผลลัพธ์ที่ต้องการและวิธีตรวจรับ ไม่ใช่ระบุแค่ชื่อผลิตภัณฑ์ ต่อไปนี้คือเช็กลิสต์ที่นำไปปรับใช้ได้

• ขอบเขต: จำนวนและประเภทของแหล่ง log จำนวนสถานที่ และบริการคลาวด์ที่ครอบคลุม
• ฐานการประมาณขนาด: จำนวนเหตุการณ์ (event) ต่อวินาที หรือปริมาณข้อมูลต่อวัน พร้อมอัตราการเติบโต
• ระยะเวลาเก็บข้อมูล: กำหนดแยกตามชั้นการเก็บ พร้อมฐานทางกฎหมายและนโยบายที่ตกลงไว้กับฝ่ายกฎหมาย
• ที่เก็บและความเป็นเจ้าของข้อมูล: ข้อมูลเก็บที่ใด และใครเป็นเจ้าของกฎตรวจจับและรายงาน
• ช่วงเวลาและระดับบริการ: นิยามระดับความรุนแรง เวลาตอบสนองและเวลาแจ้งเหตุ และรูปแบบรายงาน
• บุคลากร: บทบาท คุณสมบัติ และความต่อเนื่องของผู้ปฏิบัติงานที่ระบุชื่อไว้
• ความปลอดภัยของแพลตฟอร์ม: การแยกเครือข่าย MFA และการบันทึกและตรวจสอบการเข้าถึงระบบของหน่วยงานโดยผู้ให้บริการ
• การเชื่อมต่อ: ระบบ ticket (ระบบแจ้งและติดตามงาน) EDR ไฟร์วอลล์ และไดเรกทอรีที่หน่วยงานมีอยู่แล้ว
• การทดสอบตรวจรับ: การจำลองโจมตีที่จับคู่กับ ATT&CK และช่วงทดลองใช้กับ log ตัวอย่างของหน่วยงาน
• การเลิกสัญญาและส่งมอบงานต่อ: การส่งออกข้อมูล ความเป็นเจ้าของกฎตรวจจับ และการถ่ายทอดความรู้

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

แผนงานแบ่งเป็นระยะ

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

• ระยะ 0 (เดือน 0 ถึง 3): ทำกฎบัตร กำหนดขอบเขต ทำบัญชีรายการสินทรัพย์ และระบุผู้ประสานงานกับช่องทางแจ้งเหตุ
• ระยะ 1 (เดือน 3 ถึง 9): รวบรวม log ที่สำคัญ ติดตั้ง SIEM และให้เห็นความเคลื่อนไหวบนเครื่อง endpoint แล้วเริ่มเฝ้าระวังในเวลาทำการ พร้อมการตรวจจับชุดแรก
• ระยะ 2 (เดือน 9 ถึง 18): ขยายเป็น 24x7 หรือใช้ผู้ให้บริการ เพิ่ม playbook และระบบจัดการเคส และทำขั้นตอนที่ซ้ำให้เป็นอัตโนมัติ
• ระยะ 3 (ตั้งแต่เดือน 18): ล่าภัยเชิงรุก ปรับจูนการตรวจจับตาม ATT&CK ซ้อมสม่ำเสมอ และให้ผู้บริหารทบทวนตัวชี้วัด

ข้อผิดพลาดที่พบบ่อย

• ซื้อ SIEM ก่อนเลือกแหล่ง log และ use case: แพลตฟอร์มเต็มไปด้วยข้อมูลที่ไม่มีใครใช้
• SOC ที่ไม่มีอำนาจ: นักวิเคราะห์เห็นภัยคุกคามแต่แยกระบบที่ถูกโจมตีไม่ได้
• ไม่มี playbook: ทุกเหตุการณ์ต้องคิดวิธีแก้สดๆ ทุกครั้ง
• Alert fatigue (ทีมล้าจากการแจ้งเตือนมากเกินไป): การตรวจจับที่ไม่ได้ปรับจูนสร้างการแจ้งเตือนจำนวนมาก จนสัญญาณภัยจริงจมหายไป
• SOC แยกจากงานปฏิบัติการไอที: สิ่งที่ SOC ตรวจพบไม่ถูกส่งต่อไปเป็นการแพตช์และแก้ไขระบบ
• 24x7 บนกระดาษเท่านั้น: มีสัญญาหรือตารางเวรที่เขียนว่าครอบคลุม แต่ในทางปฏิบัติไม่มีคนเฝ้าตอนกลางคืนและวันหยุด
• มองข้ามระยะเวลาเก็บข้อมูลและหน้าที่ตามกฎหมาย: log ถูกลบไปก่อนที่การสอบสวนจะต้องใช้

เริ่มได้ทันที

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

ก่อนเริ่มวางแผน หากต้องการทราบว่าหน่วยงานอยู่ในระดับใด ลองใช้ แบบประเมินตนเอง

ความถูกต้องและขอบเขต

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

ผลสแกนช่องโหว่ต้องกลายเป็นการแก้จริงร่วมกับฝ่ายปฏิบัติการ IT ดูวิธีจัดวงจรนี้ใน โปรแกรม Vulnerability Management ที่ใช้ได้จริง

แหล่ง log จากคลาวด์เป็นอีกส่วนที่ SOC ต้องรวมเข้ามา ดู Cloud Logging และ Detection: ต้องเก็บ log อะไร

ส่วนทางเลือกรูปแบบการดำเนินงานในบทความนี้ลงรายละเอียดต่อได้ใน SOC ทำเอง, MSSP หรือ Hybrid: เลือกอย่างไร

แหล่ง log และระยะเวลาเก็บเป็นฐานของ SOC ดูแนวทางวางนโยบายใน Log Management: ต้องเก็บ log อะไร นานเท่าไร

หน่วยงานรัฐและ CII มีหน้าที่ตามกฎหมายด้วย ดู พ.ร.บ.ไซเบอร์และ CII: องค์กรไหนเกี่ยวข้อง

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• Cybersecurity Act B.E. 2562 (2019) ฉบับแปลอังกฤษไม่เป็นทางการ: มาตรา 44 ถึง 46, 49 และ 54 ถึง 58
• ThaiCERT: หน่วยงาน CII: ด้านและหน้าที่โดยสรุป
• สกมช. (NCSA): ประกาศและแนวทางอย่างเป็นทางการ
• มาตรฐานรัฐบาลดิจิทัล (สพร.): มาตรฐานและแนวทางดิจิทัลภาครัฐ
• MITRE: 11 Strategies of a World-Class Cybersecurity Operations Center: แหล่งอ้างอิงกลยุทธ์ SOC
• NIST SP 800-61 Rev. 3: Incident Response Recommendations
• NIST Cybersecurity Framework 2.0
• NIST SP 800-92: Guide to Computer Security Log Management
• CISA: Guidance for SIEM and SOAR implementation: รวมถึง priority logs
• MITRE ATT&CK
• NIST SP 800-84: Test, Training, and Exercise Programs