จากความเดิมตอนที่แล้ว ซึ่งทิ้งช่วงนานมาก ... ถือโอกาสนี้มาสานต่อเขียนให้จบ
Log files มีความสำคัญในการทำ "Incident Response" หรือภาษาไทยแปลได้ว่าการรับมือเมื่อเกิดสถานการณ์ฉุกเฉิน ซึ่งถือได้ว่าเป็นกระบวนการที่สำคัญที่ทุกองค์กรควรมีไว้
ดังนั้น Log files จึงต้องเก็บอย่างมีเหมาะสม และตรวจหาเหตุการณ์ที่เกิดได้
ที่กล่าวมาในตอนที่แล้วผมขอสรุปเพื่อสร้างเข้าใจดังต่อไปนี้
(1) Log files ที่เกิดจาก Local Host server ที่สำคัญ เช่น Authentication Server (Radius , LDAP) หรือการ Remote Access (VPN, RDP , SSH, FTP) , Proxy Server , Web Server , Internal Mail Server , Files Server เป็นต้น เหล่านี้ เราสามารถเก็บ Log ได้อย่างสมบูรณ์ได้ ไม่ยากเย็น เนื่องจากมาจากแหล่งที่มาของ Server ที่ตั้งอยู่กับเราเอง
ส่วนใหญ่ทุกองค์กรที่มีความพร้อมสามารถเก็บในส่วนนี้ได้
ซึ่งองค์กรไหนให้ความสำคัญมีงบประมาณในส่วนนี้ก็จะจัดเก็บได้ครบถ้วน
แต่มีจุดอันตรายที่อาจตกในบางจุดได้ เช่น Proxy Server ในอดีต องค์กรที่มีความพร้อมด้าน ICT นั้น ใช้ Proxy Server ในการทำ Caching เพื่อเพิ่มความเร็วในการเข้าถึงข้อมูลผ่าน HTTP และป้องกันภัยคุกคามเช่นพวก files ที่อาจติดเชื้อไวรัส จนมีสินค้าเกี่ยวกับการป้องกันภัยโดยทำตัวเป็น Proxy Server มาขายดิบขายดีในช่วงเวลาหนึ่ง ปัจจุบันการทำ Caching มีบทบาทลดลง เนื่องจากความเร็วอินเทอร์เน็ตที่สูงขึ้น Web Portal ขนาดใหญ่ลงทุนทำ CDN เช่น google , facebook , line แม้กระทั่ง pantip ก็ยังทำ CDN หมดแล้ว และ เว็บสำคัญใหญ่ๆ ตอนนี้เป็น HTTPS หมดแล้ว ป้องกันการ Strip ด้วย protocol HSTS ด้วย ดังนั้น Proxy Server ในองค์กรจึงแทบหมดความหมายไป ที่ผมกล่าวเช่นนี้เพราะ HTTPS ที่องค์กรต้องเพิ่มค่าใช้จ่าย (Cost) ในการทำ caching และ การ interception เพื่อตรวจหาภัยคุกคาม และ ค่าใช้จ่ายส่วนนั้นมากกว่าที่คิดมากครับ จึงอาจมีหลายองค์กร (ที่มีความพร้อมด้าน ICT) อาจไม่ลงทุนในส่วนนี้ก็เป็นไปได้
(2) Log file ที่เกิดจากอุปกรณ์ระบบเครือข่าย และระบบรักษาความมั่นคงปลอดภัยในระบบเครือข่าย อันได้แก่ Firewall , NIDS , NAC , Vulnerability Assessment / Management เป็นต้น ซึ่ง หากเป็นอุปกรณ์ Appliance สมัยใหม่ ก็จะมีค่า syslog ซึ่ง System admin สามารถที่จะทำการโยน Log file นั้นไปสู่อุปกรณ์เก็บ Log ที่ส่วนกลางได้
(3) Log ที่เกิดจากพฤติกรรมการใช้งานพนักงานภายใน ซึ่งส่วนนี้จริงๆแล้วก็เกิดจาก Firewall log ได้ หรือ Proxy log ได้ แต่ที่ผมยกมาเป็นหัวข้อนั้น เนื่องจากส่วนนี้เป็นปัญหาที่สุด เนื่องจากภัยคุกคามสมัยใหม่ได้มีการพัฒนาตัวในการส่งข้อมูลแบบเข้ารหัส (Encryption) เพื่อหลบการตรวจจับจากอุปกรณ์ด้านการรักษาความมั่นคงปลอดภัยชนิดต่างๆ ทั้งที่เป็นการเข้ารหัสผ่าน Protocol HTTPS , หรือทำ Tunnel VPN หรือ Tunnel SSH ออกไปสู่ข้างนอก ผ่าน port มาตรฐานที่ทุกองค์กรต้องเปิดออก
และเรื่องสำคัญสำหรับองค์กรไหนที่จำเป็นต้องใช้ Social Network อันนี้แทบไม่มีการเก็บ Log ถึงพฤติกรรมได้เลย อันเนื่องจากผู้ให้บริการ ที่เรียกว่า Content Provider นั้นอยู่ต่างประเทศทั้งหมดไม่ว่าเป็น Facebook , Line , google การเก็บเกี่ยวกับพฤติกรรมเหล่านี้จึงทำได้ยากขึ้น
ดังนั้น Log ที่มีคุณภาพ สำหรับองค์กร ที่ยังต้องใช้งาน Social Network จำเป็นต้องมองเห็นพฤติกรรมภายในการรับส่งข้อมูล HTTPS หรือไม่ ?
คำตอบ คือ จำเป็น แล้วเราจะทำอย่างไง ถึงจะเก็บข้อมูลตรงส่วนนี้ได้
ระดับ Firewall แบบ NG Next Generation ทุกตัวทำได้หมด แต่ราคาแพงสุดขั้ว และ Log ที่เก็บบันทึกในตัว Firewall หรือ Proxy ระดับสูงเหล่านี้ เมื่อดูที่ค่า syslog ของอุปกรณ์ก็จะพบว่ามีแต่ Log ด้านภัยคุกคาม (Threat data traffic log) จะ log พฤติกรรมทั่วไป ก็หามีไม่ เนื่องจากปริมาณ Log จะเยอะมาก
ดังนั้นในมุมการเก็บ Log ของต่างประเทศคือดูภัยคุกคามจริงๆ เช่นการแฮก การโจมตี Cyber attack เพื่อเยียวยาได้ทันท่วงที
แต่ Log สำหรับคนไทย กับต้องคำนึงถึง ภัยที่เกิดจากการเนื้อหาที่ส่งข้อมูลกัน เนื้อหานี้แหละเป็นภัยคุกคามด้านความมั่นคงของประเทศไทย ทั้งการหมิ่นประมาท การส่งภาพ คลิปเสียง และวิดีโอ การส่งข้อความไม่เหมาะสม หมิ่นต่อสถาบันและความมั่นคงของชาติ เป็นต้น ซึ่งต่างประเทศมองในจุดนี้ว่าเป็นลักษณะการทำ Lawful interception มากกว่า Log ที่ Centralization log management ที่เป็นอยู่ที่เน้นไปด้าน การเกิด Cyber attack , internal Fraud ที่เกิดขึ้นทางเทคนิค
แต่อย่างไรนั้นหากจำเป็นต้องเก็บ Log การใช้งาน Social network ภายในองค์กรจริงๆ นั้นสามารถทำได้
ซึ่งปัจจุบันทีมงาน SRAN เราได้พัฒนาตัวเก็บ Log ประเภทนี้ขึ้นมาเรียกว่า "Net Approved" ซึ่งราคาเข้าถึงได้ และเก็บข้อมูล Social Network จากการถอดค่า HTTPS ออกเป็นข้อมูลที่อ่านออกได้
ปัจจุบันทางเราได้ทำอยู่รุ่นเดียว หากสนใจติดต่อได้ที่ info at gbtech.co.th ได้ตลอด
นนทวรรธนะ สาระมาน
Nontawattana Saraman
SRAN Dev Team
วันเสาร์, เมษายน 11
สมัครสมาชิก:
บทความ (Atom)
