В блоге и в Твиттере мне стали оппонировать, что я критикую, не зная, как на самом деле будет устроена система обнаружения атак, описанная в Указе Президента №31с. Так уж сложилось, что темой обнаружения атак я занимаюсь давно, еще с конца 90-х и поэтому неплохо себе представляю, как может быть выстроена такая система и с какими сложностями могут столкнуться ее создатели (кстати, в Академии ФСБ до сих пор учатся по моей книжке "Обнаружение атак" 2001-го года издания).
Конечно, сложно, не зная целеполагания, предполагать, что же имели ввиду авторы 31-го указа, но вариантов на самом деле тут немного. Под описанной системой обнаружения атак может пониматься:
Начать стоило бы с того, чтобы определиться - мы хотим иметь систему ориентированную вовнутрь или с зачатками прогнозирования? Первый вариант ограничен только данными, получаемыми из множества источников (сенсоров), разбросанных по госорганам и Интернет. В этом случае мы анализируем текущий уровень защищенности; не более того. Второй позволяет учитывать и внешнюю ситуацию в киберпространстве, атаки на иные ресурсы, в т.ч. и в других странах, тенденции мира "по ту сторону баррикад" и т.д. Первый путь чуть проще в реализации, т.к. поступаемые данные более формализованные, чем различные бюллетени, сообщения на "хакерских" форумах и другая неструктурированная информация.
Ядром (и первым элементом) любого варианта построения системы обнаружения атак является механизм сбора событий для последующего их анализа. В зависимости от охвата и глубины реализации системы этот список может быть очень широким и включать в себя сетевой трафик, логи сетевого оборудования, ОС, СУБД и приложений, события средств защиты, результаты идентификации/аутентификации, события Netflow, результаты сканирования, конфиги, данные репутации Интернет-ресурсов и т.п. Не так важно, что будет выступать в качестве сборщика - SIEM, средства анализа защищенности, средства анализа рисков, системы управления журналами регистрации. Главное, чтобы выбранное средство могло:
Модули сбора и аналитики - это тот минимум, который позволяет выстроить систему обнаружения вторжений по любому из вышеописанных сценариев.И я специально не касаюсь того, как устроен модуль аналитки. Там ведь тоже вопросов выше крыши. Как бороться с ошибками первого и второго рода? Что является нормальным поведением, а что отклонением? Кто описывает профили поведения контролируемых систем? Я более чем уверен, что ФСБ не готова заниматься этой работой. Если уж не стали писать базовые модели угроз для нескольких десятков отраслей, то уж создавать десятки и сотни тысяч профилей точно не будут (в FIDNET первоначально речь шла о нескольких десятках миллионовпрофилей). Ждать этого от уважаемых мной рядовых сотрудников органов власти я тоже не могу - они и сигнатурные-то IDS не всегда настраивают, оставляя все "по умолчанию". Здесь же задача гораздо сложнее, чем просто поставить галочку напротив нужных сигнатур. Посмотрите на картинку ниже - можно ли по данному профилу сказать, речь идет об атаке на БД SQL или это просто пик обращений к ней?
А вот тут ситуация еще сложнее - два "аномальных" события. Одно предваряет другое. Кто будет описывать не только профиль трафика, но и правила корреляции между событиями?
Отдельная задача - визуализация полученных данных. При том объеме данных, которые будут поступать в систему, обычный табличный вариант не сильно подойдет. Да и традиционные карты сети тоже будут захлебываться в объеме данных. Вот так карта сети выглядит в системе визуализации для обычного предприятия (даже большого).
Все почти идеально (пример из реальной сетки). А теперь я покажу как такая карта выглядит для сети компании Cisco:
Попытка детализации карты не сильно облегчает жизнь:
Решить эту проблему можно - путем редизайна контролируемых сетей, сегментирования, применения модульного подхода и т.д. Но как заставить госорганы это сделать? Это вам не СКЗИ навязывать. Многие годами живут в плоской сети без всякой сегментации. И как в такой карте разбираться и отслеживать в ней инциденты ИБ?
Могу поделиться опытом , как Cisco проводила работы по автоматизации задачи оценки безопасности нашей сети на десятки тысяч узлов. Задача оказалась нетривиальной. В федеральной же сети узлов не десятки и даже не сотни тысяч - гораздо больше. И это только ПК, за которыми работают пользователи. Если вспомнить про M2M-взаимодействие, различные IP-устройства (принтеры, сенсоры ввода/вывода, датчики индустриальных систем и т.д.), то число узлов, которые должны будут мониториться системой обнаружения атак, будет измеряться миллионами.
Дальше начинается уже специфика и конкретика. Если в систему обнаружения атак входит реагирование, а в указе 31с оно прописано, то мы должны решить, как реагировать на обнаруженные атаки - просто уведомить "кого надо" или предпринимать более активные действия - контратака, блокирование, изоляция пострадавшего сегмента и т.д. Причем в зависимости от источника данных варианты реагирования и ликвидации последствий могут быть совершенно различными и спектр возможных вариантов просто зашкаливает. А еще они могут быть автоматическими, ручными и автоматизированными.
Мнение о том, что предлагаемая 31-м указом система обнаружения атак должна работать по принципу "установил и забыл", ошибочно с самого начала. Это совершенно не так. Это постоянная и кропотливая работа, требующая высокой квалификации от ее участников и немалых ресурсов (временных, людских, финансовых). Именно поэтому я скептически отношусь к идее, прописанной в Указе №31с. В теории такую систему создать не сложно - проблемы начинаются на практике. И пока я не вижу, чтобы кто-нибудь задумался о том, чтобы найти пути их решения до разработки системы, а не после. Если этот пост поможет ответственным за создание данной системы обратить внимание на тонкие моменты и подводные камни - уже неплохо. А если они привлекут к разработке концепции системы экспертное сообщество (правда, в это я не очень верю - ФСБ пока считает себя умнее всех), то будет вообще отлично. И еще неплохо подумать о том, кто и как будет эксплуатировать созданную систему?
ЗЫ. Я в своих постах не раз высказался о том, что у ФСБ нет достаточного количества квалифицированных специалистов, чтобы потянуть эту задачу. На чем базируется мое мнение? Если не брать некоторые сведения, которые у меня есть и которые я не буду афишировать, то достаточно взглянуть на этот вопрос с точки зрения логики. Вы видели хоть какой-нибудь документ от ФСБ по теме информационной безопасности, который бы вызвал у вас уважение и доверие к конторе, а также уверенность в ее компетенции? Я нет ;-( У меня даже к документам по криптографии есть немало претензий, а уж в этой-то теме регулятор собаку съел. Но время идет, меняются технологии, меняются подходы, а регулятор как сидит на своих "временных требованиях к СКЗИ" так и сидит. NIST и не только уже с тех пор не один и не два документа выпустили по теме управления ключами, выбора длин ключей в зависимости от задачи, облачной криптографии, а мы так и сидим в средневековье. "Святая Инквизиция" не хочет выпускать из своих рук знание о том, что Земля-то круглая. Правда все уже об этом знают, но официально регулятор хранит молчание и ничего не признает кроме принадлежащего себе сокровенного знания.
В других темах по информационной безопасности ФСБ пока "студенты" ;-( Достаточно вспомнить некоторые выступления сотрудников ФСБ по теме безопасности виртуализации и облаков. Они только-только начинают копать что-то отличное от криптографии. И они уступают специалистам коммерческих компаний, ВУЗов, госорганов, которые не связаны никакими ограничениями по части изучения международного опыта, международных стандартов и т.п. Это не то, чтобы плохо - это нормально. Все всегда с чего-то начинают. Плохо то, что ФСБ оккупировала эту тему и никого туда не пускает, считая себя умнее всех и засекречивая результаты своей работы. Может быть все-таки они одумаются?.. Или серьезный инцидент на каком-либо критически важном объекте заставит их одуматься?.. Последнего не хотелось бы.
Конечно, сложно, не зная целеполагания, предполагать, что же имели ввиду авторы 31-го указа, но вариантов на самом деле тут немного. Под описанной системой обнаружения атак может пониматься:
- Низкоуровневая система мониторинга вредоносной активности, направленной на информационные системы РФ (допустим, только на государственные информационные системы и КСИИ в КВО). Т.е. по сути - это территориально-распределенная IDS. Почему она не заработает я написал вчера и позавчера.
- Высокоуровневая система мониторинга, которая аккумулирует данные с разных источников. Некий ситуационный центр по ИБ (или Security Operation Center). При том зоопарке решений, используемых отечественными госорганами и КВО, построить такой SOC - задача нетривиальная. Еще более нетривиальная задача - визуализировать весь тот объем информации, который будет поступать в SOC. Это терабайты данных ежедневно.
- Центр сбора информации об инцидентах ИБ. Это наиболее просто реализуемая задача, но и она имеет кучу подводных камней, начиная от отсутствия единого формата для такой информации до нежелания госорганов светить такие сведения. Тут достаточно вспомнить процедуру обязательного уведомления Банка России в рамках отчетности по 2831-У. Но там хоть ответственность косвенная была за невыполнение обязательных требований ЦБ, а тут?...
- Система оповещения об уровне Интернет-угрозы. Это, пожалуй, самый простой путь реализации указа 31с. Достаточно просто поставить на сайт ФСБ иконку уровня угрозы от Cisco, Касперского или других вендоров и тем самым оповещать пользователей об уровне угроз. Я про это даже писал 10 лет назад.
Начать стоило бы с того, чтобы определиться - мы хотим иметь систему ориентированную вовнутрь или с зачатками прогнозирования? Первый вариант ограничен только данными, получаемыми из множества источников (сенсоров), разбросанных по госорганам и Интернет. В этом случае мы анализируем текущий уровень защищенности; не более того. Второй позволяет учитывать и внешнюю ситуацию в киберпространстве, атаки на иные ресурсы, в т.ч. и в других странах, тенденции мира "по ту сторону баррикад" и т.д. Первый путь чуть проще в реализации, т.к. поступаемые данные более формализованные, чем различные бюллетени, сообщения на "хакерских" форумах и другая неструктурированная информация.
Ядром (и первым элементом) любого варианта построения системы обнаружения атак является механизм сбора событий для последующего их анализа. В зависимости от охвата и глубины реализации системы этот список может быть очень широким и включать в себя сетевой трафик, логи сетевого оборудования, ОС, СУБД и приложений, события средств защиты, результаты идентификации/аутентификации, события Netflow, результаты сканирования, конфиги, данные репутации Интернет-ресурсов и т.п. Не так важно, что будет выступать в качестве сборщика - SIEM, средства анализа защищенности, средства анализа рисков, системы управления журналами регистрации. Главное, чтобы выбранное средство могло:
- собирать данные из всех источников
- собирать и хранить неструктурированные данные
- работать с большими объемами данных (сотни терабайт, а то и петабайт с эксабайтами)
- предоставить мощные аналитические возможности (причем на этом уровне они даже важнее, чем аналитика и модуль принятия решения на сенсоре)
- приоритезировать зафиксированные события.
Модули сбора и аналитики - это тот минимум, который позволяет выстроить систему обнаружения вторжений по любому из вышеописанных сценариев.И я специально не касаюсь того, как устроен модуль аналитки. Там ведь тоже вопросов выше крыши. Как бороться с ошибками первого и второго рода? Что является нормальным поведением, а что отклонением? Кто описывает профили поведения контролируемых систем? Я более чем уверен, что ФСБ не готова заниматься этой работой. Если уж не стали писать базовые модели угроз для нескольких десятков отраслей, то уж создавать десятки и сотни тысяч профилей точно не будут (в FIDNET первоначально речь шла о нескольких десятках миллионовпрофилей). Ждать этого от уважаемых мной рядовых сотрудников органов власти я тоже не могу - они и сигнатурные-то IDS не всегда настраивают, оставляя все "по умолчанию". Здесь же задача гораздо сложнее, чем просто поставить галочку напротив нужных сигнатур. Посмотрите на картинку ниже - можно ли по данному профилу сказать, речь идет об атаке на БД SQL или это просто пик обращений к ней?
А вот тут ситуация еще сложнее - два "аномальных" события. Одно предваряет другое. Кто будет описывать не только профиль трафика, но и правила корреляции между событиями?
Отдельная задача - визуализация полученных данных. При том объеме данных, которые будут поступать в систему, обычный табличный вариант не сильно подойдет. Да и традиционные карты сети тоже будут захлебываться в объеме данных. Вот так карта сети выглядит в системе визуализации для обычного предприятия (даже большого).
Все почти идеально (пример из реальной сетки). А теперь я покажу как такая карта выглядит для сети компании Cisco:
Попытка детализации карты не сильно облегчает жизнь:
Решить эту проблему можно - путем редизайна контролируемых сетей, сегментирования, применения модульного подхода и т.д. Но как заставить госорганы это сделать? Это вам не СКЗИ навязывать. Многие годами живут в плоской сети без всякой сегментации. И как в такой карте разбираться и отслеживать в ней инциденты ИБ?
Могу поделиться опытом , как Cisco проводила работы по автоматизации задачи оценки безопасности нашей сети на десятки тысяч узлов. Задача оказалась нетривиальной. В федеральной же сети узлов не десятки и даже не сотни тысяч - гораздо больше. И это только ПК, за которыми работают пользователи. Если вспомнить про M2M-взаимодействие, различные IP-устройства (принтеры, сенсоры ввода/вывода, датчики индустриальных систем и т.д.), то число узлов, которые должны будут мониториться системой обнаружения атак, будет измеряться миллионами.
Дальше начинается уже специфика и конкретика. Если в систему обнаружения атак входит реагирование, а в указе 31с оно прописано, то мы должны решить, как реагировать на обнаруженные атаки - просто уведомить "кого надо" или предпринимать более активные действия - контратака, блокирование, изоляция пострадавшего сегмента и т.д. Причем в зависимости от источника данных варианты реагирования и ликвидации последствий могут быть совершенно различными и спектр возможных вариантов просто зашкаливает. А еще они могут быть автоматическими, ручными и автоматизированными.
Мнение о том, что предлагаемая 31-м указом система обнаружения атак должна работать по принципу "установил и забыл", ошибочно с самого начала. Это совершенно не так. Это постоянная и кропотливая работа, требующая высокой квалификации от ее участников и немалых ресурсов (временных, людских, финансовых). Именно поэтому я скептически отношусь к идее, прописанной в Указе №31с. В теории такую систему создать не сложно - проблемы начинаются на практике. И пока я не вижу, чтобы кто-нибудь задумался о том, чтобы найти пути их решения до разработки системы, а не после. Если этот пост поможет ответственным за создание данной системы обратить внимание на тонкие моменты и подводные камни - уже неплохо. А если они привлекут к разработке концепции системы экспертное сообщество (правда, в это я не очень верю - ФСБ пока считает себя умнее всех), то будет вообще отлично. И еще неплохо подумать о том, кто и как будет эксплуатировать созданную систему?
ЗЫ. Я в своих постах не раз высказался о том, что у ФСБ нет достаточного количества квалифицированных специалистов, чтобы потянуть эту задачу. На чем базируется мое мнение? Если не брать некоторые сведения, которые у меня есть и которые я не буду афишировать, то достаточно взглянуть на этот вопрос с точки зрения логики. Вы видели хоть какой-нибудь документ от ФСБ по теме информационной безопасности, который бы вызвал у вас уважение и доверие к конторе, а также уверенность в ее компетенции? Я нет ;-( У меня даже к документам по криптографии есть немало претензий, а уж в этой-то теме регулятор собаку съел. Но время идет, меняются технологии, меняются подходы, а регулятор как сидит на своих "временных требованиях к СКЗИ" так и сидит. NIST и не только уже с тех пор не один и не два документа выпустили по теме управления ключами, выбора длин ключей в зависимости от задачи, облачной криптографии, а мы так и сидим в средневековье. "Святая Инквизиция" не хочет выпускать из своих рук знание о том, что Земля-то круглая. Правда все уже об этом знают, но официально регулятор хранит молчание и ничего не признает кроме принадлежащего себе сокровенного знания.
В других темах по информационной безопасности ФСБ пока "студенты" ;-( Достаточно вспомнить некоторые выступления сотрудников ФСБ по теме безопасности виртуализации и облаков. Они только-только начинают копать что-то отличное от криптографии. И они уступают специалистам коммерческих компаний, ВУЗов, госорганов, которые не связаны никакими ограничениями по части изучения международного опыта, международных стандартов и т.п. Это не то, чтобы плохо - это нормально. Все всегда с чего-то начинают. Плохо то, что ФСБ оккупировала эту тему и никого туда не пускает, считая себя умнее всех и засекречивая результаты своей работы. Может быть все-таки они одумаются?.. Или серьезный инцидент на каком-либо критически важном объекте заставит их одуматься?.. Последнего не хотелось бы.
