Процесс управления уязвимостями в контексте нормативных документов ФСТЭК

"Я не злопамятный, я записываю" (с) Бывает, подискутируешь в комментах у кого-нибудь, возьмешь паузу на подумать – и опаньки: и дискуссия, и инфоповод скрылись бесследно. И что, зря старался, думал? Придется, видимо, реанимировать блог на такой случай.

Алексей Лукацкий как-то задал разумный вопрос:

А действительно, надо ли устранять их все? И требует ли этого регулятор?

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

1. Требования, которые предъявляются к информационной системе в процессе ее эксплуатации и которые должны выполнняться оператором этой системы.
2. Требования, которые предъявляются к информационной системе в процессе ее создания/приемки и которые должны выполняться разработчиками этой системы.
3. Требования, которые предъявляются к программному обеспечению, претендующим на звание "безопасное" (в том числе - к сертифицируемым средствам защиты) и которые должны выполняться вендорами (разработчиками или заявителями)

Требования, предъявляемые к средствам защиты и прочему безопасному ПО, - предмет отдельного обсуждения, их мы рассмотрим в другой раз. К слову: Алексей имел в виду именно этот случай, хотя участники дискуссии, судя по комментариям, восприняли это как обсуждение установки обновлений безопасности.

Требования к информационной системе в процессе ее создания определяются в трех из четырех приказов ФСТЭК для трех разных случаев (ГИС, АСУ ТП и значимые объекты КИИ) совершенно одинаково:

Приказ ФСТЭК №17

16. Внедрение системы защиты информации информационной системы организуется обладателем информации (заказчиком). Внедрение системы защиты информации информационной системы осуществляется в соответствии с проектной и эксплуатационной документацией на систему защиты информации информационной системы и в том числе включает:

• ...
• анализ уязвимостей информационной системы и принятие мер защиты информации по их устранению;
• приемочные испытания системы защиты информации информационной системы.

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

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

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

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

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

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

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

• для приказов 17 и 21 (и пока еще действующей редакции приказа 31) - меры защиты "АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей" и "АНЗ.2 Контроль установки обновлений программного обеспечения, включая обновление программного обеспечения средств защиты информации";
• для приказа 239 и новой редакции приказа 31 - мера защиты "АУД.2 Анализ уязвимостей и их устранение".

Для приказов 17 и 21 требования к мере защиты приведены в методическом документе "Меры защиты информации в ГИС". При этом отмечается:

Требования к реализации АНЗ.1: Оператором должны осуществляться выявление (поиск), анализ и устранение уязвимостей в информационной системе.

...

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

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

...

Требования к реализации АНЗ.2: Оператором должен осуществляться контроль установки обновлений программного обеспечения, включая программное обеспечение средств защиты информации и программное обеспечение базовой системы ввода-вывода.

...

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

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

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

Для приказов 31 и 239 подобного документа пока нет (его принятие ожидается в этом году), зато для критической информационной инфраструктуры есть интересный приказ №235, и интересен он своим последним разделом.

28. В рамках функционирования системы безопасности субъектом критической информационной инфраструктуры должны быть внедрены следующие процессы:

• планирование и разработка мероприятий по обеспечению безопасности значимых объектов критической информационной инфраструктуры;
• реализация (внедрение) мероприятий по обеспечению безопасности значимых объектов критической информационной инфраструктуры;
• контроль состояния безопасности значимых объектов критической информационной инфраструктуры;
• совершенствование безопасности значимых объектов критической информационной инфраструктуры.

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

Но об этом в другой раз.