23 Января, 2013

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

Алексей Лукацкий
В блоге и в Твиттере мне стали оппонировать, что я критикую, не зная, как на самом деле будет устроена система обнаружения атак, описанная в Указе Президента №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 и не только уже с тех пор не один и не два документа выпустили по теме управления ключами, выбора длин ключей в зависимости от задачи, облачной криптографии, а мы так и сидим в средневековье. "Святая Инквизиция" не хочет выпускать из своих рук знание о том, что Земля-то круглая. Правда все уже об этом знают, но официально регулятор хранит молчание и ничего не признает кроме принадлежащего себе сокровенного знания.

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

CAPTCHA
24 Января, 2013
За 10 лет что ушел из этой темы
первый раз наткнулся на автора, который понимает о чем говорит. спасибо. ФСБ не имеет никаких возможностей влиять на ИБ в нынешнем глобальном информационном пространстве. не могут даже селектировать тренды, не то что угрозы. При том еще советском заделе - они все феерически промямлили десять -15 лет назад. Все что государство может сделать - выделить денег Касперскому и Адоньеву на создание независимых от внешних стандартов И-пространств для внутреннего употребления. С очень туманными перспективами. В любом случае спасибо еще раз за обзоры. С удовольствием почитал.
0 |
  • Поделиться
  • Ссылка