Федеральная система обнаружения атак — как она могла бы выглядеть?

В блоге и в Твиттере мне стали оппонировать, что я критикую, не зная, как на самом деле будет устроена система обнаружения атак, описанная в Указе Президента №31с. Так уж сложилось, что темой обнаружения атак я занимаюсь давно, еще с конца 90-х и поэтому неплохо себе представляю, как может быть выстроена такая система и с какими сложностями могут столкнуться ее создатели (кстати, в Академии ФСБ до сих пор учатся по моей книжке «Обнаружение атак» 2001-го года издания).

Конечно, сложно, не зная целеполагания, предполагать, что же имели ввиду авторы 31-го указа, но вариантов на самом деле тут немного. Под описанной системой обнаружения атак может пониматься:

• Низкоуровневая система мониторинга вредоносной активности, направленной на информационные системы РФ (допустим, только на государственные информационные системы и КСИИ в КВО). Т.е. по сути — это территориально-распределенная IDS. Почему она не заработает я написал вчера и позавчера.
• Высокоуровневая система мониторинга, которая аккумулирует данные с разных источников. Некий ситуационный центр по ИБ (или Security Operation Center). При том зоопарке решений, используемых отечественными госорганами и КВО, построить такой SOC — задача нетривиальная. Еще более нетривиальная задача — визуализировать весь тот объем информации, который будет поступать в SOC. Это терабайты данных ежедневно.
• Центр сбора информации об инцидентах ИБ. Это наиболее просто реализуемая задача, но и она имеет кучу подводных камней, начиная от отсутствия единого формата для такой информации до нежелания госорганов светить такие сведения. Тут достаточно вспомнить процедуру обязательного уведомления Банка России в рамках отчетности по 2831-У. Но там хоть ответственность косвенная была за невыполнение обязательных требований ЦБ, а тут?…
• Система оповещения об уровне Интернет-угрозы. Это, пожалуй, самый простой путь реализации указа 31с. Достаточно просто поставить на сайт ФСБ иконку уровня угрозы от Cisco, Касперского или других вендоров и тем самым оповещать пользователей об уровне угроз. Я про это даже писал 10 лет назад.

Но так уж ли важен вариант реализации данной системы? По сути они все обладают  схожим функционалом и при его реализации проблемы будут одинаковыми. Как могла бы выглядеть такая система в идеале?

Начать стоило бы с того, чтобы определиться — мы хотим иметь систему ориентированную вовнутрь или с зачатками прогнозирования? Первый вариант ограничен только данными, получаемыми из множества источников (сенсоров), разбросанных по госорганам и Интернет. В этом случае мы анализируем текущий уровень защищенности; не более того. Второй позволяет учитывать и внешнюю ситуацию в киберпространстве, атаки на иные ресурсы, в т.ч. и в других странах, тенденции мира «по ту сторону баррикад» и т.д. Первый путь чуть проще в реализации, т.к. поступаемые данные более формализованные, чем различные бюллетени, сообщения на «хакерских» форумах и другая неструктурированная информация.

Ядром (и первым элементом) любого варианта построения системы обнаружения атак является механизм сбора событий для последующего их анализа. В зависимости от охвата и глубины реализации системы этот список может быть очень широким и включать в себя сетевой трафик, логи сетевого оборудования, ОС, СУБД и приложений, события средств защиты, результаты идентификации/аутентификации, события Netflow, результаты сканирования, конфиги, данные репутации Интернет-ресурсов и т.п. Не так важно, что будет выступать в качестве сборщика — SIEM, средства анализа защищенности, средства анализа рисков, системы управления журналами регистрации. Главное, чтобы выбранное средство могло:

• собирать данные из всех источников
• собирать и хранить неструктурированные данные
• работать с большими объемами данных (сотни терабайт, а то и петабайт с эксабайтами)
• предоставить мощные аналитические возможности (причем на этом уровне они даже важнее, чем аналитика и модуль принятия решения на сенсоре)
• приоритезировать зафиксированные события.

Из современных SIEM мало кто подойдет под эту задачу. Все-таки они ориентированы для решения иных задач — аггрегирования данных от распространенных средств защиты в одной базе и генерации отчетов для реализации требований соответствия. Из всех игроков рынка лучше всего под эту задачу подходит Splunk, но и его надо докручивать, чтобы получить инструмент, похожий на нужный хотя бы в первоначальном приближении. В отличие от традиционных SIEM Splunk ориентирован на аналитику неструктурированных данных большого объема.

Модули сбора и аналитики — это тот минимум, который позволяет выстроить систему обнаружения вторжений по любому из вышеописанных сценариев.И я специально не касаюсь того, как устроен модуль аналитки. Там ведь тоже вопросов выше крыши. Как бороться с ошибками первого и второго рода? Что является нормальным поведением, а что отклонением? Кто описывает профили поведения контролируемых систем? Я более чем уверен, что ФСБ не готова заниматься этой работой. Если уж не стали писать базовые модели угроз для нескольких десятков отраслей, то уж создавать десятки и сотни тысяч профилей точно не будут (в FIDNET первоначально речь шла о нескольких десятках миллионов профилей). Ждать этого от уважаемых мной рядовых сотрудников органов власти я тоже не могу — они и сигнатурные-то IDS не всегда настраивают, оставляя все «по умолчанию». Здесь же задача гораздо сложнее, чем просто поставить галочку напротив нужных сигнатур. Посмотрите на картинку ниже — можно ли по данному профилу сказать, речь идет об атаке на БД SQL или это просто пик обращений к ней?

А вот тут ситуация еще сложнее — два «аномальных» события. Одно предваряет другое. Кто будет описывать не только профиль трафика, но и правила корреляции между событиями?

Отдельная задача — визуализация полученных данных. При том объеме данных, которые будут поступать в систему, обычный табличный вариант не сильно подойдет. Да и традиционные карты сети тоже будут захлебываться в объеме данных. Вот так карта сети выглядит в системе визуализации для обычного предприятия (даже большого).

Все почти идеально (пример из реальной сетки). А теперь я покажу как такая карта выглядит для сети компании Cisco:

Попытка детализации карты не сильно облегчает жизнь:

Решить эту проблему можно — путем редизайна контролируемых сетей, сегментирования, применения модульного подхода и т.д. Но как заставить госорганы это сделать? Это вам не СКЗИ навязывать. Многие годами живут в плоской сети без всякой сегментации. И как в такой карте разбираться и отслеживать в ней инциденты ИБ?

Могу поделиться опытом, как Cisco проводила работы по автоматизации задачи оценки безопасности нашей сети на десятки тысяч узлов. Задача оказалась нетривиальной. В федеральной же сети узлов не десятки и даже не сотни тысяч — гораздо больше. И это только ПК, за которыми работают пользователи. Если вспомнить про M2M-взаимодействие, различные IP-устройства (принтеры, сенсоры ввода/вывода, датчики индустриальных систем и т.д.), то число узлов, которые должны будут мониториться системой обнаружения атак, будет измеряться миллионами.

Дальше начинается уже специфика и конкретика. Если в систему обнаружения атак входит реагирование, а в указе 31с оно прописано, то мы должны решить, как реагировать на обнаруженные атаки — просто уведомить «кого надо» или предпринимать более активные действия — контратака, блокирование, изоляция пострадавшего сегмента и т.д. Причем в зависимости от источника данных варианты реагирования и ликвидации последствий могут быть совершенно различными и спектр возможных вариантов просто зашкаливает. А еще они могут быть автоматическими, ручными и автоматизированными.

Мнение о том, что предлагаемая 31-м указом система обнаружения атак должна работать по принципу «установил и забыл», ошибочно с самого начала. Это совершенно не так. Это постоянная и кропотливая работа, требующая высокой квалификации от ее участников и  немалых ресурсов (временных, людских, финансовых). Именно поэтому я скептически отношусь к идее, прописанной в Указе №31с. В теории такую систему создать не сложно — проблемы начинаются на практике. И пока я не вижу, чтобы кто-нибудь задумался о том, чтобы найти пути их решения до разработки системы, а не после. Если этот пост поможет ответственным за создание данной системы обратить внимание на тонкие моменты и подводные камни — уже неплохо. А если они привлекут к разработке концепции системы экспертное сообщество (правда, в это я не очень верю — ФСБ пока считает себя умнее всех), то будет вообще отлично. И еще неплохо подумать о том, кто и как будет эксплуатировать созданную систему?

ЗЫ. Я в своих постах не раз высказался о том, что у ФСБ нет достаточного количества квалифицированных специалистов, чтобы потянуть эту задачу. На чем базируется мое мнение? Если не брать некоторые сведения, которые у меня есть и которые я не буду афишировать, то достаточно взглянуть на этот вопрос с точки зрения логики. Вы видели хоть какой-нибудь документ от ФСБ по теме информационной безопасности, который бы вызвал у вас уважение и доверие к конторе, а также уверенность в ее компетенции? Я нет ;-( У меня даже к документам по криптографии есть немало претензий, а уж в этой-то теме регулятор собаку съел. Но время идет, меняются технологии, меняются подходы, а регулятор как сидит на своих «временных требованиях к СКЗИ» так и сидит. NIST и не только уже с тех пор не один и не два документа выпустили по теме управления ключами, выбора длин ключей в зависимости от задачи, облачной криптографии, а мы так и сидим в средневековье. «Святая Инквизиция» не хочет выпускать из своих рук знание о том, что Земля-то круглая. Правда все уже об этом знают, но официально регулятор хранит молчание и ничего не признает кроме принадлежащего себе сокровенного знания.

В других темах по информационной безопасности ФСБ пока «студенты» ;-(  Достаточно вспомнить некоторые выступления сотрудников ФСБ по теме безопасности виртуализации и облаков. Они только-только начинают копать что-то отличное от криптографии. И они уступают специалистам коммерческих компаний, ВУЗов, госорганов, которые не связаны никакими ограничениями по части изучения международного опыта, международных стандартов и т.п. Это не то, чтобы плохо — это нормально. Все всегда с чего-то начинают. Плохо то, что ФСБ оккупировала эту тему и никого туда не пускает, считая себя умнее всех и засекречивая результаты своей работы. Может быть все-таки они одумаются?.. Или серьезный инцидент на каком-либо критически важном объекте заставит их одуматься?.. Последнего не хотелось бы.