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

понедельник, 27 мая 2019 г.

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

Внимательно посмотрел положение ЦБ №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 в действительности не содержит никаких требований к объему и методам анализа уязвимостей, любой из этих двух вариантов будет автоматически соответствовать требованиям этого ГОСТ.

понедельник, 29 апреля 2019 г.

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

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

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

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

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

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

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

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

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

вторник, 23 апреля 2019 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

понедельник, 28 января 2019 г.

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

Алексей Лукацкий поднял интересную тему иллюзий в сертификации средств защиты по требованиям ФСТЭК. Тема слишком объемная, чтобы расписывать ее в комментариях в 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 - для остальных). И разработчикам, которые планируют сертифицироваться, стоит об этом помнить.


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

  © Blogger template 'Solitude' by Ourblogtemplates.com 2008

Back to TOP