ნაკადის პროტოკოლები, როგორც შიდა ქსელის უსაფრთხოების მონიტორინგის ინსტრუმენტი

როდესაც საქმე ეხება შიდა კორპორატიული ან უწყებრივი ქსელის უსაფრთხოების მონიტორინგს, ბევრი მას უკავშირებს ინფორმაციის გაჟონვის კონტროლს და DLP გადაწყვეტილებების განხორციელებას. და თუ შეეცდებით კითხვის გარკვევას და იკითხავთ, თუ როგორ ამოიცნობთ თავდასხმებს შიდა ქსელში, მაშინ პასუხი, როგორც წესი, იქნება შეჭრის აღმოჩენის სისტემების (IDS) ხსენება. და ის, რაც 10-20 წლის წინ ერთადერთი ვარიანტი იყო, დღეს ანაქრონიზმად იქცევა. არსებობს შიდა ქსელის მონიტორინგის უფრო ეფექტური და ზოგან ერთადერთი შესაძლო ვარიანტი - ნაკადის პროტოკოლების გამოყენება, რომლებიც თავდაპირველად შექმნილი იყო ქსელის პრობლემების მოსაძებნად (პრობლემების მოგვარება), მაგრამ დროთა განმავლობაში გადაკეთდა ძალიან საინტერესო უსაფრთხოების ინსტრუმენტად. ჩვენ ვისაუბრებთ იმაზე, თუ რა ნაკადის პროტოკოლები არსებობს და რომელი მათგანი უკეთესია ქსელის შეტევების გამოვლენაში, სად ჯობია ნაკადის მონიტორინგის განხორციელება, რა უნდა ვეძებოთ ასეთი სქემის განლაგებისას და კიდევ როგორ უნდა "აწიოთ" ეს ყველაფერი საშინაო მოწყობილობებზე. ამ სტატიის ფარგლებში.

მე არ შევჩერდები კითხვაზე "რატომ არის საჭირო შიდა ინფრასტრუქტურის უსაფრთხოების მონიტორინგი?" როგორც ჩანს, პასუხი ნათელია. მაგრამ თუ მაინც გინდა კიდევ ერთხელ დარწმუნდე, რომ დღეს მის გარეშე ცხოვრება არ შეგიძლია, გამოიყურება მოკლე ვიდეო იმის შესახებ, თუ როგორ შეგიძლიათ შეაღწიოთ კორპორატიულ ქსელში, რომელიც დაცულია firewall-ით 17 გზით. აქედან გამომდინარე, ჩვენ ვივარაუდებთ, რომ გვესმის, რომ შიდა მონიტორინგი აუცილებელი რამ არის და რჩება მხოლოდ იმის გაგება, თუ როგორ შეიძლება მისი ორგანიზება.

მე გამოვყოფდი სამ ძირითად მონაცემთა წყაროს ქსელის დონეზე ინფრასტრუქტურის მონიტორინგისთვის:

• „ნედლეული“ ტრაფიკი, რომელსაც ჩვენ ვიღებთ და ანალიზისთვის წარვადგენთ გარკვეული ანალიზის სისტემებს,
• მოვლენები ქსელური მოწყობილობებიდან, რომლებშიც გადის ტრაფიკი,
• მოძრაობის შესახებ ინფორმაცია, რომელიც მიღებულია ნაკადის ერთ-ერთი პროტოკოლით.

ნედლი ტრაფიკის დაჭერა უსაფრთხოების სპეციალისტებს შორის ყველაზე პოპულარული ვარიანტია, რადგან ის ისტორიულად გამოჩნდა და პირველი იყო. ჩვეულებრივი ქსელის შეჭრის აღმოჩენის სისტემები (პირველი კომერციული შეჭრის აღმოჩენის სისტემა იყო NetRanger Wheel Group-ისგან, რომელიც შეიძინა 1998 წელს Cisco-ს მიერ) ზუსტად იყო ჩართული პაკეტების (და შემდგომი სესიების) დაჭერით, რომლებშიც გარკვეული ხელმოწერები მოიძებნებოდა („გადამწყვეტი წესები“ FSTEC ტერმინოლოგია), სასიგნალო შეტევები. რა თქმა უნდა, თქვენ შეგიძლიათ გააანალიზოთ ნედლი ტრაფიკი არა მხოლოდ IDS-ის გამოყენებით, არამედ სხვა ინსტრუმენტების გამოყენებით (მაგალითად, Wireshark, tcpdum ან NBAR2 ფუნქციონალობა Cisco IOS-ში), მაგრამ მათ ჩვეულებრივ არ აქვთ ცოდნის ბაზა, რომელიც განასხვავებს ინფორმაციული უსაფრთხოების ინსტრუმენტს ჩვეულებრივისგან. IT ინსტრუმენტი.

ასე რომ, თავდასხმის გამოვლენის სისტემები. ქსელის თავდასხმების გამოვლენის უძველესი და ყველაზე პოპულარული მეთოდი, რომელიც კარგ საქმეს აკეთებს პერიმეტრზე (არ აქვს მნიშვნელობა რა - კორპორატიული, მონაცემთა ცენტრი, სეგმენტი და ა. ჩვეულებრივი გადამრთველების საფუძველზე აგებული ქსელის შემთხვევაში, თავდასხმის გამოვლენის სენსორების ინფრასტრუქტურა ძალიან დიდი ხდება - თქვენ მოგიწევთ სენსორის დაყენება თითოეულ კავშირზე იმ კვანძთან, რომელზეც გსურთ შეტევების მონიტორინგი. ნებისმიერი მწარმოებელი, რა თქმა უნდა, სიამოვნებით მოგყიდით ასობით და ათასობით სენსორს, მაგრამ მე ვფიქრობ, რომ თქვენი ბიუჯეტი ვერ გაუძლებს ასეთ ხარჯებს. შემიძლია ვთქვა, რომ Cisco-შიც კი (და ჩვენ ვართ NGIPS-ის დეველოპერები) ეს ვერ შევძელით, თუმცა, როგორც ჩანს, ფასის საკითხი ჩვენს წინაშეა. მე არ უნდა დავდგე - ეს ჩვენი საკუთარი გადაწყვეტილებაა. გარდა ამისა, ჩნდება კითხვა, როგორ დააკავშიროთ სენსორი ამ ვერსიაში? უფსკრულისკენ? რა მოხდება, თუ თავად სენსორი მარცხდება? გჭირდებათ შემოვლითი მოდული სენსორში? გამოიყენეთ გამყოფები (ონკანი)? ეს ყველაფერი აძვირებს გამოსავალს და მიუწვდომელს ხდის ნებისმიერი ზომის კომპანიისთვის.

შეგიძლიათ სცადოთ სენსორის „დაკიდება“ SPAN/RSPAN/ERSPAN პორტზე და გადაიყვანოთ ტრაფიკი საჭირო გადამრთველი პორტებიდან მასზე. ეს პარამეტრი ნაწილობრივ ხსნის წინა აბზაცში აღწერილ პრობლემას, მაგრამ აჩენს მეორეს - SPAN პორტს არ შეუძლია მიიღოს აბსოლუტურად ყველა ტრაფიკი, რომელიც გაეგზავნება მას - მას არ ექნება საკმარისი გამტარობა. რაღაცის გაწირვა მოგიწევს. ან დატოვეთ ზოგიერთი კვანძი მონიტორინგის გარეშე (მაშინ ჯერ მათ პრიორიტეტად უნდა დაასახელოთ), ან გაგზავნოთ არა მთელი ტრაფიკი კვანძიდან, არამედ მხოლოდ გარკვეული ტიპის. ნებისმიერ შემთხვევაში, შეიძლება გამოგვრჩეს რამდენიმე შეტევა. გარდა ამისა, SPAN პორტის გამოყენება შესაძლებელია სხვა საჭიროებისთვის. შედეგად, ჩვენ მოგვიწევს არსებული ქსელის ტოპოლოგიის გადახედვა და, შესაძლოა, მასში კორექტირება, რათა თქვენი ქსელი მაქსიმალურად დავფაროთ იმ სენსორების რაოდენობით, რაც გაქვთ (და კოორდინაცია მოვახდინოთ IT-თან).

რა მოხდება, თუ თქვენი ქსელი იყენებს ასიმეტრიულ მარშრუტებს? რა მოხდება, თუ თქვენ განახორციელეთ ან გეგმავთ SDN-ის განხორციელებას? რა მოხდება, თუ გჭირდებათ ვირტუალიზებული მანქანების ან კონტეინერების მონიტორინგი, რომელთა ტრაფიკი საერთოდ არ აღწევს ფიზიკურ გადამრთველს? ეს არის კითხვები, რომლებიც არ მოსწონთ ტრადიციულ IDS მომწოდებლებს, რადგან არ იციან როგორ უპასუხონ მათ. ალბათ ისინი დაგარწმუნებენ, რომ ყველა ეს მოდური ტექნოლოგია აჟიოტაჟია და ეს არ გჭირდება. ალბათ ისინი ისაუბრებენ მცირედ დაწყების აუცილებლობაზე. ან იქნებ ისინი იტყვიან, რომ თქვენ უნდა დააყენოთ მძლავრი თრეშერი ქსელის ცენტრში და მიმართოთ მასზე მთელი ტრაფიკი ბალანსერების გამოყენებით. როგორი ვარიანტიც არ უნდა შემოგთავაზოთ, ნათლად უნდა გესმოდეთ, როგორ ჯდება. და მხოლოდ ამის შემდეგ მიიღეთ გადაწყვეტილება ქსელის ინფრასტრუქტურის ინფორმაციული უსაფრთხოების მონიტორინგის მიდგომის არჩევის შესახებ. პაკეტების დაჭერას რომ დავუბრუნდეთ, მინდა ვთქვა, რომ ეს მეთოდი კვლავაც ძალიან პოპულარული და მნიშვნელოვანია, მაგრამ მისი მთავარი მიზანი საზღვრის კონტროლია; საზღვრები თქვენს ორგანიზაციასა და ინტერნეტს შორის, საზღვრები მონაცემთა ცენტრსა და დანარჩენ ქსელს შორის, საზღვრები პროცესის კონტროლის სისტემასა და კორპორატიულ სეგმენტს შორის. ამ ადგილებში კლასიკურ IDS/IPS-ებს ჯერ კიდევ აქვთ არსებობის უფლება და კარგად გაუმკლავდნენ თავიანთ ამოცანებს.

გადავიდეთ მეორე ვარიანტზე. ქსელური მოწყობილობებიდან მომდინარე მოვლენების ანალიზი ასევე შეიძლება გამოყენებულ იქნას თავდასხმის აღმოჩენის მიზნებისთვის, მაგრამ არა როგორც მთავარი მექანიზმი, რადგან ის საშუალებას იძლევა გამოავლინოს მხოლოდ მცირე კლასის შეჭრა. გარდა ამისა, ის თანდაყოლილია გარკვეული რეაქტიულობისთვის - თავდასხმა ჯერ უნდა მოხდეს, შემდეგ ის უნდა ჩაიწეროს ქსელური მოწყობილობით, რაც ამა თუ იმ გზით მიანიშნებს ინფორმაციული უსაფრთხოების პრობლემაზე. რამდენიმე ასეთი გზა არსებობს. ეს შეიძლება იყოს syslog, RMON ან SNMP. ინფორმაციული უსაფრთხოების კონტექსტში ქსელის მონიტორინგის ბოლო ორი პროტოკოლი გამოიყენება მხოლოდ იმ შემთხვევაში, თუ ჩვენ გვჭირდება DoS შეტევის გამოვლენა თავად ქსელურ აღჭურვილობაზე, რადგან RMON-ისა და SNMP-ის გამოყენებით შესაძლებელია, მაგალითად, მოწყობილობის ცენტრალურზე დატვირთვის მონიტორინგი. პროცესორი ან მისი ინტერფეისები. ეს არის ერთ-ერთი ყველაზე „იაფი“ (ყველას აქვს syslog ან SNMP), მაგრამ ასევე ყველაზე არაეფექტურია შიდა ინფრასტრუქტურის ინფორმაციული უსაფრთხოების მონიტორინგის ყველა მეთოდს შორის - ბევრი შეტევა უბრალოდ იმალება მისგან. რა თქმა უნდა, ისინი არ უნდა იყოს უგულებელყოფილი, და იგივე სილოგის ანალიზი გეხმარებათ დროულად დაადგინოთ ცვლილებები თავად მოწყობილობის კონფიგურაციაში, კომპრომისზე, მაგრამ ეს არ არის ძალიან შესაფერისი მთელ ქსელზე თავდასხმების გამოსავლენად.

მესამე ვარიანტი არის ინფორმაციის ანალიზი ტრაფიკის შესახებ, რომელიც გადის მოწყობილობაზე, რომელიც მხარს უჭერს რამდენიმე ნაკადის პროტოკოლს. ამ შემთხვევაში, პროტოკოლის მიუხედავად, ხრახნიანი ინფრასტრუქტურა აუცილებლად შედგება სამი კომპონენტისგან:

• ნაკადის წარმოქმნა ან ექსპორტი. ეს როლი ჩვეულებრივ ენიჭება როუტერს, გადამრთველს ან სხვა ქსელურ მოწყობილობას, რომელიც ქსელის ტრაფიკის გავლისას საშუალებას გაძლევთ ამოიღოთ მისგან ძირითადი პარამეტრები, რომლებიც შემდეგ გადაეცემა შეგროვების მოდულს. მაგალითად, Cisco მხარს უჭერს Netflow პროტოკოლს არა მხოლოდ მარშრუტიზატორებსა და სვიჩებზე, მათ შორის ვირტუალურ და სამრეწველო პირობაზე, არამედ უკაბელო კონტროლერებზე, ფეიერვოლებზე და სერვერებზეც კი.
• კოლექციის ნაკადი. იმის გათვალისწინებით, რომ თანამედროვე ქსელს ჩვეულებრივ აქვს ერთზე მეტი ქსელური მოწყობილობა, ჩნდება ნაკადების შეგროვებისა და კონსოლიდაციის პრობლემა, რომელიც წყდება ე.წ. კოლექტორების გამოყენებით, რომლებიც ამუშავებენ მიღებულ ნაკადებს და შემდეგ გადასცემენ მათ ანალიზისთვის.
• ნაკადის ანალიზი ანალიზატორი იღებს მთავარ ინტელექტუალურ დავალებას და ნაკადებზე სხვადასხვა ალგორითმის გამოყენებით, გამოაქვს გარკვეული დასკვნები. მაგალითად, როგორც IT ფუნქციის ნაწილი, ასეთ ანალიზატორს შეუძლია ქსელის შეფერხებების იდენტიფიცირება ან ტრაფიკის დატვირთვის პროფილის ანალიზი ქსელის შემდგომი ოპტიმიზაციისთვის. და ინფორმაციის უსაფრთხოებისთვის, ასეთ ანალიზატორს შეუძლია აღმოაჩინოს მონაცემთა გაჟონვა, მავნე კოდის გავრცელება ან DoS შეტევები.

არ იფიქროთ, რომ ეს სამსაფეხურიანი არქიტექტურა ძალიან რთულია - ყველა სხვა ვარიანტი (გარდა, ალბათ, SNMP-ით და RMON-ით მომუშავე ქსელის მონიტორინგის სისტემებისა) ასევე მუშაობს მის მიხედვით. ჩვენ გვაქვს მონაცემთა გენერატორი ანალიზისთვის, რომელიც შეიძლება იყოს ქსელური მოწყობილობა ან ცალკე სენსორი. ჩვენ გვაქვს განგაშის შეგროვების სისტემა და მართვის სისტემა მთელი მონიტორინგის ინფრასტრუქტურისთვის. ბოლო ორი კომპონენტი შეიძლება გაერთიანდეს ერთ კვანძში, მაგრამ მეტ-ნაკლებად დიდ ქსელებში ისინი ჩვეულებრივ განაწილებულია მინიმუმ ორ მოწყობილობაზე მასშტაბურობისა და საიმედოობის უზრუნველსაყოფად.

პაკეტის ანალიზისგან განსხვავებით, რომელიც ეფუძნება თითოეული პაკეტის სათაურის და სხეულის მონაცემების შესწავლას და სესიებს, რომლიდანაც შედგება, ნაკადის ანალიზი ეყრდნობა მეტამონაცემების შეგროვებას ქსელის ტრაფიკის შესახებ. როდის, რამდენი, საიდან და საიდან, როგორ... ამ კითხვებზე პასუხობს ქსელის ტელემეტრიის ანალიზი სხვადასხვა ნაკადის პროტოკოლების გამოყენებით. თავდაპირველად ისინი გამოიყენებოდა სტატისტიკის გასაანალიზებლად და ქსელში IT პრობლემების მოსაძებნად, მაგრამ შემდეგ, როგორც ანალიტიკური მექანიზმები განვითარდა, შესაძლებელი გახდა მათი გამოყენება იმავე ტელემეტრიაში უსაფრთხოების მიზნით. კიდევ ერთხელ უნდა აღინიშნოს, რომ ნაკადის ანალიზი არ ცვლის ან ცვლის პაკეტის დაჭერას. თითოეულ ამ მეთოდს აქვს თავისი გამოყენების სფერო. მაგრამ ამ სტატიის კონტექსტში, ეს არის ნაკადის ანალიზი, რომელიც საუკეთესოდ შეეფერება შიდა ინფრასტრუქტურის მონიტორინგს. თქვენ გაქვთ ქსელური მოწყობილობები (მიუხედავად იმისა, ისინი მუშაობენ პროგრამული უზრუნველყოფის მიერ განსაზღვრული პარადიგმით თუ სტატიკური წესების მიხედვით), რომელთა გვერდის ავლით შეტევა არ შეიძლება. მას შეუძლია კლასიკური IDS სენსორის გვერდის ავლით, მაგრამ ქსელური მოწყობილობა, რომელიც მხარს უჭერს ნაკადის პროტოკოლს, არ შეუძლია. ეს არის ამ მეთოდის უპირატესობა.

მეორე მხრივ, თუ თქვენ გჭირდებათ მტკიცებულებები სამართალდამცავებისთვის ან თქვენი ინციდენტის გამომძიებელი ჯგუფისთვის, თქვენ არ შეგიძლიათ გააკეთოთ პაკეტის დაჭერის გარეშე - ქსელის ტელემეტრია არ არის ტრაფიკის ასლი, რომელიც შეიძლება გამოყენებულ იქნას მტკიცებულებების შესაგროვებლად; ის საჭიროა ინფორმაციული უსაფრთხოების სფეროში სწრაფი გამოვლენისა და გადაწყვეტილების მისაღებად. მეორეს მხრივ, ტელემეტრიული ანალიზის გამოყენებით, თქვენ შეგიძლიათ „დაწეროთ“ არა მთელი ქსელის ტრაფიკი (თუ რამეა, Cisco ეხება მონაცემთა ცენტრებს :-), არამედ მხოლოდ ის, რაც მონაწილეობს შეტევაში. ტელემეტრიული ანალიზის ხელსაწყოები ამ მხრივ კარგად შეავსებს პაკეტების აღების ტრადიციულ მექანიზმებს, გასცემს ბრძანებებს შერჩევითი დაჭერისა და შენახვისთვის. წინააღმდეგ შემთხვევაში, მოგიწევთ კოლოსალური შენახვის ინფრასტრუქტურა.

წარმოვიდგინოთ ქსელი, რომელიც მუშაობს 250 მბიტ/წმ სიჩქარით. თუ გსურთ მთელი ამ მოცულობის შენახვა, მაშინ დაგჭირდებათ 31 მბ საცავი ტრაფიკის გადაცემის ერთი წამისთვის, 1,8 GB ერთი წუთის განმავლობაში, 108 GB ერთი საათის განმავლობაში და 2,6 TB ერთი დღის განმავლობაში. 10 გბიტ/წმ სიჩქარის მქონე ქსელიდან ყოველდღიური მონაცემების შესანახად, დაგჭირდებათ 108 ტბ მეხსიერება. მაგრამ ზოგიერთი რეგულატორი მოითხოვს უსაფრთხოების მონაცემების წლების განმავლობაში შენახვას... მოთხოვნით ჩანაწერი, რომლის განხორციელებაშიც გეხმარებათ ნაკადის ანალიზი, დაგეხმარებათ ამ მნიშვნელობების შემცირებაში სიდიდის მიხედვით. სხვათა შორის, თუ ვსაუბრობთ ჩაწერილი ქსელის ტელემეტრიული მონაცემების მოცულობის თანაფარდობაზე და მონაცემთა სრული აღრიცხვაზე, მაშინ ეს არის დაახლოებით 1-დან 500-მდე. ზემოთ მოცემული იგივე მნიშვნელობებისთვის, მთელი ყოველდღიური ტრაფიკის სრული ტრანსკრიპტის შენახვა. იქნება, შესაბამისად, 5 და 216 GB (შეგიძლიათ ჩაწეროთ ის ჩვეულებრივ ფლეშ დრაივზეც კი).

თუ ქსელის ნედლეული მონაცემების ანალიზის ხელსაწყოებისთვის, მისი აღების მეთოდი თითქმის იგივეა გამყიდველიდან გამყიდველამდე, მაშინ ნაკადის ანალიზის შემთხვევაში სიტუაცია განსხვავებულია. ნაკადის პროტოკოლების რამდენიმე ვარიანტი არსებობს, განსხვავებები, რომელთა შესახებაც უნდა იცოდეთ უსაფრთხოების კონტექსტში. ყველაზე პოპულარული არის Cisco-ს მიერ შემუშავებული Netflow პროტოკოლი. ამ პროტოკოლის რამდენიმე ვერსია არსებობს, რომლებიც განსხვავდება მათი შესაძლებლობებით და დაფიქსირებული ტრაფიკის ინფორმაციის რაოდენობით. მიმდინარე ვერსია არის მეცხრე (Netflow v9), რომლის საფუძველზეც შეიქმნა ინდუსტრიის სტანდარტი Netflow v10, ასევე ცნობილი როგორც IPFIX. დღეს, ქსელის მომწოდებლების უმეტესობა მხარს უჭერს Netflow-ს ან IPFIX-ს მათ აღჭურვილობაში. მაგრამ არსებობს ნაკადის პროტოკოლების სხვა ვარიანტები - sFlow, jFlow, cFlow, rFlow, NetStream და ა.შ., რომელთაგან sFlow ყველაზე პოპულარულია. სწორედ ამ ტიპს უჭერს მხარს ყველაზე ხშირად ქსელური აღჭურვილობის შიდა მწარმოებლები მისი განხორციელების სიმარტივის გამო. რა არის ძირითადი განსხვავებები Netflow-ს შორის, რომელიც გახდა დე ფაქტო სტანდარტი და sFlow-ს შორის? მე გამოვყოფდი რამდენიმე ძირითადს. პირველი, Netflow-ს აქვს მომხმარებლის მიერ მორგებული ველები sFlow-ის ფიქსირებული ველებისგან განსხვავებით. და მეორეც, და ეს არის ყველაზე მნიშვნელოვანი ჩვენს შემთხვევაში, sFlow აგროვებს ე.წ. განსხვავებით Netflow-ისა და IPFIX-ისთვის გამოუცდელისგან. რა განსხვავებაა მათ შორის?

წარმოიდგინე, რომ გადაწყვიტე წიგნის წაკითხვა"უსაფრთხოების ოპერაციების ცენტრი: თქვენი SOC-ის მშენებლობა, ოპერირება და შენარჩუნება”ჩემი კოლეგების - გარი მაკინტაირის, ჯოზეფ მუნიცისა და ნადემ ალფარდანის (წიგნის ნაწილი შეგიძლიათ ჩამოტვირთოთ ბმულიდან). თქვენ გაქვთ სამი ვარიანტი თქვენი მიზნის მისაღწევად - წაიკითხეთ მთელი წიგნი, გადახედეთ მას, შეჩერდით ყოველ მე-10 ან მე-20 გვერდზე, ან შეეცადეთ იპოვოთ ძირითადი ცნებების ახსნა ბლოგზე ან სერვისზე, როგორიცაა SmartReading. ასე რომ, unsampled ტელემეტრია კითხულობს ქსელის ტრაფიკის ყველა „გვერდს“, ანუ აანალიზებს მეტამონაცემებს თითოეული პაკეტისთვის. ნიმუშების ტელემეტრია არის ტრაფიკის შერჩევითი შესწავლა იმ იმედით, რომ შერჩეული ნიმუშები შეიცავს იმას, რაც გჭირდებათ. არხის სიჩქარიდან გამომდინარე, სინჯის ტელემეტრია გაიგზავნება ანალიზისთვის ყოველ 64-ე, 200-ე, 500-ე, 1000-ე, 2000-ე ან თუნდაც 10000-ე პაკეტში.

ინფორმაციული უსაფრთხოების მონიტორინგის კონტექსტში, ეს ნიშნავს, რომ ნიმუშის ტელემეტრია კარგად არის შესაფერისი DDoS შეტევების აღმოსაჩენად, სკანირებისთვის და მავნე კოდის გასავრცელებლად, მაგრამ შეიძლება გამოტოვოს ატომური ან მრავალპაკეტიანი შეტევები, რომლებიც არ იყო შეტანილი ანალიზისთვის გაგზავნილ ნიმუშში. უნიმუშო ტელემეტრიას ასეთი მინუსები არ გააჩნია. ამასთან, აღმოჩენილი თავდასხმების დიაპაზონი გაცილებით ფართოა. აქ მოცემულია მოვლენების მოკლე სია, რომელთა აღმოჩენა შესაძლებელია ქსელის ტელემეტრიის ანალიზის ხელსაწყოების გამოყენებით.

რა თქმა უნდა, ზოგიერთი ღია კოდის Netflow ანალიზატორი არ მოგცემთ ამის საშუალებას, რადგან მისი მთავარი ამოცანაა ტელემეტრიის შეგროვება და მასზე ძირითადი ანალიზის ჩატარება IT თვალსაზრისით. ნაკადზე დაფუძნებული ინფორმაციის უსაფრთხოების საფრთხის იდენტიფიცირებისთვის აუცილებელია ანალიზატორის აღჭურვა სხვადასხვა ძრავებითა და ალგორითმებით, რომლებიც გამოავლენს კიბერუსაფრთხოების პრობლემებს სტანდარტულ ან მორგებულ Netflow ველებზე დაყრდნობით, გაამდიდრებს სტანდარტულ მონაცემებს გარე მონაცემებით Threat Intelligence-ის სხვადასხვა წყაროდან და ა.შ.

ამიტომ, თუ არჩევანი გაქვთ, აირჩიეთ Netflow ან IPFIX. მაგრამ მაშინაც კი, თუ თქვენი მოწყობილობა მუშაობს მხოლოდ sFlow-თან, როგორც შიდა მწარმოებლები, მაშინ ამ შემთხვევაშიც კი შეგიძლიათ ისარგებლოთ უსაფრთხოების კონტექსტში.

2019 წლის ზაფხულში გავაანალიზე ის შესაძლებლობები, რაც აქვთ რუსულ ქსელური აპარატურის მწარმოებლებს და ყველა მათგანმა, NSG, Polygon და Craftway-ის გამოკლებით, გამოაცხადა მხარდაჭერა sFlow-ისთვის (მინიმუმ Zelax, Natex, Eltex, QTech, Rusteleteh).

შემდეგი კითხვა, რომელსაც თქვენ შეხვდებით, არის სად განხორციელდეს ნაკადის მხარდაჭერა უსაფრთხოების მიზნებისთვის? სინამდვილეში, კითხვა მთლად სწორად არ არის დასმული. თანამედროვე აღჭურვილობა თითქმის ყოველთვის მხარს უჭერს ნაკადის პროტოკოლებს. ამიტომ, სხვაგვარად ჩამოვაყალიბებდი კითხვას - სად არის ყველაზე ეფექტური ტელემეტრიის შეგროვება უსაფრთხოების თვალსაზრისით? პასუხი საკმაოდ აშკარა იქნება - წვდომის დონეზე, სადაც დაინახავთ მთელი ტრაფიკის 100%-ს, სადაც გექნებათ დეტალური ინფორმაცია ჰოსტებზე (MAC, VLAN, ინტერფეისის ID), სადაც შეგიძლიათ აკონტროლოთ კიდეც P2P ტრაფიკი ჰოსტებს შორის, რაც მნიშვნელოვანია მავნე კოდის აღმოჩენისა და გავრცელების სკანირებისთვის. ძირითადი დონეზე, თქვენ უბრალოდ ვერ იხილავთ ტრაფიკის ნაწილს, მაგრამ პერიმეტრის დონეზე ნახავთ თქვენი ქსელის მთელი ტრაფიკის მეოთხედს. მაგრამ თუ რაიმე მიზეზით თქვენს ქსელში გაქვთ უცხოური მოწყობილობები, რომლებიც თავდამსხმელებს საშუალებას აძლევს „შევიდნენ და გამოვიდნენ“ პერიმეტრის გვერდის ავლით, მაშინ მისგან ტელემეტრიის ანალიზი ვერაფერს მოგცემთ. ამიტომ მაქსიმალური დაფარვისთვის რეკომენდებულია ტელემეტრიის შეგროვების ჩართვა წვდომის დონეზე. ამავდროულად, აღსანიშნავია, რომ თუნდაც ვირტუალიზაციაზე ან კონტეინერებზე ვსაუბრობთ, ნაკადის მხარდაჭერა ასევე ხშირად გვხვდება თანამედროვე ვირტუალურ გადამრთველებში, რაც საშუალებას გაძლევთ აკონტროლოთ ტრაფიკი იქაც.

მაგრამ მას შემდეგ, რაც მე დავაყენე თემა, უნდა ვუპასუხო კითხვას: რა მოხდება, თუ მოწყობილობა, ფიზიკური თუ ვირტუალური, არ უჭერს მხარს ნაკადის პროტოკოლებს? ან მისი ჩართვა აკრძალულია (მაგალითად, სამრეწველო სეგმენტებში საიმედოობის უზრუნველსაყოფად)? ან მისი ჩართვა იწვევს პროცესორის მაღალ დატვირთვას (ეს ხდება ძველ აპარატურაზე)? ამ პრობლემის გადასაჭრელად, არსებობს სპეციალიზებული ვირტუალური სენსორები (ნაკადის სენსორები), რომლებიც არსებითად ჩვეულებრივი გამყოფებია, რომლებიც გადიან ტრაფიკს საკუთარ თავში და გადასცემენ მას ნაკადის სახით კოლექციურ მოდულში. მართალია, ამ შემთხვევაში ჩვენ ვიღებთ ყველა პრობლემას, რაზეც ზემოთ ვისაუბრეთ პაკეტის აღების ინსტრუმენტებთან დაკავშირებით. ანუ, თქვენ უნდა გესმოდეთ არა მხოლოდ ნაკადის ანალიზის ტექნოლოგიის უპირატესობები, არამედ მისი შეზღუდვები.

კიდევ ერთი წერტილი, რომელიც მნიშვნელოვანია გვახსოვდეს ნაკადის ანალიზის ინსტრუმენტებზე საუბრისას. თუ უსაფრთხოების მოვლენების წარმოქმნის ჩვეულებრივ საშუალებებთან დაკავშირებით ვიყენებთ EPS მეტრიკას (მოვლენა წამში), მაშინ ეს მაჩვენებელი არ ვრცელდება ტელემეტრიულ ანალიზზე; ის შეიცვალა FPS-ით (ნაკადი წამში). როგორც EPS-ის შემთხვევაში, მისი წინასწარ გამოთვლა შეუძლებელია, მაგრამ შეგიძლიათ შეაფასოთ ძაფების სავარაუდო რაოდენობა, რომელსაც კონკრეტული მოწყობილობა წარმოქმნის, მისი ამოცანის მიხედვით. ინტერნეტში შეგიძლიათ იპოვოთ ცხრილები მიახლოებითი მნიშვნელობებით სხვადასხვა ტიპის საწარმო მოწყობილობებისა და პირობებისთვის, რაც საშუალებას მოგცემთ შეაფასოთ რა ლიცენზიები გჭირდებათ ანალიზის ხელსაწყოებისთვის და როგორი იქნება მათი არქიტექტურა? ფაქტია, რომ IDS სენსორი შემოიფარგლება გარკვეული გამტარობით, რომელიც მას შეუძლია "გაიყვანოს", ხოლო ნაკადის კოლექტორს აქვს საკუთარი შეზღუდვები, რომლებიც უნდა იქნას გაგებული. ამიტომ, დიდ, გეოგრაფიულად განაწილებულ ქსელებში, როგორც წესი, რამდენიმე კოლექციონერია. როცა აღვწერე როგორ ხდება ქსელის მონიტორინგი Cisco-ს შიგნითმე უკვე მივაწოდე ჩვენი კოლექციონერების რაოდენობა - 21. და ეს არის ხუთ კონტინენტზე მიმოფანტული ქსელისთვის და დაახლოებით ნახევარ მილიონ აქტიურ მოწყობილობას შეადგენს).

ჩვენ ვიყენებთ საკუთარ გადაწყვეტას, როგორც Netflow მონიტორინგის სისტემას Cisco Stealthwatch, რომელიც კონკრეტულად უსაფრთხოების პრობლემების გადაჭრაზეა ორიენტირებული. მას აქვს მრავალი ჩაშენებული ძრავა ანომალიური, საეჭვო და აშკარად მავნე აქტივობის გამოსავლენად, რაც საშუალებას გაძლევთ აღმოაჩინოთ სხვადასხვა საფრთხის ფართო სპექტრი - კრიპტომაინინგიდან ინფორმაციის გაჟონვამდე, მავნე კოდის გავრცელებიდან თაღლითობამდე. ნაკადის ანალიზატორების უმეტესობის მსგავსად, Stealthwatch აგებულია სამ დონის სქემის მიხედვით (გენერატორი - კოლექტორი - ანალიზატორი), მაგრამ მას ავსებს მრავალი საინტერესო მახასიათებელი, რომელიც მნიშვნელოვანია განსახილველი მასალის კონტექსტში. პირველი, ის ინტეგრირდება პაკეტის დაჭერის გადაწყვეტილებებთან (როგორიცაა Cisco Security Packet Analyzer), რომელიც საშუალებას გაძლევთ ჩაწეროთ არჩეული ქსელის სესიები შემდგომი სიღრმისეული გამოკვლევისა და ანალიზისთვის. მეორეც, სპეციალურად უსაფრთხოების ამოცანების გასაფართოებლად, ჩვენ შევიმუშავეთ სპეციალური nvzFlow პროტოკოლი, რომელიც საშუალებას გაძლევთ „გაავრცელოთ“ აპლიკაციების აქტივობა ბოლო კვანძებზე (სერვერები, სამუშაო სადგურები და ა.შ.) ტელემეტრიაში და გადასცეთ იგი კოლექციონერს შემდგომი ანალიზისთვის. თუ თავის თავდაპირველ ვერსიაში Stealthwatch მუშაობს ნებისმიერი ნაკადის პროტოკოლით (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) ქსელის დონეზე, მაშინ nvzFlow მხარდაჭერა იძლევა მონაცემთა კორელაციას ასევე კვანძის დონეზე. მთელი სისტემის ეფექტურობის გაზრდა და უფრო მეტი შეტევის დანახვა, ვიდრე ჩვეულებრივი ქსელის ნაკადის ანალიზატორები.

ნათელია, რომ როდესაც ვსაუბრობთ Netflow ანალიზის სისტემებზე უსაფრთხოების თვალსაზრისით, ბაზარი არ შემოიფარგლება Cisco-ს ერთი გადაწყვეტით. შეგიძლიათ გამოიყენოთ როგორც კომერციული, ასევე უფასო ან საზიარო გადაწყვეტილებები. საკმაოდ უცნაურია, თუ Cisco-ს ბლოგზე მაგალითებად მოვიყვან კონკურენტების გადაწყვეტილებებს, ამიტომ რამდენიმე სიტყვას ვიტყვი იმის შესახებ, თუ როგორ შეიძლება გაანალიზდეს ქსელის ტელემეტრია ორი პოპულარული, სახელით მსგავსი, მაგრამ მაინც განსხვავებული ხელსაწყოების გამოყენებით - SiLK და ELK.

SiLK არის ინსტრუმენტების ნაკრები (ინტერნეტის დონის ცოდნის სისტემა) ტრაფიკის ანალიზისთვის, შემუშავებული ამერიკული CERT/CC-ის მიერ და რომელიც მხარს უჭერს, დღევანდელი სტატიის კონტექსტში, Netflow (მე-5 და მე-9, ყველაზე პოპულარული ვერსიები), IPFIX. და sFlow და სხვადასხვა კომუნალური საშუალებების (rwfilter, rwcount, rwflowpack და ა.შ.) გამოყენება ქსელის ტელემეტრიაზე სხვადასხვა ოპერაციების შესასრულებლად, რათა აღმოაჩინოს მასში არაავტორიზებული ქმედებების ნიშნები. მაგრამ გასათვალისწინებელია რამდენიმე მნიშვნელოვანი პუნქტი. SiLK არის ბრძანების ხაზის ინსტრუმენტი, რომელიც ახორციელებს ონლაინ ანალიზს ასეთი ბრძანებების შეყვანით (ICMP პაკეტების გამოვლენა 200 ბაიტზე მეტი):

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-ს. მასთან ანალიტიკოსის მუშაობის ციკლი ასე გამოიყურება:

• ჰიპოთეზის ფორმულირება. ჩვენ უნდა გვესმოდეს, რას ვეძებთ ქსელის ტელემეტრიაში, ვიცოდეთ უნიკალური ატრიბუტები, რომლითაც ჩვენ გამოვავლენთ გარკვეულ ანომალიებს ან საფრთხეებს.
• მოდელის აგება. ჰიპოთეზის ჩამოყალიბების შემდეგ, ჩვენ დავპროგრამებთ მას იგივე პითონის, ჭურვის ან სხვა ინსტრუმენტების გამოყენებით, რომლებიც არ შედის SiLK-ში.
• ტესტირება. დროა შევამოწმოთ ჩვენი ჰიპოთეზის სისწორე, რომელიც დადასტურებულია ან უარყოფილია SiLK უტილიტების გამოყენებით დაწყებული "rw", "set", "bag".
• რეალური მონაცემების ანალიზი. სამრეწველო ექსპლუატაციაში, SiLK გვეხმარება რაღაცის იდენტიფიცირებაში და ანალიტიკოსმა უნდა უპასუხოს კითხვებს „ვიპოვეთ თუ არა ის, რასაც ველოდით?“, „ეს შეესაბამება თუ არა ჩვენს ჰიპოთეზას?“, „როგორ შევამციროთ ცრუ დადებითი რაოდენობა?“, „როგორ შევამციროთ? ცნობადობის დონის გასაუმჯობესებლად?» და ასე შემდეგ.
• გაუმჯობესება. ფინალურ ეტაპზე ვაუმჯობესებთ იმას, რაც ადრე გაკეთდა - ვქმნით შაბლონებს, ვაუმჯობესებთ და ვაუმჯობესებთ კოდს, ვაფორმულებთ და ვაზუსტებთ ჰიპოთეზას და ა.შ.

ეს ციკლი ასევე გამოყენებული იქნება Cisco Stealthwatch-ზე, მხოლოდ ბოლო ავტომატიზირებს ამ ხუთ ნაბიჯს მაქსიმუმამდე, ამცირებს ანალიტიკოსის შეცდომების რაოდენობას და ზრდის ინციდენტების გამოვლენის ეფექტურობას. მაგალითად, SiLK-ში შეგიძლიათ გაამდიდროთ ქსელის სტატისტიკა მავნე IP-ების გარე მონაცემებით ხელნაწერი სკრიპტების გამოყენებით, ხოლო Cisco Stealthwatch-ში ეს არის ჩაშენებული ფუნქცია, რომელიც დაუყოვნებლივ აჩვენებს სიგნალიზაციას, თუ ქსელის ტრაფიკი შეიცავს ინტერაქციას IP მისამართებთან შავი სიიდან.

თუ ნაკადის ანალიზის პროგრამული უზრუნველყოფის „ფასიანი“ პირამიდაში უფრო მაღლა მიდიხართ, მაშინ აბსოლუტურად უფასო SiLK-ის შემდეგ იქნება shareware ELK, რომელიც შედგება სამი ძირითადი კომპონენტისგან - Elasticsearch (ინდექსირება, ძიება და მონაცემთა ანალიზი), Logstash (მონაცემების შეყვანა/გამომავალი). ) და კიბანა (ვიზუალიზაცია). SiLK-ისგან განსხვავებით, სადაც ყველაფერი თავად უნდა დაწეროთ, ELK-ს უკვე აქვს მრავალი მზა ბიბლიოთეკა/მოდული (ზოგი ფასიანი, ზოგს არა), რომელიც ავტომატიზირებს ქსელის ტელემეტრიის ანალიზს. მაგალითად, GeoIP ფილტრი Logstash-ში საშუალებას გაძლევთ დააკავშიროთ მონიტორინგის IP მისამართები მათ გეოგრაფიულ მდებარეობასთან (Stealthwatch-ს აქვს ეს ჩაშენებული ფუნქცია).

ELK-ს ასევე აქვს საკმაოდ დიდი საზოგადოება, რომელიც ავსებს ამ მონიტორინგის გადაწყვეტის გამოტოვებულ კომპონენტებს. მაგალითად, Netflow-თან, IPFIX-თან და sFlow-თან მუშაობისთვის შეგიძლიათ გამოიყენოთ მოდული ელასტიფრო, თუ არ ხართ კმაყოფილი Logstash Netflow მოდულით, რომელიც მხოლოდ Netflow-ს უჭერს მხარს.

ნაკადის შეგროვებისა და მასში ძიებისას მეტი ეფექტურობის მინიჭებისას, ELK ამჟამად არ გააჩნია მდიდარი ჩაშენებული ანალიტიკა ქსელის ტელემეტრიაში ანომალიებისა და საფრთხეების გამოსავლენად. ანუ, ზემოთ აღწერილი სასიცოცხლო ციკლის შემდეგ, თქვენ მოგიწევთ დამოუკიდებლად აღწეროთ დარღვევების მოდელები და შემდეგ გამოიყენოთ იგი საბრძოლო სისტემაში (იქ არ არის ჩაშენებული მოდელები).

რა თქმა უნდა, არის ELK-ის უფრო დახვეწილი გაფართოებები, რომლებიც უკვე შეიცავს რამდენიმე მოდელს ქსელის ტელემეტრიაში ანომალიების აღმოსაჩენად, მაგრამ ასეთი გაფართოებები ფული ღირს და აქ საკითხავია, ღირს თუ არა თამაში სანთლად - დაწერეთ მსგავსი მოდელი, იყიდეთ იგი. დანერგვა თქვენი მონიტორინგის ინსტრუმენტისთვის, ან იყიდეთ ქსელის ტრაფიკის ანალიზის კლასის მზა გადაწყვეტა.

ზოგადად, არ მინდა იმ დებატში შევიდე, რომ ჯობია ფულის დახარჯვა და ქსელის ტელემეტრიაში ანომალიებისა და საფრთხეების მონიტორინგისთვის მზა გადაწყვეტა იყიდო (მაგალითად, Cisco Stealthwatch) ან თავად გაარკვიო და იგივე დააკონფიგურირო. SiLK, ELK ან nfdump ან OSU Flow Tools ყოველი ახალი საფრთხისთვის (მე ვსაუბრობ მათგან ბოლო ორზე განუცხადა ბოლოჯერ)? ყველა ირჩევს თავის თავს და ყველას თავისი მოტივები აქვს ამ ორიდან რომელიმეს არჩევისთვის. მე უბრალოდ მინდოდა მეჩვენებინა, რომ ქსელური ტელემეტრია არის ძალიან მნიშვნელოვანი ინსტრუმენტი თქვენი შიდა ინფრასტრუქტურის ქსელური უსაფრთხოების უზრუნველსაყოფად და არ უნდა უგულებელყოთ იგი, რათა არ შეუერთდეთ იმ კომპანიების სიას, რომელთა სახელები მედიაში ეპითეტებთან ერთად არის მოხსენიებული. გატეხილი“, „საინფორმაციო უსაფრთხოების მოთხოვნებთან შეუსაბამო“, „არ ფიქრობენ მათი მონაცემებისა და მომხმარებლის მონაცემების უსაფრთხოებაზე“.

შეჯამებისთვის, მსურს ჩამოვთვალო ძირითადი რჩევები, რომლებიც უნდა დაიცვათ თქვენი შიდა ინფრასტრუქტურის ინფორმაციული უსაფრთხოების მონიტორინგის შექმნისას:

1. ნუ შემოიფარგლებით მხოლოდ პერიმეტრით! გამოიყენეთ (და აირჩიეთ) ქსელის ინფრასტრუქტურა არა მხოლოდ ტრაფიკის A წერტილიდან B წერტილამდე გადასატანად, არამედ კიბერუსაფრთხოების საკითხების გადასაჭრელად.
2. შეისწავლეთ ინფორმაციული უსაფრთხოების მონიტორინგის არსებული მექანიზმები თქვენს ქსელურ აღჭურვილობაში და გამოიყენეთ ისინი.
3. შიდა მონიტორინგისთვის უპირატესობა მიანიჭეთ ტელემეტრიულ ანალიზს - ის საშუალებას გაძლევთ გამოავლინოთ ქსელის ინფორმაციული უსაფრთხოების ყველა ინციდენტის 80-90%, ამასთან, გააკეთოთ ის, რაც შეუძლებელია ქსელის პაკეტების აღებისას და დაზოგეთ სივრცე ინფორმაციული უსაფრთხოების ყველა მოვლენის შესანახად.
4. ნაკადების მონიტორინგისთვის გამოიყენეთ Netflow v9 ან IPFIX - ისინი უფრო მეტ ინფორმაციას გვაწვდიან უსაფრთხოების კონტექსტში და საშუალებას გაძლევთ აკონტროლოთ არა მხოლოდ IPv4, არამედ IPv6, MPLS და ა.შ.
5. გამოიყენეთ უნივერსალური ნაკადის პროტოკოლი - ის უფრო მეტ ინფორმაციას გვაწვდის საფრთხეების გამოსავლენად. მაგალითად, Netflow ან IPFIX.
6. შეამოწმეთ დატვირთვა თქვენს ქსელურ აღჭურვილობაზე - შესაძლოა მან ვერ შეძლოს ნაკადის პროტოკოლის დამუშავებაც. შემდეგ განიხილეთ ვირტუალური სენსორების ან Netflow თაობის მოწყობილობის გამოყენება.
7. განახორციელეთ კონტროლი პირველ რიგში წვდომის დონეზე - ეს მოგცემთ შესაძლებლობას ნახოთ მთელი ტრაფიკის 100%.
8. თუ არჩევანი არ გაქვთ და იყენებთ რუსულ ქსელურ აღჭურვილობას, აირჩიეთ ისეთი, რომელიც მხარს უჭერს ნაკადის პროტოკოლებს ან აქვს SPAN/RSPAN პორტები.
9. შეუთავსეთ შეჭრის/შეტევის აღმოჩენის/პრევენციის სისტემები კიდეებზე და ნაკადის ანალიზის სისტემები შიდა ქსელში (ღრუბლების ჩათვლით).

რაც შეეხება ბოლო რჩევას, მინდა მოგცეთ ილუსტრაცია, რომელიც ადრე უკვე მოვიყვანე. თქვენ ხედავთ, რომ თუ ადრე Cisco-ს ინფორმაციული უსაფრთხოების სამსახური თითქმის მთლიანად ააშენებდა ინფორმაციული უსაფრთხოების მონიტორინგის სისტემას შეჭრის აღმოჩენის სისტემებისა და ხელმოწერის მეთოდების საფუძველზე, ახლა მათზე მოდის ინციდენტების მხოლოდ 20%. კიდევ 20% მოდის ნაკადის ანალიზის სისტემებზე, რაც ვარაუდობს, რომ ეს გადაწყვეტილებები არ არის ახირება, არამედ რეალური ინსტრუმენტი თანამედროვე საწარმოს ინფორმაციული უსაფრთხოების სამსახურების საქმიანობაში. უფრო მეტიც, თქვენ გაქვთ ყველაზე მნიშვნელოვანი რამ მათი განსახორციელებლად - ქსელური ინფრასტრუქტურა, ინვესტიციები, რომლის შემდგომი დაცვაც შესაძლებელია ქსელისთვის ინფორმაციის უსაფრთხოების მონიტორინგის ფუნქციების მინიჭებით.

მე კონკრეტულად არ შეხებივარ ქსელის ნაკადებში გამოვლენილ ანომალიებსა თუ საფრთხეებზე რეაგირების თემას, მაგრამ ვფიქრობ, უკვე გასაგებია, რომ მონიტორინგი მხოლოდ საფრთხის გამოვლენით არ უნდა დასრულდეს. მას უნდა მოჰყვეს პასუხი და სასურველია ავტომატური ან ავტომატური რეჟიმში. მაგრამ ეს ცალკე სტატიის თემაა.

დამატებითი ინფორმაცია:

• Cisco IOS Netflow-ის აღწერა
• Netflow მხარდაჭერის მატრიცა Cisco-ს სხვადასხვა გადაწყვეტილებებში
• Netflow-ის კონფიგურაციის სახელმძღვანელო Cisco-ს სხვადასხვა პლატფორმაზე
• sFlow საზოგადოება
• ლაბორატორია Stealtjwatch-ის, SiLK-ისა და ELK-ის გამოყენებით Netflow-ის უსაფრთხოების პერსპექტივიდან გასაანალიზებლად
• SiLK ვებსაიტზე
• სამასი გვერდიანი სახელმძღვანელო SiLK-ის გამოყენებისთვის უამრავი მაგალითით
• Logstash Netflow მოდული
• Cisco ნაბიჯ-ნაბიჯ სახელმძღვანელო Netflow ანალიზისთვის ELK-ში
• NetFlow v.9 Cisco ASA-ს ანალიზი Logstash-ის (ELK) გამოყენებით
• Cisco Stealthwatch Solution

PS. თუ თქვენთვის უფრო ადვილია ყველაფრის მოსმენა, რაც ზემოთ იყო დაწერილი, მაშინ შეგიძლიათ უყუროთ ერთსაათიან პრეზენტაციას, რომელიც საფუძვლად დაედო ამ შენიშვნას.

წყარო: www.habr.com