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