[ad_1]
Недавно сказал журналистам, что нормативные документы ФСТЭК заметно
эволюционировали. И это не реверанс в сторону регулятора: изменения хорошо видны, если посмотреть на динамику раскрытия в этих документах требований,
относящихся к установке обновлений и менеджменту уязвимостей. Как это происходило, можно наглядно посмотреть на примере.В начальный период истории российской ИБ нормативные требования по защите
информации (требования по защите государственной тайны в этой и остальных
публикациях не рассматриваю принципиально) предъявлялись только к
государственным информационным системам, и основным нормативным документом
являлись «Специальные требования и рекомендации по технической защите
конфиденциальной информации». Если опустить организационные меры,
защиту речевой информации и защиту от утечек по ПЭМИН, то в сухом остатке имеем:
- Информационная система в целом должна соответствовать требованиям
руководящего документа «Классификация автоматизированных систем и требования
по защите информации» (РД АС). - Операционные системы должны соответствовать требованиям руководящего
документа «Средства вычислительной техники. Показатели защищенности от
несанкционированного доступа к информации» (РД СВТ). А поскольку таких в тот
момент не было, приходилось устанавливать на обычные ОС специализированные
средства защиты информации от несанкционированного доступа, “доводящие” ОС
до соответствия требованиям этого документа. - На сетевом периметре должны применяться межсетевые экраны,
соответствующий требованиям «Средства вычислительной техники. Межсетевые
экраны. Показатели защищенности от несанкционированного доступа к
информации» (РД МЭ). - Должны применяться антивирусы. Как применяться и что они должны
уметь – не определено.
Во-первых, почитав упомянутые документы, можно заметить, что они предъявляют требования
к функциям, которые должны выполнять механизмы безопасности, но ничего не
говорят о качестве реализации этих функций. Например, тот факт, что известная
ERP при аутентификации пользователя использовала только первые восемь символов
пароля и игнорировала регистр, не мешал ей соответствовать требованиям РД. Во-вторых, в нормативных
документах того времени понятие “уязвимость” отсутствовало, а сама
возможность взлома информационной системы с использованием уязвимостей
рассматривалась как нечто гипотетически возможное.
В итоге с высоты сегодняшнего опыта видно, что даже при буквальном исполнении
нормативных требований система может быть совершенно беззащитной перед
атакующим. Межсетевые экраны сетевого уровня и функции безопасности, реализованные в самом веб-интерфейсе,
не защищают систему от атак, характерных
для веб-приложений, а применение наложенных СЗИ направлено на защиту только самих
операционных систем. При этом даже сами эти СЗИ могут вносить в информационную систему
новые уязвимости: так, в драйвере одного из популярных СЗИ присутствовал ряд
критических уязвимостей, позволявших хакеру получать контроль над ядром
операционной системы. Эти уязвимости кочевали из версии в версию, а для их
устранения потребовалось опубликование PoC-эксплойта сторонним исследователем и
вмешательство регулятора.
Есть у описанного подхода и другая проблема: проектировщики информационных
систем иногда буквально исполняли требования РД, не заботясь о смысле этих
требований. Документ требует, чтобы в информационной системе были определенные
функции безопасности? Хорошо, мы установим в операционную систему средства
защиты, которые эти функции выполняют. Что говорите, пользователи работают через
веб-интерфейс и эти функции нужно реализовать в веб-интерфейсе? А в документе об
этом прямо не сказано, так что “к пуговицам претензий нет”. Да, это вопрос
добросовестности проектировщиков и тех, кто подписывает для таких информационных
систем аттестаты соответствия. Но с подобным приходится встречаться и сегодня.
В июне 1999 г. комплект РД был дополнен четвертым документом – «Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей». Сертификация на соответствие требованиям этого документа требует предоставления испытательной лаборатории исходного кода программ, а в самом документе упоминается статический и динамический анализ этого кода. До сих пор многие считают, что сертификация на уровень контроля отсутствия НДВ означает проверку отсутствия уязвимостей, – и это глубокое заблуждение.
Действительно, среди выполняемых проверок есть “синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных программных конструкций” — и на этом все. На момент принятия документа перечня “потенциально опасных конструкций” еще не было, и первые серьезные работы по классификации уязвимостей и систематизации ошибок, которые приводят к их появлению, начались более, чем через десять лет после принятия документа. В остальном контроль отсутствия НДВ, и в том числе – динамический анализ кода, заключается в выявлении фрагментов кода, которые “непонятно, что делают”, в том числе – программных закладок.
Но это не самая большая проблема документа. Основная трудность – необходимость получения исходных кодов. Действующее законодательство не позволяет потребителю требовать у правообладателя исходники программ и прямо запрещает пытаться восстановить исходный текст без разрешения правообладателя, и эта проблема принципиально неразрешима. Да, в тот период Министерство обороны смогло себе позволить запретить использовать в ведомстве программные средства, производители которых отказываются предоставлять исходные коды, но этот подход тогда так и не удалось распространить на всю сферу государственного управления.
В итоге контроль отсутствия НДВ проводится только для средств защиты информации в процессе их сертификации. Да, для тех самых средств защиты информации, которые в эот период истории по-прежнему неспособны защитить информационную систему в нашем примере от характерных для нее атак.
Первой ласточкой будущих изменений стало принятие в качестве руководящих документов семейства международных стандартов Common Criteria (ISO 15408 и ISO 18045). Документы предусматривают, в частности, в зависимости от уровня доверия к результатам оценки, проведение проверки того, что установлены все необходимые обновления безопасности, а также проведение самостоятельного поиска уязвимостей разработчиком и независимого поиска уязвимостей оценщиком. К сожалению, стандарт, который изначально позиционировался как методика покомпонентной оценки защищенности сложных информационных систем, и в России, и за рубежом применяется только для сертификации отдельных средств защиты, и в этом смысле ничего полезного с точки зрения борьбы с уязвимостями в информационных системах он так и не добавил.
Зато в 2010 году был принят принципиально новый по своей сути приказ №58 о методах и способах защиты информации в информационных системах персональных данных. Документ официально признавал опасность использования программных уязвимостей нарушителем и требовал:
- применять средства обнаружения вторжений;
- проводить поиск и устранение уязвимостей с помощью средств анализа защищенности.
Добросовестное выполнение этих требований уже могло заметно изменить картину: новые меры защиты требовали устранять известные уязвимости “серийного” программного обеспечения и одновременно отслеживать попытки применения известных эксплойтов. Методы, которые позволили бы обнаруживать уязвимости в заказных компонентах, в документе отсутствовали. На даже в таком урезанном виде новые меры защиты в нашем примере способны сильно усложнить жизни атакующим. Применение WAF в качестве средства обнаружения вторжений отсечет скрипт-кидди и заставит более продвинутых нарушителей пытаться искать способы обхода фильтрации контента WAFом, а это — очень нетривиальная задача.
Да, документ был обязателен только для информационных систем персональных данных. Да, этих мер недостаточно для защиты от APT. Но уж такой примитив, как WannaCry и Petya, эти меры остановить способны. Жаль только, что “еж – птица гордая, пока не пнешь – не полетит”, и даже такие очевидные меры защиты полноценно реализуются далеко не во всех информационных системах.
Кардинально изменил ситуацию в подходе к регулированию приказ ФСТЭК №17, принятый в 2013 году, и дополняющий его методический документ “Меры защиты информации в государственных информационных системах”.
Во-первых, документ предписывает формировать требования безопасности, основываясь на анализе уязвимостей (на стадии проектирования – потенциальных, на стадии внедрения – реальных, свойственных выбранным компонентам, на стадии приемки – фактических, присутствующих в системе здесь и сейчас). Причем в ходе приемки требуется доказать, что в системе нет уязвимостей или что имеющиеся уязвимости невозможно использовать. В редакции 2017 года в документ была добавлена обязанность проводить тестирование на проникновение при приемке системы – и это отчасти решает проблему “отсутствия претензий к пуговицам”. Пентестеров не интересует, что именно написано в требованиях к системе, они ищут способы реализовать какие-либо угрозы. И если угрозу реализовать удается, это – недоработка, требующая безусловного устранения независимо от того, что написано в требованиях к системе. Правда, по-прежнему остается открытым вопрос добросовестности и квалификации специалистов, проводящих приемку.
Во-вторых, в базовые требования безопасности включен целый ряд мер, направленных на противодействие использованию уязвимостей:
- анализ и устранение уязвимостей (АНЗ.1) и контроль установки обновлений (АНЗ.2);
- защита от брутфорса паролей (ИАФ.3);
- анализ событий безопасности, свидетельствующих о возможном инциденте (все семейство РСБ);
- анализ уязвимостей и обнаружение вторжений (семейства АНЗ и СОВ) и т.п.
Отдельное направление регулирования – это требования к SDLC, обязательные для разработчиков, планирующих сертифицировать свои решения в системе сертификации ФСТЭК, и рекомендательные для остальных. Стандарт предписывает проводить анализ угроз для создаваемого приложения и определять фичи продукта, необходимые для противодействия этим угроззам. Стандарт определяет целый ряд мер контроля качества кода: стандарты оформления кода (фактически coding standards), экспертизу кода, статический и динамический анализ для поиска уязвимостей и т.п. Взамен третьей части ГОСТ 15408 (требования доверия при оценке защищенности информационных систем) принят новый документ, определяющий уровни доверия и соответствующие им меры контроля в рамках SDLC. В частности, для всех программных компонентов, реализующих функции безопасности государственных информационных систем (кроме низшего класса защищенности), становится обязательным проведение анализа исходного кода.
Второе интересное направление – это работа с уязвимостями нулевого дня, заслуживающая отдельной публикации. Если коротко, то в соответствии с новым регламентом ведения Банка данных угроз и уязвимостей, ФСТЭК получает функции по координации взаимодействия между исследователем, обнаружившим уязвимость нулевого дня, и разработчиком, в решении которого уязвимость найдена. Эту же функцию выполняют и зарубежные CERT/CSIRT, но в случае БДУ ФСТЭК есть интересный нюанс: в силу требований все того же приказа №17 попытка разработчика проигнорировать сообщение об уязвимости фактически закрывает для него весь государственный сектор. Не знаю, как это повлияет на зарубежных производителей, но по опыту взаимодействовать с отечественными разработчиками порой даже сложнее, чем с зарубежными.
Как видим, за четверть века сам подход к регулированию вопросов менеджмента уязвимостей изменился радикально: от полного игнорирования проблемы до активного участия регулятора в накоплении знаний об уязвимостях и в контроле их устранения. А учитывая, насколько легко хакеры взламывают самые разные, порой критические информационные, это направление регулирования сейчас требует особенного внимания.
[ad_2]
Источник