วางนโยบายความปลอดภัยก่อนติดตั้ง SIEM: เช็กลิสต์สำหรับองค์กรและเกณฑ์เลือกโซลูชัน

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

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

การเลือกติดตั้งเอง ใช้ Cloud SIEM หรือ Managed SIEM ควรพิจารณาจากความพร้อมของทีม SOC ปริมาณข้อมูลที่ต้องดูแล และขอบเขตบริการที่องค์กรต้องการจริง

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

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

ดูภาพรวมอย่างรวดเร็ว

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

รูปแบบการใช้งาน	เหมาะกับสถานการณ์	สิ่งที่ต้องประเมินก่อนตัดสินใจ
ติดตั้งและดูแลเอง	องค์กรที่มีทีม IT หรือ SOC พร้อมดูแลแพลตฟอร์ม กฎ และการตอบสนอง	ภาระการเชื่อมต่อระบบเดิม การปรับแต่ง Use Case พื้นที่จัดเก็บ Log และผู้ดูแลรายวัน
Cloud SIEM	องค์กรที่ต้องการเริ่มใช้งานโดยลดภาระโครงสร้างพื้นฐานภายใน	การเชื่อมต่อกับระบบเดิม ปริมาณ Data Ingestion ระยะเวลาเก็บข้อมูล และสิทธิ์เข้าถึงข้อมูล
Managed SIEM	องค์กรที่ทีม SOC ยังไม่พร้อมหรืออยากมีผู้ให้บริการช่วยเฝ้าระวังและดูแล	ขอบเขตการดูแล SLA การส่งต่อเหตุการณ์ บทบาทของผู้ให้บริการ และหน้าที่ของทีมภายใน

นโยบายใดต้องกำหนดก่อนเริ่มโครงการ SIEM

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

กำหนดเป้าหมาย: ตรวจจับภัยคุกคาม ตรวจสอบย้อนหลัง หรือรองรับการตรวจประเมิน

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

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

ระบุเจ้าของข้อมูล ผู้ดูแลแพลตฟอร์ม และผู้อนุมัติการเปลี่ยนแปลงกฎ

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

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

สรุป 3 เรื่องที่ควรตัดสินใจก่อนขอเดโมหรือใบเสนอราคา

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

ตารางเปรียบเทียบเกณฑ์เลือก SIEM, Cloud SIEM และ Managed SIEM

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

ความพร้อมของทีม SOC และเวลาที่ใช้ในการดูแล

การติดตั้ง SIEM ภายในเหมาะเมื่อมีผู้ดูแลระบบ ผู้วิเคราะห์ Alert และผู้รับผิดชอบปรับกฎอย่างต่อเนื่อง หากทีมมีภารกิจหลักอื่นจำนวนมาก Cloud SIEM หรือบริการ Managed SIEM อาจช่วยลดภาระการดูแลแพลตฟอร์มได้ แต่ยังต้องกำหนดผู้ประสานงานและผู้ตัดสินใจฝั่งองค์กรเสมอ

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

ปริมาณ Log การขยายระบบ และค่าใช้จ่ายตลอดอายุโครงการ

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

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

ความสามารถด้าน Integration, Dashboard, Reporting และ SLA

ก่อนเลือกโซลูชัน ควรตรวจสอบการเชื่อมต่อกับระบบสำคัญที่ใช้งานจริง เช่น ระบบยืนยันตัวตน Endpoint Firewall Cloud และแอปพลิเคชันหลัก อย่าสมมติว่าการเชื่อมต่อทำได้เหมือนกันทุกผลิตภัณฑ์ เพราะความสามารถในการเชื่อมต่อและคุณภาพของ Use Case ต้องตรวจสอบกับระบบเดิมขององค์กร

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

ออกแบบนโยบาย Log และการเข้าถึงข้อมูลอย่างไรให้ใช้งานได้จริง

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

เลือกแหล่ง Log ที่มีผลต่อความเสี่ยง

ควรเริ่มจากแหล่ง Log ที่ช่วยตอบคำถามด้านความปลอดภัยได้มากที่สุด เช่น Identity, Endpoint, Firewall, Cloud และแอปพลิเคชันสำคัญ ข้อมูลจากระบบเหล่านี้ช่วยเชื่อมโยงกิจกรรมผู้ใช้ อุปกรณ์ การเชื่อมต่อเครือข่าย และการทำงานของบริการสำคัญ

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

กำหนดระยะเวลาเก็บรักษา การสำรองข้อมูล และการเข้ารหัส

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

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

ควบคุมสิทธิ์ดู Log และตั้งหลักฐานการตรวจสอบการใช้งาน

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

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

ตั้งกฎแจ้งเตือนและขั้นตอนตอบสนองเพื่อลด Alert Fatigue

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

เริ่มจาก Use Case ความเสี่ยงสูงแทนการเปิดกฎจำนวนมาก

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

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

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

ทบทวน False Positive และปรับกฎตามเหตุการณ์จริง

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

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

ข้อผิดพลาดในการติดตั้งที่ทำให้งบ SIEM ไม่คุ้มค่า

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

เก็บ Log ทุกอย่างโดยไม่มีวัตถุประสงค์หรือการคุมต้นทุน

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

ไม่มี Runbook เมื่อเกิด Alert สำคัญ

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

มองข้ามค่าเชื่อมต่อระบบเดิม ค่าเก็บข้อมูล และภาระดูแลต่อเนื่อง

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

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

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

เช็กลิสต์ขอใบเสนอราคาที่เปรียบเทียบได้จริง

• ปริมาณ Log ที่คาดว่าจะนำเข้า และแหล่ง Log ที่อยู่ในขอบเขต
• จำนวน Endpoint หรือระบบที่ต้องเชื่อมต่อ
• ระยะเวลาเก็บรักษา Log และแนวทางจัดเก็บข้อมูล
• ค่า Data Ingestion พื้นที่จัดเก็บ การติดตั้ง การเชื่อมต่อ และการปรับแต่งกฎ
• SLA ขั้นตอนส่งต่อเหตุการณ์ และขอบเขตการดูแลของผู้ให้บริการ
• หน้าที่ของทีมภายในเมื่อเกิด Alert หรือเมื่อจำเป็นต้องปรับ Use Case

เมื่อใดควรลงทุนทีมภายใน และเมื่อใดควรใช้บริการภายนอก

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

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

สรุปการเลือกตามงบประมาณ ระดับความเสี่ยง และทรัพยากรบุคลากร

หากทีมพร้อมและต้องการควบคุมการดำเนินงานอย่างใกล้ชิด อาจพิจารณาดูแล SIEM ภายในหรือ Cloud SIEM ตามความเหมาะสมของโครงสร้างพื้นฐาน หากทีมมีข้อจำกัดด้านเวลาและบุคลากร ควรเปรียบเทียบ Managed SIEM โดยเน้น SLA และขอบเขตการดูแลมากกว่าดูเฉพาะค่าใช้จ่ายเริ่มต้น

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

เกณฑ์เลือกและเปรียบเทียบโดยสรุป

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

ส่งท้าย

SIEM จะช่วยรวมมุมมองจาก Log หลายระบบและสนับสนุนการสืบสวนเหตุการณ์ได้ดี เมื่อองค์กรเลือกข้อมูลที่สำคัญและออกแบบกระบวนการรองรับไว้แล้ว

การเริ่มจาก Use Case ความเสี่ยงสูง ช่วยให้ทีมเห็นผลการใช้งานจริงก่อนขยายขอบเขต

อย่าลืมว่าระบบ SIEM ไม่ทดแทน Incident Response การจัดการช่องโหว่ หรือการควบคุมความปลอดภัยพื้นฐานขององค์กร

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

1. Log ที่มีประโยชน์ต้องมีความครบถ้วน ถูกต้อง และสัมพันธ์กับความเสี่ยงที่องค์กรต้องการติดตาม

2. การแยกสิทธิ์ของผู้ดู Log ผู้ดูแลระบบ และผู้อนุมัติการเปลี่ยนแปลง ช่วยลดความเสี่ยงจากการเข้าถึงข้อมูลที่ไม่เหมาะสม

3. การปรับกฎแจ้งเตือนเป็นงานต่อเนื่อง ไม่ใช่งานที่สิ้นสุดเมื่อเริ่มใช้งานระบบ

ข้อควรตรวจสอบสำคัญ

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

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

Q1. องค์กรขนาดเล็กจำเป็นต้องมี SIEM หรือควรใช้บริการ Managed SIEM มากกว่าหรือไม่?

A1. ขึ้นอยู่กับระดับความเสี่ยง ระบบสำคัญ และความพร้อมของทีม ไม่ควรตัดสินจากขนาดองค์กรเพียงอย่างเดียว หากทีมยังไม่พร้อมดูแล Alert การปรับกฎ และการเฝ้าระวังต่อเนื่อง ควรเปรียบเทียบขอบเขตบริการ Managed SIEM กับหน้าที่ที่ทีมภายในยังต้องรับผิดชอบให้ชัดเจน

Q2. ค่าใช้จ่ายของ SIEM ควรประเมินจากจำนวนผู้ใช้ จำนวนอุปกรณ์ หรือปริมาณ Log?

A2. ควรประเมินจากหลายปัจจัยร่วมกัน โดยเฉพาะปริมาณ Log แหล่งข้อมูล จำนวน Endpoint ระยะเวลาเก็บรักษา การเชื่อมต่อระบบเดิม และขอบเขตการดูแล รูปแบบการคิดค่าบริการของแต่ละผู้ให้บริการอาจแตกต่างกัน จึงควรขอใบเสนอราคาบนข้อมูลขอบเขตเดียวกัน

Q3. ต้องเก็บ Log นานเท่าไรจึงเหมาะกับนโยบายความปลอดภัยและการตรวจสอบขององค์กร?

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