PDCA для менеджмента уязвимостей

В прошлый раз я уже отметил появление в нормативных документах ФСТЭК итерационного подхода PDCA к совершенствованию мер защиты. Раздел приказа 235, посвященный этому вопросу (п. 28-37) сформулирован довольно общими словами: например, из текста неочевидно, о планировании, реализации, контроле и совершенствовании каких именно мероприятий идет речь. Такая неопределенность позволяет оператору информационной системы самостоятельно решать, как именно реализовывать такой подход. Например, если бы мне понадобилось выстраивать процесс менеджмента уязвимостей на значимом объекте КИИ, получилось бы примерно следующее.

P = Планирование

Задача менеджмента уязвимостей сформулирована в приказах ФСТЭК довольно жестко: к моменту приемки (для ГИС - аттестации) по результатам анализа уязвимостей должно быть подтверждено, что в информационной системе отсутствуют уязвимости, как минимум содержащиеся в банке данных угроз безопасности информации ФСТЭК России, или выявленные уязвимости не приводят к возникновению угроз безопасности информации (п. 12.6 приказа 239, п. 16.2 приказа 17). Очевидно, что регулятор считает это одним из необходимых условий безопасного состояния информационной системы.

Для буквального выполнения этого требования достаточно выявлять и устранять уязвимости, публикуемые в БДУ ФСТЭК, что соответствует мере защиты АУД.2. Содержание этой меры еще не раскрыто в методических документах, но она соответствует мере защиты АНЗ.1, описанной в методическом документе "Меры защиты информации в ГИС", так что можно ожидать, что и ее содержание будет очень похожим, Та, в свою очередь требует проводить сканирование компонентов информационной системы с помощью средства анализа защищенности (обязательное усиление 1) и делать это с периодичностью, которую определяет само оператор. Таким образом, в рамках реализации меры защиты АУД.2 нам нужно предусмотреть мероприятие "Сканирование информационных систем и устранение выявленных уязвимостей", которое мы будем выполнять периодически.

В действительности, если мы всерьез занимаемся вопросами безопасности своих информационных систем, в процессе менеджмента уязвимостей нам нужны и другие мероприятия, например:

• проверка настроек, значимых с точки зрения безопасности (например. на основе чеклистов);
• отслеживание публикаций о появлении уязвимостей нулевого/первого дня;
• анализ уязвимостей внедряемых или модернизируемых информационных систем (black-box анализ, анализ исходных текстов и т.п.).

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

Упростим себе задачу и и ограничим процесс менеджмента уязвимостей только уязвимостями, которые обнаруживают сканеры. Организационно наше мероприятие будет выглядеть примерно так:

Ответственное подразделение (назовем их SOC) с заданной периодичностью сканирует информационную систему. По результатам сканирования могут обнаружиться уязвимости, требующие устранения. Заявку на устранение этих уязвимостей со своими рекомендациями по устранению SOC передает в IT. IT ищет способ устранить уязвимость - спектр возможных решений может варьироваться от установки обновления до модернизации системы (например. если уязвимое ПО больше не поддерживается разработчиком). В случае успешного оперативного устранения IT сообщает об этом в SOC, и при следующем сканировании устранение будет подтверждено. Устранение уязвимостей, требующих длительной работы, будет подтверждено на последующих итерациях сканирования, когда изменения наконец будут внесены в систему.

На стадии планирования мы можем формализовать цели процесса:

1. Все уязвимости, пригодные для реализации угроз (экплуатабельные), должны устраняться. При этом понятие "эксплуатабельность" можно формализовать в виде конкретных элементов вектора CVSS.
2. Эксплуатабельные уязвимости должны устраняться своевременно. При этом понятие "своевременно" можно тоже формализовать как "среднее время присутствия уязвимости в ИС не должно превышать К дней".

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

1. Предельно допустимое время обнаружения уязвимости (в данном примере - с момента начала очередной итерации до момента выдачи подразделению IT заявки на устранение уязвимостей).
2. Предельно допустимое время устранения уязвимости (с момента получения заявки до того момента, как устранение уязвимости будет подтверждено).

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

1. Зная количество серверов и рабочих мест в информационной системе, а также среднее время сканирования одного узла, мы можем оценить, сколько сканеров нужно нашему SOC.
2. Зная, сколько времени в среднем тратится одним специалистом на обработку результатов сканирования, мы модем оценить, сколько специалистов нам нужно, чтобы уложиться в норматив.

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

D = Реализация

Итак, мы разворачиваем сканеры, озадачиваем нужное количество специалистов и запускаем процесс. Все, что нам нужно на этой стадии - это исходные данные для расчета показателей эффективности. Так как в этом примере показатели у нас временные, нам нужно фиксировать по каждой выявленной уязвимости дату сканирования, при котором она была обнаружена, и дату сканирования, при котором было подтверждено ее устранение.

C = Контроль

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

1. Проверка того, что требования по выявлению и устранению уязвимостей (требования к реализации мер АНЗ.1 приказа 17 или АУД.2 приказа 239) действительно выполнятся.
2. Оценка эффективности этих мер

С проверкой выполнения требований все более или менее понятно - классический аудит или самооценка. С эффективностью интереснее. Даже если мы сами себе поставили норматив "эксплуатабельная уязвимость должна обнаруживаться и устраняться в течение двух недель", и мы в этот норматив укладываемся - это еще не значит, что наша мера защиты эффективна: фактически мы считаем нормальным, что опасная уязвимость может существовать и использоваться нарушителем в течение целых двух недель. Такой показатель полезен для демонстрации прогресса ("в прошлом-то году и за месяц устранять не получалось"), но не как абсолютный показатель.

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

Разделим суммарную длительность безопасного состояния на длительность отчетного периода - и получим интегральный показатель, демонстрирующий, насколько мала доля времени жизни информационной системы, в течение которой можно не опасаться, что ее взломают.

A = Совершенствование

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

1. Точность измерения (т.е. как часто мы сканируем систему)
2. Время, затрачиваемое на основные операции (опять же, как часто мы сканируем систему плюс время, затрачиваемое на анализ результатов, плюс время, в течение которого уязвимость реально устраняется).

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

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

При большом количестве информационных систем трудозатраты на анализ масштабируются отнюдь не линейно. Состав программного обеспечения двух раных информационных систем, построенных на основе общей платформы (например, на одной серверной операционной системе Microsoft Windows или на одном дистрибутиве Linux) может совпадать на 60-80%.  Сканируя все эти информационные системы и консолидируя результаты, мы переходим от анализа уязвимостей отдельных информационных систем к анализу уязвимостей определенного перечня программ. Эта задача хорошо распараллеливается, и при этом можно выполнять одновременный анализ уязвимостей большого количества информационных систем небольшим количеством специалистов. И чем выше степень унификации ПО в нашей инфраструктуре, тем ниже удельные трудозатраты на анализ уязвимостей.

Оптимизация работ по устранению уязвимостей - гораздо более сложная задача, но и тут есть некоторые очевидные пути решения. У некоторых заказчиков я наблюдал совершенно замечательный подход, когда выделялся и принимался в качестве стандарта определенный набор типовых компонентов (например, при создании информационных систем должны применяться вот такие серверные операционные системы, вот такие СУБД, вот такие CMS и т.п.). При этом для таких типовых компонентов принималось правило в обязательном порядке устанавливать рекомендованные разработчиками обновления с минимальным тестированием работоспособности, а в договоры заказной разработки закладывалась гарантийная поддержка, по которой неработоспособность системы из-за установки обновления типового компонента признавалась гарантийным случаем. Помимо прочих выгод такая унификация очень сильно ускоряет устранение уязвимостей.

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

Что в результате?

А в результате мы получаем одновременно и формальное выполнение требований регулятора, и постепенное, эволюционное развитие мер защиты. В самом начале, создавая систему защиты "с нуля", мы можем установить себе "щадящие" нормативы и целевые значения. Оценка покажет, что своей цели мы не достигли, и на следующей итерации мы постараемся процесс улучшить. Оценим результат, увидим, что у нас ничего не получилось - и на следующей итерации попробуем другое решение. И так далее, пока результат не начнет нас устраивать.

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

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

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

Темные века (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 попытка разработчика проигнорировать сообщение об уязвимости фактически закрывает для него весь государственный сектор. Не знаю, как это повлияет на зарубежных производителей, но по опыту взаимодействовать с отечественными разработчиками порой даже сложнее, чем с зарубежными.

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