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