среда, 11 декабря 2019 г.

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

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

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

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

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

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

среда, 20 ноября 2019 г.

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

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

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

Кредитные организации должны обеспечить использование для осуществления банковских операций прикладного программного обеспечения автоматизированных систем и приложений, распространяемых кредитной организацией клиентам для совершения действий в целях осуществления банковских операций, а также программного обеспечения, обрабатывающего защищаемую информацию на участках, используемых для приема электронных сообщений, к исполнению в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети "Интернет" (далее - сеть "Интернет"), сертифицированных в системе сертификации Федеральной службы по техническому и экспортному контролю на соответствие требованиям по безопасности информации, включая требования по анализу уязвимостей и контролю отсутствия недекларированных возможностей, или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия (далее - ОУД) не ниже чем ОУД 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 раздел функциональных требований безопасности я просто пролистал. Когда речь идет об абстрактном софте, абстрактных угрозах и заготовках требований безопасности, которые потом будут допиливаться разработчиком, невозможно сказать априори, достаточно ли такого набора заготовок и нужны ли они вообще. А вот требования к анализу уязвимостей читал очень внимательно, и даже не нашелся, что в них стоило бы изменить

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

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

четверг, 7 ноября 2019 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

среда, 16 октября 2019 г.

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

среда, 19 июня 2019 г.

Анализ уязвимостей и ОУД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 требованиям к уровням доверия. Но это уже совсем другая история.

среда, 12 июня 2019 г.

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

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

.

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

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

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

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

суббота, 1 июня 2019 г.

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

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

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

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

  © Blogger template 'Solitude' by Ourblogtemplates.com 2008

Back to TOP