С точки зрения обеспечения кибербезопасности перед нами обычно стоят всего три основные задачи, которые, конечно, потом разбиваются на более мелкие подзадачи и проекты, но, немного утрируя, в широком плане задач всего три:
- предотвращение угроз
- обнаружение угроз
- реагирование на угрозы.
Именно этот жизненный цикл борьбы с угрозами (ДО – ВО ВРЕМЯ – ПОСЛЕ) является основой деятельности службы информационной безопасности Cisco. Более того, я хотел бы обратить ваше внимание на то, что, поскольку в Cisco нет понятия периметра, мы стараемся реализовать три описанные выше задачи повсеместно – в дата-центрах, в облаках, в сегменте Wi-Fi, на мобильных устройствах сотрудников, в точках доступа в Интернет и, конечно же, в нашей внутренней сети, о мониторинге которой мы сегодня и поговорим.
Зачем вам нужно контролировать внутреннюю сеть?
По периметру у нас такого вопроса нет (расскажу как-нибудь в другой раз, почему у нас нет периметра), где мы устанавливаем MS?, IDS, средства фильтрации контента и многие другие средства сетевой безопасности.Почему внутренняя сеть должна быть исключением? Что, в него нельзя попасть снаружи, не пройдя через периметр? Да, разными способами.
Через собственный незащищенный Wi-Fi или через точку доступа соседней «Шоколадницы», к которой автоматически подключаются мобильные устройства ваших сотрудников, привыкших выпить чашечку горячего кофе или пообедать в кафе.
Через взломанный домашний ноутбук или планшет/смартфон руководства, которое затащило его в офис, чтобы «айтишники разобрались».
Через подброшенную в офисе флешку, загруженную необнаружимым вредоносным кодом.
Через зашифрованный канал клиент-серверного приложения, разработанного без учета вопросов безопасности.
Да через уязвимости в периметр в конце концов (не будем считать, что наша МС абсолютно неуязвима).
То есть внутренняя сеть нуждается в такой же защите, как и периметр, на котором многие организации неоправданно часто сосредотачивают свои усилия по защите, совершенно забывая об истине о самом слабом звене.
Разве IDS недостаточно?
Как предотвратить угрозы во внутренней сети Cisco я уже рассказывал сказал — для этого мы используем Cisco Identity Service Engine (ISE), который выполняет функцию распределенного MS?, превращая каждый свитч или маршрутизатор, а последних у нас всего более 40 тысяч, в часть внутреннего инструмента контроля доступа, который работает с динамическими политиками.Но одних лишь делимитации и предотвращения нам недостаточно.
Мы также должны отслеживать активность внутри разрешенных внутри соединений, а также следить за любыми нарушениями установленных внутренних правил доступа (все мы люди, все мы совершаем ошибки).
Мы бы установили систему обнаружения вторжений (IDS) по периметру и решили эту проблему.
Установить IDS во внутренней сети непросто, хотя Cisco была бы рада продать как можно больше наших датчиков Cisco NGIPS, тем более, что мы в очередной раз стали лидером на этом рынке по версии Gartner. Но зачастую это невозможно (исключая некоторые места внутри сети, например центры обработки данных или отдельные сегменты).
Это невозможно и с архитектурной точки зрения — не каждый порт свитча может иметь датчик IDS, не каждый транковый или спан-порт, к которому часто подключается IDS, будет тянуть трафик со всех портов свитча, а спан-порт не всегда свободен.
Это невозможно и с финансовой точки зрения — покупать высокопроизводительные датчики для каждого свитча или роутера очень дорого.
Даже в Cisco, несмотря на то, что мы сами производим NGIPS, мы не можем тратить много денег на мониторинг своей внутренней сети с помощью IDS — это довольно дорого.
Даже если вы попытаетесь использовать сплиттеры (отводы), они не решат всех проблем ни с архитектурной, ни с финансовой точки зрения.
Кроме того, если охранники на периметре как-то научились жить с айтишниками (сетевиками), то во внутренней сети конфликт продолжает тлеть.
Есть ли у нас альтернатива классической сетевой IDS для решения той же проблемы?
Как мониторить внутреннюю сеть без IDS?
Ответ будет утвердительным, и он называется Netflow. Это протокол, изначально разработанный Cisco с целью обнаружения сетевых проблем (диагностики неполадок), который затем стал стандартом де-факто для многих производителей сетей, которые либо поддерживали Netflow в своем оборудовании, либо создавали его клоны — Cflow, sFlow, Jflow, NetStream, Rflow и т. д. Но поскольку сегодня мы говорим о том, как осуществляется мониторинг внутренней сети Cisco, и мы используем собственное сетевое оборудование, то сосредоточимся только на протоколе Netflow, который сегодня доступен практически на любом нормальном сетевом оборудовании корпоративного уровня.(из всяких «домашних»).
Поддержки Netflow для устройств ждать не приходится - дома она просто не нужна и только усложнит и подорожает решение).
Итак, на сетевом оборудовании есть Netflow, через который проходит весь трафик, требующий контроля.
Это означает, что мы можем попытаться использовать его не только для обнаружения каких-либо проблем в сети, но и в целях информационной безопасности.
Кроме того, поддержка Netflow сетевым оборудованием позволяет не строить отдельную, оверлейную сеть для целей мониторинга, а позволяет использовать уже используемое сетевое оборудование для задач информационной безопасности.
Это, с одной стороны, защищает уже сделанные инвестиции и снижает стоимость решения по мониторингу, а с другой стороны, упрощает его как с точки зрения архитектуры, так и с точки зрения реализации – не нужно пытаться правильно направить потоки нам нужны для десятков или сотен датчиков IDS, которые в противном случае мы были бы вынуждены установить в своей сети.
Работа с Netflow дает нам еще одно, не сразу заметное преимущество.
В случае установки обычного IDS необходимо решить проблему направления трафика или его копии на датчики системы безопасности.
Если по каким-то причинам этого не произойдет (например, из-за изменения топологии или отсутствия пропускной способности у сенсора), то мы абсолютно ничего не увидим и будем думать, что в интересующем нас трафике атак нет. Сам датчик работает — просто не принимает и не анализирует нужный трафик.
С Netflow этого не происходит — мы видим все, что проходит через сетевое устройство, которым может быть не только маршрутизатор или свитч (в том числе виртуальный), но и, например, межсетевой экран (например, Cisco ASA поддерживает функцию NSEL , Netflow Security Event Logging, позволяющая транслировать сетевые потоки в виде Netflow для анализа соответствующим инструментом мониторинга).
Пришло время сделать пару комментариев относительно Netflow, который мы получили в результате использования Netflow в целях безопасности в сети Cisco. Во-первых, вам нужно знать, что Netflow можно использовать как для выборки, так и для выборки.
Различия между ними такие же, как если бы вы прочитали всю книгу «от корки до корки» или листали ее, останавливаясь лишь на каждой десятой странице.
Многие сетевые устройства поддерживают Netflow, но только выборочный, который не подходит в целях безопасности, поскольку мы видим лишь небольшую часть всего трафика, который нам необходимо отслеживать.
Поэтому обратите внимание, какой Netflow вы поддерживаете.
Выборка не подходит для целей информационной безопасности.
Во-вторых, необходимо знать, что обработка Netflow, особенно несемплированного, создает нагрузку на процессор сетевого устройства, что необходимо учитывать при планировании сети и построении системы мониторинга информационной безопасности на базе Netflow. Если ваши свитчи или роутеры уже работают на пределе своих возможностей и загрузка их процессора в обычном режиме достигает 80-90%, то вам стоит десять раз подумать, стоит ли включать на них Netflow, из-за чего производительность устройства обязательно упадет еще больше.
В этой ситуации есть два решения — обновление сетевой инфраструктуры (рано или поздно это все равно придется сделать) и использование устройств генерации Netflow. В Cisco мы использовали оба варианта.
В тех случаях, когда мониторинг Netflow был критической задачей и пришло время обновления, мы устанавливали новые коммутаторы и маршрутизаторы с аппаратной обработкой Netflow, которая не нагружает ЦП.
В остальных случаях мы использовали решение под названием FlowSensor, которое передавало пропущенный через себя трафик (аналог сплиттера, тапа) в Netflow, который передавался дальше для анализа нашей службой безопасности.
Что нам может сказать Netflow?
Существует несколько версий протокола Netflow, наиболее распространенными на сегодняшний день являются 5-я и 9-я.На основе последнего была разработана открытая спецификация IPFIX. Версия 5 протокола позволяет собирать следующую информацию о сетевом трафике:
- Адрес источника
- Адрес назначения
- Исходный порт для UDP и TCP
- Порт назначения для UDP и TCP
- Тип и код ICMP-сообщения
- номер IP-протокола
- Сетевой интерфейс (параметр ifindex SNMP)
- Стоимость типа услуги
- Параметры времени
- Объем переданных байтов и пакетов
- Значения TCP-флагов
- Информация о маршруте
- Информация об автономных системах.
Эта информация на первый взгляд поверхностна и отражает лишь то, что есть в заголовках сетевых сессий, но на самом деле, как мы уже пила В истории о технологии анализа зашифрованного трафика (ETA) во многих случаях этого достаточно для классификации и распознавания трафика.
Например, чрезмерно большое количество пакетов или байтов может указывать на DoS, большое количество адресов назначения за ограниченный интервал времени может указывать на сканирование сети и т. д. С помощью Netflow вы можете профилировать узлы и отслеживать отклонения от их стандартного поведения.
Как мы раньше контролировали нашу сеть?
Первоначально Cisco использовала для мониторинга бесплатные решения nfdump ( https://github.com/phaag/nfdump ) и OSU FlowTools (OSU — аббревиатура от Университета штата Огайо), которые позволяют работать с Netflow — фильтровать, выбирать и выполнять другие операции над сетевыми потоками.Оба решения довольно быстрые (могут обрабатывать несколько десятков гигабайт потоков в день), просты в использовании для тех, кто уже имеет опыт работы с классическими утилитами, такими как tcpdump, и гибки в фильтрации.
Но у этих инструментов также есть проблемы, которые можно разбить на три части.
Во-первых, это недостатки самих утилит, которые не позволяли, например, нормально агрегировать потоки, что часто приводит к их дублированию (представьте, что один и тот же поток проходит через 5 сетевых устройств — утилиты их тоже увидят и запишут).
5 раз).
Кроме того, nfdump и Flow Tools не позволяли отслеживать потерянные потоки, что приводило к ощущению ложной безопасности (перефразируя классическую фразу из фильма «ДМБ», «вы думаете, что видите поток, но на самом деле вы его не видите»).
т»).
В небольшой сети это не так критично, а вот в такой распределенной, как в Cisco, это стало создавать большие трудности по мере расширения внедрения системы мониторинга на новых площадках.
Во-вторых, любой проект с открытым исходным кодом имеет сложности, связанные с поддержкой, добавлением новых функций, расширением количества поддерживаемых версий Netflow и т. д. И, наконец, работа с nfdump и OSU Flow Tools требовала не только высококвалифицированного персонала, но и значительных усилий по автоматизации.
стандартные и рутинные задачи, связанные с расследованием инцидентов и реагированием на них.
Например, для обнаружения зараженных внутренних машин, взаимодействующих с командными серверами, необходимо создать и поддерживать соответствующий список в формате Cisco ACL, а затем подать его на вход утилит потоковой фильтрации, которые будут применять его к собранным данным.
Потоки Netflow.
Понятно, что для эффективной работы необходимо поддерживать в актуальном состоянии множество заранее созданных списков — злоумышленников, командных серверов, внутренних узлов, сегментированных по различным критериям и т. д. Однако сам последний список будет постоянно меняться из-за изменчивости.[mynfchost]$ head bot.acl ip access-list standard bot permit host 69.50.180.3 ip access-list standard bot permit host 66.182.153.176 [mynfchost]$ flow-cat /var/local/flows/data/2007-02-12/ft* | flow-filter -S bot.acl Start End Sif SrcIPaddress SrcP DIf DstIPaddress DstP 0213.08:39:49.911 0213.08:40:34.519 58 10.10.71.100 8343 98 69.50.180.3 31337 0213.08:40:33.590 0213.08:40:42.294 98 69.50.180.3 31337 58 10.10.71.100 83
динамической инфраструктуры Cisco. Еще одна проблема с использованием nfdump и OSU Flow Tools — невозможность распознать, кто инициировал то или иное соединение (это важно при расследовании), поскольку потоки однонаправленные.
Нам предстоит проделать дополнительную работу, чтобы понять, кто был первым в клиент-серверных соединениях.
Наконец, мы столкнулись еще с одной тонкостью, связанной с работой этих утилит. Они записывают только завершенные потоки, что может сделать невозможным быстрое отслеживание происходящих атак в режиме реального времени.
Например, злоумышленник уже просканировал сеть, скомпрометировал узел и проник в него, но ни nfdump, ни Flow Tools об этом пока не знают, так как они не зафиксировали сетевой поток.
Что мы используем сейчас?
После нашего опыта работы с nfdump и OSU Flow Tools, а также по мере перехода на IPv6 и Netflow версии 9, мы начали искать инструмент, который не имел бы тех недостатков, с которыми мы столкнулись.Это было решение Stealthwatch от Lancope, которое мы позже приобрели и стали частью Cisco. Stealthwatch построен по классической для любого анализатора архитектуре «датчик-сборщик-анализатор».
В качестве датчиков мы используем нашу сетевую инфраструктуру, которая пропускает весь внутренний сетевой трафик, транслирует его в Netflow и передает коллекторам для анализа.
Как я писал выше, сетевое оборудование не всегда поддерживает Netflow или способно его эффективно обрабатывать.
Для этой задачи мы используем отдельное оборудование или виртуальные датчики FlowSensor (всего их у нас 13).
Учитывая географически распределенную инфраструктуру Cisco, мы сводим все потоки не в один-два коллектора, а в целый распределенный кластер из 21 FlowCollector, которые ежедневно обрабатывают около 20 миллиардов потоков Netflow в поисках вредоносной активности в наших корпоративных магистралях и центрах обработки данных.
А консолей у нас всего две — сотрудники реагирования на инциденты Cisco имеют к ним доступ в соответствии со своими ролями.
Вариант использования
Пожалуй, главным препятствием на пути эффективного использования инструментов мониторинга Netflow с открытым исходным кодом в нашей сети (да и вообще) было отсутствие у них нормальной аналитики.У них есть гибкие возможности фильтрации и выборки, но без людей они не могут решить, есть ли проблема в сетевых потоках.
Stealthwatch был лишен этого недостатка — его ключевым преимуществом было наличие встроенной базы алгоритмов, позволяющей оценивать Netflow и распознавать в нем различные нарушения безопасности — сканирование сети, DoS, распространение вредоносного кода, утечку информации и т. д. 
Ключевые сценарии, в которых мы используем Stealthwatch (на самом деле их больше):
- проведение расследований
- Обнаружение взаимодействия C&C
- Обнаружение DoS-атак
- обнаружение утечки данных
- проверка настроек правил контроля доступа в Интернет.
Netflow — идеальный источник информации для расследования инцидентов, содержащий всю необходимую информацию о том, кто, что, когда и какие действия предпринял.
При этом вся эта информация сохраняется в базе данных и сотрудники службы реагирования могут делать к ней необходимые запросы, фильтруя и отбирая по нужным полям, быстро находя ответы на свои вопросы.
Интеграция с Cisco ISE предоставляет информацию, связанную не только с IP-адресами узлов, вовлеченных в инцидент, но и с учетными записями пользователей компании в Active Directory. Последняя функция не только удобна, но и значительно сокращает время сопоставления имени пользователя с его динамическим IP-адресом, который у него был в интересующий момент. Сокращение времени является решающим фактором успеха в расследовании инцидентов.
Второй случай, показывающий мощь Stealthwatch, — это обнаружение взаимодействия с серверами управления ботнетами и вредоносным ПО.
Казалось бы, это можно сделать по периметру, но давайте вспомним, с чего началась эта заметка.
Сегодня атаковать пользователя можно множеством разных способов и не всегда через периметр.
Что делать, если программа-вымогатель попала в сеть через незащищенный Wi-Fi и через него происходит утечка информации или получение обновлений вредоносного кода? Обнаружить это можно только путем мониторинга внутреннего сетевого трафика, и Stealthwatch здесь незаменим.
Раньше мы выполняли эту задачу с помощью nfdump, но у него было одно ограничение — нам приходилось вручную обновлять список IP-адресов командных серверов, собирая его из разных источников.
В случае со Stealthwatch эта задача решается автоматически — он регулярно загружает обновленные индикаторы компрометации, содержащие информацию о серверах управления.
Полезность этой функции в том, что она отслеживает устаревание адресов из списка и удаляет их при необходимости.
В случае с nfdump это приходилось делать вручную, что отнимало драгоценное время.
Обнаружение атак типа «отказ в обслуживании» — еще один популярный вариант использования, который мы используем в нашей сети.
Нельзя сказать, что подобные инциденты происходят регулярно, но они случаются.
«Потопы», «штормы», «лавины» запросов по различным сетевым и прикладным протоколам достаточно легко обнаруживаются с помощью Stealthwatch. Решения класса «Анализ сетевого трафика», в состав которого входит Stealthwatch, не обладают функционалом DLP и не способны отслеживать содержимое переписки по различным протоколам.
Однако в то же время они являются способами борьбы с утечками информации, для которых используется несколько иной принцип.
Учитывая, что в рамках Netflow можно отслеживать объем передаваемой информации, для каждого узла или пользователя мы можем установить определенные средние значения объема информации по разным протоколам, которые пользователь может скачать из Интернета или загрузить в Интернет. .
Допустим, для протокола HTTP этот показатель составит 100 МБ в сутки.
Соответственно, превышение этого значения будет считаться аномалией, а значительное превышение, например, в 5 раз и более, будет явным нарушением политики информационной безопасности.
Загрузка больших объемов данных в облачное хранилище может свидетельствовать о том, что пользователь пытается украсть конфиденциальную информацию.
Конечно, я не зря использую слово «может», поскольку это может быть и признаком вполне легальной деятельности, например, пользователь передает через облако новый дистрибутив ПО или комплект документов или видеообучение.
В любом случае повод для превышения пороговых значений данных должен вызывать расследование.
Еще один сценарий, который мы активно используем в нашей сети применительно к Stealthwatch, — это тестирование конфигурации правил контроля доступа для отслеживания несанкционированного трафика между сегментами.
Сегментация — один из самых полезных инструментов в арсенале служб информационной безопасности, который позволяет существенно сократить поверхность атаки, локализовать проблемы, быстро провести расследования и т. д. В нашей сети сегментация активно используется на базе сетевого оборудования, и она управляется Cisco ISE. С помощью Stealthwatch мы проверяем правильность настроек сегментации и видим трафик, который не должен появляться в конкретном сегменте.
Эта же функция позволяет проверить корректность настроек межсетевых экранов, расположенных по периметру и, возможно, пропускающих некоторый несанкционированный трафик.
По сути, Stealthwatch в таком случае использования превращается в дополнительный инструмент контроля за действиями администраторов.
Кто и где использует Stealthwatch?
Stealthwatch — это решение, которое, хотя и может использоваться сетевиками и ИТ-специалистами, предназначено для профессионалов в области безопасности.В Cisco этим занимается служба реагирования на инциденты Cisco CSIRT. Мы собираем данные со 180 ключевых сетевых устройств, установленных в центрах обработки данных, крупных корпоративных хабах и демилитаризованных зонах, получая примерно 180 тысяч потоков в секунду.
В одном из прошлых примечания Я уже писал о наличии API в наших продуктах.
Этот API также доступен в Stealthwatch и активно используется нашей командой реагирования на инциденты.
В частности, именно через API мы обновляем информацию об узлах, входящих в определенные группы.
Именно через API мы обновляем информацию о новых вредоносных узлах, взаимодействие с которыми отслеживается с помощью Stealthwatch. Используя API, мы интегрируем Stealthwatch с используемой нами платформой Threat Intelligence CRiTS с открытым исходным кодом.
Это позволяет нам при получении данных о новых индикаторах компрометации распространять эту информацию по всем средствам безопасности, интегрированным с CRiTS, через API. 
API позволяет нам собирать нужные нам события и потоки из Stealthwatch и передавать их в Splunk, который является основным инструментом мониторинга в Cisco, в том числе для проведения более детальных расследований.
Интересный опыт, которого я больше нигде не видел, — это концепция мобильного SOC (Security Operations Center), которую мы используем для мониторинга информационной безопасности на удаленных объектах, компаниях, которые мы покупаем, новых заводах, партнерах или при проведении расследований на объектах, которые мы покупаем.
не подключены к центральной системе мониторинга.
Мобильный SOC — это переносная стойка с оборудованием информационной безопасности, в которую входят не только Stealthwatch, но и Netflow Generation Appliance, Splunk, Firepower, Web Security Appliance и т. д. 
Планы развития
Мы не останавливаемся на достигнутом и планируем довольно активно развивать использование Stealthwatch в нашей инфраструктуре.Среди приоритетных планов:
- Продолжение интеграции с ISE не только для получения контекстной информации о хостах и пользователях, вовлеченных в инцидент, но и для реализации функции блокировки.
В будущем через ISE должна быть реализована комбинация Stealthwatch на уровне сети и AMP4E на уровне ПК, что позволит быстрее локализовать проблемы с информационной безопасностью.
- При обновлении до новой версии Stealthwatch автоматически появится функция Encrypted Traffic Analytics, позволяющая обнаруживать вредоносный код в зашифрованном трафике.
- Внедрение Stealthwatch Cloud для мониторинга облачных платформ IaaS и PaaS, которые активно используются в Cisco.
- Интеграция с AnyConnect, которая устанавливается у каждого сотрудника Cisco на его ноутбуке, смартфоне или ноутбуке, с целью получения данных об активности пользователей и приложений в формате Netflow и соотнесения этой информации с Netflow на сетевом уровне.
Вы можете отслеживать динамику изменения источников данных о происшествиях, происходящих в нашей стране.
Если раньше это были преимущественно сигнатуры атак от IDS, то сегодня на этот источник приходится лишь пятая часть всех инцидентов.
Еще пятая часть приходится на поведенческий анализ, 40% — на индикаторы компромисса.
Обнаружение остальных 20% инцидентов основано именно на Netflow. 
Дополнительная информация:
— История успеха Cisco Stealthwatch (Английский) — рассказ об использовании Stealthwatch в Cisco от руководителя CSIRT (видео, английский) — Страница Stealthwatch на веб-сайте Cisco Теги: #информационная безопасность #Сетевые технологии #Netflow #NTA #мониторинг сети #stealthwatch #stealthwatch #stealthwatch #nbad-
Обсерватория
19 Oct, 24 -
Подготовка К Ludum Dare
19 Oct, 24 -
Мы Столкнулись С Зависимостью От Смартфонов
19 Oct, 24 -
Что Такое Цифровая Рукописная Подпись (Dhs)
19 Oct, 24
