Flow протоколите като инструмент за наблюдение на сигурността на вътрешна мрежа

Когато става въпрос за наблюдение на сигурността на вътрешна корпоративна или ведомствена мрежа, мнозина го свързват с контрол на изтичането на информация и внедряване на DLP решения. И ако се опитате да прецизирате въпроса и да попитате как откривате атаки във вътрешната мрежа, тогава отговорът обикновено ще бъде споменаване на системи за откриване на проникване (IDS). И това, което беше единственият вариант преди 10-20 години, днес се превръща в анахронизъм. Има по-ефективен и на места единствен възможен вариант за наблюдение на вътрешната мрежа - да се използват поточни протоколи, първоначално предназначени за търсене на мрежови проблеми (отстраняване на неизправности), но с течение на времето трансформирани в много интересен инструмент за сигурност. Тук ще говорим за това какво представляват протоколите за поток и кои помагат за по-добро откриване на мрежови атаки, къде е най-добре да се приложи мониторинг на потока, какво да търсите при внедряването на такава схема и дори как да „повдигнете“ всичко това на домашно оборудване , ще говорим в рамките на тази статия.

Няма да се спирам на въпроса „Защо трябва да следим сигурността на вътрешната инфраструктура?“ Отговорът на това е донякъде очевиден. Но ако все пак искате още веднъж да се уверите, че днес не можете без него, гледам кратко видео с история за това как можете да влезете в корпоративна мрежа, защитена от защитна стена, по 17 начина. Следователно ще приемем, че разбираме, че вътрешният мониторинг е необходимо нещо и остава само да разберем как може да се организира.

Бих отделил три ключови източника на данни за мониторинг на инфраструктурата на ниво мрежа:

• „суров“ трафик, който улавяме и изпращаме за анализ на някои системи за анализ,
• събития от мрежови устройства, през които минава трафик,
• информация за трафика, получена чрез един от протоколите за потока.

Улавянето на необработен трафик е най-популярната опция сред хората по сигурността, тъй като исторически се появи и беше първата. Конвенционалните системи за откриване на проникване в мрежа (първата комерсиална система за откриване на проникване беше NetRanger от Wheel Group, закупена през 1998 г. от Cisco) просто бяха ангажирани с улавяне на пакети (и по-късни сесии), в които бяха търсени определени сигнатури („решаващи правила“ във 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 ви помага да идентифицирате промените в конфигурацията на самото устройство своевременно, компрометирайки го, но не е много подходящ за откриване на атаки в цялата мрежа.

Третият вариант е да се анализира информация за трафика, преминаващ през устройство, което поддържа един от няколко протокола за поток. В този случай, независимо от протокола, стрийминг инфраструктурата задължително се състои от три компонента:

• Поток на генериране или експортиране. Тази роля обикновено се присвоява на рутер, комутатор или друго мрежово устройство, което, преминавайки мрежов трафик през себе си, ви позволява да извличате ключови параметри от него, които след това се предават на модула за събиране. Например, протоколът Netflow на Cisco се поддържа не само от рутери и комутатори, включително виртуални и индустриални, но и от безжични контролери, защитни стени и дори сървъри.
• Поток на събиране. Като се има предвид, че в съвременната мрежа обикновено има повече от едно мрежово устройство, възниква проблемът със събирането и консолидирането на потоци, който се решава с помощта на така наречените колектори, които обработват получените потоци и след това ги предават за анализ.
• анализ на потока. Анализаторът поема основната интелектуална задача и, прилагайки различни алгоритми към потоците, прави определени заключения. Например, в рамките на ИТ функция, такъв анализатор може да идентифицира тесните места в мрежата или да анализира профила на натоварване на трафика, за да оптимизира допълнително мрежата. А за информационна сигурност такъв анализатор може да открие изтичане на данни, разпространение на зловреден код или DoS атаки.

Не мислете, че такава тристепенна архитектура е твърде сложна - всички други опции (с изключение може би на системите за наблюдение на мрежата, които работят с SNMP и RMON) също работят според нея. Имаме генератор на данни за анализ, който е мрежово устройство или самостоятелен сензор. Имаме система за събиране на аларми и имаме система за управление на цялата инфраструктура за наблюдение. Последните два компонента могат да бъдат комбинирани в рамките на един възел, но в повече или по-малко големи мрежи те обикновено са разпръснати върху поне две устройства, за да се осигури мащабируемост и надеждност.

За разлика от анализа на пакети, който се основава на изследването на заглавката и тялото на всеки пакет и сесиите, състоящи се от тях, анализът на потока разчита на събирането на метаданни за мрежовия трафик. Кога, колко, от къде и къде, как ... това са въпросите, на които мрежовият телеметричен анализ отговаря с помощта на различни протоколи за поток. Първоначално те бяха използвани за анализ на статистика и търсене на ИТ проблеми в мрежата, но след това, с развитието на аналитичните механизми, стана възможно да се прилагат към същата телеметрия за целите на сигурността. Струва си да се повтори тук, че анализът на потока не замества или замества улавянето на пакети. Всеки от тези методи има свой собствен обхват. Но в контекста на тази статия анализът на потока е най-подходящият за наблюдение на вътрешна инфраструктура. Имате мрежови устройства (независимо дали работят в софтуерно дефинирана парадигма или според статични правила), които една атака не може да заобиколи. Той може да заобиколи класическия IDS сензор, но не и мрежово устройство, което поддържа протокола за потока. Това е предимството на този метод.

От друга страна, ако имате нужда от доказателствена база за правоприлагащите органи или собствен екип за разследване на инциденти, не можете да минете без улавяне на пакети - мрежовата телеметрия не е копие на трафика, което може да се използва за събиране на доказателства; необходимо е за бързо откриване и вземане на решения в областта на информационната сигурност. От друга страна, използвайки телеметричен анализ, можете да „напишете“ не целия мрежов трафик (ако не друго, Cisco също участва в центрове за данни :-), а само този, който е включен в атаката. Инструментите за телеметричен анализ в това отношение ще допълнят добре традиционните механизми за улавяне на пакети, давайки команда за селективно улавяне и съхранение. В противен случай ще трябва да имате колосална инфраструктура за съхранение.

Представете си мрежа, работеща със скорост 250 Mbps. Ако искате да спестите целия този обем, тогава ще ви трябват 31 MB място за съхранение за една секунда пренос на трафик, 1,8 GB за една минута, 108 GB за един час и 2,6 TB за един ден. За да съхранявате ежедневни данни от мрежа с честотна лента от 10 Gb / s, ще ви трябват 108 TB място за съхранение. Но някои регулатори изискват да съхранявате данни за сигурност в продължение на години ... Записът при поискване, който анализира потока, ви помага да намалите тези стойности с порядъци. Между другото, ако говорим за съотношението на обема на записаните данни на мрежовата телеметрия и пълното улавяне на данни, то е приблизително 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 без извадка. Каква е разликата между тях?

Представете си, че решите да прочетете книгата “Център за операции по сигурността: Изграждане, експлоатация и поддръжка на вашия SOC” моите колеги Гари Макинтайър, Джоузеф Муниц и Надем Алфардан (можете да изтеглите част от книгата от линка). Имате три възможности да постигнете целта си – прочетете книгата цялата, прегледайте я набързо, спирайки на всяка 10-та или 20-та страница или опитайте да намерите преразказ на ключови концепции в блог или услуга като SmartReading. И така, телеметрията без извадка е четенето на всяка „страница“ от мрежовия трафик, тоест анализът на метаданните за всеки пакет. Извадковата телеметрия е селективно изследване на трафика с надеждата, че избраните проби ще бъдат това, от което се нуждаете. В зависимост от скоростта на канала, избраната телеметрия ще изпраща всеки 64-ти, 200-ти, 500-ти, 1000-ти, 2000-ти или дори 10000 XNUMX-ти пакет за анализ.

В контекста на мониторинга на информационната сигурност това означава, че телеметрията с извадка е много подходяща за откриване на DDoS атаки, сканиране, разпространение на злонамерен код, но може да пропусне атомни или многопакетни атаки, които не са включени в извадката, изпратена за анализ. Необработената телеметрия също няма такива недостатъци. използването на обхвата на откритите атаки е много по-широк. Ето малък списък от събития, които могат да бъдат открити с помощта на инструменти за мрежов телеметричен анализ.

Разбира се, някой анализатор на Netflow с отворен код няма да ви позволи да направите това, тъй като основната му задача е да събира телеметрия и да извършва основен анализ върху нея от гледна точка на ИТ. За да се идентифицират IS заплахите въз основа на потока, е необходимо анализаторът да се оборудва с различни двигатели и алгоритми, които ще идентифицират проблеми с киберсигурността въз основа на стандартни или персонализирани Netflow полета, ще обогатят стандартните данни с външни данни от различни източници на Threat Intelligence и т.н.

Ето защо, ако имате избор, спрете го на Netflow или IPFIX. Но дори ако вашето оборудване работи само с sFlow, като местните производители, тогава дори и в този случай можете да се възползвате от него в контекста на сигурността.

През лятото на 2019 г. анализирах възможностите, които имат руските производители на мрежово желязо, и всички те, с изключение на NSG, Polygon и Craftway, обявиха поддръжка за sFlow (поне Zelaks, Natex, Eltex, QTech, Rusteletech).

Следващият въпрос, който ще възникне пред вас, е къде да внедрите поддръжка на потока за целите на сигурността? Всъщност въпросът е поставен не съвсем правилно. На модерно оборудване протоколите за поток почти винаги се поддържат. Затова бих преформулирал въпроса по различен начин - къде е най-ефективният начин за събиране на телеметрия от гледна точка на сигурността? Отговорът ще бъде доста очевиден - на ниво достъп, където ще видите 100% от целия трафик, където ще имате подробна информация за хостове (MAC, VLAN, интерфейс ID), където можете да проследявате дори P2P трафик между хостове, които е критичен за откриване на сканиране и разпространение на зловреден код. На ниво ядро ​​може просто да не виждате част от трафика, но на ниво периметър ще виждате добре една четвърт от вашия мрежов трафик. Но ако по някаква причина имате външни устройства във вашата мрежа, които позволяват на нападателите да „влизат и излизат“, заобикаляйки периметъра, тогава анализът на телеметрията от него няма да ви даде нищо. Следователно, за максимално покритие се препоръчва да се активира събирането на телеметрия на нивото на достъп. В същото време си струва да се отбележи, че дори ако говорим за виртуализация или контейнери, съвременните виртуални комутатори също често поддържат поток, което ви позволява да контролирате трафика и там.

Но тъй като повдигнах темата, тогава трябва да отговоря на въпроса, какво ще стане, ако в крайна сметка оборудването, физическо или виртуално, не поддържа протоколи за поток? Или е забранено включването му (например в индустриални сегменти за осигуряване на надеждност)? Или включването му причинява високо натоварване на процесора (това се случва на по-стар хардуер)? За решаването на този проблем има специализирани виртуални сензори (сензор за поток), които по същество са обикновени сплитери, които пропускат трафика през себе си и го излъчват под формата на поток към модула за събиране. Вярно е, че в този случай получаваме цялата купчина проблеми, за които говорихме по-горе във връзка с инструментите за улавяне на пакети. Това означава, че е необходимо да се разберат не само предимствата на технологията за анализ на потока, но и нейните ограничения.

Още един момент, който е важно да запомните, когато говорим за инструменти за анализ на потока. Ако приложим метриката EPS (събитие в секунда, събития в секунда) по отношение на обичайните средства за генериране на събития за сигурност, тогава този индикатор не е приложим за телеметричен анализ; той се заменя с FPS (поток в секунда, поток в секунда). Както в случая с EPS, той не може да бъде изчислен предварително, но е възможно да се оцени приблизителният брой нишки, които дадено устройство генерира в зависимост от задачата си. В интернет можете да намерите таблици с приблизителни стойности за различни типове корпоративни устройства и условия, които ще ви позволят да прецените какви лицензи са ви необходими за инструменти за анализ и каква ще бъде тяхната архитектура? Факт е, че IDS сензорът е ограничен до определена честотна лента, която ще „издърпа“, а колекторът на потока има свои собствени ограничения, които трябва да се разберат. Следователно в големи, географски разпределени мрежи обикновено има няколко колектора. Когато описах как се наблюдава мрежата в Cisco, вече дадох броя на нашите колекционери - те са 21. И това е за мрежа, разпръсната на пет континента и наброяваща около половин милион активни устройства).

Използваме собствено решение като система за наблюдение на Netflow Cisco Stealth Watch, който е специално фокусиран върху решаването на проблеми със сигурността. Той има много вградени двигатели за откриване на аномална, подозрителна и очевидно злонамерена дейност, което ви позволява да откривате широк спектър от различни заплахи - от криптодобив до изтичане на информация, от разпространение на зловреден код до измами. Подобно на повечето анализатори на потока, 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. Работният цикъл на анализатора с него е следният:

• Формулиране на хипотеза. Трябва да разберем какво ще търсим в мрежовата телеметрия, да знаем уникалните атрибути, чрез които ще идентифицираме определени аномалии или заплахи.
• Изграждане на модел. След като сме формулирали хипотеза, ние я програмираме, използвайки същия Python, shell или други инструменти, които не са включени в 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. Не се ограничавайте само до периметъра! Използвайте (и изберете) мрежова инфраструктура не само за прехвърляне на трафик от точка А до точка Б, но и за решаване на проблеми с киберсигурността.
2. Проучете съществуващите механизми за наблюдение на информационната сигурност във вашето мрежово оборудване и ги използвайте.
3. За вътрешен мониторинг отдайте предпочитание на телеметричния анализ - той ви позволява да откриете до 80-90% от всички инциденти, свързани със сигурността на мрежовата информация, като същевременно правите това, което е невъзможно, когато улавяте мрежови пакети и спестявате място за съхранение за всички събития, свързани със сигурността на информацията.
4. За да наблюдавате потоците, използвайте Netflow v9 или IPFIX - те дават повече информация в контекста на сигурността и ви позволяват да наблюдавате не само IPv4, но и IPv6, MPLS и т.н.
5. Използвайте протокол за поток без извадки - той предоставя повече информация за откриване на заплахи. Например Netflow или IPFIX.
6. Проверете натоварването на вашето мрежово оборудване - то може да не успее да се справи и с обработката на протокола за потока. Тогава обмислете използването на виртуални сензори или устройство за генериране на Netflow.
7. Внедрете контрол на първо място на ниво достъп - това ще ви даде възможност да видите 100% от целия трафик.
8. Ако нямате избор и използвате руско мрежово оборудване, изберете такова, което поддържа протоколи за поток или има SPAN / RSPAN портове.
9. Комбинирайте откриване/предотвратяване на проникване/атака на границите и системи за анализ на потока във вътрешната мрежа (включително в облаците).

Що се отнася до последния съвет, бих искал да дам илюстрация, която вече дадох преди. Можете да видите, че ако по-рано услугата Cisco IS почти изцяло изгради своята система за мониторинг на IS, базирана на системи за откриване на проникване и методи за подписване, сега те представляват само 20% от инцидентите. Други 20% се падат на системите за анализ на потока, което предполага, че тези решения не са прищявка, а реален инструмент в дейността на услугите за информационна сигурност на модерно предприятие. Нещо повече, вие разполагате с най-важното за тяхното внедряване - мрежовата инфраструктура, инвестициите в която могат да бъдат допълнително защитени чрез присвояване на функции за наблюдение на информационната сигурност на мрежата.

Съзнателно не засегнах темата за реагиране на аномалии или заплахи, идентифицирани в мрежовите потоци, но мисля, че е ясно, че наблюдението не трябва да завършва само с откриването на заплаха. То трябва да бъде последвано от отговор и за предпочитане в автоматичен или автоматичен режим. Но това е тема за отделна статия.

Допълнителна информация:

• Описание на Cisco IOS Netflow
• Матрица за поддръжка на Netflow в различни решения на Cisco
• Ръководство за конфигуриране на Netflow на различни платформи на Cisco
• Общност sFlow
• Лаборатория за използване на Stealtjwatch, SiLK и ELK за анализиране на Netflow от гледна точка на сигурността
• Уеб сайт на SiLK
• Ръководство от XNUMX страници за използване на SiLK с много примери
• Logstash Netflow модул
• Ръководство стъпка по стъпка на Cisco за анализиране на Netflow в ELK
• Анализ на Cisco ASA NetFlow v.9 с Logstash (ELK)
• Решение Cisco Stealthwatch

PS. Ако ви е по-лесно да слушате всичко, което е написано по-горе, тогава можете да гледате едночасовата презентация, която е в основата на тази бележка.

Източник: www.habr.com