Эволюция нормативных требований к менеджменту уязвимостей

Недавно сказал журналистам, что нормативные документы ФСТЭК заметно эволюционировали. И это не реверанс в сторону регулятора: изменения хорошо видны, если посмотреть на динамику раскрытия в этих документах требований, относящихся к установке обновлений и менеджменту уязвимостей. Как это происходило, можно наглядно посмотреть на примере.

Темные века (1992-1999 г.)

В начальный период истории российской ИБ нормативные требования по защите информации (требования по защите государственной тайны в этой и остальных публикациях не рассматриваю принципиально) предъявлялись только к государственным информационным системам, и основным нормативным документом являлись «Специальные требования и рекомендации по технической защите конфиденциальной информации». Если опустить организационные меры, защиту речевой информации и защиту от утечек по ПЭМИН, то в сухом остатке имеем:

1. Информационная система в целом должна соответствовать требованиям руководящего документа «Классификация автоматизированных систем и требования по защите информации» (РД АС).
2. Операционные системы должны соответствовать требованиям руководящего документа «Средства вычислительной техники. Показатели защищенности от несанкционированного доступа к информации» (РД СВТ). А поскольку таких в тот момент не было, приходилось устанавливать на обычные ОС специализированные средства защиты информации от несанкционированного доступа, “доводящие” ОС до соответствия требованиям этого документа.
3. На сетевом периметре должны применяться межсетевые экраны, соответствующий требованиям «Средства вычислительной техники. Межсетевые экраны. Показатели защищенности от несанкционированного доступа к информации» (РД МЭ).
4. Должны применяться антивирусы. Как применяться и что они должны уметь – не определено.

Во-первых, почитав упомянутые документы, можно заметить, что они предъявляют требования к функциям, которые должны выполнять механизмы безопасности, но ничего не говорят о качестве реализации этих функций. Например, тот факт, что известная ERP при аутентификации пользователя использовала только первые восемь символов пароля и игнорировала регистр, не мешал ей соответствовать требованиям РД. Во-вторых, в нормативных документах того времени понятие “уязвимость” отсутствовало, а сама возможность взлома информационной системы с использованием уязвимостей рассматривалась как нечто гипотетически возможное.

В итоге с высоты сегодняшнего опыта видно, что даже при буквальном исполнении нормативных требований система может быть совершенно беззащитной перед атакующим. Межсетевые экраны сетевого уровня и функции безопасности, реализованные в самом веб-интерфейсе, не защищают систему от атак, характерных для веб-приложений, а применение наложенных СЗИ направлено на защиту только самих операционных систем. При этом даже сами эти СЗИ могут вносить в информационную систему новые уязвимости: так, в драйвере одного из популярных СЗИ присутствовал ряд критических уязвимостей, позволявших хакеру получать контроль над ядром операционной системы. Эти уязвимости кочевали из версии в версию, а для их устранения потребовалось опубликование PoC-эксплойта сторонним исследователем и вмешательство регулятора.

Есть у описанного подхода и другая проблема: проектировщики информационных систем иногда буквально исполняли требования РД, не заботясь о смысле этих требований. Документ требует, чтобы в информационной системе были определенные функции безопасности? Хорошо, мы установим в операционную систему средства защиты, которые эти функции выполняют. Что говорите, пользователи работают через веб-интерфейс и эти функции нужно реализовать в веб-интерфейсе? А в документе об этом прямо не сказано, так что “к пуговицам претензий нет”. Да, это вопрос добросовестности проектировщиков и тех, кто подписывает для таких информационных систем аттестаты соответствия. Но с подобным приходится встречаться и сегодня.

Средние века (1999–2010 г.)

В июне 1999 г. комплект РД был дополнен четвертым документом – «Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей». Сертификация на соответствие требованиям этого документа требует предоставления испытательной лаборатории исходного кода программ, а в самом документе упоминается статический и динамический анализ этого кода. До сих пор многие считают, что сертификация на уровень контроля отсутствия НДВ означает проверку отсутствия уязвимостей, – и это глубокое заблуждение.

Действительно, среди выполняемых проверок есть “синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных программных конструкций” - и на этом все. На момент принятия документа перечня “потенциально опасных конструкций” еще не было, и первые серьезные работы по классификации уязвимостей и систематизации ошибок, которые приводят к их появлению, начались более, чем через десять лет после принятия документа. В остальном контроль отсутствия НДВ, и в том числе – динамический анализ кода, заключается в выявлении фрагментов кода, которые “непонятно, что делают”, в том числе – программных закладок.

Но это не самая большая проблема документа. Основная трудность – необходимость получения исходных кодов. Действующее законодательство не позволяет потребителю требовать у правообладателя исходники программ и прямо запрещает пытаться восстановить исходный текст без разрешения правообладателя, и эта проблема принципиально неразрешима. Да, в тот период Министерство обороны смогло себе позволить запретить использовать в ведомстве программные средства, производители которых отказываются предоставлять исходные коды, но этот подход тогда так и не удалось распространить на всю сферу государственного управления.

В итоге контроль отсутствия НДВ проводится только для средств защиты информации в процессе их сертификации. Да, для тех самых средств защиты информации, которые в эот период истории по-прежнему неспособны защитить информационную систему в нашем примере от характерных для нее атак.

Эпоха Возрождения (2010-2013 г.)

Первой ласточкой будущих изменений стало принятие в качестве руководящих документов семейства международных стандартов Common Criteria (ISO 15408 и ISO 18045). Документы предусматривают, в частности, в зависимости от уровня доверия к результатам оценки, проведение проверки того, что установлены все необходимые обновления безопасности, а также проведение самостоятельного поиска уязвимостей разработчиком и независимого поиска уязвимостей оценщиком. К сожалению, стандарт, который изначально позиционировался как методика покомпонентной оценки защищенности сложных информационных систем, и в России, и за рубежом применяется только для сертификации отдельных средств защиты, и в этом смысле ничего полезного с точки зрения борьбы с уязвимостями в информационных системах он так и не добавил.

Зато в 2010 году был принят принципиально новый по своей сути приказ №58 о методах и способах защиты информации в информационных системах персональных данных. Документ официально признавал опасность использования программных уязвимостей нарушителем и требовал:

• применять средства обнаружения вторжений;
• проводить поиск и устранение уязвимостей с помощью средств анализа защищенности.

Добросовестное выполнение этих требований уже могло заметно изменить картину: новые меры защиты требовали устранять известные уязвимости “серийного” программного обеспечения и одновременно отслеживать попытки применения известных эксплойтов. Методы, которые позволили бы обнаруживать уязвимости в заказных компонентах, в документе отсутствовали. На даже в таком урезанном виде новые меры защиты в нашем примере способны сильно усложнить жизни атакующим. Применение WAF в качестве средства обнаружения вторжений отсечет скрипт-кидди и заставит более продвинутых нарушителей пытаться искать способы обхода фильтрации контента WAFом, а это - очень нетривиальная задача.

Да, документ был обязателен только для информационных систем персональных данных. Да, этих мер недостаточно для защиты от APT. Но уж такой примитив, как WannaCry и Petya, эти меры остановить способны. Жаль только, что “еж – птица гордая, пока не пнешь – не полетит”, и даже такие очевидные меры защиты полноценно реализуются далеко не во всех информационных системах.

Новейшая история (2013 г. – н.в.)

Кардинально изменил ситуацию в подходе к регулированию приказ ФСТЭК №17, принятый в 2013 году, и дополняющий его методический документ “Меры защиты информации в государственных информационных системах”.

Во-первых, документ предписывает формировать требования безопасности, основываясь на анализе уязвимостей (на стадии проектирования – потенциальных, на стадии внедрения – реальных, свойственных выбранным компонентам, на стадии приемки – фактических, присутствующих в системе здесь и сейчас). Причем в ходе приемки требуется доказать, что в системе нет уязвимостей или что имеющиеся уязвимости невозможно использовать. В редакции 2017 года в документ была добавлена обязанность проводить тестирование на проникновение при приемке системы – и это отчасти решает проблему “отсутствия претензий к пуговицам”. Пентестеров не интересует, что именно написано в требованиях к системе, они ищут способы реализовать какие-либо угрозы. И если угрозу реализовать удается, это – недоработка, требующая безусловного устранения независимо от того, что написано в требованиях к системе. Правда, по-прежнему остается открытым вопрос добросовестности и квалификации специалистов, проводящих приемку.

Во-вторых, в базовые требования безопасности включен целый ряд мер, направленных на противодействие использованию уязвимостей:

• анализ и устранение уязвимостей (АНЗ.1) и контроль установки обновлений (АНЗ.2);
• защита от брутфорса паролей (ИАФ.3);
• анализ событий безопасности, свидетельствующих о возможном инциденте (все семейство РСБ);
• анализ уязвимостей и обнаружение вторжений (семейства АНЗ и СОВ) и т.п.

Отдельное направление регулирования – это требования к SDLC, обязательные для разработчиков, планирующих сертифицировать свои решения в системе сертификации ФСТЭК, и рекомендательные для остальных. Стандарт предписывает проводить анализ угроз для создаваемого приложения и определять фичи продукта, необходимые для противодействия этим угроззам. Стандарт определяет целый ряд мер контроля качества кода: стандарты оформления кода (фактически coding standards), экспертизу кода, статический и динамический анализ для поиска уязвимостей и т.п. Взамен третьей части ГОСТ 15408 (требования доверия при оценке защищенности информационных систем) принят новый документ, определяющий уровни доверия и соответствующие им меры контроля в рамках SDLC. В частности, для всех программных компонентов, реализующих функции безопасности государственных информационных систем (кроме низшего класса защищенности), становится обязательным проведение анализа исходного кода.

Второе интересное направление – это работа с уязвимостями нулевого дня, заслуживающая отдельной публикации. Если коротко, то в соответствии с новым регламентом ведения Банка данных угроз и уязвимостей, ФСТЭК получает функции по координации взаимодействия между исследователем, обнаружившим уязвимость нулевого дня, и разработчиком, в решении которого уязвимость найдена. Эту же функцию выполняют и зарубежные CERT/CSIRT, но в случае БДУ ФСТЭК есть интересный нюанс: в силу требований все того же приказа №17 попытка разработчика проигнорировать сообщение об уязвимости фактически закрывает для него весь государственный сектор. Не знаю, как это повлияет на зарубежных производителей, но по опыту взаимодействовать с отечественными разработчиками порой даже сложнее, чем с зарубежными.

Как видим, за четверть века сам подход к регулированию вопросов менеджмента уязвимостей изменился радикально: от полного игнорирования проблемы до активного участия регулятора в накоплении знаний об уязвимостях и в контроле их устранения. А учитывая, насколько легко хакеры взламывают самые разные, порой критические информационные, это направление регулирования сейчас требует особенного внимания.