เมื่อพูดถึงการตรวจสอบความปลอดภัยของเครือข่ายภายในองค์กรหรือแผนก หลายๆ คนเชื่อมโยงกับการควบคุมการรั่วไหลของข้อมูลและการนำโซลูชัน DLP ไปใช้ และหากคุณพยายามชี้แจงคำถามและถามว่าคุณตรวจจับการโจมตีบนเครือข่ายภายในได้อย่างไร ตามกฎแล้วจะเป็นการกล่าวถึงระบบตรวจจับการบุกรุก (IDS) และทางเลือกเดียวเมื่อ 10-20 ปีที่แล้วกำลังกลายเป็นยุคสมัยในปัจจุบัน มีตัวเลือกเดียวที่เป็นไปได้สำหรับการตรวจสอบเครือข่ายภายในที่มีประสิทธิภาพมากกว่าและในบางสถานที่ - โดยใช้โปรโตคอลโฟลว์ซึ่งเดิมออกแบบมาเพื่อค้นหาปัญหาเครือข่าย (การแก้ไขปัญหา) แต่เมื่อเวลาผ่านไปก็กลายเป็นเครื่องมือรักษาความปลอดภัยที่น่าสนใจมาก เราจะพูดถึงโฟลว์โปรโตคอลที่มีอยู่และอันไหนดีกว่าในการตรวจจับการโจมตีเครือข่าย ที่ไหนดีที่สุดที่จะใช้การตรวจสอบโฟลว์ สิ่งที่ควรมองหาเมื่อปรับใช้โครงร่างดังกล่าว และแม้แต่วิธี “ยก” ทั้งหมดนี้บนอุปกรณ์ภายในบ้าน ภายในขอบเขตของบทความนี้
ฉันจะไม่จมอยู่กับคำถามที่ว่า "เหตุใดจึงต้องมีการตรวจสอบความปลอดภัยของโครงสร้างพื้นฐานภายใน" คำตอบดูเหมือนจะชัดเจน แต่ถ้าคุณอยากจะแน่ใจอีกครั้งว่าวันนี้คุณจะขาดมันไม่ได้ วิดีโอสั้น ๆ เกี่ยวกับวิธีที่คุณสามารถเจาะเครือข่ายองค์กรที่ได้รับการคุ้มครองโดยไฟร์วอลล์ได้ 17 วิธี ดังนั้นเราจะถือว่าเราเข้าใจว่าการตรวจสอบภายในเป็นสิ่งจำเป็นและสิ่งที่เหลืออยู่ก็คือการทำความเข้าใจว่าจะจัดระเบียบได้อย่างไร
ฉันจะเน้นแหล่งข้อมูลหลักสามแหล่งสำหรับการตรวจสอบโครงสร้างพื้นฐานในระดับเครือข่าย:
- ปริมาณข้อมูล "ดิบ" ที่เรารวบรวมและส่งเพื่อการวิเคราะห์ไปยังระบบการวิเคราะห์บางระบบ
- เหตุการณ์จากอุปกรณ์เครือข่ายที่การรับส่งข้อมูลผ่าน
- ข้อมูลการจราจรที่ได้รับผ่านหนึ่งในโปรโตคอลโฟลว์
การบันทึกการรับส่งข้อมูลดิบเป็นตัวเลือกที่ได้รับความนิยมมากที่สุดในหมู่ผู้เชี่ยวชาญด้านความปลอดภัย เนื่องจากในอดีตเคยปรากฏและเป็นตัวเลือกแรกๆ ระบบตรวจจับการบุกรุกเครือข่ายแบบทั่วไป (ระบบตรวจจับการบุกรุกเชิงพาณิชย์ระบบแรกคือ NetRanger จาก Wheel Group ซึ่ง Cisco ซื้อในปี 1998) มีส่วนร่วมอย่างแม่นยำในการดักจับแพ็กเก็ต (และเซสชันในภายหลัง) ซึ่งมีการค้นหาลายเซ็นบางอย่าง (“กฎชี้ขาด” ใน คำศัพท์เฉพาะของ FSTEC) ส่งสัญญาณการโจมตี แน่นอน คุณสามารถวิเคราะห์ทราฟฟิกดิบได้ไม่เพียงแค่ใช้ IDS เท่านั้น แต่ยังใช้เครื่องมืออื่นๆ ด้วย (เช่น Wireshark, tcpdum หรือฟังก์ชัน NBAR2 ใน Cisco IOS) แต่โดยปกติแล้วพวกเขาจะขาดฐานความรู้ที่ทำให้เครื่องมือรักษาความปลอดภัยข้อมูลแตกต่างจากปกติ เครื่องมือไอที
ดังนั้นระบบตรวจจับการโจมตี วิธีการตรวจจับการโจมตีเครือข่ายที่เก่าแก่และเป็นที่นิยมมากที่สุด ซึ่งทำงานได้ดีในขอบเขต (ไม่ว่าจะเป็นองค์กร ศูนย์ข้อมูล เซ็กเมนต์ ฯลฯ) แต่ล้มเหลวในเครือข่ายสวิตช์ที่ทันสมัยและเครือข่ายที่กำหนดโดยซอฟต์แวร์ ในกรณีของเครือข่ายที่สร้างขึ้นบนพื้นฐานของสวิตช์ทั่วไป โครงสร้างพื้นฐานของเซ็นเซอร์ตรวจจับการโจมตีมีขนาดใหญ่เกินไป - คุณจะต้องติดตั้งเซ็นเซอร์ในแต่ละการเชื่อมต่อกับโหนดที่คุณต้องการตรวจสอบการโจมตี แน่นอนว่าผู้ผลิตรายใดยินดีที่จะขายเซ็นเซอร์นับแสนตัวให้คุณ แต่ฉันคิดว่างบประมาณของคุณไม่สามารถรองรับค่าใช้จ่ายดังกล่าวได้ ฉันสามารถพูดได้ว่าแม้แต่ที่ Cisco (และเราเป็นผู้พัฒนา NGIPS) เราก็ทำสิ่งนี้ไม่ได้แม้ว่าดูเหมือนว่าปัญหาเรื่องราคาจะอยู่ตรงหน้าเราก็ตาม ฉันไม่ควรยืน - มันเป็นการตัดสินใจของเราเอง นอกจากนี้ ยังเกิดคำถามว่า จะเชื่อมต่อเซ็นเซอร์ในเวอร์ชันนี้ได้อย่างไร? เข้าไปในช่องว่าง? จะเกิดอะไรขึ้นถ้าเซ็นเซอร์เองล้มเหลว? จำเป็นต้องมีโมดูลบายพาสในเซนเซอร์หรือไม่? ใช้ตัวแยก (แตะ)? ทั้งหมดนี้ทำให้โซลูชันมีราคาแพงขึ้น และทำให้ไม่สามารถจ่ายได้สำหรับบริษัททุกขนาด
คุณสามารถลอง "แขวน" เซ็นเซอร์บนพอร์ต SPAN/RSPAN/ERSPAN และควบคุมการรับส่งข้อมูลจากพอร์ตสวิตช์ที่จำเป็นไปยังเซ็นเซอร์ได้ ตัวเลือกนี้จะช่วยขจัดปัญหาที่อธิบายไว้ในย่อหน้าก่อนหน้าบางส่วน แต่ก่อให้เกิดปัญหาอื่น - พอร์ต SPAN ไม่สามารถยอมรับการรับส่งข้อมูลทั้งหมดที่จะถูกส่งไปอย่างแน่นอน - จะมีแบนด์วิดท์ไม่เพียงพอ คุณจะต้องเสียสละบางสิ่งบางอย่าง ปล่อยบางโหนดไว้โดยไม่มีการตรวจสอบ (จากนั้นคุณต้องจัดลำดับความสำคัญก่อน) หรือไม่ส่งการรับส่งข้อมูลทั้งหมดจากโหนด แต่ส่งเฉพาะบางประเภทเท่านั้น ไม่ว่าในกรณีใด เราอาจพลาดการโจมตีบ้าง นอกจากนี้ พอร์ต SPAN ยังสามารถใช้เพื่อความต้องการอื่นๆ ได้อีกด้วย ด้วยเหตุนี้ เราจะต้องตรวจสอบโทโพโลยีเครือข่ายที่มีอยู่ และอาจทำการปรับเปลี่ยนเพื่อให้ครอบคลุมเครือข่ายของคุณให้มากที่สุดตามจำนวนเซ็นเซอร์ที่คุณมี (และประสานงานเรื่องนี้กับฝ่ายไอที)
จะเกิดอะไรขึ้นถ้าเครือข่ายของคุณใช้เส้นทางที่ไม่สมมาตร? จะเกิดอะไรขึ้นหากคุณได้ดำเนินการหรือกำลังวางแผนที่จะนำ SDN ไปใช้? จะเกิดอะไรขึ้นถ้าคุณต้องการตรวจสอบเครื่องเสมือนหรือคอนเทนเนอร์ที่มีการรับส่งข้อมูลไม่ถึงสวิตช์ทางกายภาพเลย? คำถามเหล่านี้คือคำถามที่ผู้จำหน่าย IDS แบบเดิมไม่ชอบ เพราะพวกเขาไม่รู้ว่าจะตอบอย่างไร บางทีพวกเขาอาจจะชักชวนคุณว่าเทคโนโลยีที่ทันสมัยเหล่านี้กำลังเป็นที่นิยมและคุณไม่จำเป็นต้องใช้มัน บางทีพวกเขาอาจจะพูดถึงความจำเป็นในการเริ่มต้นจากเล็กๆ น้อยๆ หรือบางทีพวกเขาจะบอกว่าคุณต้องวางเครื่องนวดข้าวอันทรงพลังไว้ที่ศูนย์กลางของเครือข่ายและกำหนดเส้นทางการรับส่งข้อมูลทั้งหมดไปยังเครือข่ายโดยใช้เครื่องปรับสมดุล ไม่ว่าจะเสนอตัวเลือกใดก็ตาม คุณต้องเข้าใจอย่างชัดเจนว่าตัวเลือกนั้นเหมาะกับคุณอย่างไร และหลังจากนั้นก็ตัดสินใจเลือกแนวทางในการตรวจสอบความปลอดภัยของข้อมูลของโครงสร้างพื้นฐานเครือข่าย กลับมาที่การจับแพ็คเก็ต ฉันอยากจะบอกว่าวิธีนี้ยังคงได้รับความนิยมและสำคัญมาก แต่จุดประสงค์หลักคือการควบคุมชายแดน ขอบเขตระหว่างองค์กรของคุณกับอินเทอร์เน็ต ขอบเขตระหว่างศูนย์ข้อมูลและส่วนที่เหลือของเครือข่าย ขอบเขตระหว่างระบบควบคุมกระบวนการและส่วนองค์กร ในสถานที่เหล่านี้ IDS/IPS แบบคลาสสิกยังคงมีสิทธิ์ที่จะดำรงอยู่และรับมือกับงานของตนได้ดี
เรามาดูตัวเลือกที่สองกันดีกว่า การวิเคราะห์เหตุการณ์ที่มาจากอุปกรณ์เครือข่ายสามารถใช้เพื่อวัตถุประสงค์ในการตรวจจับการโจมตี แต่ไม่ใช่เป็นกลไกหลัก เนื่องจากทำให้สามารถตรวจจับการบุกรุกประเภทเล็กๆ เท่านั้น นอกจากนี้ยังมีอยู่ในปฏิกิริยาบางอย่าง - การโจมตีจะต้องเกิดขึ้นก่อนจากนั้นจะต้องบันทึกโดยอุปกรณ์เครือข่ายซึ่งจะส่งสัญญาณปัญหาเกี่ยวกับความปลอดภัยของข้อมูลไม่ทางใดก็ทางหนึ่ง มีหลายวิธีดังกล่าว นี่อาจเป็น syslog, RMON หรือ SNMP สองโปรโตคอลสุดท้ายสำหรับการตรวจสอบเครือข่ายในบริบทของความปลอดภัยของข้อมูลจะใช้เฉพาะในกรณีที่เราต้องการตรวจจับการโจมตี DoS บนอุปกรณ์เครือข่ายนั้นเอง เนื่องจากการใช้ RMON และ SNMP จึงเป็นไปได้ เช่น เพื่อตรวจสอบโหลดบนส่วนกลางของอุปกรณ์ โปรเซสเซอร์หรืออินเทอร์เฟซของมัน นี่เป็นหนึ่งใน "ที่ถูกที่สุด" (ทุกคนมี syslog หรือ SNMP) แต่ยังเป็นวิธีที่ไม่ได้ผลมากที่สุดในบรรดาวิธีการตรวจสอบความปลอดภัยของข้อมูลของโครงสร้างพื้นฐานภายใน - การโจมตีจำนวนมากถูกซ่อนไว้ แน่นอนว่าพวกเขาไม่ควรละเลยและการวิเคราะห์ syslog เดียวกันช่วยให้คุณระบุการเปลี่ยนแปลงในการกำหนดค่าของอุปกรณ์ได้ทันเวลาการประนีประนอมของอุปกรณ์ แต่ไม่เหมาะมากสำหรับการตรวจจับการโจมตีในเครือข่ายทั้งหมด
ตัวเลือกที่สามคือการวิเคราะห์ข้อมูลเกี่ยวกับการรับส่งข้อมูลที่ส่งผ่านอุปกรณ์ที่รองรับหนึ่งในหลายโปรโตคอลโฟลว์ ในกรณีนี้ โดยไม่คำนึงถึงโปรโตคอล โครงสร้างพื้นฐานของเธรดจำเป็นต้องประกอบด้วยสามองค์ประกอบ:
- การสร้างหรือส่งออกการไหล โดยปกติบทบาทนี้จะถูกกำหนดให้กับเราเตอร์สวิตช์หรืออุปกรณ์เครือข่ายอื่น ๆ ซึ่งโดยการส่งทราฟฟิกเครือข่ายผ่านตัวมันเองจะช่วยให้คุณสามารถแยกพารามิเตอร์หลักจากนั้นซึ่งจะถูกส่งไปยังโมดูลการรวบรวม ตัวอย่างเช่น Cisco รองรับโปรโตคอล Netflow ไม่เพียงแต่บนเราเตอร์และสวิตช์ รวมถึงโปรโตคอลเสมือนและอุตสาหกรรม แต่ยังรวมถึงตัวควบคุมไร้สาย ไฟร์วอลล์ และแม้แต่เซิร์ฟเวอร์ด้วย
- การไหลของคอลเลกชัน เมื่อพิจารณาว่าเครือข่ายสมัยใหม่มักจะมีอุปกรณ์เครือข่ายมากกว่าหนึ่งเครื่อง ปัญหาในการรวบรวมและรวมโฟลว์เกิดขึ้น ซึ่งแก้ไขได้โดยใช้สิ่งที่เรียกว่าตัวรวบรวม ซึ่งประมวลผลโฟลว์ที่ได้รับแล้วส่งไปวิเคราะห์
- การวิเคราะห์การไหล เครื่องวิเคราะห์ทำหน้าที่หลักทางปัญญาและใช้อัลกอริธึมต่างๆ ในการสตรีม เพื่อสรุปข้อสรุปบางประการ ตัวอย่างเช่น ในฐานะส่วนหนึ่งของฟังก์ชันไอที เครื่องวิเคราะห์ดังกล่าวสามารถระบุปัญหาคอขวดของเครือข่ายหรือวิเคราะห์โปรไฟล์โหลดการรับส่งข้อมูลเพื่อเพิ่มประสิทธิภาพเครือข่ายเพิ่มเติม และเพื่อความปลอดภัยของข้อมูล เครื่องวิเคราะห์ดังกล่าวสามารถตรวจจับการรั่วไหลของข้อมูล การแพร่กระจายของโค้ดที่เป็นอันตราย หรือการโจมตี DoS
อย่าคิดว่าสถาปัตยกรรมสามชั้นนี้ซับซ้อนเกินไป ตัวเลือกอื่น ๆ ทั้งหมด (ยกเว้นบางทีระบบตรวจสอบเครือข่ายที่ทำงานกับ SNMP และ RMON) ก็ใช้งานได้เช่นกัน เรามีเครื่องกำเนิดข้อมูลสำหรับการวิเคราะห์ ซึ่งอาจเป็นอุปกรณ์เครือข่ายหรือเซ็นเซอร์แบบสแตนด์อโลน เรามีระบบรวบรวมสัญญาณเตือนและระบบการจัดการสำหรับโครงสร้างพื้นฐานการตรวจสอบทั้งหมด ส่วนประกอบสองชิ้นสุดท้ายสามารถรวมกันภายในโหนดเดียว แต่ในเครือข่ายขนาดใหญ่ไม่มากก็น้อย ส่วนประกอบเหล่านั้นมักจะกระจายไปทั่วอุปกรณ์อย่างน้อยสองเครื่อง เพื่อให้มั่นใจถึงความสามารถในการปรับขนาดและความน่าเชื่อถือ
ต่างจากการวิเคราะห์แพ็กเก็ตซึ่งอิงจากการศึกษาข้อมูลส่วนหัวและเนื้อหาของแต่ละแพ็กเก็ตและเซสชันที่ประกอบด้วย การวิเคราะห์โฟลว์อาศัยการรวบรวมข้อมูลเมตาเกี่ยวกับการรับส่งข้อมูลเครือข่าย เมื่อใด เท่าใด จากที่ไหน และที่ไหน อย่างไร... คำถามเหล่านี้ได้รับคำตอบโดยการวิเคราะห์การวัดและส่งข้อมูลทางไกลของเครือข่ายโดยใช้โปรโตคอลโฟลว์ต่างๆ เริ่มแรกใช้เพื่อวิเคราะห์สถิติและค้นหาปัญหาด้านไอทีบนเครือข่าย แต่เมื่อกลไกการวิเคราะห์พัฒนาขึ้น ก็เป็นไปได้ที่จะนำไปใช้กับการวัดและส่งข้อมูลทางไกลเดียวกันเพื่อความปลอดภัย เป็นที่น่าสังเกตอีกครั้งว่าการวิเคราะห์โฟลว์ไม่ได้แทนที่หรือแทนที่การจับแพ็คเก็ต แต่ละวิธีเหล่านี้มีพื้นที่การใช้งานของตนเอง แต่ในบริบทของบทความนี้ การวิเคราะห์โฟลว์เหมาะสมที่สุดสำหรับการตรวจสอบโครงสร้างพื้นฐานภายใน คุณมีอุปกรณ์เครือข่าย (ไม่ว่าจะทำงานในกระบวนทัศน์ที่กำหนดโดยซอฟต์แวร์หรือตามกฎแบบคงที่) ที่การโจมตีไม่สามารถหลีกเลี่ยงได้ สามารถข้ามเซ็นเซอร์ IDS แบบคลาสสิกได้ แต่อุปกรณ์เครือข่ายที่รองรับโปรโตคอลโฟลว์ไม่สามารถทำได้ นี่คือข้อดีของวิธีนี้
ในทางกลับกัน หากคุณต้องการหลักฐานสำหรับการบังคับใช้กฎหมายหรือทีมสืบสวนเหตุการณ์ของคุณเอง คุณไม่สามารถทำได้หากไม่มีการจับแพ็กเก็ต - การวัดและส่งข้อมูลทางไกลของเครือข่ายไม่ใช่สำเนาการรับส่งข้อมูลที่สามารถใช้เพื่อรวบรวมหลักฐาน จำเป็นสำหรับการตรวจจับและการตัดสินใจอย่างรวดเร็วในด้านความปลอดภัยของข้อมูล ในทางกลับกัน เมื่อใช้การวิเคราะห์ระยะไกล คุณสามารถ "เขียน" ไม่ใช่การรับส่งข้อมูลเครือข่ายทั้งหมดได้ (หากมีอะไร Cisco จะจัดการกับศูนย์ข้อมูล :-) แต่ทำได้เฉพาะส่วนที่เกี่ยวข้องกับการโจมตีเท่านั้น เครื่องมือวิเคราะห์การวัดและส่งข้อมูลทางไกลในเรื่องนี้จะช่วยเสริมกลไกการจับแพ็คเก็ตแบบดั้งเดิมได้เป็นอย่างดี โดยให้คำสั่งสำหรับการจับและการจัดเก็บแบบเลือกสรร มิฉะนั้น คุณจะต้องมีโครงสร้างพื้นฐานการจัดเก็บข้อมูลขนาดมหึมา
ลองจินตนาการถึงเครือข่ายที่ทำงานด้วยความเร็ว 250 Mbit/วินาที หากคุณต้องการจัดเก็บไดรฟ์ข้อมูลทั้งหมดนี้ คุณจะต้องมีพื้นที่จัดเก็บข้อมูล 31 MB สำหรับการรับส่งข้อมูลหนึ่งวินาที, 1,8 GB สำหรับหนึ่งนาที, 108 GB สำหรับหนึ่งชั่วโมง และ 2,6 TB สำหรับหนึ่งวัน หากต้องการจัดเก็บข้อมูลรายวันจากเครือข่ายที่มีแบนด์วิดท์ 10 Gbit/s คุณจะต้องมีพื้นที่จัดเก็บข้อมูล 108 TB แต่หน่วยงานกำกับดูแลบางแห่งจำเป็นต้องจัดเก็บข้อมูลความปลอดภัยเป็นเวลาหลายปี... การบันทึกตามความต้องการซึ่งการวิเคราะห์โฟลว์ช่วยให้คุณนำไปใช้ได้ จะช่วยลดค่าเหล่านี้ตามลำดับความสำคัญ อย่างไรก็ตามถ้าเราพูดถึงอัตราส่วนของปริมาณข้อมูล telemetry ของเครือข่ายที่บันทึกไว้และการจับข้อมูลที่สมบูรณ์ก็จะอยู่ที่ประมาณ 1 ถึง 500 สำหรับค่าเดียวกันที่ให้ไว้ข้างต้น ให้จัดเก็บบันทึกที่สมบูรณ์ของการรับส่งข้อมูลรายวันทั้งหมด จะเป็น 5 และ 216 GB ตามลำดับ (คุณสามารถบันทึกลงในแฟลชไดรฟ์ปกติได้ )
หากสำหรับเครื่องมือในการวิเคราะห์ข้อมูลดิบของเครือข่าย วิธีการจับข้อมูลนั้นแทบจะเหมือนกันจากผู้ขายรายหนึ่งไปอีกรายหนึ่ง ดังนั้นในกรณีของการวิเคราะห์โฟลว์ สถานการณ์จะแตกต่างกัน มีหลายตัวเลือกสำหรับโฟลว์โปรโตคอล ซึ่งเป็นข้อแตกต่างที่คุณต้องทราบในบริบทของการรักษาความปลอดภัย ที่ได้รับความนิยมมากที่สุดคือโปรโตคอล Netflow ที่พัฒนาโดย Cisco โปรโตคอลนี้มีหลายเวอร์ชัน ซึ่งแตกต่างกันในความสามารถและปริมาณข้อมูลการจราจรที่บันทึกไว้ เวอร์ชันปัจจุบันคือเวอร์ชันที่เก้า (Netflow v9) บนพื้นฐานของมาตรฐานอุตสาหกรรม Netflow v10 หรือที่เรียกว่า IPFIX ได้รับการพัฒนา ปัจจุบันผู้จำหน่ายเครือข่ายส่วนใหญ่สนับสนุน Netflow หรือ IPFIX ในอุปกรณ์ของตน แต่มีตัวเลือกอื่น ๆ มากมายสำหรับโปรโตคอลโฟลว์ - sFlow, jFlow, cFlow, rFlow, NetStream ฯลฯ ซึ่ง sFlow ได้รับความนิยมมากที่สุด เป็นประเภทนี้ที่ผู้ผลิตอุปกรณ์เครือข่ายในประเทศมักสนับสนุนบ่อยที่สุดเนื่องจากใช้งานง่าย อะไรคือความแตกต่างที่สำคัญระหว่าง Netflow ซึ่งกลายเป็นมาตรฐานโดยพฤตินัยและ sFlow ฉันจะเน้นสิ่งสำคัญหลายประการ ประการแรก Netflow มีฟิลด์ที่ผู้ใช้ปรับแต่งได้ ซึ่งต่างจากฟิลด์คงที่ใน sFlow และประการที่สอง นี่คือสิ่งที่สำคัญที่สุดในกรณีของเรา sFlow รวบรวมสิ่งที่เรียกว่าการวัดและส่งข้อมูลทางไกลตัวอย่าง ตรงกันข้ามกับอันที่ไม่ได้สุ่มตัวอย่างสำหรับ Netflow และ IPFIX ความแตกต่างระหว่างพวกเขาคืออะไร?
ลองจินตนาการว่าคุณตัดสินใจอ่านหนังสือ”” ของเพื่อนร่วมงานของฉัน - Gary McIntyre, Joseph Munitz และ Nadem Alfardan (คุณสามารถดาวน์โหลดส่วนหนึ่งของหนังสือได้จากลิงก์) คุณมีสามทางเลือกในการบรรลุเป้าหมาย ได้แก่ อ่านหนังสือทั้งเล่ม อ่านผ่านๆ หยุดทุกๆ หน้าที่ 10 หรือ 20 หรือพยายามค้นหาการเล่าแนวคิดหลักๆ ในบล็อกหรือบริการ เช่น SmartReading ดังนั้นการวัดและส่งข้อมูลทางไกลแบบไม่สุ่มตัวอย่างกำลังอ่านทุก ๆ “หน้า” ของการรับส่งข้อมูลเครือข่าย นั่นคือการวิเคราะห์ข้อมูลเมตาสำหรับแต่ละแพ็กเก็ต การวัดและส่งข้อมูลทางไกลตัวอย่างคือการศึกษาแบบเลือกสรรของการรับส่งข้อมูลโดยหวังว่าตัวอย่างที่เลือกจะมีสิ่งที่คุณต้องการ การวัดและส่งข้อมูลทางไกลตัวอย่างจะถูกส่งไปวิเคราะห์ทุกๆ แพ็กเก็ตที่ 64, 200, 500, 1000, 2000 หรือแม้กระทั่ง 10000 ขึ้นอยู่กับความเร็วของช่องสัญญาณ
ในบริบทของการตรวจสอบความปลอดภัยของข้อมูล หมายความว่าการวัดและส่งข้อมูลทางไกลตัวอย่างนั้นเหมาะสมอย่างยิ่งสำหรับการตรวจจับการโจมตี DDoS การสแกน และการแพร่กระจายโค้ดที่เป็นอันตราย แต่อาจพลาดการโจมตีแบบอะตอมมิกหรือหลายแพ็กเก็ตที่ไม่รวมอยู่ในตัวอย่างที่ส่งไปวิเคราะห์ การวัดและส่งข้อมูลทางไกลที่ไม่ได้สุ่มตัวอย่างไม่มีข้อเสียดังกล่าว ด้วยเหตุนี้ ระยะการโจมตีที่ตรวจพบจึงกว้างขึ้นมาก ต่อไปนี้คือรายการเหตุการณ์สั้นๆ ที่สามารถตรวจพบได้โดยใช้เครื่องมือวิเคราะห์การวัดและส่งข้อมูลทางไกลของเครือข่าย
แน่นอนว่าเครื่องวิเคราะห์ Netflow โอเพ่นซอร์สบางตัวจะไม่อนุญาตให้คุณทำเช่นนี้เนื่องจากงานหลักคือการรวบรวมการวัดและส่งข้อมูลทางไกลและดำเนินการวิเคราะห์พื้นฐานจากมุมมองด้านไอที ในการระบุภัยคุกคามด้านความปลอดภัยของข้อมูลตามโฟลว์ จำเป็นต้องจัดเตรียมเครื่องมือและอัลกอริธึมต่างๆ ให้กับเครื่องวิเคราะห์ ซึ่งจะระบุปัญหาความปลอดภัยทางไซเบอร์ตามฟิลด์ Netflow มาตรฐานหรือแบบกำหนดเอง เพิ่มคุณค่าข้อมูลมาตรฐานด้วยข้อมูลภายนอกจากแหล่งข่าวกรองภัยคุกคามต่างๆ เป็นต้น
ดังนั้น หากคุณมีทางเลือก ให้เลือก Netflow หรือ IPFIX แต่แม้ว่าอุปกรณ์ของคุณจะใช้งานได้กับ sFlow เท่านั้น เช่นเดียวกับผู้ผลิตในประเทศ ในกรณีนี้ คุณก็ยังสามารถได้รับประโยชน์จากอุปกรณ์ดังกล่าวในบริบทด้านความปลอดภัย
ในฤดูร้อนปี 2019 ฉันได้วิเคราะห์ความสามารถที่ผู้ผลิตฮาร์ดแวร์เครือข่ายของรัสเซียมี และทั้งหมด ยกเว้น NSG, Polygon และ Craftway ได้ประกาศสนับสนุน sFlow (อย่างน้อย Zelax, Natex, Eltex, QTech, Rusteleteh)
คำถามต่อไปที่คุณจะต้องเผชิญคือจะใช้การรองรับโฟลว์เพื่อความปลอดภัยได้ที่ไหน จริงๆ แล้ว คำถามไม่ได้ถูกตั้งอย่างถูกต้องทั้งหมด อุปกรณ์สมัยใหม่รองรับโปรโตคอลการไหลเกือบทุกครั้ง ดังนั้น ฉันจะปรับคำถามใหม่ให้แตกต่างออกไป - การรวบรวมการวัดและส่งข้อมูลทางไกลจากมุมมองด้านความปลอดภัยมีประสิทธิภาพมากที่สุดที่ใด คำตอบจะค่อนข้างชัดเจน - ในระดับการเข้าถึงซึ่งคุณจะเห็น 100% ของการรับส่งข้อมูลทั้งหมด ซึ่งคุณจะมีข้อมูลโดยละเอียดเกี่ยวกับโฮสต์ (MAC, VLAN, ID อินเทอร์เฟซ) ซึ่งคุณสามารถตรวจสอบการรับส่งข้อมูล P2P ระหว่างโฮสต์ได้ ซึ่ง เป็นสิ่งสำคัญสำหรับการสแกนการตรวจจับและการกระจายโค้ดที่เป็นอันตราย ในระดับแกนหลัก คุณอาจไม่เห็นการรับส่งข้อมูลบางส่วน แต่ในระดับขอบเขต คุณจะเห็นหนึ่งในสี่ของการรับส่งข้อมูลเครือข่ายทั้งหมดของคุณ แต่หากคุณมีอุปกรณ์ต่างประเทศในเครือข่ายของคุณด้วยเหตุผลบางประการที่อนุญาตให้ผู้โจมตี "เข้าและออก" โดยไม่ต้องข้ามขอบเขตการวิเคราะห์การวัดและส่งข้อมูลทางไกลจากอุปกรณ์นั้นจะไม่ให้อะไรเลย ดังนั้น เพื่อความครอบคลุมสูงสุด ขอแนะนำให้เปิดใช้งานการรวบรวมการวัดและส่งข้อมูลทางไกลที่ระดับการเข้าถึง ในเวลาเดียวกันเป็นที่น่าสังเกตว่าแม้ว่าเรากำลังพูดถึงการจำลองเสมือนหรือคอนเทนเนอร์ แต่การรองรับโฟลว์ก็มักจะพบในสวิตช์เสมือนสมัยใหม่ซึ่งช่วยให้คุณควบคุมการรับส่งข้อมูลที่นั่นได้เช่นกัน
แต่เนื่องจากฉันยกหัวข้อขึ้น ฉันจึงต้องตอบคำถาม: จะเกิดอะไรขึ้นหากอุปกรณ์ ทั้งทางกายภาพหรือเสมือน ไม่รองรับโฟลว์โปรโตคอล หรือเป็นสิ่งต้องห้าม (เช่น ในกลุ่มอุตสาหกรรมเพื่อให้มั่นใจในความน่าเชื่อถือ)? หรือการเปิดเครื่องทำให้ CPU มีภาระสูง (สิ่งนี้เกิดขึ้นกับฮาร์ดแวร์รุ่นเก่า) เพื่อแก้ไขปัญหานี้ มีเซ็นเซอร์เสมือนเฉพาะ (เซ็นเซอร์การไหล) ซึ่งเป็นตัวแยกสัญญาณธรรมดาที่ส่งผ่านการรับส่งข้อมูลผ่านตัวเองและออกอากาศในรูปแบบของโฟลว์ไปยังโมดูลการรวบรวม จริงอยู่ ในกรณีนี้ เราได้รับปัญหาทั้งหมดที่เราพูดถึงข้างต้นเกี่ยวกับเครื่องมือดักจับแพ็กเก็ต นั่นคือ คุณต้องเข้าใจไม่เพียงแต่ข้อดีของเทคโนโลยีการวิเคราะห์การไหลเท่านั้น แต่ยังรวมถึงข้อจำกัดของมันด้วย
อีกจุดที่สำคัญที่ต้องจำเมื่อพูดถึงเครื่องมือวิเคราะห์การไหล หากเกี่ยวข้องกับวิธีการทั่วไปในการสร้างเหตุการณ์ด้านความปลอดภัย เราใช้การวัด EPS (เหตุการณ์ต่อวินาที) ตัวบ่งชี้นี้จะไม่สามารถใช้ได้กับการวิเคราะห์การวัดและส่งข้อมูลทางไกล มันถูกแทนที่ด้วย FPS (การไหลต่อวินาที) เช่นเดียวกับในกรณีของ EPS ไม่สามารถคำนวณล่วงหน้าได้ แต่คุณสามารถประมาณจำนวนเธรดโดยประมาณที่อุปกรณ์เฉพาะสร้างขึ้นได้ขึ้นอยู่กับงานของอุปกรณ์ คุณสามารถค้นหาตารางบนอินเทอร์เน็ตพร้อมค่าโดยประมาณสำหรับอุปกรณ์และเงื่อนไของค์กรประเภทต่างๆ ซึ่งจะช่วยให้คุณสามารถประมาณใบอนุญาตที่คุณต้องการสำหรับเครื่องมือวิเคราะห์และสถาปัตยกรรมของพวกเขาจะเป็นอย่างไร ความจริงก็คือเซ็นเซอร์ IDS ถูกจำกัดด้วยแบนด์วิธบางอย่างที่สามารถ "ดึง" ได้ และตัวรวบรวมการไหลก็มีข้อจำกัดของตัวเองที่ต้องเข้าใจ ดังนั้นในเครือข่ายขนาดใหญ่ที่มีการกระจายทางภูมิศาสตร์มักจะมีผู้รวบรวมหลายคน เมื่อฉันอธิบาย ฉันได้ให้จำนวนนักสะสมของเราไปแล้ว - มี 21 คน และนี่คือสำหรับเครือข่ายที่กระจัดกระจายไปทั่วห้าทวีปและมีอุปกรณ์ที่ใช้งานอยู่ประมาณครึ่งล้านเครื่อง)
เราใช้โซลูชันของเราเองเป็นระบบตรวจสอบ Netflow ซึ่งเน้นไปที่การแก้ปัญหาด้านความปลอดภัยโดยเฉพาะ มีเอ็นจิ้นในตัวมากมายสำหรับการตรวจจับกิจกรรมที่ผิดปกติ น่าสงสัย และเป็นอันตรายอย่างชัดเจน ซึ่งช่วยให้คุณตรวจจับภัยคุกคามที่แตกต่างกันได้หลากหลาย ตั้งแต่การขุด cryptomining ไปจนถึงการรั่วไหลของข้อมูล ตั้งแต่การแพร่กระจายของโค้ดที่เป็นอันตรายไปจนถึงการฉ้อโกง เช่นเดียวกับเครื่องวิเคราะห์การไหลส่วนใหญ่ Stealthwatch ถูกสร้างขึ้นตามรูปแบบสามระดับ (เครื่องกำเนิด - ตัวรวบรวม - ตัววิเคราะห์) แต่เสริมด้วยคุณสมบัติที่น่าสนใจหลายประการที่มีความสำคัญในบริบทของวัสดุที่อยู่ระหว่างการพิจารณา ขั้นแรก จะทำงานร่วมกับโซลูชันการจับแพ็คเก็ต (เช่น Cisco Security Packet Analyzer) ซึ่งช่วยให้คุณสามารถบันทึกเซสชันเครือข่ายที่เลือกไว้สำหรับการตรวจสอบและวิเคราะห์เชิงลึกในภายหลัง ประการที่สอง โดยเฉพาะเพื่อขยายงานด้านความปลอดภัย เราได้พัฒนาโปรโตคอล nvzFlow พิเศษ ซึ่งช่วยให้คุณสามารถ “เผยแพร่” กิจกรรมของแอปพลิเคชันบนโหนดปลายทาง (เซิร์ฟเวอร์ เวิร์กสเตชัน ฯลฯ) เข้าสู่การวัดและส่งข้อมูลทางไกลและส่งไปยังตัวรวบรวมเพื่อการวิเคราะห์เพิ่มเติม หาก Stealthwatch เวอร์ชันดั้งเดิมทำงานร่วมกับโฟลว์โปรโตคอลใดๆ (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) ในระดับเครือข่าย ดังนั้นการรองรับ nvzFlow จะอนุญาตให้มีการเชื่อมโยงข้อมูลในระดับโหนดได้เช่นกัน เพิ่มประสิทธิภาพของทั้งระบบและมองเห็นการโจมตีมากกว่าเครื่องวิเคราะห์โฟลว์เครือข่ายทั่วไป
เป็นที่ชัดเจนว่าเมื่อพูดถึงระบบการวิเคราะห์ Netflow จากมุมมองด้านความปลอดภัย ตลาดไม่ได้จำกัดอยู่เพียงโซลูชันเดียวจาก Cisco คุณสามารถใช้โซลูชันเชิงพาณิชย์และฟรีหรือแชร์แวร์ได้ มันค่อนข้างแปลกถ้าฉันยกตัวอย่างโซลูชันของคู่แข่งในบล็อกของ Cisco ดังนั้น ฉันจะพูดสักสองสามคำเกี่ยวกับวิธีการวิเคราะห์การวัดและส่งข้อมูลทางไกลของเครือข่ายโดยใช้เครื่องมือยอดนิยมสองชนิดที่มีชื่อคล้ายกัน แต่ยังคงเครื่องมือที่แตกต่างกัน - SiLK และ ELK
SiLK เป็นชุดเครื่องมือ (ระบบสำหรับความรู้ระดับอินเทอร์เน็ต) สำหรับการวิเคราะห์การรับส่งข้อมูล พัฒนาโดย American CERT/CC และสนับสนุน IPFIX ในบริบทของบทความในปัจจุบัน และ sFlow และใช้ยูทิลิตี้ต่างๆ (rwfilter, rwcount, rwflowpack ฯลฯ ) เพื่อดำเนินการต่างๆ บนเครือข่าย telemetry เพื่อตรวจจับสัญญาณของการกระทำที่ไม่ได้รับอนุญาต แต่มีประเด็นสำคัญสองสามข้อที่ควรทราบ SiLK เป็นเครื่องมือบรรทัดคำสั่งที่ทำการวิเคราะห์ออนไลน์โดยการป้อนคำสั่งเช่นนี้ (การตรวจจับแพ็กเก็ต ICMP ที่มีขนาดใหญ่กว่า 5 ไบต์):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
ไม่สบายมาก คุณสามารถใช้ iSiLK GUI ได้ แต่จะไม่ทำให้ชีวิตของคุณง่ายขึ้นมากนัก มีเพียงการแก้ไขฟังก์ชันการแสดงภาพเท่านั้น และไม่ได้แทนที่นักวิเคราะห์ และนี่คือประเด็นที่สอง แตกต่างจากโซลูชันเชิงพาณิชย์ซึ่งมีฐานการวิเคราะห์ที่มั่นคงอยู่แล้ว อัลกอริธึมการตรวจจับความผิดปกติ ขั้นตอนการทำงานที่เกี่ยวข้อง ฯลฯ ในกรณีของ SiLK คุณจะต้องทำทั้งหมดนี้ด้วยตัวเอง ซึ่งจะต้องใช้ความสามารถที่แตกต่างจากคุณเล็กน้อยมากกว่าการใช้พร้อมแล้ว- เครื่องมือที่จะใช้ นี่ไม่ใช่สิ่งดีหรือไม่ดี - นี่เป็นคุณสมบัติของเครื่องมือฟรีเกือบทุกชนิดที่ถือว่าคุณรู้ว่าต้องทำอะไร และจะช่วยคุณในเรื่องนี้เท่านั้น (เครื่องมือเชิงพาณิชย์จะขึ้นอยู่กับความสามารถของผู้ใช้น้อยกว่า แม้ว่าพวกเขาจะถือว่ายังถือว่า ที่นักวิเคราะห์เข้าใจพื้นฐานของการตรวจสอบและติดตามเครือข่ายเป็นอย่างน้อย) แต่กลับมาที่ SilK กันดีกว่า วงจรการทำงานของนักวิเคราะห์มีลักษณะดังนี้:
- การกำหนดสมมติฐาน เราต้องเข้าใจว่าเราจะมองหาอะไรในการตรวจวัดทางไกลของเครือข่าย รู้คุณลักษณะเฉพาะที่เราจะระบุความผิดปกติหรือภัยคุกคามบางอย่าง
- การสร้างแบบจำลอง หลังจากกำหนดสมมติฐานแล้ว เราตั้งโปรแกรมโดยใช้ Python, เชลล์ หรือเครื่องมืออื่นๆ ที่ไม่รวมอยู่ใน SiLK
- การทดสอบ ตอนนี้ถึงเวลาตรวจสอบความถูกต้องของสมมติฐานของเรา ซึ่งได้รับการยืนยันหรือหักล้างโดยใช้ยูทิลิตี้ SiLK ที่ขึ้นต้นด้วย 'rw', 'set', 'bag'
- การวิเคราะห์ข้อมูลจริง ในการดำเนินอุตสาหกรรม SiLK ช่วยให้เราระบุบางสิ่งบางอย่าง และนักวิเคราะห์จะต้องตอบคำถาม “เราพบสิ่งที่เราคาดหวังไว้หรือไม่”, “สิ่งนี้สอดคล้องกับสมมติฐานของเราหรือไม่”, “จะลดจำนวนผลบวกลวงได้อย่างไร”, “อย่างไร เพื่อปรับปรุงระดับการรับรู้? » และอื่น ๆ
- การปรับปรุง. ในขั้นตอนสุดท้าย เราปรับปรุงสิ่งที่ทำไว้ก่อนหน้านี้ - เราสร้างเทมเพลต ปรับปรุงและเพิ่มประสิทธิภาพโค้ด ปรับโครงสร้างใหม่และชี้แจงสมมติฐาน ฯลฯ
รอบนี้จะใช้ได้กับ Cisco Stealthwatch เช่นกัน โดยมีเพียงขั้นตอนสุดท้ายเท่านั้นที่ทำให้ห้าขั้นตอนเหล่านี้เป็นอัตโนมัติสูงสุด ซึ่งจะช่วยลดจำนวนข้อผิดพลาดของนักวิเคราะห์ และเพิ่มประสิทธิภาพในการตรวจจับเหตุการณ์ ตัวอย่างเช่น ใน SiLK คุณสามารถเพิ่มสถิติเครือข่ายด้วยข้อมูลภายนอกบน IP ที่เป็นอันตรายโดยใช้สคริปต์ที่เขียนด้วยมือ และใน Cisco Stealthwatch เป็นฟังก์ชันในตัวที่แสดงการแจ้งเตือนทันทีหากการรับส่งข้อมูลเครือข่ายมีการโต้ตอบกับที่อยู่ IP จากบัญชีดำ
หากคุณไปสูงกว่าในพีระมิด "ที่ต้องชำระเงิน" สำหรับซอฟต์แวร์วิเคราะห์การไหล หลังจาก SiLK ฟรีอย่างแน่นอนจะมีแชร์แวร์ ELK ซึ่งประกอบด้วยองค์ประกอบหลักสามประการ - Elasticsearch (การจัดทำดัชนี การค้นหา และการวิเคราะห์ข้อมูล), Logstash (อินพุต/เอาท์พุตข้อมูล ) และ Kibana (การสร้างภาพข้อมูล) ต่างจาก SiLK ตรงที่คุณต้องเขียนทุกอย่างด้วยตัวเอง ELK มีไลบรารี/โมดูลสำเร็จรูปจำนวนมากอยู่แล้ว (บางตัวต้องเสียเงิน บางตัวไม่) ที่ทำให้การวิเคราะห์การวัดและส่งข้อมูลทางไกลของเครือข่ายเป็นแบบอัตโนมัติ ตัวอย่างเช่น ตัวกรอง GeoIP ใน Logstash ช่วยให้คุณเชื่อมโยงที่อยู่ IP ที่ได้รับการตรวจสอบกับที่ตั้งทางภูมิศาสตร์ (Stealthwatch มีคุณสมบัติในตัวนี้)
ELK ยังมีชุมชนขนาดใหญ่ที่กำลังดำเนินการส่วนประกอบที่ขาดหายไปสำหรับโซลูชันการตรวจสอบนี้ ตัวอย่างเช่น หากต้องการทำงานกับ Netflow, IPFIX และ sFlow คุณสามารถใช้โมดูลได้ หากคุณไม่พอใจกับ Logstash Netflow Module ซึ่งรองรับเฉพาะ Netflow เท่านั้น
ในขณะที่ให้ประสิทธิภาพมากขึ้นในการรวบรวมโฟลว์และการค้นหาในนั้น ปัจจุบัน ELK ยังขาดการวิเคราะห์ในตัวสำหรับการตรวจจับความผิดปกติและภัยคุกคามในการวัดและส่งข้อมูลทางไกลของเครือข่าย นั่นคือตามวงจรชีวิตที่อธิบายไว้ข้างต้น คุณจะต้องอธิบายโมเดลการละเมิดอย่างอิสระ จากนั้นใช้มันในระบบการต่อสู้ (ไม่มีโมเดลในตัว)
แน่นอนว่ามีส่วนขยายที่ซับซ้อนกว่าสำหรับ ELK ซึ่งมีบางโมเดลสำหรับตรวจจับความผิดปกติในการวัดและส่งข้อมูลทางไกลของเครือข่ายอยู่แล้ว แต่ส่วนขยายดังกล่าวต้องเสียค่าใช้จ่ายและคำถามก็คือว่าเกมนี้คุ้มค่ากับเทียนหรือไม่ - เขียนโมเดลที่คล้ายกันด้วยตัวคุณเอง ซื้อมัน การใช้งานสำหรับเครื่องมือตรวจสอบของคุณ หรือซื้อโซลูชันสำเร็จรูปของคลาส Network Traffic Analysis
โดยทั่วไปฉันไม่ต้องการถกเถียงกันว่าควรใช้จ่ายเงินและซื้อโซลูชันสำเร็จรูปสำหรับการตรวจสอบความผิดปกติและภัยคุกคามในระบบโทรมาตรเครือข่าย (เช่น Cisco Stealthwatch) จะดีกว่าหรือคิดออกเองและปรับแต่งสิ่งเดียวกัน SiLK, ELK หรือ nfdump หรือ OSU Flow Tools สำหรับภัยคุกคามใหม่แต่ละรายการ (ฉันกำลังพูดถึงสองตัวสุดท้าย ครั้งสุดท้าย)? ทุกคนเลือกเพื่อตนเองและทุกคนก็มีแรงจูงใจในการเลือกหนึ่งในสองตัวเลือกของตนเอง ฉันแค่อยากจะแสดงให้เห็นว่าการตรวจวัดระยะไกลของเครือข่ายเป็นเครื่องมือที่สำคัญมากในการรับรองความปลอดภัยเครือข่ายของโครงสร้างพื้นฐานภายในของคุณและคุณไม่ควรละเลยมัน เพื่อที่จะไม่เข้าร่วมรายชื่อบริษัทที่มีการกล่าวถึงชื่อในสื่อพร้อมกับคำฉายา “ ถูกแฮ็ก”, “ไม่ปฏิบัติตามข้อกำหนดด้านความปลอดภัยของข้อมูล”, “ไม่ได้คำนึงถึงความปลอดภัยของข้อมูลและข้อมูลลูกค้า”
โดยสรุป ฉันต้องการแสดงรายการเคล็ดลับสำคัญที่คุณควรปฏิบัติตามเมื่อสร้างการตรวจสอบความปลอดภัยของข้อมูลสำหรับโครงสร้างพื้นฐานภายในของคุณ:
- อย่าจำกัดตัวเองอยู่แค่ในขอบเขต! ใช้ (และเลือก) โครงสร้างพื้นฐานเครือข่ายไม่เพียงแต่เพื่อย้ายการรับส่งข้อมูลจากจุด A ไปยังจุด B แต่ยังเพื่อแก้ไขปัญหาความปลอดภัยทางไซเบอร์ด้วย
- ศึกษากลไกการตรวจสอบความปลอดภัยของข้อมูลที่มีอยู่ในอุปกรณ์เครือข่ายของคุณและใช้งาน
- สำหรับการตรวจสอบภายใน ให้ความสำคัญกับการวิเคราะห์การวัดและส่งข้อมูลทางไกล ซึ่งช่วยให้คุณตรวจจับเหตุการณ์ความปลอดภัยของข้อมูลเครือข่ายได้มากถึง 80-90% ในขณะที่ทำสิ่งที่เป็นไปไม่ได้เมื่อจับแพ็กเก็ตเครือข่ายและประหยัดพื้นที่สำหรับจัดเก็บเหตุการณ์ความปลอดภัยของข้อมูลทั้งหมด
- หากต้องการตรวจสอบโฟลว์ ให้ใช้ Netflow v9 หรือ IPFIX ซึ่งจะให้ข้อมูลเพิ่มเติมในบริบทด้านความปลอดภัย และช่วยให้คุณตรวจสอบได้ไม่เพียงแต่ IPv4 เท่านั้น แต่ยังรวมถึง IPv6, MPLS และอื่นๆ ด้วย
- ใช้โปรโตคอลโฟลว์ที่ไม่ได้สุ่มตัวอย่าง - ให้ข้อมูลเพิ่มเติมสำหรับการตรวจจับภัยคุกคาม ตัวอย่างเช่น Netflow หรือ IPFIX
- ตรวจสอบโหลดบนอุปกรณ์เครือข่ายของคุณ - อาจไม่สามารถจัดการโฟลว์โปรโตคอลได้เช่นกัน จากนั้นให้พิจารณาใช้เซ็นเซอร์เสมือนหรือ Netflow Generation Appliance
- ใช้การควบคุมที่ระดับการเข้าถึงเป็นอันดับแรก ซึ่งจะทำให้คุณมีโอกาสเห็นการเข้าชมทั้งหมด 100%
- หากคุณไม่มีทางเลือกและคุณกำลังใช้อุปกรณ์เครือข่ายของรัสเซีย ให้เลือกอุปกรณ์ที่รองรับโฟลว์โปรโตคอลหรือมีพอร์ต SPAN/RSPAN
- รวมระบบการตรวจจับ/ป้องกันการบุกรุก/การโจมตีที่ขอบและระบบวิเคราะห์การไหลในเครือข่ายภายใน (รวมถึงในระบบคลาวด์)
ส่วนทิปสุดท้ายผมขอยกตัวอย่างที่ผมเคยให้ไปแล้วครับ คุณจะเห็นว่าหากก่อนหน้านี้บริการรักษาความปลอดภัยข้อมูลของ Cisco ได้สร้างระบบตรวจสอบความปลอดภัยของข้อมูลเกือบทั้งหมดโดยใช้ระบบตรวจจับการบุกรุกและวิธีการลงนาม ปัจจุบันระบบเหล่านี้คิดเป็นสัดส่วนเพียง 20% ของเหตุการณ์เท่านั้น อีก 20% ตกอยู่ในระบบการวิเคราะห์การไหลซึ่งชี้ให้เห็นว่าโซลูชันเหล่านี้ไม่ใช่ความตั้งใจ แต่เป็นเครื่องมือที่แท้จริงในกิจกรรมบริการรักษาความปลอดภัยข้อมูลขององค์กรสมัยใหม่ ยิ่งไปกว่านั้น คุณมีสิ่งที่สำคัญที่สุดสำหรับการนำไปใช้งาน - โครงสร้างพื้นฐานเครือข่าย การลงทุนที่สามารถป้องกันเพิ่มเติมได้โดยการกำหนดฟังก์ชันการตรวจสอบความปลอดภัยของข้อมูลให้กับเครือข่าย
ฉันไม่ได้พูดถึงหัวข้อการตอบสนองต่อความผิดปกติหรือภัยคุกคามที่ระบุในโฟลว์เครือข่ายโดยเฉพาะ แต่ฉันคิดว่าเป็นที่ชัดเจนแล้วว่าการตรวจสอบไม่ควรสิ้นสุดเพียงการตรวจจับภัยคุกคามเท่านั้น ควรตามด้วยการตอบสนองและควรอยู่ในโหมดอัตโนมัติหรืออัตโนมัติ แต่นี่เป็นหัวข้อสำหรับบทความแยกต่างหาก
ข้อมูลสมาชิกเพิ่มเติม:
ป.ล. หากเป็นการง่ายกว่าสำหรับคุณที่จะได้ยินทุกสิ่งที่เขียนไว้ข้างต้น คุณสามารถดูการนำเสนอที่มีความยาวหนึ่งชั่วโมงซึ่งเป็นพื้นฐานของบันทึกย่อนี้ได้
ที่มา: will.com