Для чего используется вывод данных мониторинга
Зачем мониторить трафик локальной сети?
Локальные сети с каждым годом становятся более технологичными, появляются новые сервисы и услуги, а вместе с ними развиваются и угрозы информационной безопасности (ИБ). Если проследить тенденцию развития систем мониторинга сети, то сначала появился мониторинг локальных машин, потом начали мониторить периметр, а впоследствии стало понятно, что всех этих мероприятий уже недостаточно.
Угрозы ИБ
Компания Positive Technologies провела исследование угроз ИБ в корпоративных сетях, в ходе которого был составлен рейтинг угроз:
Нарушение регламентов ИБ найден у 100% компаний
Подозрительная сетевая активность найдена у 90% компаний
Активность вредоносного ПО найдена у 68% компаний
Попытки эксплуатации уязвимости в ПО найдены у 31% компаний
Попытки подбора пароля найдены у 26% компаний
Попытки эксплуатации веб-уязвимостей найдены у 3% компаний
Зачем мониторить трафик локальной сети?
Рисунок 1
Имея доступ ко всему трафику в сети, анализируя его и сопоставляя, мы можем создать поведенческий профиль узла. В данный профиль будет входить следующая информация: какие протоколы использует, с какими сегментами сети взаимодействует, сколько трафика передает/получает и т.п. В случае выявления нетипичного поведения (аномалии) подается сигнал тревоги. Появление нового узла в сети не останется незамеченным.
Благодаря распределенной системе мониторинга трафика локальной сети возможно детально провести анализ распространения угроз ИБ, определив место их возникновения. Имея мощности для хранения трафика, можно произвести его ретроспективный анализ в будущем и разобраться в прошедшем инциденте. Также можно отслеживать распределение трафика в сети между узлами. Благодаря этому легко определить узкие места, неправильную конфигурацию оборудования или его неисправность. Полученные данные можно использовать для анализа и планирования дальнейшего развития сети.
Решения по защите от угроз ИБ, работающие с трафиком локальной сети
Для предотвращения нарушения регламентов ИБ, подозрительной сетевой активности, использования вредоносного ПО и эксплуатации уязвимости в ПО используются административные и технические меры. К административным относятся разграничение прав пользователей оконечного оборудования и введение списков разрешенного ПО. К техническим мерам – отключение уязвимых протоколов, правильная настройка сети (ограничение доступа к внешним ресурсам, блокировка портов и сервисов, отказ от использования незащищенных протоколов передачи данных). Рассмотрим системы организации мониторинга и защиты от угроз ИБ, изображенные на рисунке 2.
Рисунок 2
Для анализа трафика, взятого на периметре и в самой сети, на наличие используемых запрещенных протоколов и сервисов, используется Network Traffic Analysis (NTA) и Network Behavior Analysis (NBA). С помощью сравнения сигнатур и поведенческого анализа система NTA/NBA сможет распознать работу вредоносного ПО. Благодаря функциональным возможностям по работе с шифрованным трафиком и анализом протоколов возможно выявить аномалии в трафике. Поведенческий анализ и машинное обучение системы NTA/NBA позволит выявить странную активность в работе сети и попытки подбора учетных данных, которые порождают большое количество неуспешных аутентификаций. Данный факт будет виден в трафике.
Выявить угрозы безопасности сети и провести анализ поведения пользователей можно с помощью системы Data Leak Prevention (DLP), которая использует сбор данных с точек мониторинга локальной сети и с DLP-агентов, установленных на сетевом и абонентском оборудовании. Однако использование DLP-агентов может вызывать затруднения, ведь существуют устройства, на которые их невозможно установить. Причины могут быть разные – отсутствие доступа к ОС, нет поддержки ОС, конфликты с установленным ПО и прочие. Существует риск несанкционированного подключения к сети, когда пользователи могут подключать к сети свои личные устройства. В сети могут присутствовать контроллеры, различные датчики, которые генерируют большое количество трафика, но установить на такие устройства DLP-агенты невозможно. Стоит отметить, что вредоносное ПО может обходить мониторинг DLP-агента. В таких случаях анализ трафика локальной сети позволит системе DLP исключить описанные ограничения, наложенные DLP-агентами. Получая трафик с точек мониторинга локальной сети, система DLP сможет проводить анализ поведения всех устройств в сети в независимости, установлен ли на них DLP-агент или нет.
Система Security Information and Event Management (SIEM) собирает, анализирует логи различных приложений и на их основании может делать выводы о наличии угроз ИБ: подозрительный трафик и атаки, случаи заражения вредоносным ПО, нарушение регламентов ИБ пользователями. Работа системы SIEM со встроенным модулем NetFlow/sFlow заключается в следующем: трафик с точек мониторинга сети поступает на модуль NetFlow/sFlow, модуль NetFlow/sFlow анализирует трафик, формирует события и отправляет на SIEM, где проводится анализ и делается вывод о наличии угрозы ИБ. Таким образом, модуль NetFlow/sFlow собирает сетевую статистику по полученному трафику, а применение его совместно с SIEM позволяет осуществлять независимый от других приложений мониторинг сети на предмет угроз ИБ.
Система Intrusion Detection System (IDS) предназначена для обнаружения вторжений. Среди самых распространённых видов IDS можно выделить Perimeter Intrusion Detection Systems (PIDS) и Network Intrusion Detection System (NIDS). Система PIDS анализирует трафик, взятый с периметра сети (данный трафик может быть получен как с активного сетевого оборудования, так и с точки мониторинга на сети). Но не все угрозы ИБ можно выявить на периметре сети, они могут возникнуть внутри сети и не выходить наружу. Такие угрозы чаще всего возникают при подключении к сети несанкционированных устройств пользователей, подключении модемов, Wi-Fi адаптеров, заражение локальных устройств вирусами. Система NIDS получает и анализирует трафик с точек мониторинга, расположенных по всей локальной сети. Использование системы NIDS позволяет выявить все описанные угрозы ИБ.
Вместо заключения
Как мы видим, мониторинг трафика локальной сети необходим для эффективной защиты от рассматриваемых угроз ИБ. Комплексное использование мониторинга локальной сети, локальных машин и периметра сети даёт возможность достичь максимальной защиты от актуальных угроз ИБ и позволяет проводить анализ эффективности работы сети.
Зачем нужен комплексный мониторинг ИТ и бизнесу и КАК его внедрять?
На «Хабре» есть статьи о том, как внедрять мониторинг. В них описано, как надо и не надо организовывать систему мониторинга. Все эти статьи мы прочитали и поняли, что чего-то не хватает. Здесь не будет информации о важности разработки ресурсно-сервисной модели и о том, как уменьшить число ложно-позитивных сообщений о проблеме. Мы поделимся лайфхаками в работе команды, которые помогают реализовывать подобные проекты. Дальше будут такие рекомендации, которых в других статьях нет. Советы собраны на основе нашего опыта.
Комплексный мониторинг позволяет компаниям понять, где они теряют деньги
В компаниях всегда есть бизнес-подразделения. Они смотрят, где компания может больше зарабатывать и меньше тратить. Часто они обращают внимание на внутренние ИТ-системы. Если в ИТ-системах возникают инциденты, компания будет терять деньги. Например, рухнула платёжная система. Или регистрация стала сложнее, потому что её модифицировали. Или процесс оплаты неудобен для пользователей – в нем 10 кликов вместо 2.
Чем сложнее архитектура бизнес-приложения, тем больше людей необходимо для ее обслуживания: мониторить системы, анализировать и диагностировать инциденты, вникать, как эти инциденты влияют на клиентов. Итог – потрачены часы на выяснение причин сбоя, кто виноват и что делать. Пока это делается, клиенты страдают, деньги компании тратятся, а время устранения инцидентов растёт. Компании приходится смотреть на шлейф всех этих проблем, а не в светлое будущее. Дальше разберёмся, почему так происходит.
Есть кое-что, что мешает быстро обнаруживать источник проблем. Это разрозненность средств мониторинга. Все вместе они не дают единой картины для всех ИТ-компонентов, которые влияют на работу бизнес-приложения. Бывает так, что задачи похожи или даже одинаковые, но повторно их решают другие люди другими инструментами. Нередко приходится сверять друг с другом показатели одних и тех же метрик.
Что будет, если вот это все заставить работать вместе? О плюсах комплексного мониторинга – далее.
Преимущества комплексного мониторинга
Внедрение единого комплексного мониторинга для бизнес-процессов и ИТ-систем – логичное решение. Вот, что сможет делать компания, которая внедрила комплексный мониторинг:
Оперативно обнаруживать и решать проблемы в работе приложений до того, как они повлияют на пользователей;
Оценивать качество работы приложений на основе объективного мониторинга работы пользователей с приложением, а не обращаться в службу поддержки;
Анализировать клиентский опыт на протяжении всего процесса взаимодействия пользователя с системой;
Оценивать работу подрядчиков. Сравнивать их по количеству пользователей, которые выбирают данную платформу;
Получить единую точку доступа к общей картине состояния ИТ, возможность исследования «вглубь» – до сырых данных, а также анализировать корреляции.
Какие правила при внедрении комплексного мониторинга мы выработали
Совет №1: Выделите отдельную целостную команду разработки системы комплексного мониторинга.
Вот, кто должен быть в команде:
Специалист по Data Science
Бизнес- и системные аналитики должны быть вовлечены в проект на 100% и играть роль Product Owner’а. Они общаются с командой разработки основного продукта компании: от администраторов до руководителей. Бизнес- и системные аналитики пишут требования к системе мониторинга, планируют релизы и проводят UAT. Они обучают конечных пользователей системы мониторинга.
ИТ-роли в команде можно совмещать: разработчик системы мониторинга и инженер данных, администратор и DevOps инженер.
Совет №2: Заведите мониторинг препродуктивной среды. Потом синхронизируйте релизные циклы команды разработки основного продукта и команды разработки системы мониторинга
Бизнес ставит задачу разработчикам оптимизировать процесс взаимодействия пользователей с платформой. Например, процесс регистрации, оформления покупки, оплаты или возврата средств. Это влечет за собой изменение логов и логики построения KPI. Чтобы это сделать, нужно строить синхронные процессы изменения логики бизнес-процессов сайта и их KPI. Это важно, чтобы одним утром после релиза не обнаружить, что мониторинг не работает.
Совет №3: Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно
Мониторинг не универсален. Он много от чего зависит. Например, от архитектуры систем и взаимодействия между ними, от пользователей мониторинга и их видения.
В проектах разработки и внедрения системы комплексного мониторинга лучше использовать спринты и Agile-подход. Процесс разработки в нашей команде упрощенно выглядит так:
Определяем один показатель или один бизнес-процесс для мониторинга
Делаем небольшие выгрузки данных, достаточные для построения KPI. Чем больше выгрузок, тем лучше. Изучаем данные и определяем минимально достаточные источники для построения KPI.
Реализуем KPI на основе выгрузок и демонстрации пользователя мониторинга.
Дорабатываем источники данных и их подключения.
Разрабатываем KPI на основе живых данных.
Дальше релиз и получение обратной связи.
Потом планируем доработки на основе отзывов. Усложняем KPI путём подключения новых источников. Повторяем цикл.
Совет №4: Не планируйте ресурсные затраты на разработку мониторинга на основе объема систем, покрываемых мониторингом, или по количеству метрик и KPI, запланированных в разработку – вы все равно промахнетесь
Этот пункт вытекает из предыдущего. Наша команда начала разрабатывать мониторинг с зафиксированным объемом и количеством KPI. Сначала мы реализовали несколько дашбордов. Потом перешли на спринты и запланировали только набор бизнес процессов, которые будут мониториться. В результате (а может в процессе) перехода выработался процесс разработки KPI. Тот, что описан выше.
Совет №5: Дайте пользователям системы мониторинга больше свободы
Пускай у пользователей будет возможность исследовать данные, на основе которых вычисляется KPI. Ещё хорошо, если они смогут реализовывать простейшие вычисления и разрабатывать собственные метрики.
Продуктовая команда знает о своем продукте всё. При общении с системными аналитиками они могут упустить некоторые детали в работе или архитектуре систем. Если дать им доступ к изучению сырых данных, вы повышаете интерес конечных пользователей к мониторингу. Может так получиться, что продуктовая команда заметит отклонение показателей. Тогда она начнёт исследовать причины отклонений. Для этого команда сформирует новые метрики – так в будущем обнаруживать подобные проблемы будет проще. Команде мониторинга останется только формализовать метрику и запустить в работу.
Совет №6: Предусмотрите возможность отображения показателей на дашбордах в разрезе разных отрезков времени
Рассмотрим пример: мы разрабатываем бизнес KPI «Процент успешно завершенных регистраций пользователей на сайте». Для разработки KPI необходимо выбрать промежуток времени, в рамках которого мы будем наблюдать за показателем, а также на основе исторических данных определить уровни критичности. Уровень критичности, или важность проблем, определяет какой процент успешно завершенных регистраций считается обычным поведением (обычно обозначается зеленым цветом), или, когда процент успешно завершенных регистраций очень мал, сигнализирует о серьезных проблемах и обозначается красным цветом. В зависимости от промежутка времени, за который мы рассчитываем «Процент успешно завершенных регистраций», уровень критичности может быть разным. Процесс регистрации, как правило состоит из двух основных шагов: заполнение формы на сайте и подтверждение почты путем перехода по ссылке из письма. Некоторые пользователи выполняют регистрацию за пару минут, а другим – требуется вспомнить или восстановить забытый пароль от своей почты, что может занять более 5 минут. Если мы будем вычислять Процент успешных регистраций в рамках 5 минут, то мы «потеряем» пользователей, которые завершат регистрацию за 7-8 минут, что может значительно повлиять на Процент успешных регистраций, и система будет сигнализировать о проблеме.
Поэтому, разрабатывая KPI, мы ориентируемся и выбираем промежуток согласно оценке от бизнес аналитика, но обязательно добавляем другие промежутки времени в интерфейс, чтобы иметь возможность анализировать реальное поведение пользователей.
Совет №7: Настраивайте self-мониторинг, чтобы сохранить доверие к системе мониторинга
Совет №8: Используйте стандартный функционал продвинутой аналитики «из коробки». Например, «Автоматический ML»
Когда мы подключаем новый источник, мы уже знаем, какие поля и значения мы будем использовать. Ещё мы знаем, как будем строить KPI. По возможности, подгружаем в систему мониторинга исторические данные.
Однако, мы всегда прогоняем их через встроенные аналитические инструменты. Полученные показатели и графики оставляем «пожить» в течение какого-то времени и «пережить» инциденты. В половине случаев обнаруживаем новые зависимости от других показателей и интересные аномалии. На основе этого рождаются новые KPI.
Совет №9: Не спешите передавать дашборды и направлять оповещения группе поддержки второй и третьей линии
Есть показатели, разрабатываемые в рамках комплексного мониторинга, а есть – в рамках инфраструктурного. Они сильно различны по своей природе и имеют совершенно разные понятия «нормы» и отклонения от нее.
«Комплексные» KPI строятся на основе корреляции разнородных бизнес и ИТ-показателей. Как правило, этим показателям присваивают веса, которые определяют влияние на «комплексный» KPI. Поэтому сразу определить понятие «нормы» и построить грамотный алертинг бывает очень сложно.
Команда разработки мониторинга должна брать на себя роль поддержки на какое-то время при релизе каждого нового дашборда или KPI. Это позволит получать обратную связь без посредников и дорабатывать «на ходу». Оповещений не должно быть много.
Есть специалист поддержки, который отвечает за решение проблемы или поиск её причин. Действия этого специалиста должны быть максимально понятными и простыми. Написано множество статей про лечение событийной усталости и о том, как грамотно настраивать алертинг.
Совет №10: Ведите историю инцидентов
ИТОГ: Выгоды от внедрения системы мониторинга
Мы собрали их пять. Вот они:
Система комплексного мониторинга является зонтичным решением для существующих систем мониторинга. Она объединяет агрегированные данные из других узкоспециализированных систем.
Комплексное решение закрывает все «слепые зоны», не покрытые существующими в компании системами мониторингами – сбор сырых данных из систем источников в комплексный мониторинг.
Появляется единая точка для анализа данных и расследования причин инцидентов.
Бизнес-аналитики, маркетологи, администраторы и руководители подразделений смотрят на одни и те же данные.
Все события имеют корреляцию по времени.
Ещё раз все наши рекомендации кратко:
Комплексный мониторинг внедряет отдельная команда, а не участники продуктовой команды;
Не упускайте мониторинг препродуктивной среды;
Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно;
Для внедрения комплексного мониторинга больше подходит Agile методология и отсутствие жестко зафиксированного скоупа;
При планировании закладывайте ресурсы продуктовой команды на доработку и изменение источников данных;
Пользователи системы мониторинга должны иметь возможность «покрутить» данные и метрики;
Дашборды должны иметь фильтры для настройки отображения метрик в разрезе 5 минут и 1 часа;
Разрабатывайте мониторинг для системы мониторинга. Особое внимание стоит уделить точкам взаимодействия системы мониторинга с источниками данных;
Аналитический функционал системы мониторинга, поставляемый «из-коробки», может быть полезен;
Не спешите передавать дашборды и направлять оповещения группе поддержки второй и третьей линии. Пусть команда разработки мониторинга поживет с ними сама, чтобы понаблюдать за количеством оповещений и по возможности сократить их количество;
Ведите историю инцидентов.
Статью подготовил консультант компании Accenture Анастасия Астафьева
Что такое мониторинг в IT или почему админы стали больше спать?
Для чего нужен мониторинг IT?
Чтобы администраторы узнавали о проблемах в инфраструктуре раньше пользователей. Это, по сути, комплекс быстрой диагностики, который дает своевременное оповещение о проблемах и точную информацию, где и что случилось конкретно.
Пример: в 15:05 возникает проблема с почтой. Благодаря системе мониторинга админ уже в 15:07 видит, что на сервере не стартовала конкретная служба Windows, из-за чего не поднялся Exchange, и юзеры не получат писем. Без мониторинга ему бы позвонил руководитель около 17:00 и спросил бы, где письмо от партнёра, которое тот уже три раза отправил полчаса назад.
Как это было раньше?
Раньше информация о всей инфраструктуре (серверах, сетевых устройствах и так далее) просто собиралась. Роль «интеллектуального обработчика» лежала на администраторе: он, как пилот в кабине самолёта, должен был окинуть все приборы взглядом, чтобы понять картину. Ясно, что так мог не каждый.
Сейчас всё более автоматизированно и немного сложнее с точки зрения системы. Статусы стараются тесно привязать к бизнес-серверам, чтобы не было информации о мониторинге «в вакууме».
Также добавился мониторинг от лица конечного пользователя, когда эмулируются действия юзера — это робот, который раз в определённый промежуток времени запускает специальный скрипт: как будто пользователь бегает по менюшкам, что-то нажимает — и если у робота что-то не получается сделать, значит, и у человека не выйдет.
Плюс сейчас используется конфигурационная база данных: информация об объектах мониторинга представлена, как набор конфигурационных единиц. Каждый сервер, каждое сетевое устройство — это некая единица, все это хранится в централизованной базе данных. Такое представление позволяет потом интегрировать систему мониторинга с сервис-деском, системой управления активами и расширять функционал дальше.
Виртуализация
Раньше вся инфраструктура была физическая, все серверы представляли собой отдельные железки, находились в стойке, их можно было приходить и щупать, пока админ не видит. Сейчас инфраструктура часто состоит из виртуальных машин, когда сервер физически один, но на нём, например, крутится с десяток виртуальных. Это требует ряда тонкостей в настройке, зато дает массу преимуществ. Например, для нас, как для разработчиков систем мониторинга, это явный плюс: можно разместить всё в виртуальной среде. Система мониторинга – это ПО, которое состоит из нескольких модулей. И раньше под каждый модуль нужен был отдельный сервер. Когда железок было несколько, заказчик мог сказать, что, мол, слишком много оборудования требуется под вашу систему. Сейчас можно делать эти сервера виртуальными, и размещать их на одном физическом сервере. Это, к тому же, серьёзно снижает стоимость хороших систем мониторинга.
Пример того, как это работает
Есть один пример из жизни (имена и лица изменены). Итак, стоит HP Operations. Юзеры, привыкшие меняться файлами через FTP, в какой-то момент обнаруживают, что файл выложить не получается. Ткнулся первый юзер: сервер его не пустил. Пользователь подумал, что сбой временный и переслал файл по почте. Потом ткнулась ещё пара человек, у них тоже ничего не получилось, и кто-то написал тикет в поддержку. Саппорт начал разбираться, в чем дело. С виду все было хорошо: сервер был работоспособен, и, тем не менее, не сервис был недоступен. Искать такую проблему «на горячую» (при том, что останавливать работу других сервисов нельзя) — задача, в принципе, стандартная, но очень муторная без системы мониторинга. Админ же просто заглянул в список событий мониторинга и увидел много алертов от файрволов. Причём множественные обращения фиксировались снаружи. Очень быстро обнаружилась (сюрприз!) DDoS-атака на этот FTP, которая и была отсечена. Думаю, без мониторинга поиск проблемы был бы часа на три-четыре дольше, что могло повлечь дальнейшие осложнения.
Автоматизация
Ещё системы мониторинга умеют автоматически выполнять сервисные действия. Например, характерная ситуация: на сервере кончается место из-за временных файлов, приложения начинают тормозить. Админ заходит, чистит временные файлы, уходит — всё тип-топ до следующего повтора. Мониторинг умеет определять момент, например, когда 90% диска заполнено, генерировать событие – и запускать очистку самостоятельно в автоматическом режиме.
Поскольку система мониторинга умеет интегрироваться с сервис-десками, она может автоматически создавать тикеты о проблемах. То есть ниндзя из саппорта могут тихо и внезапно решить проблему еще до момента первого звонка.
Как это внедрить у себя?
Можно сказать, что система мониторинга, как и любая другая система большого объема, штука достаточно сложная. Внедрение обычно делается поэтапно, вне зависимости от того, делает это заказчик своими силами или же с помощью интегратора.
Сначала определяются объекты мониторинга (сетевое оборудование, серверы, приложения и т.д.). Потом выбираются критичные показатели для каждого объекта. Если взять слишком много данных, админы утонут в потоке оповещений о превышении предельных показателей, а если слишком мало – могут пропустить что-то важное. После этого нужно определиться с архитектурой, выбрать продукт, решение, вендора. Дальше уже можно приступать к настройке. Иногда делается пилотная зона-макет, а потом уже этот макет расширяется на всю инфраструктуру.
Готовые продукты
Системы мониторинга ориентированы на заказчиков разного уровня. Большие, сложные и дорогие решения требуют огромных трудозатрат по их разворачиванию и внедрению, но для крупного бизнеса это стоит того. Есть варианты поменьше и попроще для среднего и малого бизнеса, они представляют из себя некую коробку, которую достаточно легко внедрить. Самое известное решение из недорогих — Microsoft SCOM. Есть ряд open-source вариантов, они вообще бесплатны и требуют только довольно кропотливой настройки.
Для какого размера компании система полезна?
Предел там, где системный администратор не справляется с объемом работы и уже не может контролировать каждый сервер. В маленьких компаниях смысла в использовании таких систем обычно нет (или же можно брать частичные решения), а в компаниях среднего размера и крупных более-менее серьёзная система мониторинга обязательно должна быть. Такие системы начали развивать лет 10 назад, и сейчас почти все крупные заказчики IT-услуг уже внедрили у себя что-то подобное.
Что ещё умеет мониторинг?
Мониторинг кода
Обучение
Изначально системы требовали больших усилий для настройки пороговых значений (что считать аварийной ситуацией – когда диск заполняется на 90% или 95%?). Естественно, при большом количестве объектов мониторинга это было трудоёмкой задачей. Сейчас системы мониторинга умеют анализировать исторические данные, изучать поведение объектов и на основании этого строить так называемые «динамические пороги». То есть система мониторинга «обучается» и понимает, что является нормальным подведением объекта, а что говорит об аварии.
Что это поменяет для ИТ-отдела?
Администраторы смогут освободиться от рутинной работы и сконцентрироваться на более важных и интересных задачах. Они будут точно представлять, что происходит в системе на данный момент, т.е. инфраструктура будет прозрачна. Стиля работы, когда они вынуждены тушить пожары и постоянно чинить неисправности, не будет, можно будет обходить грабли заранее. Решение рутинных проблем можно будет автоматизировать. Конечно, непредвиденные аварии, все равно придется устранять «вручную», но это будет легче, так как будет точная диагностика.
Останется только читать Хабр и убеждать бухгалтерию, что если админ мало работает, то это невероятное счастье.