Что ожидать от судебной практики по статье 274.1 УК РФ

Прогнозировать судебную практику - занятие неблагодарное, но иногда это удается с высокой степенью уверенности в результате. Субъекта КИИ в первую очередь интересует, кто и в каком случае может быть привлечен к ответственности по ч. 3-5 статьи 274.1 УК РФ ("Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации").

Для события преступления по этим составам требуется два фактора: должен быть причинен вред КИИ и причиной этого вреда должно являться невыполнение виновником правил эксплуатации "средств хранения, обработки или передачи охраняемой компьютерной информации, содержащейся в КИИ". КИИ определена в ФЗ-187 как совокупность объектов критической информационной инфраструктуры и сетей электросвязи, используемых для организации взаимодействия таких объектов. Соответственно, причинение вреда любому объекту КИИ будет причинением вреда КИИ в целом.

Рассматриваемую предметную область можно охарактеризовать так:

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

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

• "Предметом данного преступления являются средства хранения, обработки или передачи охраняемой компьютерной информации, информационно-телекоммуникационные сети и оконечное оборудование." Тут все понятно: для события преступления требуется, чтобы вред был причинен воздействием на техническую составляющую объекта.
• "Данная норма является бланкетной и отсылает к конкретным инструкциям и правилам, устанавливающим порядок работы со средствами хранения, обработки или передачи охраняемой компьютерной информации, информационно-телекоммуникационными сетями и оконечным оборудованием в ведомстве или организации." Т.е. не существует абстрактных, по умолчанию всем известных правил - нарушить можно только требования конкретных документов.
• "Эти правила должны устанавливаться правомочным лицом." Тут тоже понятно: никто не обязан выполнять предписания лица, которое никто такими полномочиями не наделял. В зачет идут только требования, установленные уполномоченным лицом.
• "Между фактом нарушения и наступившим существенным вредом должна быть установлена причинная связь, а также доказано, что наступившие последствия являются результатом нарушения правил эксплуатации... Правила, о которых идет речь в ст. 274 УК РФ, должны быть направлены только на обеспечение информационной безопасности.". Очевидно.
• "Правила доступа и эксплуатации, относящиеся к обработке информации, содержатся в различных положениях, инструкциях, уставах, приказах, ГОСТах, проектной документации на соответствующую автоматизированную информационную систему, договорах, соглашениях и иных официальных документах." Т.е. нарушением правил эксплуатации считается нарушение вообще любых обязательных к исполнению требований, в каких бы документах и нормативных актах они ни содержались.

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

Пересказывая чужое мнение, люди склонны опускать или искажать незначительные, по их мнению, подробности. Так, в учебных пособиях понятие "правила эксплуатации" пересказывается более простым языком и, к примеру, студентам Университета прокуратуры РФ преподносятся так:

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

Как видим, смысл разъяснений Генпрокуратуры тут сохранен, но из примеров исчезли ГОСТы и иные официальные документы, остались только внутренние нормативные документы, с которыми ознакомливается пользователь или работник. Неудивительно, что в дальнейшем выпускники не обращаются к первоисточникам, а пересказывают единожды выученный материал.

Второй фактор - ничтожно малое количество случаев применения статьи 274 УК РФ: по данным Судебного департамента при ВС РФ, за 2017-2018 годы всеми судами РФ вынесено 2 (прописью "Два") приговора, причем в обоих случаях эта статья являлась дополнительной к основному деянию. По другим источникам (спасибо Валерию Комарову), в 2010-2017 годах правоохранительными органами было возбуждено всего 21 уголовное дело с квалификацией деяния по этой статье. Поэтому, говоря о судебной практике по нарушениям правил эксплуатации, мы имеем дело со статистически ничтожной выборкой, в которую попали, в основном, уголовные дела по преступлениям против коммерческих компаний, возбужденные по заявлению их владельцев. Для квалификации деяния было достаточно того, что нарушены внутренние правила потерпевших.

В КИИ, применительно к значимым объектам, мы имеем принципиально иную ситуацию: есть ряд правовых норм, которые определяют обязанности субъекта КИИ в ходе эксплуатации значимого объекта КИИ - см. например, раздел 13 приказа ФСТЭК №239. Возникает вопрос: что будет, если причиной резонансного инцидента на значимом объекте КИИ станет игнорирование требований регулятора?

Судебная практика по статье 274 УК РФ нам тут не помощник, но есть другая предметная область, обладающая точно такими же характеристиками - пожарная безопасность:

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

В обзоре судебной практики мы видим, что Пленум ВС РФ трактует понятие "правила пожарной безопасности" точно так же, как Генпрокуратура - понятие "правила эксплуатации":

Как известно, диспозиция этой статьи является бланкетной. Законодатель не раскрывает в ней понятия "правил пожарной безопасности" и отсылает нас к нормам специального законодательства. При этом в Федеральном законе "О пожарной безопасности" один из видов нормативных документов в этой области называется "правилами пожарной безопасности". В то же время этим Федеральным законом отнесены к нормативным документам по пожарной безопасности стандарты, нормы, инструкции и иные документы, нарушение которых при наступлении указанных в диспозиции ст. 219 УК РФ последствий влечет уголовную ответственность.

Как видим, в обеих предметных областях под "правилами" судебная система РФ понимает совокупность всех норм, устанавливающих обязанности субъекта в данной предметной области, независимо от того, каким именно документом эти обязанности установлены. Значит, стоит ожидать, что и при применении статьи 274.1 УК РФ судебная система будет относить к правилам эксплуатации также и нормативные требования ФСБ и ФСТЭК, определяющие обязанности субъекта КИИ в ходе эксплуатации объекта КИИ.

Говоря проще, если п. 13.2 и 13.3 приказа ФСТЭК №239 требуют от субъекта КИИ проводить периодический анализ уязвимостей и выполнять управление обновлениями, то невыполнение этих требований в случае успешной атаки на объект КИИ вируса-шифровальщика станет самостоятельным уголовным преступлением, ответственность за которое лежит на субъекте КИИ. И тут возникает интересный вопрос: кто именно эту ответственность понесет?

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

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

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

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

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

Профиль защиты автоматизированных банковских систем и приложений

Начало тут...

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

Кредитные организации должны обеспечить использование для осуществления банковских операций прикладного программного обеспечения автоматизированных систем и приложений, распространяемых кредитной организацией клиентам для совершения действий в целях осуществления банковских операций, а также программного обеспечения, обрабатывающего защищаемую информацию на участках, используемых для приема электронных сообщений, к исполнению в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети "Интернет" (далее - сеть "Интернет"), сертифицированных в системе сертификации Федеральной службы по техническому и экспортному контролю на соответствие требованиям по безопасности информации, включая требования по анализу уязвимостей и контролю отсутствия недекларированных возможностей, или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия (далее - ОУД) не ниже чем ОУД 4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013

В формулировке этого требования есть, как минимум, два неясных момента:

1. Какие именно автоматизированные системы и приложения имеются в виду?
2. В чем именно должен заключаться анализ их уязвимостей?

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

• программное обеспечение АБС;
• приложения, распространяемые клиентам;
• программное обеспечение, используемое для приема электронных сообщений от клиентов.

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

• Попадают ли в первую категорию все автоматизированные банковские системы, используемые в платежных процессах банка? Некоторые комментаторы считают, что в эту категорию попадают только фронтэнды АБС, непосредственно доступные из сети Интернет, хотя из формулировки это никак не следует.
• Относятся ли куда-нибудь скрипты веб-интерфейса ДБО, исполняемые в браузере клиента?
• Относится ли это требование к программному обеспечению банкоматов?

С анализом уязвимостей по ОУД4 тоже все непросто, так как ГОСТ 15408-3 никакой конкретики по этому поводу не содержит: оценщик должен как-нибудь поискать потенциальные уязвимости и точка.

Частичную ясность вносит проект профиля защиты для прикладного программного обеспечения автоматизированных систем и приложений, который уже дважды рассматривался в техническом комитете №122 и который ЦБ намеревается принять до конца этого года. Профиль защиты - это специализированный документ, разработка которого предусматривается Общими Критериями для тех случаев, когда нужно установить какие-то единые требования для определенного вида информационных систем или средств защиты. Документ объемный (более 150 страниц), его чтение требует навыка работы с Общими Критериями, и, к сожалению, требования таких документов не всегда правильно интерпретируются неспециалистами.

Что подпадает под действие профиля защиты

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

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

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

И, наверное, также стоит подчеркнуть, что определение объекта оценки, данное в профиле, не уточняет область действия положений Банка России. Если в положении Банка России говорится об АБС, используемых в платежном процессе, а в профиле защиты - о фронтэндах этих АБС, то это означает только то, что профиль применим лишь к части области действия положений ЦБ.

Что такое "функциональные требования безопасности" и почему они такие странные

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

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

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

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

ФБО должны обнаруживать, когда произойдет [выбор: [назначение: положительное целое число]; устанавливаемое администратором положительное целое число в пределах [назначение: диапазон допустимых значений] ] неуспешных попыток аутентификации, относящихся к [назначение: список событий аутентификации].

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

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

Анализ уязвимостей в соовтетствии с профилем защиты

Как человека, зарекшегося заниматься сертификацией (спасибо нашей команде сертификаторов, успешно справляющимся с этой задачей), меня больше интересует, как в профиле защиты раскрывается вопрос анализа уязвимостей. Напомню, нормативные документы ЦБ ссылаются на ГОСТ 15408-3, а в этом документе ничего вразумительного по этому поводу нет. Зато есть в профиле защиты - за это отвечают три компонента доверия:

• "ADV_ARC.1 Описание архитектуры безопасности"
• "ADV_IMP.2 Полное отображение представления реализации ФБО"
• "AVA_VAN.5 Усиленный методический анализ"

Причем основная ценность профиля защиты даже не в самих этих компонентах доверия (они, как положено, просто скопированы из ГОСТ 15408-3), а в замечаниях к их применению.

Как я уже писал ранее, компонент доверия ADV_ARC.1 требует, чтобы разработчик продемонстрировал, что объект оценки защищен от вмешательства нарушителя в момент своего запуска (элемент ADV_ARC.1.3C) и в ходе своей работы (элемент ADV_ARC.1.4C), а также что нарушитель не может обойти механизмы защиты (элемент ADV_ARC.1.5C). Для этого разработчик должен самостоятельно провести анализ уязвимостей своего продукта и предоставить его результаты оценщику). В тексте ГОСТ 15408-3 прямого указания на это нет, поэтому в профиле защиты, в замечаниях к применению этого компонента доверия, дана явная ссылка на пункт 10.3.1 ГОСТ 18045, где подробно описывается, что как именно должны быть обоснованы невмешательство и невозможность обхода.

Компонент доверия ADV_IMP в исходном тексте Общих Критериев не определен ("Общее руководство отсутствует; за консультациями по выполнению данного подвида деятельности следует обращаться в конкретную систему оценки." - ГОСТ 18045, п. 10.5.2), поэтому в профиле защиты он определен "с нуля" замечаниями по применению. Если вкратце, от разработчика (именно от разработчика, не от оценщика) требуется:

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

Результаты анализа должны быть переданы оценщику вместе с исходными кодами для независимой проверки.

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

• Провести анализ известных уязхвимостей, опираясь на БДУ ФСТЭК, CVE, бюллетени вендоров, уведомления ФинЦЕРТ и т.п.
• Провести анализ типовых уязвимостей веб-интерфейсов методом "черного ящика"
• Провести динамический анализ кода, ориенртируясь на выявление типовых уязвимостей, предусмотренных классификатором CWE
• Провести тестирование на проникновение (при этом определен минимально-необходимый состав проверок, включающий в себя как внешний, так и внутренний пентесты

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

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

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

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

Анализ уязвимостей в ГОСТ 15408

И еще раз (а может, еще и не раз) вернемся к вопросу о том, что такое "анализ уязвимостей в соответствии с требованиями ОУД4 ГОСТ 15408-3". А точнее, о том, что делать банкам с самостоятельно разработанными приложениями.

Прежде всего стоит обратить внимание на то, что сам по себе ГОСТ 15408 никак не определяет, в чем именно должен заключаться анализ уязвимостей. В ОУД4 за него отвечает компонент доверия AVA_VAN.3, который говорит, что должен посмотреть оценщик (документацию, внешние источники на предмет наличия в продукте уже известных уязвимостей и исходный код на предмет зеродеев, но ничего не говорит о том, как что именно и как именно оценщик должен искать. Более полное описание содержится в дополнении к ГОСТ 15408 - в стандарте ГОСТ 18045 "Методология оценки безопасности информационных технологий". Итак, в чем именно заключается анализ уязвимостей по версии "Общих критериев"?

1. Оценщик должен изучить открытые источники и выяснить, нет ли в исследуемом продукте известных потенциальных уязвимостей. Очень часто это воспринимается как "давайте посмотрим в CVE, нет ли там известных уязвимостей для продукта", и это неверно. В методологии четко оговаривается, что речь идет об открытых материалах (книгах, статьях, материалах конференций), в которых описываются потенциально возможные уязвимости информационной технологии, реализованной в продукте. Так, если речь идет о веб-приложении (а к им относятся практически все фронтэнды ДБО и мобильного банкинга), то основным открытым источником для оценщика должен стать OWASP, а потенциальными уязвимостями - SQL-инъекции, XSS и весь прочий зверинец типовых уязвимостей веб-приложений. Т.е. речь на этом шаге оценки идет прежде всего о типовых уязвимостях и типовых ошибках разработки, характерных для технологии, а не только об отдельных идентификаторfх CVE.

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

Кроме того, оценщик должен провести анализ исходного кода продукта (т.н. "представление реализации") в поисках зеродеев.

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

• демонстрацию того, что невозможно прямое несанкционированное вмешательство нарушителя в работу продукта;

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

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

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

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

К сожалению, ни ГОСТ 15408, ни ГОСТ 18045 ничего не говорят о том, в чем именно должен заключаться поиск зеродеев в исходных кодах - и это один из основных недостатков Общих Критериев. Отсутствие прямых указаний на эту тему побудило Банк России разработать дополнительные требования к анализу уязвимостей, включив их в проект профиля защиты для автоматизированных банковских систем и приложений. Но об этих требованиях - в следующий раз.

ОУД4 для банковских приложений

В последнее время заказчики из банковской сферы все чаще спрашивают, можем ли мы провести анализ уязвимостей их приложений в соответствии с требованиями ОУД4 ГОСТ 15408-3. Связано это со скорым вступлением в силу уже упоминавшихся положений Банка России. К сожалению, при этом заказчики часто слабо представляют, что от них требуется и в чем заключается такой анализ.

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

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

ОУД4 - средний, сбалансированный уровень доверия - он еще не настолько фантастичен, как ОУД7, но уже позволяет не верить разработчику на слово, в отличие от ОУД1. Одним из свидетельств, которым разработчик подтверждает корректность своих заявлений на ОУД4 - исходные коды, которые он должен предоставить оценщику.

Одна из мер доверия, которая проверяется на ОУД4 - анализ уязвимостей, мера доверия AVA_VAN.3, определенная в ч. 3 ГОСТ 15408. Для тех кому сложно продираться сквозь птичий язык Общих Критериев (Вам не нравится канцелярит нормативных документов? Вы просто не пробовали читать ОК, после них Налоговый Кодекс читается, как сказка про Колобка), переведу требования к этой мере доверия на человеческий язык:

1. Разработчик должен описать архитектуру подсистемы безопасности своего продукта (мера доверия ADV_ARC.1). В описании архитектуры должно быть продемонстрировано, что функции безопасности его продукта невозможно обойти, т.е. что в нем нет архитектурных уязвимостей.
2. Разработчик должен написать функциональную спецификацию своего продукта (мера доверия ADV_FSP.4). В ней должен быть описан весь API, связанный с реализацией функций безопасности, назначение каждой функции API, способ ее использования, ее параметры, а также описание всех (вообще всех) ошибок, сообщения о которых могут появляться в интерфейсе или в логах, причем с разблюдовкой: вот эти ошибки - результат некорректного срабатывания функций безопасности, а вот эти - не связаны с безопасностью по вот такой причине.
3. Разработчик должен описать разделение своего продукта на подсистемы, а каждой подсистемы - на отдельные модули (мера доверия ADV_TDS.3). Для каждого модуля, в котором реализуются функции безопасности, должно быть описано, какие функции API он реализует. Для каждой функции безопасности должно быть расписано что-то вроде диаграммы взаимодействия UML - через какие модули и через какие функции API этих модулей идут пути исполнения кода при выполнении функций безопасности.
4. Разработчик должен передать оценщику всю эту документацию и исходный код продукта.
5. Оценщик должен убедиться, что документация полна и соответствует исходному коду.
6. Оценщик должен проверить, нет ли для этого продукта уже известных уязвимостей.
7. Оценщик должен провести анализ документации на предмет потенциальных архитектурных уязвимостей.
8. Оценщик должен провести анализ исходных кодов на предмет потенциальных зеродеев.
9. Оценщик должен верифицировать все найденные потенциальные уязвимости, проверив их эксплуатабельность.
10. Если оценщик обнаруживает эксплуатабельные уязвимости, продукт и документация отправляются на доработку и оценка повторяется после устранения уязвимостей.

Описанная процедура чем-то напоминает сертификацию по уровню контроля отсутствия недекларированых возможностей, которую когда-то практиковала ФСТЭК.

Как видно из описания, анализ уязвимостей - это довольно большой объем работы по анализу архитектурных уязвимостей и уязвимостей кода. Замечу, что при сертификации в системе ФСТЭК проводится точно такая же работа, но она - лишь часть сертификационных испытаний: анализ уязвимостей на ОУД4 - это примерно треть трудозатрат испытательной лаборатории на полноценную сертификацию продукта.

К чему я все это пишу. Как видно из описания, ГОСТ ничего не говорит о том, как именно должны выявляться уязвимости - например, нужно ли проводить для этого динамический анализ кода или достаточно только статики. Более того, сильно подозреваю, что авторы этой редакции Common Criteria вообще очень слабо представляли себе, что такое уязвимости и как их обычно отыскивают: не хочу обидеть парней из профильного комитета ISO, но только очень альтернативно одаренный человек мог назвать верификацию уже найденной уязвимости словосочетанием "penetration test".

Такая неопределенность в способах поиска потенциальных уязвимостей не устраивает ЦБ, поэтому "встроенные" требования ГОСТ 15408-3 по анализу уязвимостей расширены в проекте профиля защиты, который сейчас рассматривается в ТК122. Изменения существенны:

1. Анализ уязвимостей должен проводить разработчик. Оценщик проверяет, что анализ уязвимостей разработчиком действительно проводится, а также самостоятельно проводит независимый анализ уязвимостей, чтобы убедиться, что разработчик не халтурит. Такой дублирующий контроль не избавляет разработчика от обязанности самостоятельно проводить анализ уязвимостей.
2. Добавлены примечания, в которых подробно описано, какими именно способами должны выявляться уязвимости. В частности, прямо указана необходимость проведения статического и динамического анализа исходного кода.
3. Верификация уязвимостей (она обычно проводится в лабораторных условиях) заменена полноценным тестированием на проникновение в реальных условиях эксплуатации. Требования к тестированию на проникновение взяты из РС БР ИББС 2.6, тем самым переведя описанную там процедуру тестирования на проникновения из рекомендованной в обязательную.
4. Описаны требования к отчетам об анализе уязвимостей. Именно такими отчетами разработчик (или банк) будет подтверждать аудиторам самостоятельное проведение анализа уязвимостей.

В чем принципиальное отличие? "Чистый" ОУД4 позволял относится к анализу уязвимостей как работе, которую должен выполнить сторонний эксперт. С момента утверждения профиля защиты ЦБ усиливает требования ОУД4, заставляя разработчиков встраивать анализ уязвимостей в жизненный цикл разработки банковских приложений. Напрямую это касается только собственной разработки платежных приложений банками и некредитными финансовыми организациями, но косвенно это создает и потребительское давление на разработчиков АБС и систем ДБО: финансовая организация не может использовать в платежном процессе приложение, разработчик которого не проводит самостоятельный анализ уязвимостей.

Анализ уязвимостей и ОУД4 ГОСТ 15408-3

"По заявкам радиослушателей". Заказчики уже несколько раз просили прокомментировать, что такое "анализ уязвимостей в соответствии с требованиями ОУД4". Я об этом уже писал, здесь - чуть подробнее.

Нормативные документы ЦБ обязывают организации финансовой сферы с 01.01.2020 проводить анализ уязвимостей прикладного ПО, которое используется в платежных и иных финансовых операциях. Навскидку вспомнил три документа, в которых это требование присутствует:

• положение Банка России от 9 июня 2012 г. № 382-П "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств";
• положение Банка России от 17 апреля 2019 г. № 683-П "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента";
• положение Банка России от 17 апреля 2019 г. № 684-П "Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций".

В части анализа уязвимостей все три документа используют примерно одинаковые формулировки:

...обеспечить использование ... прикладного программного обеспечения автоматизированных систем и приложений, ... а также программного обеспечения, обрабатывающего защищаемую информацию ..., сертифицированных в системе сертификации Федеральной службы по техническому и экспортному контролю на соответствие требованиям по безопасности информации, в том числе на наличие уязвимостей или недекларированных возможностей (далее - сертификация), или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия (далее - ОУД) не ниже чем ОУД 4, предусмотренного пунктом 7.6 национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013

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

Формулировка "сертификация на соответствие требованиям по безопасности информации, в том числе на наличие уязвимостей или недекларированных возможностей" была придумана, когда система сертификации ФСТЭК работала по старым правилам. Тогда анализ уязвимостей и недекларированных возможностей проводился в двух случаях: при сертификации в рамках ГОСТ 15408 на соответствие профилю защиты с оценочным уровнем доверия ОУД4 и при сертификации на соответствие "уровню контроля отсутствия недекларированных возможностей". В переводе на русский язык приведенная формулировка означает "годится любой софт, у которого есть сертификат ФСТЭК, в тексте которого присутствуют 'ОУД4' или 'контроль отсутствия НДВ'".

Однако, начиная с этого года система сертификации ФСТЭК работает по новым правилам:

• сертификация на контроль отсутствия НДВ прекращена;
• ГОСТ 15408-3 больше не является методическим документом ФСТЭК, а установленные в нем уровни доверия больше не используются при сертификации;
• сертификаты, в которых присутствуют буковки "НДВ" и "ОУД" до 01.01.2020 г. должны быть переоформлены по новым требованиям или будут аннулированы (подробнее см. информационное сообщение ФСТЭК).

Если для выполнения процитированного требования организация рассматривает вариант с сертифицированным ПО, то у меня для нее три новости: хорошая и две плохие:

1. С 01.01.2020, в соответствии с новыми правилами сертификации, любой сертификат ФСТЭК будет означать, что при сертификации проводился анализ уязвимостей и недекларированных возможностей. Просто потому, что все старые сертификаты будут аннулированы.
2. Сертифицировать можно только средство защиты, то есть ПО, в котором есть функции безопасности. В платежном процессе часто используется софт, в котором функций безопасности нет в принципе (например, самописные конвертеры, которые просто преобразуют платежные данные из одного формата в другой) - такие приложения сертифицировать невозможно.
3. Сертификация в среднем занимает около года, и сертифицируется определенная сборка ПО. При этом фиксируются контрольные суммы файлов, и любое обновление фактически делает сертификат недействительным для новой сборки. Поэтому сертифицировать часто обновляемые компоненты, например - веб-интерфейсы ДБО и мобильные приложения, бессмысленно.

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

Альтернативой является проведение анализа уязвимостей, и на самом деле именно этот вариант и является основным (вариант с сертификацией был включен в проект положения 382-П уже на стадии общественного обсуждения под предлогом "при сертификации тоже уязвимости анализируют"). ГОСТ 15408-3 определяет меры доверия, которые раньше применялись при сертификации средств защиты. Сейчас он не применяется, но пользоваться этим инструментом самостоятельно по-прежнему можно. В состав мер доверия входит анализ уязвимостей, требования к нему для ОУД4 определены в компоненте доверия AVA_VAN.3. В соответствии с этим компонентом доверия оценщик (лицо, которое проводит анализ уязвимостей) должен проделать следующую работу:

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

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

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

• 382-П (в редакции указания 4793-У): "следует привлекать организацию, имеющую лицензию на осуществление деятельности по технической защите конфиденциальной информации";
• 683-П: "должны привлекать организации, имеющие лицензию на осуществление деятельности по технической защите конфиденциальной информации";
• 684-П: "анализ уязвимостей ... проводится самостоятельно или с привлечением проверяющей организации", требование о наличии у проверяющей организации лицензии ФСТЭК отсутствует.

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

1. "Анализ уязвимостей обязательно должен делать независимый лицензированный оценщик".
2. "Анализ уязвимостей требует подтверждения квалификации исследователей. Хотите делать сами - получите лицензию ФСТЭК.".
3. "В ходе разработки можно и нужно проводить анализ уязвимостей самостоятельно. Но при этом нужна контрольная проверка, для проведения которой нужно звать лицензиатf".
4. "Если для анализа уязвимостей банк привлекает стороннюю организацию, то он должен привлекать организацию-лицензиата".

Из них самой разумной кажется третья трактовка. Если проводить анализ уязвимостей только основных релизов, то в проверяемом релизе гарантированно будут уязвимости, и их устранение может затянуть релиз на неопределенный срок. При этом для проверки того, а хорошо ли мы сами анализируем уязвимости, разумно время от времени привлекать внешнего оценщика. Четвертая трактовка тоже возможна, но если выбbрать именно этот вариант, то лучше все же запросить разъяснения у ЦБ.

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

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

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

А вот госам придется хуже - с 01.01.2020 при создании и модернизации ГИС, являющихся значимыми объектами КИИ применять СЗИ с непереоформленными сертификатами нельзя даже если действие сертификата не приостановлено: эти СЗИ не будут соответствовать введенным в приказ 239 требованиям к уровням доверия. Но это уже совсем другая история.

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

Принято постановление Правительства о порядке подготовки сетей электросвязи к функционированию объектов КИИ. Документ разрабатывался больше года, результат - "ну не шмогла я, не шмогла".

.

На что нужно обратить внимание:

1. Подключать объекты КИИ к сети Интернет, использовать для передачи данных сети операторов мобильной связи и т.п. можно только разрешения ФСТЭК. Да, каждый субъект КИИ должен согласовывать с ФСТЭК возможность подключения своих объктов КИИ к сетям общего доступа. Порядок такого согласования определяет ФСТЭК, и подозреваю, что оно будет требоваться только для значимых объектов. Тем не менее, тем, кто сейчас проводит категорирование объектов, стоит внимательно отнестись к этому моменту: если в акте категорирования будет написано, что информационная система не подключена к сетям электросвязи, а при инспекции выяснится, что она активно взаимодействует с внешним миром, это будет нарушением требований безопасности.
2. Операторы связи должны обеспечивать защиту информации, передаваемой по их сетям связи, в соответствии с требованиями, которые установит Минсвязи. Ух ты, Минсвязи наконец разработает требования по обеспечению тайны связи! С 2003 года все разрабатывает-разрабатывает, никак не разработает, но сейчас каааааак...
3. Операторы связи должны обеспечивать безопасность своих сетей, которые используются для организации взаимодействия значимых объектов КИИ. Минутку, и откуда же оператор связи узнает, что вот эта его сеть используется его клиентами для взаимодействия каких-то значимых объектов КИИ? В проекте документа был прописан механизм уведомления операторов связи владельцами значимых объектов, но в финальном тексте этого механизма нет. Забавная ситуация: надзорный орган (ФСТЭК) знает, что сети вот такого оператора используются вот таким значимым объектом КИИ - об этом владелец объекта сообщает при категорировании, а сам оператор связи этого не знает и никаким способом узнать не может.
4. Оператор связи отвечает только за выполнение требований Минсвязи и в случае сетевой атаки на информационные системы своих клиентов не обязан им помогать. В проекте был прописан механизм разделения обязанностей и совместного реагирования на атаки, но из финального текста он исчез.

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

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

Требования к средствам ГосСОПКА

Утверждены требования к средствам ГосСОПКА

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

1. В статье ФЗ-187 говорится:

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

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

Так вот, это не так. ГосСОПКА была создана на основании указа Президента №31с от от 15.01.2013 г., и все нормативные акты, регулирующие ее деятельность, принимались во исполнение этого указа. ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации" ее деятельность не регулирует. Нормы ФЗ-187 говорят лишь о том, как ГосСОПКА, живущая по своим собственным правилам, используется при обеспечении безопасности объектов КИИ. В частности, когда в нормативных документах ГосСОПКА говорится о силах и средствах ГосСОПКА, речь идет именно о силах и средствах субъектов ГосСОПКА (термин, введенный в одном из ДСПшных нормативных документов ФСБ), а не о силах и средствах субъектов КИИ.

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

Проще всего проиллюстрировать это следующим примером. Есть холдинг из десятка предприятий. Для защиты холдинга создан SOC, который стал центром ГосСОПКА. На каждом предприятии в рамках выполнения требований 239 приказа ФСТЭК развернуты SIEM, которые накапливают события, проводят их первичную обработку. События, потенциально свидетельствующие о проведении компьютерной атаки, направляются в SIEM SOC'а для централизованного реагирования. Так вот, в этой схеме требования обсуждаемого нормативного документа ФСБ распространяются на SIEM SOC'а и не распространяются на SIEM'ы предприятий.

2. Хочу обратить внимание на то, что в обсуждаемом приказе ФСБ обнаружением компьютерных атак фактически назван анализ событий. Это принципиальная позиция регулятора, поэтому когда вы слышите от интегратора: "Для обнаружения атак в рамках ГосСОПКА достаточно развернуть вот такую систему сенсоров IDS с вот такой централизованной управлялкой", - нужно четко понимать, что вас обманывают.

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

В результате между документами двух регуляторов получилась терминологическая путаница, поэтому стоит запомнить:

• "средство обнаружения вторжений" в нормативных документах ФСТЭК - это IDS;
• "средства обнаружения компьютерных атак" в нормативных документах ФСБ - это совокупность SIEM и подключенных к нему источников событий.

3. Еще один аспект требований к обнаружению атак: они должны обнаруживаться не только в режиме реального времени, но и в ретроспективе. Для SOC, которые планируют стать центрами ГосСОПКа, это означает:

• если появилась новая сигнатура для IDS, SOC должен иметь возможность проверить, не мелькала ли подобная сигнатура трафике раньше;
• если антивирус обнаружил на узле зараженный файл, SOC должен суметь проследить, как этот файл и его копии "мигрировали" в инфраструктуре до обнаружения и т.п.

Предупреждая хайп на тему "повторения закона Яровой": речь не идет об обязательном хранении всего трафика и "слепков" всех файлов, передаваемых по сети. Требования к средствам ГосСОПКА нужно выполнять в контексте функций центров ГосСОПКА, описанных в методических рекомендациях. Там говорится, что центр ГосСОПКА должен концентрироваться на противодействии типовым атакам, пополняя свои знания о таких атаках на основе threat hunting'а. То есть, если SOC заявляет, что умеет справляться с атаками на веб-приложения, для ретроспективного анализа новых атак, которые для этого SOC становятся типовыми, можно записывать трафик строго определенных протоколов к строго определенным веб-серверам - а можно ограничиться хранением логов этих веб-серверов. Но независимо от того, какие данные используются для обнаружения типовой атаки в ретроспективе, SIEM должен обеспечивать техническую возможность ретроспективного анализа этих данных.

4. Как и в случае с обнаружением атак, под предупреждением атак в ГосСОПКА понимается ни разу не применение средств защиты информации. Предупреждение компьютерных атак в контексте ГосСОПКА - это threat hunting и заюлаговременная подготовка к вохможности проведения атак, а именно: анализ и устранения уязвимостей, которые могут использоваться в новых видах атак, и заготовка плейбуков для реагирования на ьтакие атаки.

Требования ЦБ по противодействию мошенническим денежным переводам

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

Кредитные организации обязаны выполнять требования ГОСТ Р 57580.1-2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер". При этом значимые кредитные организации должны выполнять требования усиленного (т.е. высшего) уровня, остальные - стандартного (т.е. среднего) уровня. Требования стандарта предъявляются ко всем объектам информационной инфраструктуры, которые участвуют в обработке, передаче и хранении платежной информации. И это, наверное, хорошо. Правда, в стандарте нет требований по защите информации - он содержит просто перечень мер защиты, без детализации требований к ним. Например, стандарт говорит, что кредитная организация должна контролировать отсутствие и обеспечивать оперативное устранение известных уязвимостей (меры защиты ЦЗИ.1 - ЦЗИ.6), для чего нужно применять сканеры уязвимостей к объектам инфраструктуры (меры защиты ЦЗИ.7 - ЦЗИ.10). При этом он ничего не говорит о том, как часто нужно проводить анализ уязвимостей и что понимается под оперативностью их устранения.

OK, добросовестному банку этого достаточно: менеджмент известных уязвимостей уже описан много раз, и как его реализовывать - понятно. Остаются уязвимости нулевого дня - например, те же уязвимости веб-интерфейсов систем ДБО. В соответствии с положением, такие интерфейсы ("программное обеспечение, используемое для приема сообщений ... в сети Интернет") должно или сертифицироваться в системе сертификации ФСТЭК, или пройти анализ уязвимостей в объеме, соответствующем оценочному уровню доверия ОУД4 ГОСТ 15408-3. Альтернатива "сертифицировать или анализировать уязвимости" появилась еще год назад в положении Банка России 382-П (в редакции указания N 4793-У от 7 мая 2018 г.), и на тот момент логика авторов документа была понятна. Сертификация включает в себя проведение анализа уязвимостей, поэтому в теории подобное требование означало, что банки вынуждены будут так или иначе проводить работу по поиску и анализу уязвимостей нулевого дня в используемом программном обеспечении, при этом ОУД4 задает минимально-приемлемую глубину анализа. К сожалению, только в теории.

Часть 3 ГОСТ 15408 описывает требования к свидетельствам, с помощью которых заявитель доказывает, что его продукт действительно соответствует заявленным требованиям, и действия сертификатора при оценке таких свидетельств. Состав свидетельств и действий по оценке определяется оценочным уровнем доверия, а анализ уязвимостей является одним из действий сертификатора. Когда регулятор говорит, что должен быть проведен анализ уязвимостей в объеме, соответствующем ОУД4, он говорит следующее (за подробностями отсылаю к описанию компонента доверия AVA_VAN.3 ГОСТ 15408-3-2013):

1. Заявитель должен предоставить на оценку следующие свидетельства:
• проектную документацию оцениваемого программного компонента (описание архитектуры безопасности и детальное описание реализации функций безопасности);
• руководства (администратора/пользователя, по инсталляции);
• исходные коды.
2. Оценщик должен все это посмотреть и каким-то способом поискать уязвимости.

ГОСТ ничего не говорит о том, как же именно оценщик должен обнаруживать уязвимости. Несколько лет назад профильный комитет ISO уже пытался стандартизировать хотя бы поиск известных уязвимостей и фаззинг, но на проект документа без слез смотреть было нельзя, и он был благополучно похоронен. Т.е. в альтернативе "анализ уязвимостей" регулятор требует провести его хоть как-то, фактически ставя только два условия: анализ должен проводить лицензиат ФСТЭК и ему должны быть предоставлены исходные коды.

С альтернативой "сертифицировать" тоже не все просто. Во-первых, в системе сертификации ФСТЭК больше нет сертификации "на отсутствие уязвимостей или недекларированных возможностей". Теперь сертификация - это только оценка соответствия требованиям безопасности (например, техническим условиям, которые разрабатывает сам заявитель), а анализ уязвимостей - просто составная часть работ по сертификации. Во-вторых, ФСТЭК вместо ГОСТ 15408-3 руководствуется своим собственным документом, в котором оценочные уровни доверия определены совсем по-другому. Их шесть, на ОУД6, низшем уровне доверия, проводится лишь анализ архитектурных уязвимостей и фаззинг в режиме черного ящика, в то время как ОУД4 требует проведения полноценных статического и динамического анализа исходных кодов. При этом ни положение 382-П, ни положение 683-П ничего не говорят о том, какой уровень доверия должен быть выбран при сертификации. Ну и в-третьих, сертификация - это длительный процесс, который включает в себя "тройной контроль" (испытательная лаборатория, орган по сертификации и ФСТЭК) и может длиться от года и дольше.

В итоге требование об анализе уязвимостей нулевого дня получается очень странным. С одной стороны, ЦБ признает крайнюю необходимость поиска и устранения уязвимостей нулевого дня, особенно в самописных фронтэндах систем ДБО. С другой стороны, регулятор тщательно прячется "в домик", точнее, за требования ГОСТ, который на самом деле ничего не требует, и за практику деятельности системы сертификации ФСТЭК.

Как в этой ситуации поступать банкам? Ну, во-первых, стоит вспомнить о том, что есть рекомендации в области стандартизации РС БР ИББС-2.6-2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем»", где в приложении подробно расписано, что подразумевается под анализом уязвимостей компонентов информационных систем. Во-вторых, можно провести анализ уязвимостей в объеме все того же ОУД4, но только определенного не в ГОСТ 15408, а в "Методике выявления уязвимостей и недекларированных возможностей в программном обеспечении" ФСТЭК. Так как ГОСТ 15408 в действительности не содержит никаких требований к объему и методам анализа уязвимостей, любой из этих двух вариантов будет автоматически соответствовать требованиям этого ГОСТ.

Повторяемость инцидента при оценке ущерба объектам КИИ

При категорировании объектов критической инфраструктуры ущерб от возможных инцидентов можно разделить на моментальный и длящийся. Очевидные примеры моментального ущерба – прекращение работы систем жизнеобеспечения, транспорта или связи (показатели категорирования 2, 3 и 4): для выбора категории значимости важно только количество людей, которое потенциально может пострадать от инцидента, но неважна длительность их страданий. Длящийся ущерб актуален для показателей категорирования экономического блока: снижение доходов субъекта КИИ напрямую зависит от времени простоя его основных средств производства.

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

“5. Категорирование включает в себя: … д) оценку … масштаба возможных последствий в случае возникновения компьютерных инцидентов на объектах критической информационной инфраструктуры;”

“14. Комиссия по категорированию в ходе своей работы: … д) анализирует угрозы безопасности информации, которые могут привести к возникновению компьютерных инцидентов на объектах критической информационной инфраструктуры; е) оценивает … масштаб возможных последствий в случае возникновения компьютерных инцидентов на объектах критической информационной инфраструктуры …;”

“17. Субъект критической информационной инфраструктуры … направляет … сведения о результатах присвоения объекту критической информационной инфраструктуры одной из категорий значимости либо об отсутствии необходимости присвоения ему одной из таких категорий. Указанные сведения включают: … ж) возможные последствия в случае возникновения компьютерных инцидентов на объекте критической информационной инфраструктуры либо сведения об отсутствии таких последствий;”

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

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

То есть при оценке возможных действий нарушителя (пункт 14 “г”) и анализе угроз, связанных с этими действиями (пункт 14 “д”), требуется рассматривать самый плохой сценарий. Следовательно, если мы утверждаем, что нарушитель может, используя уязвимости инфраструктуры, остановить работу защищаемого объекта, в силу пункта 14(1) мы обязаны рассматривать сценарии, при которых нарушитель будет целенаправленно блокировать работу этого объекта максимально возможное время, используя все возможные уязвимости инфраструктуры.

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

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

Аппарат УЗИ как объект критической инфраструктуры

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

Объектами критической информационной инфраструктуры являются информационные системы и сети, используемые в тринадцати сферах, в том числе - в сфере здравоохранения. Так как понятие "информационная система" определено очень расплывчато, с некоторой натяжкой объектом КИИ можно назвать и отдельно взятый аппарат УЗИ или компьютерный томограф. Если атака на такой объект может привести к последствиям, перечисленным в приложении к 127му постановлению Правительства (например - если в результате атаки может быть причинен ущерб жизни и здоровью людей), объект категорироется как значимый и должен защищаться в соответствии с требованиями ФСТЭК. Соответственно, при категорировании нужно определить актуальные для этого объекта угрозы и их последствия.

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

• угроза внедрения вредоносного кода (УБИ.006);
• угроза неправомерного ознакомления с защищаемой информацией (УБИ.067);
• угроза подмены программного обеспечения (УБИ.188) и т.п.

Иp этого делается вывод, что атакующий способен получить полный контроль над аппаратом, подменять изображение, выдаваемое на экран и скриншоты, которые врач делает в процессе работы. Из этого делается вывод, что атакующий способен исказить информацию, которая нужна врачу для постановки диагноза, а значит потенциально способен заставить врача принять неверное решение и причинить тем самым вред здоровью пациента. Бинго, аппарат УЗИ становится значимым объектом наивысшей категории значимости.

Это хороший пример того, как нельзя моделировать угрозы. Исполнитель не разбирается в вопросах лечения ("что произойдет, если нарушитель взломает аппарат УЗИ"), и поэтому подменяет предмет исследования другим, в котором разбирается ("как можно взломать аппарат УЗИ"). При добросовестном же категорировании предметом исследования должен быть именно процесс лечения, и делать это должен не безопасник, а врач-лечебник или врач УЗИ-диагностики. Тогда и результат категорирования будет совсем другим.

Начнем с того, что в соответствии с порядком категорирования объектов КИИ исследуется процесс, нарушение которого моет привести к неприемлемым последствиям. Если мы изучаем вопрос о возможности причинения вреда здоровью пациента в результате неверного лечения, то и изучать нужно весь лечебный процесс, а не отдельный его кусочек. Как правило, УЗИ - лишь один из видов исследования, назначаемых больному в лечебном процессе, и неверные результаты, полученные на аппарате УЗИ, необязательно приведут к врачебной ошибке.

Но предположим, что УЗИ является единственным исследованием, на основании которого ставится диагноз и назначается лечение. Можно ли так атаковать аппарат УЗИ, чтобы заставить лечащего врача ошибиться, навязав ему ложную информацию? OK, упростим задачу нарушителя, приняв в качестве аксиомы, что он:

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

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

А дальше проведем мысленный эксперимент:

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

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

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

И что мы видим в результате анализа угроз? Что атака на аппарат УЗИ возможно, но к негативным последствиям лдя жизни и здоровья пациента она привести не может. А раз так, то и значимым объектом КИИ аппарат УЗИ не является. А мораль этой истории проста: категорировать объекты КИИ должны специалисты. И специалистами в этом процессе - ни разу не безопасники.

И тоже об иллюзиях в сертификации средств защиты

Алексей Лукацкий поднял интересную тему иллюзий в сертификации средств защиты по требованиям ФСТЭК. Тема слишком объемная, чтобы расписывать ее в комментариях в FB. Остановлюсь на двух моментах, о которых пишет Алексей:

• "чтобы сертифицировать на класс 5 и выше средство защиты с встроенными чужими антивирусными модулями, заявитель обязан представить исходные тексты каждого из модулей" и
• "сертифицировать UTM и NGFW практически невозможно"

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

Как проходит "сертификация по требованиям ФСТЭК"

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

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

...должны блокировать неразрешенный информационный поток по протоколу передачи гипертекста, путем [выбор:
а) блокирования запроса по протоколу передачи гипертекста;
б) разрыва сетевого соединения;
в) перезапуска сетевого соединения;
г) блокирования взаимодействия с конкретным сетевым адресом;
д) блокирование сессии на уровне конкретного приложения;
е) блокирование взаимодействия на уровне конкретного пользователя приложения;
ж) отправка управляющего сигнала на иной МЭ для блокирования неразрешенного информационного потока;
з) [назначение: другой способ]]

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

Так как речь идет о специальных видах средств защиты, для которых есть профили защиты, остановимся на сертификации по ГОСТ 15408. Профиль защиты определяет не только требования функциям средства защиты, но и оценочный уровень доверия - требования к глубине исследований, которые должны проводиться в ходе сертификации (т.е. требования доверия). Например:

• ОУД1: "мамой клянусь!" (анализируются руководства администратора/пользователя, проводится выборочное тестирование)
• ОУД2: ОУД1 плюс анализируется проектная документация и проводится полное тестирование;
• ОУД3: ОУД2 плюс анализируется жизненный цикл разработки;
• ОУД4: ОУД3 плюс анализируются исходные коды.

Сертификация на более высокие уровни доверия практически не проводится. Каждый ОУД определяет, какими именно свидетельствами заявитель должен доказывать, что в средстве защиты выполнены заявленные им же самим требования. Кроме перечисленного, начиная с ОУД2 проводится анализ уязвимостей в том объеме, который возможен на тех исходных данных, которые анализируются на этом уровне (например, искать зеродеи анализом исходного кода можно только на ОУД4).

Так вот, о нюансах...

"Мы делили апельсин, много наших полегло"

Предположим, что мы хотим сертифицировать комбайн, например - какой-нибудь UTM с антивирусным модулем и модулем IDS.

Такое комбинированное решение относится сразу к двум видам специальных средств защиты: оно одновременно является и антивирусом и средством обнаружения вторжений. Если оно заявляется как единый комплекс, то и сертифицируется как единый комплекс. Для этого в задание по безопасности включаются требования из обоих профилей защиты (на антивирусы и на СОВ), вписывается утверждение о соответствии одновременно двум профилям защиты и устанавливается максимальный из двух уровней доверия, которые установлены в этих двух профилях. Соответственно, ко всем трем модулям (платформе, IDS и AV) предъявляются одинаковые требования доверия. При этом никого не волнует, сами во разработали эти модули или позаимствовали по лицензии: если вы сертифицируетесь на ОУД4, то должны предоставлять исходные коды и на платформу, и на IDS, и на AV. Это не новшество, так оно и было изначально и в Common Criteria, и в ISO/ГОСТ 15408.

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

А что делать, если вы используете чужие модули и у вас нет доступа к документации и исходникам, необходимым для нужного вам уровня доверия? Для этого во всех схемах сертификации СС/ISO 15408/ГОСТ 15408 есть трюк, который называется "разделение на объект оценки и среду"

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

Отмечу: таким способом заявитель решает свои проблемы, но не проблемы своих заказчиков. Последним все равно понадобятся сертификаты и на модуль IDS, и на модуль AV. Такой трюк используется довольно часто, но упоминавшийся Алексеем PT MultiScanner сертифицируется по самому первому варианту.

"Все или ничего"

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

Давным давно, когда аббревиатуру NGFW еще не придумали, один известный вендор злоупотребил приемом "а ТУ я вам не покажу". Суть приема очень проста: вы заявляете на сертификацию комплексное решение (DPI, IDS, DLC, AV, IPSec и т.п. в одном флаконе), указав в ТУ единственную (утрирую) функцию: например, пакетную фильтрацию. Получив сертификат, бегаете по рынку с радостными криками, что ФСТЭК сертифицировал все предлагаемые вами радости жизни. А ТУ... "Фиг вам, а не ТУ почитать, коммерческая тайна". В принципе, так поступают многие, но втихую - но этот вендор уж слишком активно пытался продаваться в госы, и ФСТЭК вскоре это лазейку закрыла.

Это затруднило сертификацию решений, которые содержат наборы модулей, динамически активируемых и деактивируемых опциями лицензии. Действительно, самый честный путь - это сертификация всего набора модулей. Именно так работает MaxPatrol 8: с дистрибутива устанавливаются все модули, а какие именно будут работать - определяется опциями лицензии, привязанной к данному экземпляру. MP Local Update Server может превратиться в MP Scanner без установки дополнительных бинарников одним только переключением опций лицензии. Соответственно, сертфицированы все модули, и нас это устраивало с самого начала.

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

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

А что же действительно изменится?

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

До недавнего времени основной упор при сертификации делался на проверку того, как реализованы заявленные самим разработчиком функции сертифицируемого средства защиты. Чем выше ОУД, тем больше требуется документации и тем детальнее она должна быть. ГОСТ 15408 делает реверансы в сторону анализа уязвимостей, но не более того. Во всяком случае и российские, и зарубежные сертификаторы на вопрос: "И какими же инструментами вы делаете динамический анализ исходников?" отвечают что-нибудь одинаково невразумительное. Тоже мне, секрет Полишинеля.

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

Второе направление изменений - это ужесточение подхода к оценке жизненного цикла разработки. В этом плане россйская нормативная база действительно намного строже зарубежной. Например, когда я обсуждал с "германским ФСТЭК" сертификацию на ОУД3, оказалось, что в немецкой схеме сертификации нет требований не только к жизненному циклу разработки, но и к безопасности разработки. "Описываете свою политику безопасности, и оценивается, как вы ей соответствуете". Бардак-с :)

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

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