Всем добрый день! Я Андрей Дугин, руководитель центра сервисов кибербезопасности RED Security.
Сервисы кибербезопасности широко применяются в любой крупной компании, а также во многих средних и малых. Но сам по себе факт их подключения не гарантирует результата. Следует грамотно подойти к организации процесса использования сервиса, иначе есть риск потратить деньги, но не получить должный уровень защиты. На прошедшем SOC Forum 2024 я выступал с презентацией о частых ошибках, которые допускают компании при подключении ИБ-сервисов. Хочу поделиться этой информацией и с вами.
Делать все своими силами
Некоторые компании хотят защитить свою инфраструктуру самостоятельно, а не делегировать эту задачу сторонним сервисам. Желание понятное, но при его реализации есть сложность: как правило, скорость внедрения in-house-решений крайне низкая.
И это без учета стоимости внедрения решения in-house. Чаще всего она на порядок выше, так как нужно приобретать дорогостоящее оборудование и ПО. Позволить себе подобное решение могут только очень крупные компании, и на время его реализации им все равно придется защищаться с помощью сторонних сервисов.
А если речь идет об Anti-DDoS, собственное решение в принципе сложно использовать эффективно, если вы не провайдер интернет-услуг с очень широким каналом.
В результате может возникнуть ситуация, когда угроза безопасности уже есть, а реагировать на нее еще нечему: система не готова. Учитывая, что количество атак ежегодно растет, внедрение сервисов защиты — это не то, с чем следует задерживаться.
Думать, что поставщик сделает все сам
Вторая крайность — считать, что заказчику достаточно оплатить сервис, а дальше его вмешательство не потребуется: пусть провайдер делает все самостоятельно. Это тоже ошибка.
Чтобы грамотно настроить компоненты защиты, поставщик сервиса должен иметь представление об инфраструктуре вашей компании. Информацию о ней он получает от вас. А без нее не всегда сможет однозначно определить, считать ли то или иное событие инцидентом ИБ.
Благодаря накопленному опыту провайдер понимает, что значат разнообразные события и инциденты, но только в общем случае. А конкретно в вашей ситуации какой-то тип инцидента на определенном участке инфраструктуры может оказаться ложным срабатыванием.
Пример — создание локального пользователя на активном сетевом оборудовании:
если компания использует для аутентификации и авторизации протокол RADIUS или TACACS, появление нового локального пользователя может говорить, что устройство скомпрометировано;
но если администрированием занимаются локально — а такое часто бывает в компаниях с небольшой ИТ-инфраструктурой и малым количеством оборудования — возможно, учетную запись создали для нового сетевого инженера.
Такая нехватка информации приводит к тому, что провайдер постоянно обращается к клиенту с вопросами. А если тот не будет вовремя отвечать, то сервис не сможет работать эффективно.
Сюда же можно отнести ситуацию, когда подразделение ИБ отдает коммуникацию с провайдером ИТ-отделу, чтобы они разбирались самостоятельно. В целом это нормально — связывать технических специалистов поставщика со своими ИТ-сотрудниками. Но этот процесс нужно контролировать, чтобы избежать недопониманий и разрыва в коммуникациях.
Забивать на рекомендации по инцидентам
Как правило, при выявлении инцидента ИБ поставщик сервиса отправляет клиенту отчет с рекомендациями по улучшению. Игнорировать их — ошибка, даже если кажется, что угроза слишком мелкая для какой-либо реакции.
Например, сервис сработал на событие: пользователь много раз неудачно ввел пароль. Это может оказаться инцидентом подбора пароля. А может быть побочным результатом легитимной смены пароля: пользователь изменил пароль и забыл обновить его на всех устройствах. Кажется, что событие небольшое, но все равно нужно связаться с пользователем и выяснить, в чем дело. Без этого есть риск дать злоумышленнику дойти до этапа с возможностью влияния на бизнес. И это только один из возможных примеров.
Рекомендации помогают избегать таких проблем в будущем. Если же изменения не внедрить, точно такие же инциденты могут появляться вновь и вновь, снижая общий уровень безопасности. Сервис станет работать в режиме тушения пожаров с регулярно повторяющимися инцидентами, за которые никто не будет браться, пока не возникнет какое-либо особенно критичное для бизнеса событие.
Если рекомендации выполнены или их по какой-то причине невозможно внедрить, не забывайте сообщить об этом поставщику сервиса. Отсутствие обратной связи не позволяет провайдеру узнать, что вы доработали, а что пока осталось в исходном виде. А значит, не помогает защищать вас в будущем.
Подключать сервис для галочки
Бывает, что бизнес подключает ИБ-сервис просто чтобы он был. При этом о реальной защите думают минимально. Сервис не настраивают, не адаптируют под инфраструктуру. Иногда в него могут «обернуть» только случайную часть периметра, считая, что какая-то защита лучше вообще никакой.
В итоге получается, что одна часть инфраструктуры защищена от атак, а другая — нет. Это становится слабым местом, уязвимым для атак. Так как защищенный и незащищенный участки выбраны случайно, уязвимой вполне может оказаться критическая инфраструктура, повреждение которой приведет к серьезным потерям.
Поэтому к использованию ИБ-сервиса всегда нужно подходить серьезно. Если вы не можете подключить защиту на весь периметр — выберите для начала критичные узлы, атака на которые может вывести из строя инфраструктуру. Не берите участок периметра наугад — ни к чему хорошему это не приведет.
Не понимать, что вы защищаете
Этот пункт частично перекликается с предыдущим. Ситуация, когда критичные узлы не защищены, возникает еще по одной причине: у периметра нет четкого описания. Никто не может сказать точно, как он устроен. За этим следует целый ряд проблем:
у вас не получится сформулировать четкое техническое задание — выйдет только «защити то, не знаю что»;
вы не знаете о возможных уязвимостях в своем периметре, поэтому не представляете, откуда ждать атаки и какого типа она может быть;
у провайдера также нет понимания, что именно должно находиться под защитой сервиса, и получить эту информацию ему неоткуда.
В такой ситуации нельзя создать эффективно работающее решение. Можно пропустить ключевой узел и оставить его незащищенным. Или наоборот — качественно защитить второстепенные участки в ущерб более важным.
Чтобы такого не происходило, еще до обращения к провайдеру ИБ-решения нужно провести инвентаризацию — описать все ключевые узлы, хосты, устройства и участки сети. А уже на этапе переговоров передать эту информацию провайдеру, чтобы он тоже понимал, как выглядит ваша инфраструктура.
Инвентаризация полезна и самому заказчику. С актуальной информацией он может обратить внимание на неочевидные слабые места в периметре.
Как часто проводить инвентаризацию и как выстроить процесс — тема для отдельной статьи. Но если резюмировать коротко, все зависит от размера инфраструктуры и частоты ее обновления:
если инфраструктура небольшая и статичная, результаты первой инвентаризации можно просто зафиксировать в таблице и обновлять по факту внесения изменений;
для крупных и быстро меняющихся систем нужно или регулярно описывать все новые узлы, или выстроить процесс непрерывной инвентаризации — чтобы актуализировать сведения в реальном времени.
Главное — поддерживать информацию актуальной.
Не вести системную работу по устранению первопричин инцидентов
Выполнять рекомендации провайдера можно по-разному. Бывает так, что заказчик точечно внедряет изменения, про которые ему сообщил поставщик ИБ-услуги. Но при этом не обращает внимания на картину в целом — игнорирует первопричину. Получается такая ситуация: инциденты вспыхивают то в одном, то в другом месте. Их последствия устраняют, но события продолжают появляться.
На самом деле у них есть какая-то общая причина — скажем, отсутствие единого стандарта безопасности. Но об этом никто не знает: ни заказчик, ни провайдер. Она остается неизвестной и незамеченной, потому что компании не хватает системной работы.
Например, если одну и ту же уязвимость успешно эксплуатируют на разных ресурсах — это могут ошибочно воспринимать как не связанные друг с другом события. На деле причина глубже: повторение инцидентов говорит об отсутствии процесса управления уязвимостями в компании.
Вывод простой: работу с ИБ-сервисами стоит систематизировать по методу Root Cause Analysis (RCA). Он предполагает несколько шагов, которые нужно выполнить, если появилась какая-то проблема:
выявить и подробно описать эту проблему;
собрать максимум информации о ее возникновении;
предположить возможные причины появления;
выделить из них ключевую причину;
предложить решения и способы устранить источник;
реализовать и поддерживать решение, чтобы не допустить повторения проблемы в будущем.
Описание шагов в разных источниках может отличаться, но суть у RCA одна — анализ первопричин. Он помогает обращать внимание на картину в целом, а не только на точечные инциденты и сделать работу с ИБ-сервисами более системной.
Считать, что существует универсальный сервис, который защитит от всего
На рынке существует множество разных ИБ-сервисов, и у каждого из них своя роль. Например:
SOC мониторит периметр на наличие угроз и быстро сообщает о киберинцидентах;
WAF в автоматическом режиме защищает веб-приложение от атак, специфичных для web;
Anti-DDoS блокирует DDoS-атаки, при которых ресурс выводят из строя большим количеством запросов.
Бывает, что в компании не вполне понимают, чем один сервис отличается от другого, и начинают считать выбранное решение универсальным. Хотя это не так — одно не заменит другое.
Разберем на примере: компания подключает SOC и считает, что он один заменяет WAF и Anti-DDoS, так как сообщает обо всех инцидентах. Но на практике защита оказывается недостаточной:
SOC не справится с DDoS-атакой. Чтобы отразить ее, нужен очень широкий канал и специализированное оборудование очистки трафика. У SOC, в отличие от сервисов Anti-DDoS, нет ни того, ни другого;
об атаке на web-приложение SOC предупредит, но заблокировать вредоносный трафик в режиме реального времени не сумеет. Причина та же: отсутствие специализированного решения по отражению web-атак. А вот WAF заблокирует опасный трафик сразу и даст компании время, чтобы применить полноценный патч и закрыть уязвимость.
Если компания часто подвергается DDoS-атакам и атакам на web-приложения — SOC без других сервисов не обеспечит ей нужный уровень безопасности. А значит, еще до внедрения стоит решить, какие инструменты для вас критичнее, начать с них и постепенно подключать другие сервисы. Помните: одно решение не защитит от всего.
Нужного эффекта от ИБ-сервисов можно добиться, только если внедрять их правильно:
уделять внимание инвентаризации своего периметра — как внешнего, так и внутреннего;
актуализировать информацию об инфраструктуре;
подбирать сервис и защитные меры, исходя из особенностей своей инфраструктуры;
передавать провайдеру все нужные сведения о защищаемых ресурсах;
вовремя реагировать на инциденты, находить и устранять их причины;
регулярно давать провайдеру обратную связь.
Если подойти к вопросу грамотно, ИБ-сервисы серьезно повышают безопасность инфраструктуры и позволяют делегировать провайдеру большую часть работы, которая требует высокой квалификации в сфере ИБ.
На этом у меня все. Желаю вам безопасности, стабильности и до новых встреч!
