Если в компании есть центр обеспечения безопасности (SOC — Security Operations Center) и внедрено решение по сбору и обработке журналов и оповещений, относящихся к безопасности (SIEM - Security information and event management) - в них информация приходит из множества разнородных источников. В оповещения включаются данные о возможных инцидентах из средств мониторинга инцидентов ИБ, а также связанный контекст из различных шлюзов, МФА, СКУД, AD, DNS, СЭД, ERP, CRM, других информационных систем и средств обеспечения безопасности. При этом настроенные на срабатывание по конкретному событию (или по серии событий) программы сообщают не о фактическом инциденте, а лишь о срабатывании на некие формальные признаки.
Чем опасны ложные оповещения?
Ручной анализ информации отнимает много времени у сотрудников, а слишком большой поток данных приводит к рассеиванию внимания, при этом заявленная критичность уже не воспринимается ими как фактическая и действительно опасная. Из-за высокой нагрузки люди испытывают сложности во время принятия решений, быстро устают и начинают оповещения игнорировать. К тому же детально анализируя одно из них, сотрудник редко обращает внимание или вовсе не смотрит на другие.От этой проблемы страдают не только крупные холдинги со множеством разнородных систем и критериев срабатывания, где невозможно быстро настроить корректные правила для контроля абсолютно всех возможных угроз и установления исходной причины, а также «узловых точек» конкретного инцидента для оперативной реакции и качественного устранения последствий. Сложности возникают даже в небольших компаниях, в которых мониторинг, наиболее вероятно, не был настроен — его внедрение становится неподъемной задачей для единственного системного администратора или небольшого подрядчика. В малых организациях объем необходимых правил не всегда меньше. Да, количество бизнес-систем и средств безопасности в этом случае относительно невелико, но это, в свою очередь, снижает точность срабатываний, и заставляет проверять «вручную» больше гипотез для обнаружения развивающейся атаки.
Как работает корреляция?
На помощь в обоих случаях приходит математика. Корреляция определяет статистическую взаимосвязь двух и более случайных величин: применяя этот метод можно автоматически сопоставлять отдельные события или цепочки событий из разных систем, а также задавать их последовательности или, скажем, сравнивать значения в полях данных. Чем больше в этом смысле умеет инструмент, и чем из большего количества источников получает телеметрию - тем больше шансов создать корректные правила на его основе.
Какую систему выбрать?
Отдельно средства корреляции событий ИБ не поставляются, но они встроены практически в любое решение класса SIEM или в системы поведенческого анализа, подразумевающие активное вмешательство заказчика в преднастроенные правила хотя бы для внесения исключений. Выбирать при этом следует даже не систему как таковую, а какие угрозы, согласно вероятности возникновения такого риска, требуется обнаруживать с ее помощью в первую очередь.
Насколько надежна корреляция?
Чем больше корпоративных информационных систем отдает события в базу для дальнейшей обработки правилами корреляции - тем больше будет возможностей для обнаружения специфической угрозы. Стоит отметить, что обнаружить активность проникших внутрь защищенного периметра хакеров или вредоносного ПО обычно удается и с базовым набором источников событий. Их действия слишком выделяются на фоне обычной пользовательской активности и засечь злоумышленников в ручном режиме мешают только огромные объемы данных, которые необходимо сопоставить.
Благодаря своей комплексности сложные правила корреляции не дают шанса появиться сколь-либо значимому количеству ложных срабатываний. Реакция на них должна следовать всегда, при этом сложно заранее предсказать, насколько критичным будет конкретный инцидент: никто не знает, рядовое это нарушение политики ИБ лояльными сотрудниками, либо вскроется давно подготавливаемая операция с участием группы инсайдеров.
Что в итоге?
Важно понимать, что хотя средства корреляции уменьшают количество ложных оповещений об инцидентах ИБ, целью их внедрения является далеко не это. Важнее комплексно посмотреть на поступающие из различных систем оповещения о событиях безопасности, определить взаимосвязь между ними и показать ее оператору SOC. Только так можно узнать, например, производил ли нестандартные подключения к внутренним или внешним адресам узел, с которого сейчас происходит потенциальная атака Pass-the-Ticket или Pass-the-Hash, какие изменения произошли после этих подключений в реестре или иных областях, где обычно «гнездятся» APT, был ли запущен новый процесс или служба, и т.д.
При обсуждении средств корреляции и фактической реализации конкретных правил нужно говорить не столько об освобождении времени сотрудников, занимающихся рассмотрением инцидентов, сколько о выделении в SOC специалистов, ответственных за автоматизацию и повышение эффективности работы остальных сотрудников.
Повышение уровня безопасности в таком случае достигается двумя обязательными шагами. Первый — обеспечить существенно большую скорость адекватной оценки критичности инцидента. Второй заключается в устранении возникающих угроз при использовании автоматизации предоставления важных дополнительных данных при обнаружении того или иного «первичного» IOC (признака компрометации ).
