Безопасность КИИ: взаимодействие с НКЦКИ

Это еще один часто задаваемый вопрос, причем от словосочетания "подключиться к ГосСОПКА" у меня уже глаз начинает дергаться. С огромным уважением отношусь к Алексею Комарову, и в целом согласен с его выводами. Но есть пара моментов, которые не могу не прокомментировать.

Обязанности, установленные нормативным документом, не стоит рассматривать в отрыве друг от друга - они взаимосвязаны. Вот произошел у вас на значимом объекте инцидент. Согласно букве закона этим инцидентом связаны три обязанности:

• вы обязаны об этом инциденте сообщить в НКЦКИ (статья 9 п. 3 ФЗ-187);
• вы обязаны на этот инцидент отреагировать в порядке, установленном ФСБ(там же, статья 9 п. 2);
• а для того, чтобы суметь все это проделать, вы еще раньше должны были создать систему защиты, соответствующую требованиям ФСТЭК.

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

Итак, в подразделение ИБ поступила информация (от SIEM или от пользователей) о возможном инциденте. Эта информация перепроверяется, и если факт инцидента подтвержден, субъект информирует НКЦКИ. Дальше по обстановке:

• подразделение ИБ (или персонал объекта) может быть достаточно компетентным (или подобные инциденты уже могли достаточно часто случаться в прошлом), чтобы с инцидентом можно было справиться самостоятельно;
• необходимой компетенции может не быть, и тогда нужна "помощь зала".

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

Безусловно, такие сообщения можно передавать и голосом по телефону, и на бумаге, и по электронной почте, но опять есть несколько "но":

• и при взаимодействии с НКЦКИ, и при взаимодействии между ИБ и ИТ (особенно в случае территориально удаленного объекта) вместе с таким сообщением может понадобиться передавать данные довольно большого (для электронной почты) объема (образцы файлов, записи трафика и т.п.);

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

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

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

Обязан ли субъект непременно использовать подобную систему? Нет, не обязан. В далекие времена, когда нас в Позитиве работало человек сто, наше ИТ-подразделение прекрасно справлялось с координацией своей деятельности с помощью обычной электронной почты. Но, по мере роста компании и увеличения количества заявок, пришлось перейти на специализированный хелпдеск. Так же и здесь: потребность в формализации процесса реагирования на инциденты зависит от количества случаев, требующих скоординированных действий (то есть, прежде всего, от количества защищаемых информационных систем), и от территориальной распределенности субъекта.

Но в любом случае, в ответе на вопрос "использовать ли инфраструктуру НКЦКИ для информирования об инцидентах или обойтись подручными средствами" буква нормативных актов имеет второстепенное значение.

Второй момент, который меня резанул в отчете блогеров о встрече в ФСТЭК - фраза "у нас в стране всё теперь средства ГоСОПКА". Не знаю, обсуждался ли на встрече контекст, в котором эта фраза была сказана изначально, но отчеты этот контекст не передают. Об этом - в следующий раз.

Значимые объекты КИИ в банках

Уже не первый раз слышу от банковских безопасников: "Мы - не системно значимый банк, у нас не может быть значимых объектов КИИ."

Причиной стала формулировка одного из экономических показателей в ПП127:

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

Коллеги видят упоминание системно значимых банков и решают, что оно относится ко всему показателю. Но это не так.

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

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

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

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

То есть на самом деле АБС может быть значимым объектом КИИ в двух случаях:

1. Банк системно значимый, и инцидент с АБС приведет к прекращению или нарушению любого вида операций
2. Банк не является системно значимым, и инцидент с АБС приведет к прекращению или нарушению операций, которые клиенты выполняют со своими счиетами.

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

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

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

Безопасность КИИ: что считать "ущербом бюджету"?

И в чатиках о безопасности КИИ и АСУ ТП, и на встречах с заказчиками часто задают одни и те же вопросы. Этот вопрос - один из самых частых.

Постановление Правительства РФ №127 от 08.02.2018 «Об утверждении Правил категорирования объектов КИИ РФ, а также перечня показателей критериев значимости объектов КИИ РФ и их значений», показатель 9:

9. Возникновение ущерба бюджетам Российской Федерации, оцениваемого:

а) в снижении доходов федерального бюджета, (процентов прогнозируемого годового дохода бюджета);

6) в снижении доходов бюджета субъекта Российской Федерации (процентов прогнозируемого годового дохода бюджета);

в) в снижении доходов бюджетов государственных внебюджетных фондов (процентов прогнозируемого годового дохода бюджета)

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

Если налогоплательщик в отчетном периоде получил определенную прибыль, у него возникла обязанность уплатить определенную сумму налогов. Неисполнение этой обязанности (неуплата налогов) - это ущерб, который налогоплательщик причинил государству. Этот ущерб может быть взыскан как с самого налогоплательщика, так и с конкретного виновника (например, с генерального директора организации). Но как быть, если по какой-то причине (неважно, киберинцидент или забастовка) прибыль недополучена? Некоторые считают, что в этом случае к налогам можно применять понятие "упущенная выгода", но это не так. Вот, например, определение ВС РФ №58-КГПР16-22 от 22 ноября 2016 г. (рассматривалось как раз взыскание ущерба по неуплате налога):

В силу п. 2 ст. 15 Гражданского кодекса Российской Федерации под убытками понимаются расходы, которые лицо, чьё право нарушено, произвело или должно будет произвести для восстановления нарушенного права, утрата или повреждение его имущества (реальный ущерб), а также неполученные доходы, которые это лицо получило бы при обычных условиях гражданского оборота, если бы его право не было нарушено (упущенная выгода).

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

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

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

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

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

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

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

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

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

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 - благо, мы такое не раз уже делали.

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