งานในศูนย์เฝ้าระวังความปลอดภัยไซเบอร์: หน้าที่ ขอบเขตกฎหมาย และเกณฑ์เลือกบริการ SOC

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

การทำงานที่ปลอดภัยต้องกำหนดสิทธิ์เข้าถึง การจัดการ log และผู้มีอำนาจตัดสินใจให้ชัดเจนตั้งแต่ต้น. องค์กรที่กำลังเลือกระหว่างทีม SOC ภายในกับ Managed SOC ควรเทียบขอบเขตข้อมูล ชั่วโมงเฝ้าระวัง SLA และระดับการตอบสนอง มากกว่าดูค่าใช้จ่ายเพียงด้านเดียว.

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

หากต้องขอใบเสนอราคา ควรระบุแหล่งข้อมูล ปริมาณ log และความคาดหวังเมื่อเกิดเหตุให้ครบก่อนเปรียบเทียบบริการ.

สรุปอย่างรวดเร็ว

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

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

ศูนย์เฝ้าระวังความปลอดภัยไซเบอร์ทำอะไร และไม่ควรทำอะไร

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

ภารกิจหลักตั้งแต่รับสัญญาณเตือนจนถึงยกระดับเหตุ

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

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

เส้นแบ่งระหว่างการเฝ้าระวัง การสืบค้น และการเข้าถึงระบบ

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

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

สรุป 3 บรรทัดสำหรับผู้บริหารและผู้เริ่มงาน

SOC ตรวจจับและประสาน ไม่ได้แทนผู้มีอำนาจอนุมัติทุกเรื่อง
สิทธิ์เข้าถึงต้องผูกกับหน้าที่และตรวจสอบย้อนหลังได้
เหตุที่เกี่ยวกับข้อมูลส่วนบุคคลหรือผลกระทบต่อธุรกิจควรประสานฝ่ายกฎหมาย ผู้รับผิดชอบ PDPA และผู้บริหารตามกรณี

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

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

SOC Analyst, Incident Responder, ผู้ดูแลระบบ และ DPO ทำหน้าที่ต่างกันอย่างไร

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

Log ใดอาจเป็นข้อมูลส่วนบุคคลและควรควบคุมการเข้าถึงอย่างไร

log บางประเภทอาจมีข้อมูลส่วนบุคคล เช่น IP address, ชื่อผู้ใช้, อีเมล และประวัติการใช้งาน การเก็บ ใช้ หรือเปิดเผยข้อมูลเหล่านี้ต้องพิจารณาหลักการตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 รวมถึงการมีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม

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

เมื่อพบเหตุ ควรบันทึกหลักฐานและส่งต่อข้อมูลแบบใด

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

เปรียบเทียบ SOC ภายในกับ Managed SOC: ต้นทุน ขอบเขต และความคุ้มค่า

การตัดสินใจไม่ควรเริ่มจากคำถามว่าแบบใด “ถูกกว่า” แต่ควรถามว่าองค์กรต้องการเฝ้าระวังระบบใด ต้องการให้ครอบคลุมช่วงเวลาใด และเมื่อเกิดเหตุใครสามารถตัดสินใจหรือดำเนินการได้จริง

ตารางเปรียบเทียบงบคน เครื่องมือ ชั่วโมงเฝ้าระวัง และ SLA

SOC ภายในเหมาะกับองค์กรที่ต้องการควบคุมการปฏิบัติงานและข้อมูลอย่างใกล้ชิด พร้อมดูแลบุคลากรและเครื่องมืออย่างต่อเนื่อง ขณะที่ Managed SOC เหมาะกับองค์กรที่ต้องการกำหนดขอบเขตบริการให้ชัด และต้องการอาศัยทีมภายนอกเพื่อช่วยเฝ้าระวังตามเงื่อนไขที่ตกลง

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

ค่าใช้จ่ายมักเปลี่ยนตามจำนวนอุปกรณ์ ปริมาณ log และระดับการตอบสนอง

บริการ Managed SOC มักคิดค่าใช้จ่ายตามจำนวนแหล่งข้อมูล ปริมาณ log จำนวนอุปกรณ์ ชั่วโมงเฝ้าระวัง ระดับ SLA และขอบเขตการตอบสนองต่อเหตุ ดังนั้นใบเสนอราคาที่เปรียบเทียบกันได้ควรใช้ข้อมูลตั้งต้นใกล้เคียงกัน ไม่เช่นนั้นราคาที่ต่างกันอาจสะท้อนขอบเขตที่ต่างกันมากกว่าประสิทธิภาพของบริการ

กรณีใดควรเริ่มจากบริการภายนอก และกรณีใดควรสร้างทีมเอง

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

ขั้นตอนทำงานเมื่อพบสัญญาณเสี่ยง และข้อผิดพลาดที่พบบ่อย

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

ตรวจสอบบริบท คัดกรองเหตุ และกำหนดระดับความรุนแรง

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

จำกัดความเสียหายโดยไม่ทำลายหลักฐานหรือกระทบธุรกิจเกินจำเป็น

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

ข้อผิดพลาดเรื่องสิทธิ์เข้าถึง การเก็บ log และการแจ้งผู้เกี่ยวข้อง

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

แนวทางตามสถานการณ์สำหรับองค์กรขนาดต่าง ๆ

ธุรกิจขนาดเล็กที่ไม่มีทีมเฝ้าระวังตลอด 24 ชั่วโมง

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

องค์กรที่มีระบบคลาวด์ หลายสาขา หรือผู้ให้บริการหลายราย

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

องค์กรที่ประมวลผลข้อมูลลูกค้าจำนวนมาก

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

เกณฑ์เลือกและเปรียบเทียบบริการ SOC ก่อนตัดสินใจ

ขอบเขตแหล่งข้อมูล การตรวจจับ และการตอบสนองที่รวมในสัญญา

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

SLA ช่องทางแจ้งเหตุ รายงาน และผู้รับผิดชอบเมื่อเกิดเหตุรุนแรง

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

คำถามเรื่อง PDPA การเก็บข้อมูล สิทธิ์เข้าถึง และการส่งมอบหลักฐาน

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

เกณฑ์เลือกและเปรียบเทียบบริการ

1. ระบุระบบและแหล่งข้อมูล ที่ต้องการให้เฝ้าระวัง
2. ระบุชั่วโมงเฝ้าระวังและระดับ SLA ที่ต้องการจริง

3. แยกขอบเขตการแจ้งเตือน การวิเคราะห์ และการตอบสนองต่อเหตุ

4. ตรวจสอบสิทธิ์เข้าถึง ที่ตั้งข้อมูล และแนวทางตาม PDPA

5. ขอรายละเอียดการเก็บและส่งมอบหลักฐานดิจิทัล
6. เปรียบเทียบใบเสนอราคาจากขอบเขตบริการเดียวกัน

รายละเอียดเงื่อนไขบริการและขอบเขตการตอบสนอง ควรตรวจสอบจากเอกสารเสนอราคาและข้อตกลงของผู้ให้บริการแต่ละรายโดยตรง

ส่งท้าย

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

ข้อมูลที่ควรรู้เพิ่มเติม

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

พระราชบัญญัติการรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 มีความเกี่ยวข้องกับการรับมือภัยคุกคามไซเบอร์ โดยเฉพาะในบริบทของหน่วยงานหรือบริการที่เกี่ยวข้องกับโครงสร้างพื้นฐานสำคัญทางสารสนเทศ

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

ข้อควรพิจารณาสำคัญ

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

คำถามที่พบบ่อย

Q1. ผู้เริ่มทำงาน SOC ต้องรู้กฎหมายไทยด้านใดบ้าง?

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

Q2. องค์กรขนาดเล็กควรมี SOC ภายในหรือใช้ Managed SOC คุ้มกว่ากัน?

A2. ไม่มีคำตอบเดียว ควรเทียบความพร้อมด้านบุคลากร เครื่องมือ ชั่วโมงเฝ้าระวัง การควบคุมข้อมูล และ SLA ที่ต้องการ Managed SOC อาจเหมาะเมื่อองค์กรยังไม่มีทีมเฝ้าระวังต่อเนื่อง แต่ต้องตรวจสอบขอบเขตบริการและสิทธิ์เข้าถึงข้อมูลให้ละเอียด

Q3. Log จากระบบเฝ้าระวังถือเป็นข้อมูลส่วนบุคคลและเก็บได้นานแค่ไหน?

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