Clear
Lead Graphic Papers

Security Information Manager (2)

ผู้เขียน:รณนเรศร์ เรืองจินดา
วันที่เผยแพร่: 26 ธันวาคม 2556
ปรับปรุงล่าสุด: 26 ธันวาคม 2556

Share on Facebook Share on Twitter Share on Google+

ในบทความก่อนหน้านี้ ได้แนะนำให้ผู้อ่านรู้จักกับ SSIM กันไปแล้ว ในบทความตอนนี้จะนำเสนอ-ขั้นตอนวิธีในดำเนินโครงการในการนำเอา SIM เข้ามาใช้ในองค์กรเพื่อการเฝ้าระวังความปลอดภัยระบบสารสนเทศ เนื่องจากการดำเนินโครงการลักษณะนี้จัดเป็น โครงการที่มีความซับซ้อนพอสมควร อีกทั้งไม่มีขั้นตอนวิธีที่เป็นมาตรฐาน ทำให้ผู้ดำเนินโครงการมักจะมองโครงการลักษณะนี้เป็นการ จัดซื้ออุปกรณ์ นำมาตั้งค่า และเชื่อมต่อเข้าด้วยกันทำนองเดียวกับการจัดซื้ออุปกรณ์เครือข่ายทั่วไป ทำให้มองไม่เห็นรายละเอียดและความซับซ้อนที่ซ่อนอยู่ ในความเห็นผู้เขียน โครงการลักษณะจัดเป็น Solution มากกว่าจะเป็นการติดตั้งอุปกรฺณ์ หัวใจสำคัญจึงอยู่ที่การออกแบบ และนำเสนอ Solution ให้สอดคล้องกับความต้องการ ซึ่งจะเป็นผู้อ่านจะได้รับประโยชน์ในการใช้บทความนี้เป็นแนวทางในการดำเนินโครงการลักษณะดังกล่าว ความจริงแล้วขั้นตอนการดำเนินโครงการลักษณะนี้แทบจะไม่แตกต่างกับโครงการระบบสารสนเทศอื่น คือ เริ่มจาก Preliminary (การสำรวจความต้องการเบื้องต้น) Requirement Analysis (การวิเคราะห์ความต้องการ) Design (การออกแบบ) Implement (การติดตั้ง) Test (การทดสอบ) และ Production (เปิดใช้งาน) เพียงแต่มีกิจกรรมย่อย ๆ ที่จำเป็นต้องใช้ความระมัดระวัง มิฉะนั้นโครงการอาจล่าช้า หรือถึงกับต้องรื้อออกแบบใหม่กันเลย ในที่นี้จะขอกล่าวถึงแต่รายละเอียดที่สำคัญ

การสำรวจความต้องการเบื้องต้น ปกติขั้นตอนนี้จะทำกันก่อนการเลือกซื้อ หรือบางองค์กรอาจมองเป็นขั้นตอนเดียวกันเลย ในขั้นตอนนี้สิ่งสำคัญคงไม่พ้นการกำหนดจุดมุ่งหมายของการนำ SIM มาใช้ ซึ่งก็มีได้สองลักษณะคือ การนำมาใช้เพื่อเป็นการเฝ้าระวัง คือแจ้งเตือนเมื่อมีเหตุการณ์เกิดขึ้น หรือนำมาใช้เพื่อช่วยในการวิเคราะห์ข้อมูล log ย้อนหลัง สำหรับเหตุการณ์ที่เกิดขึ้นไปแล้ว ดังที่ได้อธิบายไว้แล้วว่า ทั้งสองแบบมีความต้องการหน่วยจัดเก็บข้อมูลและประสิทธิภาพต่างกัน อย่างแรกต้องการระบบที่มีประสิทธิภาพสูงที่ตอบสนองได้รวดเร็ว ในขณะที่แบบหลังต้องการหน่วยจัดเก็บข้อมูลขนาดใหญ่ ลำดับถัดมาที่ต้องพิจารณาควบคู่กันไปด้วยคือ ปริมาณข้อมูล log ที่จะจัดเก็บ ซึ่งหาได้จากการประมาณจำนวนอุปกรณ์กำเนิดข้อมูล log ซึ่งจำเป็นต้องทราบให้แน่นอนระดับหนึ่งว่า มีปริมาณข้อมูลเหตุการณ์ (number of event) ต่อวันเท่าไร และที่สำคัญ มีอัตราการส่งข้อมูลต่อวินาที (event per sec หรือ EPS) เป็นเท่าไร ข้อมูลเหล่านี้จำเป็นสำหรับการเลือกรุ่นและยี่ห้อของ SIM นอกจากนี้ ยังต้องกำหนดความต้องการด้านเครือข่ายสำหรับการเชื่อมต่อให้ชัดเจน เนื่องจาก SIM จำเป็นต้องเชื่อมกับอุปกรณ์กำเนิด log ทุกตัว สิ่งเหล่านี้ล้วนต้องทำการวิเคราะห์และจัดทำเป็นส่วนหนึ่งของข้อกำหนดข้อกำหนดความต้องการของโครงการ (TOR)

การวิเคราะห์ความต้องการ ขั้นตอนนี้มีความจำเป็นอย่างยิ่ง เพราะหลังจากได้รับข้อเสนอจากผู้ค้าที่สอดคล้องกับ TOR ก็มักจะเข้าใจกันไปว่า ให้ผู้ค้าดำเนินโครงการให้สอดคล้องกับ TOR ก็น่าจะเพียงพอแล้ว ในความเป็นจริง TOR เป็นเพียงข้อกำหนดกว้าง ๆ ที่ไม่ได้เฉพาะเจาะจง ผู้เขียนแนะนำให้นำ TOR แต่ละข้อมาทำการวิเคราะห์และขยายความเพื่อให้เกิดความชัดเจนแล้วจัดทำเป็นเอกสารความต้องการของระบบ (System Requirement Specification-SRS) สำหรับ SIM แล้ว สิ่งที่ต้องมากทำการวิเคราะห์เพิ่มเติมคือ รายละเอียดการตั้งค่าที่สำคัญ ๆ ของ SIM ได้แก่

  • Aggregation ต้องทำการกำหนดรายชื่ออุปกรณ์ รุ่น และรูปแบบการบันทึกข้อมูล จัดทำเป็นเอกสาร และทดสอบยืนยันว่า SIM รองรับการเชื่อมต่อกับอุปกรณ์ดังกล่าวหรือไม่ และถ้าไม่ จะมีแนวทางการแก้ไขอย่างไร อย่างที่กล่าวไว้ในตอนที่ 1 ว่าเนื่องจากการอุปกรณ์กำเนิด log มีความหลากหลายทำให้ข้อมูล log มีรูปแบบไม่เหมือนกัน และอาจได้รับการตั้งค่าให้ต่างไปจากค่าตั้งต้นโดยปริยาย รวมทั้งอุปกรณ์อาจมีการส่งข้อมูล log ไปยังระบบอื่นแล้ว ฯลฯ สิ่งเหล่านี้ล้วนจำเป็นจะต้องกำหนดลงในเอกสาร ให้ชัดเจน เนื่องจากมีผลกระทบต่อการดำเนินโครงการในเฟสการออกแบบ ในส่วนของการเชื่อมต่อและติดตั้ง รวมถึงการตั้งค่าระบบ
  • Correlation ต้องทำการกำหนดขอบเขตและรายละเอียดการตั้งค่าการวิเคราะห์ความสัมพันธ์ของข้อมูล (Correlation Rule) ซึ่งควรจะกำหนดให้ชัดเจนว่าจะมีจำนวนกี่แบบ แต่ละแบบมีรายละเอียดอย่างไร ส่วนนี้นับเป็นประเด็นที่น่าสนใจตรงที่ว่า ผู้ใช้หรือผู้ซื้อระบบก็คาดหวังว่าผู้ค้าหรือผู้ออกแบบติดตั้งจะนำให้คำแนะนำที่เหมาะสมในการตั้งค่า ในขณะที่ผู้ค้าหรือผู้ออกแบบติดตั้งก็คาดหวังว่าผู้ใช้หรือผู้ซื้อจะกำหนดหรือบอกความต้องการของตนให้ทราบ ไป ๆ มา ๆ ต่างฝ่ายต่างก็ได้แต่แลตากัน สุดท้ายก็ใช้ค่าโดยปริยายที่ตั้งมาจากโรงงานหรือผู้ผลิต ซึ่งโดยมากก็มักจะไม่ตรงตามความต้องการ และไปมีผลกระทบเมื่อระบบเริ่มใช้งาน เพราะจะมีแต่ข้อมูลส่วนเกิน หรือไม่ตรงความต้องการเต็มไปหมด ดังนั้นผู้เขียนจึงขอแนะนำว่าให้ทำการประชุมหารือและกำหนดรายละเอียดในส่วนนี้ให้เรียบร้อย ข้อสังเกตอีกประการหนึ่งคือ การตั้งค่า Correlation Rule นั้น เป็นเรื่องละเอียดอ่อนและซับซ้อนพอสมควร แม้จะมีการกำหนดขอบเขตชัดเจนแล้ว ก็ยังจำเป็นที่จะต้องทดสอบและปรับให้สอดคล้องกับธรรมชาติการดำเนินงานของแต่ละระบบเป็นราย ๆ ไปเพื่อลด False Positive ตัวอย่างเช่น การตั้งค่า Correlation Rule “มี IP ใดบ้างที่เชื่อมต่อเข้ามายัง IP ภายในองค์กรด้วยหมายเลขพอร์ตปลายทางที่สูงกว่า 1024 มากกว่า 1,000 เหตุการณ์ต่อ 10 นาที ภายใน 24 ชั่วโมง” ซึ่งจะเห็นได้อย่างชัดเจนว่ามีสองประเด็นคือ หากองค์กรมีการเชื่อมต่อเข้ามาด้วยพอร์ตหมายเลขสูงกว่า 1024 โดยเจตนา (อาจจะด้วยความจำเป็นหรือข้อจำกัดก็ตาม) เป็นประจำอยู่แล้ว Correlation Rule ข้อนี้ก็ต้องได้รับการปรับแก้ กับอีกประเด็นคือ จำนวนการเชื่อมต่อเข้ามา ไม่ว่าจะเพื่อการทำงานโดยปรกติหรือการถูกโจมตีด้วยการ Scan Port องค์กรหรือผู้ดูแลระบบจะมองว่าเป็น เรื่องผิดปรกติหรือไม่ เพราะองค์กรหรือผู้ดูแลแต่ละท่าน ก็มีวิจารณญาณที่ต่างกันบางท่านอาจมองว่า การถูก Scan Port เป็นปรกติ ไม่จำเป็นต้องสนใจ ในขณะที่บางองค์กรอาจมองว่าเป็นภัยคุกคาม ซึ่งก็ต้องมีการ ปรับค่าในช่วงที่ระบบเริ่มดำเนินการ
  • Alert เป็นอีกสิ่งหนึ่งที่ควรจะกำหนดให้ชัดเจนว่า ระบบจะแจ้งเตือนไปที่ใคร อย่างไร แต่ละวันคาดว่าจะมีจำนวนประมาณเท่าไร แล้วการจัดการตอบรับจะทำกันอย่างไร แม้เรื่องเหล่านี้จะเป็นข้อกำหนดความต้องการที่เกี่ยวข้องกับการดำเนินการ (Operations Requirement) แต่หากไม่ทำการวิเคราะห์และทำความเข้าใจให้ตรงกันระหว่างติดตั้งออกแบบและผู้ใช้แล้ว ก็จะเกิดปัญหาการแจ้งเตือนทีมีมากจนล้นเกิน หรือในทางกลับกันไม่มีการแจ้งเตือนที่สำคัญไปยังผู้ดูแลระบบ เป็นต้น
  • รายงานและ Dashboard ข้อนี้คงไม่ต้องบรรยายอะไรมาก เนื่องจากทุกท่านคงเข้าถึงความสำคัญและความจำเป็นในการวิเคราะห์ความต้องการตรงส่วนนี้อยู่แล้ว สิ่งที่ผู้เขียนอยากแนะนำคงมีเพียงเรื่อง ปริมาณรายงาน เนื่องจากประสบการณ์ของผู้เขียนพบว่า ผู้ใช้มักจะอยากได้รายงานต่าง ๆ เป็นจำนวนมาก ๆ (เพื่อความอุ่นใจ) แทนที่จะเลือกเอารายงานที่สำคัญและต้องใช้เท่านั้น อย่าลืมว่าในการทำโครงการ ทรัพยากรมีจำกัด โดยเฉพาะอย่างยิ่งเวลา หากให้ความสำคัญหมดไปกับสิ่งที่ไม่ได้ใช้ นับเป็นเรื่องที่น่าเสียดาย

การออกแบบ หลังจากที่ได้ SRS มาแล้วก็เป็นการนำเอาความต้องการแต่ละข้อมาออกแบบ สำหรับ SIM ก็มีส่วนที่สำคัญ ๆ อยู่สองประเด็นคือ การตั้งค่าระบบที่สำคัญอย่างCorrelation Rule, Alert กับการออกแบบการเชื่อมต่อ ขอให้มีการจัดทำเอกสารการออกแบบระบบ (System Design) ที่ชัดเจนสำหรับใช้อ้างอิงในขั้นตอนการติดตั้ง และทดสอบ ก็คงเพียงพอแล้ว แต่ถ้าให้ดีควรจัดทำเป็นเอกสารข้อกำหนดการออกแบบระบบ (System Design Specification - SDS) ในกรณีที่ต้องการให้แน่ใจว่าความต้องการใน SRS สอดคล้องกับการออกแบบ นอกจากนี้ในช่วงของการออกแบบ หากข้อกำหนดความต้องการใดมีความคลุมเคลือ หรือมีความรู้สึกว่าการออกแบบอาจจะไม่รองรับ ผู้เขียนแนะนำให้ทำการทดสอบเบื้องต้นก่อน อาจจะเรียกว่าเป็น Proof Of Concept (POC) ก็ได้ แม้ว่าโดยปรกติ เรามักจะทำ POC กันก่อนที่จะทำการซื้อหรือดำเนินโครงการ แต่จากประสบการณ์ของผู้เขียนแล้ว หากโครงการยังอยู่ในช่วงการวิเคราะห์ความต้องการ หรือช่วงออกแบบ หากมีข้อสงสัยที่สำคัญและคาดว่าจะมีผลกระทบสูง ก็สมควรจะทำ POC เสมอ เพื่อลดความเสี่ยงในการออกแบบผิดพลาด อย่างไรก็ตาม ก็ขอให้คำนึงถึงเรื่องทรัพยากร เพราะการทำ POC เป็นกิจกรรมพิเศษ ควรดำเนินการด้วยความระมัดระวังและรวบรัด

การติดตั้ง สำหรับ SIM แล้วไม่มีอะไรที่ต้องจัดการเป็นพิเศษ ขอเพียงผู้ติดตั้งดำเนินการตามการออกแบบ และจัดทำคู่มือเอกสารประกอบการตั้งค่า ก็เพียงพอแล้ว สำหรับองค์กรที่นำ SIM เข้ามาใช้เพื่อ เฝ้าระวังภัยคุกคาม ผู้เขียนแนะนำให้ทำการ ทดสอบความมั่นคงปลอดภัย (Vulnerability Assessment – VA) ของระบบที่มีอยู่ ก่อนทำการติดตั้ง ทั้งนี้เพื่อนำข้อมูลที่ได้มาประกอบ ในการดำเนินการเฝ้าระวังภัยคุกคาม

การทดสอบ โดยทั่วไปแล้วสำหรับ SIM การทดสอบระบบที่แนะนำก็คือ การทดสอบการตั้งค่าว่าเป็นไปตามที่ออกแบบไว้หรือไม่ซึ่งหากมีการกำหนดความต้องการเรื่องปริมาณและอัตราการรับส่งข้อมูลก็ควรมีการทดสอบความสามารถในการรองรับปริมาณข้อมูลนำเข้า (Load Test) และหากใช้ SIM เพื่อให้บริการในการเฝ้าระวังภัยคุกคามให้แก่ระบบสารสนเทศที่มีความสำคัญอาจจำเป็นต้องทำการทดสอบความเครียดของระบบ (Stress Test) เพื่อดูว่าหากระบบดำเนินไปในสภาวะไม่ปรกติ เช่น หน่วยความจำไม่เพียงพอ อัตราการส่งข้อมูลน้อยกว่าการรับข้อมูล ฯลฯ ระบบที่ออกแบบมาจะตอบสนองอย่างไร และท้ายสุดการทดสอบเชื่อมต่อและเปิดใช้ระบบ(Integration Test and Pilot) ทั้งหมดนี้ขึ้นกับความต้องการขององค์กรและลักษณะโครงการ

การเปิดใช้งาน เช่นเดียวกับโครงการพัฒนาระบบสารสนเทศทั่วไป SIM เมื่อเปิดใช้งานก็จำเป็นจะต้องได้รับการดูแลเป็นพิเศษหรือที่เรียกว่า Nursing Period ซึ่งไม่ควรน้อยกว่าหนึ่งสัปดาห์ ซึ่งช่วงนี้เอง ที่ผู้ใช้จะได้ทราบผลกระทบที่อยู่นอกเหนือการควบคุมในช่วงการออกแบบ รวมทั้งเป็นช่วงเวลาสำหรับการปรับ Correlation, Alert ให้สอดคล้องกับการดำเนินการและธรรมชาติของผู้ใช้ระบบ

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

Clear