Коли йдеться про моніторинг безпеки внутрішньої корпоративної чи відомчої мережі, то у багатьох виникає асоціація з контролем витоків інформації та впровадженням DLP-рішень. А якщо спробувати уточнити питання та запитати, як ви виявляєте атаки у внутрішній мережі, то відповіддю буде, як правило, згадка систем виявлення атак (intrusion detection systems, IDS). І те, що було єдиним варіантом ще років 10-20 тому, сьогодні стає анахронізмом. Існує більш ефективний, а подекуди й єдиний можливий варіант моніторингу внутрішньої мережі — використовувати flow-протоколи, що спочатку призначені для пошуку мережевих проблем (troubleshooting), але згодом трансформувалися в дуже цікавий інструмент безпеки. Ось про те, які flow-протоколи бувають і які з них краще допомагають виявляти мережеві атаки, де найкраще впроваджувати моніторинг flow, на що звернути увагу при розгортанні такої схеми, і навіть як це все підняти на вітчизняному устаткуванні, ми і поговоримо у межах цієї статті.
Я не зупинятимусь на питанні “Навіщо потрібен моніторинг безпеки внутрішньої інфраструктури?” Відповідь на нього ніби й так зрозуміла. Але якщо ви хотіли б ще раз переконатися, що сьогодні без цього нікуди, невелике відео з розповіддю про те, як можна 17-ма способами проникнути в корпоративну мережу, захищену міжмережевим екраном. Тому вважатимемо, що ми розуміємо, що внутрішній моніторинг — потрібна штука і залишилося тільки зрозуміти, як його можна організувати.
Я виділив би три ключові джерела даних для моніторингу інфраструктури на мережному рівні:
- "сирий" трафік, який ми захоплюємо і подаємо на аналіз деяким системам аналізу,
- події з мережевих пристроїв, через які проходить трафік,
- інформація про трафік, яка отримується по одному з flow-протоколів.
Захоплення сирого трафіку - найпопулярніший у безпечників варіант, тому що він історично з'явився і найпершим. Звичайні мережеві системи виявлення атак (найпершою комерційною системою виявлення атак була NetRanger від компанії Wheel Group, куплена в 1998 році Cisco) якраз і займалися захопленням пакетів (а пізніше і сесій), в яких шукалися певні сигнатури (“вирішальні правила” у термінології ФСТЕК), що сигналізують про атаки. Зрозуміло, аналізувати сирий трафік можна не лише за допомогою IDS, але й за допомогою інших засобів (наприклад, Wireshark, tcpdum або функціонал NBAR2 у Cisco IOS), але їм зазвичай не вистачає бази знань, що відрізняє засіб ІБ від звичайного ІТ-інструменту.
Отже, система виявлення атак. Найстаріший і найпопулярніший метод виявлення мережевих атак, який непогано справляється зі своїм завданням на периметрі (будь-якому - корпоративному, ЦОДа, сегмента і т.п.), але пасує в сучасних комутованих і програмно-визначуваних мережах. У випадку з мережею, побудованою на базі звичайних комутаторів, інфраструктура сенсорів виявлення атак стає занадто великою – вам доведеться ставити по сенсору на кожне з'єднання з вузлом, атаки на який ви хочете моніторити. Будь-який виробник, звичайно, буде радий продати вам сотні та тисячі сенсорів, але думаю ваш бюджет не витримати таких витрат. Можу сказати, що навіть у Cisco (а ми розробники NGIPS) ми не змогли це зробити, хоча, здавалося б, питання ціни перед нами. стояти не повинен - це ж наше власне рішення. Крім того, виникає питання, а як підключати сенсор у такому варіанті? У розрив? А якщо сам сенсор буде виведено з ладу? Вимагати наявності bypass-модуля у сенсорі? Використовувати розгалужувачі (tap)? Все це подорожчає рішення і робить його непідйомним для будь-якого масштабу.
Можна спробувати "повісити" сенсор на SPAN/RSPAN/ERSPAN-порт та направити на нього трафік із необхідних портів комутатора. Цей варіант частково знімає проблему, описану в попередньому абзаці, але ставить іншу - SPAN-порт не може прийняти абсолютно весь трафік, який до нього спрямовуватиметься - йому не вистачить пропускної спроможності. Доведеться чимось жертвувати. Або частину вузлів залишити без моніторингу (тоді попередньо вам треба провести їхню пріоритезацію), або спрямовувати не весь трафік з вузла, а лише певного типу. У будь-якому випадку ми можемо пропустити якісь атаки. Крім того, SPAN-порт може бути зайнятий під інші потреби. У результаті нам доведеться переглянути існуючу топологію мережі і внести, можливо, до неї корективи, щоб охопити по максимуму вашу мережу наявним у вас числом сенсорів (і узгодити це з ІТ).
А якщо мережа використовує асиметричні маршрути? А якщо у вас впроваджено чи планується до впровадження SDN? А якщо вам треба моніторити віртуалізовані машини чи контейнери, трафік яких взагалі не доходить до фізичного комутатора? Ці питання не люблять виробники традиційних IDS, тому що не знають, як відповісти на них. Можливо, вони схилятимуть вас до того, що всі ці модні технології — хайп і вам він не потрібний. Можливо, вони будуть говорити про необхідність розпочати з малого. А можливо вони скажуть, що вам треба поставити потужну молотилку в центр мережі і направити весь трафік до неї за допомогою балансувальників. Який варіант вам не пропонували, вам потрібно самим чітко зрозуміти, наскільки він вам підходить. І лише після цього приймати рішення про вибір підходу до моніторингу ІБ мережної інфраструктури. Повертаючись до захоплення пакетів, хочу сказати, що цей метод продовжує залишатися дуже популярним і важливим, але його основне призначення - контроль кордонів; кордонів між вашою організацією та Інтернет, кордонів між ЦОДом та іншою мережею, кордонів між АСУ ТП та корпоративним сегментом. У цих місцях класичні IDS/IPS, як і раніше, мають право на існування і непогано справляються з поставленими завданнями.
Перейдемо до другого варіанта. Аналіз подій, що надходять з мережевих пристроїв, теж може бути використаний для виявлення атак, але не як основний механізм, так як він дозволяє детектувати тільки невеликий клас вторгнень. До того ж йому притаманна деяка реактивність — атака спочатку має відбутися, потім вона має бути зафіксована мережевим пристроєм, який у той чи інший спосіб сигналізуватиме про проблему з ІБ. Способів таких кілька. Це може бути syslog, RMON чи SNMP. Останні два протоколи для мережного моніторингу в контексті ІБ застосовуються тільки якщо нам необхідно виявити DoS-атаку на саме мережеве обладнання, оскільки за допомогою RMON та SNMP можна, наприклад, відстежувати завантаження центрального процесора пристрою або його інтерфейсів. Це один з "найдешевших" (syslog або SNMP є у всіх), але і найнеефективніший з усіх способів моніторингу ІБ внутрішньої інфраструктури - багато атак просто приховані від нього. Зрозуміло, їм не треба нехтувати і той же аналіз syslog допомагає вам своєчасно ідентифікувати зміни в конфігурації самого пристрою, компрометацію саме його, але виявляти атаки на всю мережу він не дуже підходить.
Третій варіант - це аналіз інформації про трафік, що проходить через пристрій, що підтримує один із кількох flow-протоколів. В даному випадку, незалежно від протоколу, інфраструктура роботи з потоками обов'язково складається із трьох компонентів:
- Генерація чи експорт flow. Ця роль зазвичай покладається на маршрутизатор, комутатор або інший мережний пристрій, який, пропускаючи через себе мережевий трафік, дозволяє виділяти ключові параметри, які потім передаються на модуль збору. Наприклад, у Cisco протокол Netflow підтримується не тільки на маршрутизаторах і комутаторах, включаючи і віртуальні та промислові, але і бездротових контролерах, міжмережевих екранах і навіть серверах.
- Збір flow. Враховуючи, що в сучасній мережі зазвичай більше одного мережевого пристрою, виникає завдання збору та консолідації потоків, що вирішується за допомогою так званих колекторів, які проводять обробку отриманих потоків і потім передають їх для аналізу.
- Аналіз flow. Аналізатор перебирає основне інтелектуальне завдання і, застосовуючи до потоків різні алгоритми, робить ті чи інші висновки. Наприклад, в рамках ІТ-функції такий аналізатор може виявляти вузькі місця мережі або аналізувати профіль завантаження трафіку для подальшої оптимізації мережі. А для ІБ такий аналізатор може виявляти виток даних, поширення шкідливого коду або DoS-атаки.
Не варто думати, що така триланкова архітектура дуже складна — всі інші варіанти (за винятком, можливо, системи мережевого моніторингу, що працюють з SNMP і RMON) також працює згідно з нею. У нас є генератор даних для аналізу, в якості якого виступає мережевий пристрій або сенсор, що окремо стоїть. У нас є система збору сигналів тривоги і система управління всією інфраструктурою моніторингу. Останні два компоненти можуть бути об'єднані в рамках одного вузла, але в більш-менш великих мережах вони зазвичай рознесені по двох, як мінімум, пристрої з метою забезпечення масштабування і надійності.
На відміну від аналізу пакетів, що базується на вивченні заголовка і тіла даних кожного пакета і сесій, що складаються з них, аналіз потоків спирається на збір метаданих про мережний трафік. Коли, скільки, звідки й куди, як… ось питання, куди відповідає аналіз мережевої телеметрії з допомогою різних протоколів flow. Спочатку вони використовувалися для аналізу статистики та пошуку ІТ-проблем у мережі, але потім, у міру розвитку аналітичних механізмів, їх стало можливим застосовувати до тієї ж телеметрії та з метою безпеки. Тут варто ще раз відзначити, що аналіз потоків не замінює та не скасовує захоплення пакетів. Кожен із цих методів мають свою сферу застосування. Але в контексті цієї статті саме аналіз потоків найкраще підходить для моніторингу внутрішньої інфраструктури. У вас є мережеві пристрої (і не важливо, працюють вони у програмно-визначуваній парадигмі або згідно зі статичними правилами), які атака пройти не може. Сенсор класичної IDS вона може обійти, а мережевий пристрій, що підтримує flow-протокол, немає. У цьому є перевага цього методу.
З іншого боку, якщо вам потрібна доказова база для правоохоронних органів або власної групи розслідування інцидентів, без захоплення пакетів вам не обійтися — мережева телеметрія не є копією трафіку, який можна використовувати при збиранні доказів; вона потрібна для оперативного виявлення та прийняття рішень у галузі ІБ. З іншого боку, використовуючи аналіз телеметрії, ви можете "писати" не весь мережевий трафік (якщо що, то Cisco та ЦОД займається :-), а тільки той, який бере участь в атаці. Засоби аналізу телеметрії у цьому плані добре доповнять традиційні механізми захоплення пакетів, даючи команду на вибіркове захоплення та зберігання. А якщо ні, то вам доведеться мати колосальну інфраструктуру зберігання.
Уявимо мережу, що працює на швидкості 250 Мбіт/сек. Якщо ви захочете зберігати весь цей обсяг, то вам знадобиться сховище на 31 Мб для однієї секунди передачі трафіку, 1,8 Гб - на одну хвилину, 108 Гб - на одну годину, і 2,6 Тб - на одну добу. Для зберігання добових даних з мережі з пропускною здатністю 10 Гбіт/сек вам знадобиться сховище на 108 Тб. Але ж деякі регулятори вимагають зберігати дані з безпеки роками… Запис «на вимогу», який вам допомагає реалізувати аналіз потоків, допомагає скоротити ці значення на порядки. До речі, якщо говорити про співвідношення обсягу даних мережної телеметрії, що записуються, і повного захоплення даних, то воно становить приблизно 1 до 500. Для тих же наведених вище значень, зберігання повної розшифровки всього денного трафіку складе 5 і 216 Гб відповідно (можна навіть на звичайну флешку записати ).
Якщо засоби аналізу сирих мережевих даних метод їх захоплення майже відрізняється від вендора до вендору, то разі аналізом потоків ситуація інша. Існує кілька варіантів flow-протоколів, про відмінності у яких необхідно знати саме у контексті безпеки. Найпопулярнішим є протокол Netflow, розроблений компанією Cisco. Існує кілька версій цього протоколу, що відрізняються за своїми можливостями і обсягом інформації, що записується про трафік. Поточна версія - дев'ята (Netflow v9), на базі якої було розроблено промисловий стандарт Netflow v10, також відомий як IPFIX. Сьогодні більшість мережевих вендорів підтримує саме Netflow або IPFIX у своєму обладнанні. Але є й різні інші варіанти flow-протоколів - sFlow, jFlow, cFlow, rFlow, NetStream і т.п., з яких популярнішим є sFlow. Саме він найчастіше підтримується вітчизняними виробниками мережевого обладнання через простоту реалізації. У чому ключові відмінності між Netflow, як стандарту став таким де-факто, і тим же sFlow? Ключових я виділив би кілька. По-перше, Netflow має поля, що настроюються користувачем на відміну від фіксованих полів в sFlow. А по-друге, і це найголовніше у нашому випадку, sFlow збирає так звану семпльовану телеметрію; на відміну від несемпльованої у Netflow та IPFIX. У чому між ними різниця?
Уявіть, що ви вирішили ознайомитись із книгою “” моїх колег — Гарі Макінтайра, Джозефа Муніца та Надема Альфардана (за посиланням ви можете завантажити частину книги). У вас є три варіанти досягти поставленої мети - прочитати книгу повністю, пробігти її очима, зупиняючись на кожній 10-й або 20-й сторінці, або спробувати знайти переказ ключових концепцій у будь-якому блозі або сервісі SmartReading. Так ось несемпльована телеметрія - це читання кожної "сторінки" мережного трафіку, тобто аналіз метаданих по кожному пакету. Семпльована телеметрія — це вибіркове вивчення трафіку, сподіваючись, що в обраних семплах виявиться те, що вам потрібно. Залежно від швидкості каналу, семпльована телеметрія віддаватиме для аналізу кожен 64-й, 200-й, 500-й, 1000-й, 2000-й або навіть 10000-й пакет.
У контексті моніторингу ІБ це означає, що семпльована телеметрія добре підходить для виявлення DDoS-атак, сканування, розповсюдження шкідливого коду, але може пропустити атомарні або багатопакетні атаки, які не потрапили в семпл, надісланий для аналізу. У незмепленої телеметрії таких недоліків немає і з неї. За допомогою спектр виявлених атак набагато ширше. Ось невеликий перелік подій, які можна виявляти за допомогою засобів аналізу мережевої телеметрії.
Зрозуміло, якийсь open source аналізатор Netflow вам цього не дозволить, тому що його основне завдання - зібрати телеметрію і провести над нею базовий аналіз з точки зору ІТ. Для виявлення на базі flow загроз ІБ необхідно оснастити аналізатор різними двигунами та алгоритмами, які і будуть на базі стандартних або користувацьких полів Netflow виявляти проблеми кібербезпеки, збагачувати стандартні дані зовнішніми даними від різних джерел Threat Intelligence і т.п.
Тому якщо ви маєте вибір, то зупиняйте його на Netflow або IPFIX. Але навіть якщо ваше обладнання працює тільки з sFlow, як у вітчизняних виробників, то навіть у цьому випадку ви можете отримати з нього користь у контексті безпеки.
Влітку 2019-го року я проводив аналіз можливостей, які є у російських виробників мережевого заліза і всі вони, за винятком NSG, Полігона та Крафтвея, заявляли про підтримку sFlow (як мінімум, Зелакс, Натекс, Елтекс, QTech, Рустелетех).
Наступне питання, яке постає перед вами, — де впроваджувати підтримку flow з метою безпеки? Насправді питання поставлене не зовсім коректно. На сучасному устаткуванні підтримка flow-протоколів є майже завжди. Тому питання я б переформулював інакше — де найефективніше збирати телеметрію з погляду безпеки? Відповідь буде досить очевидною - на рівні доступу, де ви побачите 100% всього трафіку, де у вас буде детальна інформація з хостів (MAC, VLAN, ID інтерфейсу), де ви зможете відстежувати навіть P2P-трафік між хостами, що критично для виявлення сканування та й поширення шкідливого коду. На рівні ядра частину трафіку ви можете просто не побачити, а на рівні периметра ви побачите добре, якщо чверть всього вашого мережевого трафіку. Але якщо з якихось причин у вас в мережі завелися сторонні пристрої, що дозволяють зловмисникам "входити і виходити", минаючи периметр, аналіз телеметрії з нього вам нічого не дасть. Тому для максимального охоплення рекомендується включати збір телеметрії на рівні доступу. При цьому варто відзначити, що навіть якщо ми говоримо про віртуалізацію або контейнери, то в сучасних віртуальних комутаторах також часто зустрічається підтримка flow, що дозволяє контролювати трафік і там.
Але якщо вже я порушив тему, то треба відповісти на запитання, а якщо все-таки обладнання, фізичне чи віртуальне, не підтримує flow-протоколи? Чи його включення заборонено (наприклад, у промислових сегментах для забезпечення надійності)? Чи його включення призводить до високого завантаження центрального процесора (таке буває на застарілому устаткуванні)? Для вирішення цього завдання існують спеціалізовані віртуальні сенсори (flow sensor), які по суті є звичайними розгалужувачами, що пропускають через себе трафік і транслюють його у вигляді flow модуль збору. Правда, в цьому випадку ми отримуємо всю купу проблем, про які ми говорили вище стосовно засобів захоплення пакетів. Тобто треба розуміти як переваги технології аналізу потоків, а й її обмеження.
Ще один момент, який важливо пам'ятати, говорячи про засоби аналізу потоків. Якщо стосовно звичайних засобів генерації подій безпеки ми застосовуємо метрику EPS (event per second, подій на секунду), то аналіз телеметрії цей показник неприменим; він замінюється на FPS (flow per second, потік за секунду). Як і у випадку з EPS, заздалегідь обчислити його не можна, але можна оцінити приблизну кількість потоків, яке генерує той чи інший пристрій залежно від його завдання. В Інтернеті ви можете знайти таблиці з приблизними значеннями для різних типів корпоративних пристроїв і умов, що дозволить вам прикинути, які ліцензії вам потрібні для аналізу та яка буде їх архітектура? Справа в тому, що сенсор IDS обмежений певною пропускною здатністю, яку він "витягне", так і колектор потоків має свої обмеження, які треба розуміти. Тож у великих, територіально-розподілених мережах колекторів зазвичай кілька. Коли я описував, , я вже наводив число наших колекторів - їх 21. І це на мережу, розкидану по п'яти материках і близько півмільйона активних пристроїв).
Як система моніторингу Netflow ми використовуємо наше власне рішення , яке спеціально орієнтоване вирішення завдань безпеки. У нього багато вбудованих двигунів виявлення аномальної, підозрілої та явно шкідливої активності, що дозволяє детектувати широкий спектр різних загроз - від криптомайнінгу до витоків інформації, від поширення шкідливого коду до шахрайства. Як і більшість аналізаторів потоків Stealthwatch побудований за трирівневою схемою (генератор - колектор - аналізатор), але він доповнений рядом цікавих особливостей, які важливі в контексті матеріалу, що розглядається. По-перше, він інтегрується з рішеннями щодо захоплення пакетів (наприклад, Cisco Security Packet Analyzer), що дозволяє записувати вибрані мережеві сесії для подальшого глибокого розслідування та аналізу. По-друге, спеціально для розширення завдань безпеки ми розробили спеціальний протокол nvzFlow, який дозволяє транслювати активність додатків на кінцевих вузлах (серверах, робочих станціях тощо) в телеметрію і передавати її на колектор для подальшого аналізу. Якщо у своєму одвічному варіанті Stealthwatch працює з будь-яким flow-протоколом (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) на рівні мережі, то підтримка nvzFlow дозволяє проводити кореляцію даних ще й на рівні вузла, тим самим. підвищуючи ефективність всієї системи і бачачи більше атак, ніж звичайні мережеві аналізатори потоків.
Зрозуміло, що, говорячи про системи аналізу Netflow з точки зору безпеки, ринок не обмежений єдиним рішенням від Cisco. Ви можете використовувати як комерційні, так і безкоштовні чи умовно безкоштовні рішення. Досить дивно, якщо я в блозі Cisco наводитиму в приклад рішення конкурентів, тому скажу пару слів про те, як мережева телеметрія може бути проаналізована за допомогою двох популярних, схожих за назвою, але все-таки різних інструментів - SiLK і ELK.
SiLK - це набір інструментів (the System for Internet-Level Knowledge) для аналізу трафіку, розроблений американським 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, але він не сильно полегшить ваше життя, вирішуючи лише функцію візуалізації, а не заміну аналітика. І це другий момент. На відміну від комерційних рішень, в які вже закладена солідна аналітична база, алгоритми виявлення аномалій, відповідні workflow і т.п., у випадку з SiLK ви все це повинні будете зробити самостійно, що вимагатиме від вас трохи інших компетенцій, ніж від використання вже готового на роботу інструментарію. Це погано і непогано - це особливість майже будь-якого безкоштовного інструменту, який виходить з того, що ви знаєте, що робити, а він вам тільки допоможе в цьому (комерційний інструментарій менш залежний від компетенцій його користувачів, хоча теж припускає, що аналітики розуміють хоча б основи проведення мережевих розслідувань та моніторингу). Але повернемось до SiLK. Цикл роботи аналітика з ним виглядає так:
- Формулювання гіпотези. Ми повинні розуміти, що ми шукатимемо всередині мережевої телеметрії, знатимемо унікальні атрибути, за якими виявлятимемо ті чи інші аномалії чи погрози.
- Побудова моделі. Сформулювавши гіпотезу, ми програмуємо її за допомогою того ж Python, Шелла або інших інструментів, що не входять до SiLK.
- Тестування. Настає черга перевірки правильності нашої гіпотези, яка підтверджується або спростовується за допомогою утиліт SiLK, що починаються з 'rw', 'set', 'bag'.
- Аналіз реальних даних. У промисловій експлуатації SiLK нам допомагає нам виявляти щось і аналітик повинен відповісти на запитання «Чи знайшли ми те, що передбачали?», «Чи відповідає це нашій гіпотезі?», «Як знизить кількість помилкових спрацьовувань?», «Як покращити рівень розпізнавання? » і т.п.
- Поліпшення. На фінальному етапі ми покращуємо зроблене раніше — створюємо шаблони, покращуємо та оптимізуємо код, переформулюємо та уточнюємо гіпотезу та ін.
Цей цикл буде застосовний і до того ж Cisco Stealthwatch, тільки останній п'ять кроків автоматизує по максимуму, знижуючи кількість помилок аналітика і підвищуючи оперативність виявлення інцидентів. Наприклад, у SiLK мережеву статистику ви можете збагатити зовнішніми даними по шкідливим IP за допомогою власноручно написаних скриптів, а в Cisco Stealthwatch - це вбудована функція, яка відразу відображає сигнал тривоги, якщо в мережевому трафіку зустрічається взаємодія з IP-адресами з чорного списку.
Якщо піти вище по піраміді «платності» ПЗ з аналізу flow, то за абсолютно безкоштовним SiLK йтиме умовно безкоштовний ELK, що складається з трьох ключових компонентів - Elasticsearch (індексація, пошук та аналіз даних), Logstash (введення/виведення даних) та Kibana ( візуалізація). На відміну від SiLK, де все доводиться писати самому, ELK вже має багато готових бібліотек/модулів (частина платна, частина немає), які автоматизують аналіз мережевої телеметрії. Наприклад, фільтр GeoIP в Logstash дозволяє прив'язати спостерігаються IP-адреси до їхнього географічного розташування (у того ж Stealthwatch це вбудована функція).
ELK також має досить велике ком'юніті, яке дописує відсутні компоненти для цього рішення з моніторингу. Наприклад, щоб працювати з Netflow, IPFIX та sFlow ви можете скористатися модулем , якщо вас не влаштовує Logstash Netflow Module, який підтримує лише Netflow.
Даючи більше оперативності зі збирання flow та пошуку в ньому, у ELK на даний момент відсутня багата вбудована аналітика з виявлення аномалій та погроз у мережній телеметрії. Тобто, виходячи з описаного життєвого циклу, вам доведеться самостійно описувати моделі порушень і потім вже користуватися ним у бойовій системі (вбудованих моделей там немає).
Є звичайно і більш наворочені розширення для ELK, в яких вже закладено деякі моделі виявлення аномалій у мережній телеметрії, але такі розширення коштують грошей і тут уже питання, чи варто шкурка вичинки - писати аналогічну модель самому, купувати її реалізацію для свого засобу моніторингу або купити готове рішення класу Network Traffic Analysis.
Взагалі не хочу вдаватися в полеміку, що краще витратити гроші і купити готове рішення для моніторингу аномалій і погроз у мережній телеметрії (наприклад, Cisco Stealthwatch) або розібратися самостійно і докручувати під кожну нову загрозу той же SiLK, ELK або nfdump або OSU Flow Tools ( я про останні два з них минулого разу)? Кожен вибирає для себе і кожен має свої мотиви вибрати будь-який з двох варіантів. Я ж хотів просто показати, що мережева телеметрія — це дуже важливий інструмент у забезпеченні мережевої безпеки своєї внутрішньої інфраструктури і нехтувати ним не варто, щоб не поповнити список компанія, чиє ім'я згадується у ЗМІ разом з епітетами «зламана», «що не дотрималася вимог ІБ », «яка не думає про безпеку своїх даних і даних клієнтів».
Підбиваючи підсумки, я хотів би перерахувати ключові поради, яким варто слідувати при вибудовуванні моніторингу ІБ своєї внутрішньої інфраструктури:
- Не обмежуйтесь лише периметром! Використовуйте (і вибирайте) мережну інфраструктуру не тільки для передачі трафіку з точки А до точки Б, але і для вирішення питань кібербезпеки.
- Вивчіть існуючі механізми моніторингу ІБ у вашому мережевому обладнанні та задіяйте їх.
- Для внутрішнього моніторингу віддавайте перевагу аналізу телеметрії - він дозволяє виявляти до 80-90% всіх мережевих інцидентів ІБ, роблячи при цьому те, що неможливо під час захоплення мережевих пакетів і заощаджуючи простір для зберігання всіх подій ІБ.
- Для моніторингу потоків використовуйте Netflow v9 або IPFIX – вони дають більше інформації в контексті безпеки та дозволяють моніторити не лише IPv4, а й IPv6, MPLS тощо.
- Використовуйте несемпльований протокол - він дає більше інформації для виявлення загроз. Наприклад, Netflow або IPFIX.
- Перевірте завантаження вашого мережевого обладнання – можливо, воно не впорається з обробкою ще й flow-протоколу. Тоді продумайте застосування віртуальних детекторів або Netflow Generation Appliance.
- Реалізуйте контроль насамперед на рівні доступу – це дасть вам можливість бачити 100% всього трафіку.
- Якщо ви не маєте вибору і ви використовуєте російське мережеве обладнання, то вибирайте те, яке підтримує flow-протоколи або має SPAN/RSPAN-порти.
- Комбінуйте системи виявлення/запобігання вторгнення/атак на кордонах та системи аналізу потоків у внутрішній мережі (у тому числі й у хмарах).
Щодо останньої поради, то я хотів би навести ілюстрацію, яку вже наводив раніше. Ви бачите, якщо раніше служба ІБ Cisco майже повністю вибудовувала свою систему моніторингу ІБ на базі систем виявлення вторгнень і сигнатурних методів, то зараз на їхню частку припадає всього 20% інцидентів. Ще 20% припадає на системи аналізу потоків, що говорить про те, що ці рішення — не дурощі, а реальний інструмент у діяльності служб ІБ сучасного підприємства. Тим більше, що у вас для їхнього впровадження є найголовніше — мережна інфраструктура, інвестиції в яку можна додатково захистити, поклавши на мережу ще й функції моніторингу ІБ.
Я спеціально не став торкатися теми реагування на виявлені в мережевих потоках аномалії чи загрози, але гадаю, що й так зрозуміло, що моніторинг не повинен завершуватися лише виявленням загрози. За ним має йти реагування і бажано в автоматичному або автоматизованому режимі. Але це вже тема окремого матеріалу.
Додаткова інформація:
ЗИ. Якщо вам простіше сприймати на слух все, що було написано вище, ви можете подивитися годинну презентацію, яка лягла в основу цієї нотатки.
Джерело: habr.com