Назад в библиотеку
Вступление
Мониторинг информационной безопасности автоматизируют с использованием различных средств защиты: LM/SIEM, UBA/UEBA, IRP/SOAR, TIP, IDS/IPS, NTA, EDR. Объединение решений по классам одновременно и удобно, и условно. Системы одного типа отличаются не только количеством функций, но и своей философией. Вернёмся к этой идее позже.
Эти решения давно есть на рынке, но при внедрении мне, как сотруднику интегратора ИБ с большим практическим опытом, приходится сталкиваться с проблемами. Непонимание принципов работы этих инструментов приводит к попыткам «приготовить» их неправильно. Даже успешный пилот – не гарантия успешного внедрения.
Все участники рынка со стороны исполнителя – интеграторы, дистрибьюторы, сервис провайдеры (далее просто «интеграторы») и производители – коммерческие компании. Но конкуренция растёт и для беспечной старости уже недостаточно, как в нулевых, «как-то» закрыть прибыльный проект и убежать в закат. Техническая поддержка, модернизация и развитие, смежные проекты – основной источник дохода в наши дни. И он не существует без нахождения в едином понятийном поле, обмена знаниями и принятия стратегий совместно с заказчиками.
Статья рассчитана на тех, кто уже задумался о мониторинге ИБ, но ещё не погрузился в тему глубоко. Поэтому в ней не раскрываются такие базовые термины, как “событие”, “мониторинг”, “аналитик”, “пилот” (“пилотный проект”). Смысловые компоненты, вкладываемые в них, различаются в зависимости от того, кто их применяет. А хорошее описание с обоснованием, почему именно так их определяем, может потянуть на отдельную статью.
IRP или SOAR
Эти термины изначально говорили о разных системах: Incident Response Platform и Security Orchestration, Automation and Response (или Report). Но современные решения расположились по всей палитре между этими огнями и поэтому термины стали синонимами с широким диапазоном значений.
Основных функций у этих систем четыре:
Это специализированный сервис деск с функцией исполнения скриптов. Если у вас получится закрыть часть требований встроенным функционалом, вам необходимо получить более простые и стабильные способы работы со скриптами или дать службе мониторинга отдельный от ИТ инструмент со специализированным интерфейсом – это решения для вас.
Автоматизация способна ускорить реагирование на часть кейсов на 1-2 порядка. Но далеко не в каждом случае. Второй вариант использования – учёт действий аналитика. Если в инциденте участвует критичный актив, например, АСУ ТП, каждый шаг должен быть выполнен компетентным сотрудником, который ответственен за решение; ничего не должно быть пропущено, лог реагирования сохранён. Здесь будут преимущества от использования даже полностью «ручных» ранбуков. Таким образом систему можно применить к любому инциденту, сочетая оба варианта использования в разных пропорциях.
Результата использования IRP/SOAR:
EDR
Постепенно ряд производителей включает решения данного класса в состав уже существующих агентов – антивирусной защиты, систем защиты от утечек данных и т.д. Но оно несёт принципиально другой функционал – это дополнительная телеметрия (Detection в Endpoint Detection and Response) и возможности по реагированию (Response).
Телеметрия расширяет и унифицирует функции штатных журналов операционных систем. То, что раньше выявлялось SIEM на основе нескольких событий или не выявлялось вовсе, теперь фиксируется как единая запись агента EDR, обогащённая различными метаданными. И, насколько это возможно, не зависит от семейства и версии операционной системы, на которую установлен агент.
Реагирование средствами EDR делает процесс локальным и увеличивает его стабильность.
Так как к этому этапу у вас уже выстроены процессы обнаружения и реагирования, при оценке эффективности от внедрения EDR можно приложить решение к каждому из них и понять, какой плюс будет в конкретном случае и суммарно.
Результат использования EDR – расширенная телеметрия и локальное автоматизированное реагирование.
UBA или UEBA
Некоторые решения данного класса являются самостоятельными продуктами. Но многие вендоры SIEM предоставляют его в виде модуля. Кто-то говорит, что он заменяется набором правил (а кто-то даже заменяет). Какие возможности даёт это техническое средство?
Такой подход полезен в двух случаях:
Результат использования U(E)BA – выявление угроз методами с высоким ЛПС или методами, для которых невозможно создать и поддерживать простой алгоритм без ущерба для качества обнаружения инцидентов.
Log Management
Первым этапом может быть Log Management (LM) в виде специализированного решения или унифицированного варианта, типа Elastic Stack. Вы получите централизованное хранилище журналов событий различных источников, которые приведены к единой модели данных «из коробки» или под ваши требования рядом нехитрых манипуляций. Система обеспечивает простой, гибкий и производительный поиск по событиям, отчёты и визуальные панели (дашборды) на основе таких поисков.
Почему полезно начать с данного этапа, а не сразу переходить к SIEM? Это дешевле, а решаемые в процессе внедрения вопросы одинаковые. Учитывайте и стоимость поддержки от покупки до перевода в промышленную эксплуатацию – 30-60% от стоимости в год. Растянулся проект на два года – скупой платит дважды в прямом смысле слова.
Система может продолжить работать рядом с SIEM для экономии его лицензионной квоты одновременно с хранением дополнительных данных для расследований и Threat Hunting-а. Или её можно модернизировать в SIEM: некоторые производители предлагают такой вариант.
Какие задачи стоит решить при внедрении решения LM:
Результаты использования LM:
Следующий этап зрелости – переход от LM к SIEM. Мы пойдём более кратко: этот раздел уже создал нам базу.
Технические средства мониторинга ИБ
Время на прочтение
Мониторинг состояний и процессов функционирования автоматизированных систем
Мониторинг процессов функционирования автоматизированных систем, текущего состояния объектов АС и телекоммуникационного оборудования заключается в эффективном информационно- логическом взаимодействии источников и потребителей информации, в соответствии с этим, в состав каждого АРМ должна входить программа, являющаяся клиентом сервера мониторинга. Клиенты сервера мониторинга обеспечивают сбор и передачу информации о состоянии работоспособности и безопасности каждого АРМ, которая является структурированной и обрабатывается на сервере мониторинга по заданным алгоритмам.
Сервер мониторинга осуществляет контроль состояния АС на основании эталонных сведений. Визуальная интерпретация состояния АС и событий должна обеспечивать адекватную реакцию оператора подсистемы. На основании представленной текстовой, картографической и графической информации производится оповещение подразделений ОБИ и обслуживающего персонала АС о характере выявленных неисправностей при функционировании системы.
Для решения задач мониторинга функционирования АС возможно также использование встроенных в большинство операционных систем файлов регистрации. Анализ такой информации позволяет выявить некоторые особенности функционирования АС и предотвратить НСД. В частности, необходимо постоянно анализировать следующую информацию:
На основе эталонной модели взаимодействия открытых систем можно определить основные области мониторинга функционирования АС, которые представлены в таблице1.
Мониторинг функционирования АС целесообразно выполнять на основе специального протокола, который реализует функции сбора информации от управляемых ресурсов АС и передачу управляющего воздействия на управляемый ресурс. При этом, администратор является управляющим звеном либо всей АС, либо ее части.
Информационно-логическая структура типовой АС с подсистемой мониторинга, выполненной в соответствии со специальным протоколам представлена на рисунке 1.
Задачами, решаемыми клиентом мониторинга являются:
Кроме программ клиента и сервера сбора информации в подсистему мониторинга должно входить рабочее место оператора анализа информации, позволяющего подключать службы администрирования и эксплуатации к серверу сбора информации. В состав такого рабочего места должны входить средства генерации отчетов и справок-докладов, обобщения данных за необходимый срок, визуализации и отображения данных, позволяющие проводить анализ качества функционирования АС.
Алгоритм проведения мониторинга функционирования АС представлен на рисунке 2.
Мониторинг предусматривает последовательность применения следующих этапов:
1. При планировании мониторинга анализируется структура АС. По результатам анализа производится формирование списка контролируемых объектов и их параметров, а также определяются объемы выборки, способы накопления данных, в том числе периодичность мониторинга. Также на этапе планирования определяются коэффициенты важности параметров для контроля качества функционирования АС.
2. Мониторинг АС производится на основе сбора и обработки данных о функционировании системы безопасности, наличия и состояния информационных ресурсов, а также состояния технических средств.
3. Анализ результатов мониторинга должен производиться непрерывно в масштабе времени близком к реальному. Результаты анализа должны постоянно отражать состояние качества функционирования АС, каналов доступа к АС, соответствие технологических циклов обработки информации, принятым для системы, проведение регламента ОБИ и настроек СЗИ, целостность информации серверов БД, соответствие принятой номенклатуре запросов к серверам БД, соответствие внешних подключений и протоколов информационного взаимодействия АС, обнаружение информационных воздействий.
4. В ходе обработки результатов мониторинга АС должны быть получены данные об общем состоянии системы, о состоянии СОБИ, уязвимых местах, угрозах или фактах нарушения безопасности (компьютерные атаки, нарушения технологических циклов, попытках осуществления НСД), дефектах в ПО, сбоях в работе технических средств, нарушениях в работе СЗИ и так далее. Для обработки результатов мониторинга используются эталонные сведения об АС, средства визуализации, экспертного анализа.
5. Доведение результатов мониторинга качества функционирования АС осуществляется в целях оперативной реакции на факты обнаруженных воздействий на систему, угроз ее безопасности.
6. Оценка качества мониторинга производится в целях приведения его на уровень необходимый для поддержания обеспечения функционирования АС. При оценке качества мониторинга учитывается его соответствие структуре АС, полноте контроля параметров объектов АС, оперативности предоставления информации о состоянии АС и ее СОБИ.
Мониторинг качества функционирования АС позволят повысить эффективность функционирования подсистемы администрирования, а программная реализация предложенного алгоритма является модулем программы администратора, который предлагает отображать реальную обстановку выполнения процессов, событий и запросов в АС.
TIP
TIP или TI Platform – это средство обработки входящего Threat Intelligence. T I – это тема для отдельной статьи. Тут под TI будем понимать лишь малую его часть: перечни IOC – IP, FQDN, хэшей и т.д., считающихся злонамеренными; а под пользой TI – сокращение разрыва между первым обнаружением атаки где-то в мире и возможностью выявлять её у нас в инфраструктуре.
Разве нельзя IOC использовать в средствах защиты напрямую, зачем TIP? Этот класс решений предоставляет функционал управления TI – нормализация, обогащение, дедупликация, приоритезация, хранение, устаревание, удаление. Эти задачи могут реализовываться в ручном, автоматизированном или автоматическом режиме.
В систему приходит IOC и подвергается нормализации – приведению к единому набору полей заданного формата. С ним можно связать другие индикаторы – узнать FQDN по IP или всё семейство хэшей по исходному. Если IOC уже есть в базе – добавить атрибуты, например, что мы видели его в данных ещё одного источника в такое-то время. И присвоить ему оценку. Пришёл с трёх источников – достовернее, оценка выше; IOC в виде IP с источника X – уменьшаем оценку, IP от этих ребят быстро устаревают; индикатор ложный – обнуляем вручную. Оценка падает с течением времени – угроза либо теряет актуальность сама по себе (пирамида боли в действии), либо производители средств защиты блокируют её более рационально, чем по IOC.
Результат использования TIP – на средства защиты, в том числе в систему мониторинга, попадает более качественный, однозначно трактуемый и актуальный TI. А перечни IOC сокращаются на порядок, что позволяет повысить эффективность средств защиты, их использующих.
IDS или IPS
Этот класс решений скорее всего уже внедрён вами как отдельное средство защиты. Он позволяет анализировать копию трафика (Detection в Intrusion Detection Systems) или блокировать вредоносную активность (Prevention). Современные решения работают в гибридном режиме. Это аналог антивируса для сети. Основным методом обнаружения угроз являются сигнатуры, от обновления которых производителем или сообществом (в случае opensource решения) зависит эффективность работы системы. Специалисту или даже отделу сложно угнаться за скоростью обновления такой низкоуровневой логики при самостоятельной разработке. При этом основных сетевых протоколов несколько десятков, что делает решение «из коробки» довольно эффективным. По крайней мере, не так сильно зависящим от инфраструктуры, как хостовые средства защиты.
Пользовательские сигнатуры позволяют часть логики корреляции, относящейся к сети, вынести во внешнее относительно SIEM устройство. Это отлично дополняет SIEM, даже если он анализирует копию трафика.
Результат использования IDS/IPS:
SIEM
Переход от LM к системам класса Security Information and Event Management требуется в двух случаях:
Дополнительно вы получите:
Задачи на этом этапе следующие:
Обе задачи решаем итерационно. Хороший показатель – 15 инцидентов на смену аналитика. Достигли его – закручиваем гайки дальше.
Начинаем оценивать эффективность расследования – время на приём в работу инцидента, время на реагирование, время на устранение последствий и т.д. И пытаться этой эффективностью управлять – что мешает работать быстрее, где основные задержки?
Результаты использования SIEM:
Какой шаг сделать дальше? Тут лучших практик нет. Следующие этапы могут идти последовательно в любом порядке, параллельно или вовсе отсутствовать.
Что нам стоит SOC построить
Чем выше бюджет проекта, чем больше проект политизирован, тем сложнее изменить его вводные. Но для решения вопросов безопасности тоже действует принцип Парето. Добивать самые трудоёмкие 1-5-10% договора, которые не будут заметны в общем результате, не выгодно ни одной из его сторон. Проект лучше разбивать на этапы, а не гнаться за постройкой условного SOC с нуля. Это позволит учесть опыт предыдущих стадий и минимизировать риски по реализации нереализуемого, а часто и не нужного.
Итоговые цели нужно как ставить, так и пересматривать. А когда они зафиксированы в договоре, это практически невозможно. Например, база данных, с которой по грандиозному плану будут собираться события аудита, упадёт под дополнительной нагрузкой, вызванной этим самым аудитом. Но в техническое задание уже заложено требование по написанию ранбука на основе данных источника и реализации его в IRP. Переходим к правкам по ходу пьесы?
Декомпозицию на этапы можно производить вплоть до подключения «вот этих 5 видов источников» или создания «вот этих 10 сценариев и ранбуков к ним». Главное – это не полнота внедрения, а полнота использования того, что внедрено. Обосновать модернизацию эффективного решения проще, чем того, которое всплывает два раза в год в негативном контексте и стоит в десять раз дороже.
Если не знаете, что точно хотите и можете получить от автоматизации – просите пилотный проект. Но если не понимаете, что вам надо «без автоматизации» – от кого будете защищаться, куда и как ему было бы интересно проникнуть, что вам с этим делать – преимуществ от пилота будет мало. В технической части вы, вероятно, совершите скачок. Но подходит ли вам конкретный продукт – сказать будет сложно. Тут нужен консалтинг, а не внедрение технических решений. Пока вы не определитесь, что хотите автоматизировать, выбор конкретной системы не будет обоснованным. То, что показалось достаточным в ходе сегодняшнего пилота, завтра придётся подпирать костылями.
Пилот должен проводиться в рамках разумного. Я знаю организацию, которая столкнулась с невозможностью масштабирования после закупки. Не первый раз просят пилот, в котором у SIEM 30 графических панелей, 40 видов источников, 50 правил корреляции и 60 отчётов. Сделайте, а мы подумаем, покупать или обойдёмся. Интересы сторон должны сходиться. В той же части масштабирования можно согласовать решение с производителем и, например, заручиться от него гарантийным письмом.
Мониторинг в ИТ, как организовать работу
В данной статье хочу поделиться своим опытом организации работы системы мониторинга ИТ. Здесь будет рассмотрен один из возможных вариантов решения именно организационных задач, технические аспекты современных систем мониторинга обсуждаться не будут. Хочу сразу уточнить, что объектами мониторинга в моем случае являются исключительно компоненты ИТ, это: серверы, операционные системы, базы данных, транзакции и т.д.
Каждый раз в своей профессиональной деятельности, решая задачу построения комплексной системы мониторинга ИТ, я стараюсь придерживаться этого подхода, что позволяет заказчику получать качественно функционирующею систему мониторинга. Подход универсален, убежден, что он может найти свое применение и не на ИТ-шном поприще.
Как бывает
По роду своей деятельности, часто приходится сталкиваться с системами мониторинга, которые после внедрения равномерно покрываются толстым слоем пыли, а те для кого системы создавались благополучно забывают об их существовании, и только трудолюбивые серверы добросовестно продолжают потреблять электроэнергию ЦОДов.
И еще! что примечательно — программное обеспечение, используемое в подобных «горе» системах, самое современное, самое дорогущее и претензий к техническим недостаткам вообще никаких быть не может. А вот системный администратор как получал уведомления о сбоях, используя свой годами проверенный скрипт, так и по сей день получает! Картину с администратором могу дополнить следующими знакомыми синдромами:
Для чего же нужен мониторинг
Чтобы подготовить читателя для дальнейшего чтения, хочу добавить несколько определений:
Система мониторинга – система, которая обнаруживает отклонение наблюдаемого параметра от заданной нормы и в результате выполняет определенное действие.
Задачи мониторинга:
Я так же убежден, что современная система мониторинга в ИТ обязательно должна обеспечивать большее количество функций, например: сбор и хранение значений отслеживаемых параметров, прогнозирование возможных сбоев, автоматическое обнаружение компонентов инфраструктуры и т.д. Но выполнение двух основных функций (Обнаружение и Действие) делает систему именно системой мониторинга.
Еще пара определений:
Заказчик – лицо, заинтересованное в получении услуг мониторинга.
Провайдер – лицо, предоставляющее услугу мониторинга.
Определение правил игры (регламент)
Так кто же такой Заказчик – это, как правило, человек ответственный за функционирование того или иного сервиса, программного обеспечения или даже просто сервера в рамках организации, именно с него спрашивают за качество функционирования перечисленных объектов.
Провайдер имеет возможность организовать мониторинг для Заказчика, необходимых объектов их параметров для своевременного обнаружения или предотвращения сбоя.
И так! Необходимо определить, некие правила взаимодействия между Заказчиком и Провайдером. Проработка этого вопроса является необходимой мерой для создания комфортной среды взаимодействия, ведь Заказчик является лицом ответственным и ему необходимо понимать, каким образом будет распределяться ответственность между ним и Провайдером мониторинга.
Еще раз хочу отметить в том или ином виде, но регламент должен быть!
Регламент – документ, определяющий правила взаимодействия и правила распределения ответственностей между Заказчиком и Провайдером.
Вот список вопросов, на которые должен отвечать регламент:
Заявка
Основным документов взаимодействия меду Заказчиком и Провайдером будет являться Заявка на мониторинг.
Заявка – это документ, в котором формализуются все требования Заказчика к задачам, которые он предполагает решать с помощью системы мониторинга.
Правила заполнения, согласования, испытаний, перевода в эксплуатацию все это предлагаю описывать в регламенте, также список лиц, которым допустимо выступать в роли Заказчика.
Заявка — это как бы небольшой договор, соответствующий определенной форме, между заказчиком и Провайдером, он же будет основным средством разрешения споров между ними, например: «Смог ли мониторинг выполнить свою задачу так, как это прописано в Заявке!»
Способ оформления заявки зависит от принятых в организации методов ведения документов:
Структура заявки
Вот я уже рассказал о двух самых важных вещах в организации системы мониторинга: Регламент – это раз, Заявка – это два. Вот тут читатель может вскрикнуть «Как и это все, этого недостаточно!». Отвечу: «Конечно, недостаточно, остальное просто не входит в рамки этой статьи».
Теперь хочу добавить технических деталей, приведу пример структуры Заявки, которую мне приходилось использовать. И раз уж дальше речь пойдет о технических деталях, то всех кто готов закончить чтение данной статьи именно на этом месте, приглашаю к обсуждению, буду рад обсудить возникшие вопросы.
Вернемся в структуре заявки, укрупнено заявку могу описать в виде следующих групп:
Общее:
Здесь предлагаю определить уникальный идентификатор заявки, вести версионность, вести статус и т.д.
Ответственный – лицо, выступающее со стороны Заказчика, которое курирует создание Заявки. Ответственный обязательный атрибут Заявки, он может меняться, но его не может не быть. Круг лиц, имеющих возможность инициировать процесс создания Заявки, предлагается определить в Регламенте.
Конфигурационные единицы (КЕ) – это список объектов, для которых необходимо реализовать условия данной заявки. Информации о КЕ должно быть в полной мере достаточно для ее однозначной идентификации. На этапе проектирования системы мониторинга предлагается разработать план КЕ, их возможные типы и необходимые атрибуты.
В зависимости от архитектуры системы мониторинга список КЕ в заявке может формироваться вручную или же на основе данных обнаружения объектов инфраструктуры (есть специализированные системы, которые способны инвентаризировать всю ИТ-инфраструктуру). Так же список КЕ в заявке допускается формировать автоматизировано на основе условия (Например: все сервера принадлежащие определенной подсети, это может быть ссылка на запрос в базу данных, где хранится информация об объектах инфраструктуры).
Условия – точные формулировки проверок, которые необходимо выполнять для реализации мониторинга. Условия необходимо тщательно фиксировать в Заявке, это будет исходными данными для разработки. Каждое условия сопоставляется со списком КЕ или же с отдельными экземплярами КЕ.
Пример типов условий:
Действие
Каждому условию могут соответствовать действия, которые необходимо выполнить. Каждое действие должно иметь уникальное наименование (идентификатор). Этот идентификатор необходимо включить в атрибуты сообщения, поступающего в систему мониторинга, что позволит идентифицировать необходимое действие на стороне системы мониторинга. В свою очередь система мониторинга должна иметь настройки позволяющие выполнить то или иное действие в зависимости от наименования действия.
Примеры типов действий:
Конфигурация – ссылка на конфигурацию программного обеспечения, реализующего условия заявки. Может содержать следующую информацию:
Ссылка на конфигурацию системы мониторинга может являться входными данными для автоматизации процесса развертывания Заявка. Также ссылка на конфигурацию позволит определить, с какой Заявкой связаны те или иные настройки системы мониторинга.
Вот схематичная структура заявки:
Жизненный цикл заявки
Последнее чему хочу уделить внимание это жизненный цикл заявки, выделю следующие этапы:
Подробнее о каждом:
Оформление
Здесь происходит заполнение Заявки в установленной форме, согласование условий мониторинга и в перевод на следующий этап — разработки.
Разработка
Тут все просто! Создание конфигураций в системе мониторинга в соответствии с условиями Заявки и перевод на следующий этап – тестовая эксплуатация.
Не исключаем возможности возврата Заявки на этап оформления для уточнения или переопределения условий мониторинга.
Тестовая эксплуатация
Здесь решаем тонкий политический вопрос: «Кто занимается подготовкой тестовой среды» и проводим все необходимые мероприятия, связанные с тестированием Заявки.
По результатам тестирования возможен возврат Заявки на этапы оформления или разработки в зависимости от выявленных проблем.
При успешном окончании тестовой эксплуатации – следующий этап, промышленная эксплуатация.
Промышленная эксплуатация
Тут уже все серьезно: система работает, инциденты обнаруживаются, уведомления рассылаются. На этапе промышленной эксплуатации предусматриваю возможность внесения изменений в Заявки, типа изменений:
Подробнее об этих типах:
Минорные – изменения, не требующие возврата на этап разработки, например изменения списка объектов мониторинга или изменение списка адресатов почтовой рассылки. При минорных изменениях версионность Заявок я не меняем.
Мажорные – изменения, требующие возврата на этап разработки, например изменение условий мониторинга. При мажорных изменениях меняем версионность Заявки, предыдущие версии необходимо вывести из эксплуатации.
И на последок, из промышленной эксплуатации Заявку возможно вывести из эксплуатации или перевести в режим обслуживания. Режим обслуживания – тот случай, когда временно необходимо отключить мониторинг для проведения технических мероприятий.
Схематично жизненные этапы Заявки представлю на следующем рисунке:
Итого
Подводя итог, хочу сказать, что успешную работу системы мониторинга опираю на три столпа: Регламент, Заявка и технические возможности самой системы.
Хорошей практикой будет — создание некоторого количества Заявок, вмещающих в себя типовые условия мониторинга. Для таких заявок достаточно просто определить объекты мониторинга, определить адресатов уведомлений и вперед – на этап промышленной эксплуатации.
Вот и все что мне хотелось рассказать в этой статье, с удовольствием приглашаю к обсуждению, готов ответить на вопросы.
Эти новые решения класса _подставить_нужное_ – только очередная трата денег
А может построим ИБ без технических средств? Есть оценка рисков, вы вольны выбрать одну из стратегий: избегание, минимизация, передача и принятие. По какой-то логике вы выбираете минимизацию. Дальше уже не важно, как вы будете её реализовывать. Чью экспертизу задействовать – положитесь на защиту от вредоносов с помощью антивирусов, будете пытаться блокировать их на подлёте, внедрив решение типа IPS, или выберете гибридный вариант? Будут ваши затраты входить в CAPEX из-за внедрения средства защиты в инфраструктуре предприятия или весь ЦОД, вместе с системами обеспечения безопасности, поедет в облако, попадая в OPEX? Доверитесь встроенным решениям от облачного провайдера, или, уйдя в облака, предпочтёте наложенные средства? Технические средства служат автоматизации или привносят экспертизу, подсвечивая расхождения текущего состояния с лучшими практиками? Всё это будет не интересно руководству, которое спросит только, удалось ли минимизировать риски и сколько это стоит.
Хотя важен не подход, а результат, лучший вариант – соблюдение баланса между трудозатратами сотрудников и использованием систем защиты. Можно пытаться обходиться без технических решений. Но если компания развивается и растёт, то растут и риски, как качественно, так и количественно. А вслед за ними – желание этими рисками управлять. В том числе, за счёт улучшения качества мониторинга – увеличения его «площади» (сегментов сети, тактик, техник) и «глубины» (не очевидное использование тех же техник, уменьшение порогов срабатывания). Чем больше угроз вы мониторите, тем больше аналитиков вам потребуется. Специалисты в дефиците, а растить их приходится годами.
Автоматизировать те, и только те процессы, которые достигли зрелости – хорошая идея. Да, на начальном этапе это трудозатраты и дополнительные требования к персоналу. Но после выполнения проекта подход приносит плоды в части операционных затрат. Другой ответ на вопрос «зачем» – не устраивает время реакции на инцидент. Если десять аналитиков примутся за одну задачу, результат не будет получен в десять раз быстрее. Но если доверить что-то автоматике, это достижимо.
Важно отличать полезное, новое техническое средство от ребрендинга чего-то старого. А систему, которая принесёт вам пользу уже сейчас, от той, которая будет мигать огоньками в стойке. А когда понадобится – устареет.
Перейдем к техническим средствам системы мониторинга.
NTA и NBA
У вас уже скорее всего есть SIEM, который получает агрегированные данные трафика в форматах NetFlow, sFlow, jFlow, Packeteer или сам создаёт такие агрегаты из копии трафика. Их основные данные – информация L3 и L4 OSI. Также, у вас скорее всего внедрён IDS/IPS, который не записывает трафик, но анализирует его полную копию от L2 до L7, насколько позволяет шифрование.
Если эти средства не решили ваши задачи, можно дополнить систему мониторинга с помощью Network Traffic Analysis. Это решение производит запись трафика для его последующего исследования. При планировании стоит учесть гораздо больший по сравнению с LM/SIEM объем хранилища и необходимость предварительной расшифровки данных.
Трафик объединяет в себе и информацию, и факт её передачи. В отличие от событий, генерация которых избирательна, он полностью описывает, что произошло между двумя взаимодействующими системами, и его нельзя удалить или сфабриковать. События собираются в LM или SIEM с некоторой задержкой, если это не Syslog, в случае которого возможен спуфинг. А если успеть очистить журнал источника – действие, подозрительное само по себе – что точно случилось узнать будет трудно.
Также можно использовать решения класса Network Behavior Analysis – аналог U(E)BA для сети со всеми его преимуществами и недостатками, но с парой особенностей. Во-первых, эти решения гораздо чаще выпускаются в виде обособленных продуктов. Во-вторых, как мы уже говорили в части 6, основных сетевых протоколов несколько десятков, что делает решение «из коробки» довольно эффективным.
Результат использования NTA и NBA – у вас есть аналоги SIEM и U(E)BA, позволяющие использовать все особенности трафика.
Заключение
Рассмотренные нами решения являются одновременно и специализированными, и универсальными. Поэтому они не соберутся в единую систему как кубики. Каждый придётся дорабатывать напильником не только для стыковки друг с другом, но и с вашими задачами и процессами. Это стоит учитывать при планировании сроков проекта.
Если вы ещё не строили подобных систем, ваши знания, а соответственно, и требования к техническим решениям будут меняться по ходу проекта. В процессе его реализации будут эволюционировать инфраструктура, угрозы безопасности, сам бизнес. И после достижения цели – создания системы – изменения продолжатся. Проект живой, его не уложить на бумагу от и до. Это стоит учесть при планировании задач проекта и создании технических требований к его решениям.
Поэтому важен поэтапный подход. В обозримые сроки вы получаете то, что запланировали. Берёте паузу и добиваетесь максимума эффективности, попутно понимая, чего не хватает. Переходите к следующему этапу, который может быть как развитием системы, так и модернизацией или заменой её существующих компонентов.
Эта статья – описание технических решений. Она поможет выделить такие этапы. За кадром остались ценные для мониторинга, но более обособленные решения: почти все средства защиты, VM, CMDB и т.д. Не забудьте и о них.