Информационная безопасность банковских безналичных платежей. Часть 7 — Базовая модель угроз

  • Tutorial


О чем исследование
Ссылки на другие части исследования


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

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

Настоящая модель угроз предназначена для обеспечения практической безопасности и формирования внутренней документации банков в соответствии с требованиями Положений Банка России № 552-П от 24 августа 2016 г. и № 382-П от 9 июня 2012 г.
Применение сведений из статьи в противоправных целях преследуется по закону.



Методика моделирования


Структура модели угроз


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

Описание большинства этапов приведено в MITRE ATT&CK Matrix, но в ней нет расшифровки конечных действий — «Actions» (последнего этапа Kill chain), ради которых злоумышленники осуществляли атаку и которые, по сути, и являются кражей денег у банка. Другой проблемой применения классического Kill chain для моделирования угроз является отсутствие в нем описания угроз, связанных с доступностью.

Данная модель угроз призвана компенсировать эти недостатки. Для этого она формально будет состоять из двух частей:

  • Первая будет описывать проблемы, связанные с доступностью.
  • Вторая, представляющая собой классический Kill chain с расшифрованным последним этапом, будет описывать «компьютерную» кражу денег у банка.



Методика формирования модели угроз


Основными требованиями к создаваемой модели угроз были:

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

Для реализации поставленных задач модель строилась на базе методики «дерево угроз», в которую были внесены небольшие улучшения:

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

Порядок применения данной модели угроз к реальным объектам


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

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

Особенности оформления модели угроз


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

  1. Модель угроз представляет собой дерево угроз. Дерево угроз записывается в виде иерархического списка, где каждый элемент списка соответствует узлу дерева и соответственно определенной угрозе.
  2. Наименование угрозы начинается с идентификатора угрозы, который имеет вид:

    У<Код угрозы>

    где «У» — сокращение от угроза, «Код угрозы» — номер угрозы в иерархическом списке (дереве угроз).
  3. Описание угрозы может содержать в себе два блока:
    • Пояснения содержат разъяснения к описываемой угрозе. Здесь могут приводиться примеры реализации угрозы, объяснение решений, принятых во время декомпозиции, ограничения по моделированию и другая информация.
    • Декомпозиция содержит иерархический список дочерних угроз.

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

    • (И) – реализация родительской угрозы происходит только при реализации всех дочерних угроз.
    • (Сценарий) – реализация родительской угрозы происходит при некотором определенном сценарии или алгоритме реализации дочерних угроз.

  5. Ссылки на угрозы, описанные в этой же или других моделях угроз, оформляются по шаблону: Ссылка: «<Наименование модели угроз>.<Наименование угрозы>».
  6. Если наименование дочерней угрозы начинается с <...>, то это означает, что при чтении вместо <...> необходимо полностью вставить наименование родительской угрозы.

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


Объект защиты, для которого применяется модель угроз (scope)


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

Архитектура
В зону действия модели входит следующая информационная инфраструктура:



Здесь:

«Участок платежной системы Банка России (ПС БР)» — участок информационной инфраструктуры, подпадающий под действие требований Положения Банка России от 24 августа 2016 г. № 552-П. Критерий отнесения информационной инфраструктуры к участку ПС БР — обработка на объектах информационной инфраструктуры электронных сообщений в формате УФЭБС.

«Канал передачи электронных сообщений» включает в себя канал связи банка с ЦБ РФ, построенный через специализированного оператора связи или модемное соединение, а так же механизм обмена электронными сообщениями, функционирующий с помощью курьера и отчуждаемых машинных носителей информации (ОМНИ).

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

Ограничения модели
Настоящая модель угроз распространяется только на вариант организации платежной инфраструктуры с АРМ КБР, совмещающим в себе функции шифрования и электронной подписи, и не рассматривает случая использования АРМ КБР-Н, где электронная подпись осуществляется «на стороне АБС».

Угрозы безопасности верхнего уровня


Декомпозиция

У1. Прекращение функционирования системы безналичных переводов.
У2. Кража денежных средств в процессе функционирования системы безналичных переводов.

У1. Прекращение функционирования системы безналичных переводов


Пояснения

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

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

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

При декомпозиции данной угрозы учитывались следующие документы:


Декомпозиция

У1.1. Проблемы с оборудованием или носителями информации, используемыми в осуществлении переводов:
У1.1.1. Отказы и сбои.
У1.1.2. Кража.
У1.1.3. Утрата.
У1.2. Уничтожение программ или данных, необходимых для осуществления переводов.
У1.3. Совершение злоумышленниками атак, направленных на отказ в обслуживании (DoS, DDoS) технических средств и каналов связи, используемых для осуществления переводов.
У1.4. Невозможность обмена электронными сообщениями с платежной системой ЦБ РФ (И):
У1.4.1. <...>, осуществляемого через сетевые соединения:
У1.4.1.1. Неработоспособность каналов связи с ЦБ РФ (И):
У1.4.1.1.1. <...>, предоставляемых специализированным оператором связи.
У1.4.1.1.2. <...>, организованных как модемное соединение.
У1.4.1.2. Прекращение действия информации, используемой для аутентификации сетевого соединения с ЦБ РФ.
У1.4.2. <...>, осуществляемого с помощью курьера на отчуждаемых машинных носителях информации (ОМНИ):
У1.4.2.1. Отсутствие должным образом оформленных документов:
У1.4.2.1.1 <...>, подтверждающих полномочия курьера.
У1.4.2.1.2 <...>, сопровождающих платежи на ОМНИ.
У1.5. Прекращения действия криптографических ключей, используемых для защиты электронных сообщений:
У1.5.1. Окончание сроков действия криптографических ключей.
У1.5.2. Компрометация криптографических ключей.
У1.5.3. Провокация злоумышленниками удостоверяющего центра ЦБ РФ на блокирование действия криптографических ключей банка.
У1.6. Отсутствие на рабочем месте лиц, участвующих в осуществлении безналичных платежей.
У1.7. Использование устаревших версий программного обеспечения, применяемого для осуществления безналичных переводов.
У1.8. Возникновение в помещениях условий, при которых невозможно нормальное функционирование технических средств, каналов связи и персонала, участвующих в переводах:
У1.8.1. Отсутствие электропитания.
У1.8.2. Существенные нарушения температурного режима (перегрев, переохлаждение).
У1.8.3. Пожар.
У1.8.4. Затопление помещения.
У1.8.5. Обрушение или угроза обрушения помещений.
У1.8.6. Вооруженное нападение.
У1.8.7. Радиоактивное или химическое заражение.
У1.8.8. Сильные электромагнитные помехи.
У1.8.9. Эпидемии.
У1.9. Административное прекращение доступа в здания или помещения, в которых расположена информационная инфраструктура, используемая для осуществления платежей:
У1.9.1. Блокирование доступа со стороны органов власти:
У1.9.1.1. Проведение обысков или других оперативно-следственных мероприятий.
У1.9.1.2. Проведение культурно-массовых мероприятий, религиозных праздников и т.д.
У1.9.2. Блокирование доступа со стороны собственника:
У1.9.2.1. Конфликт хозяйствующих субъектов.
У1.10. Действие обстоятельств непреодолимой силы (стихийные бедствия, катастрофы, массовые беспорядки, теракты, военные действия, зомбиапокалипсис, ...).

У2. Кража денежных средств в процессе функционирования системы безналичных переводов


Пояснения

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

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

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

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

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

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

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

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

В общем случае можно считать, что обработка банком внутрибанковских переводов является частным случаем обработки межбанковских переводов, поэтому для сохранения компактности модели далее будут рассматривать только межбанковские переводы.

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

Декомпозиция

У2.1. Исполнение банком поддельных исходящих платежных поручений.
У2.2. Исполнение банком поддельных входящий платежных поручений.
У2.3. Нештатное изменение остатков на счете.

У2.1. Исполнение банком поддельных исходящих платежных поручений


Пояснения

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

Декомпозиция

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

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


Пояснения

Декомпозиция данной угрозы будет производиться по элементам информационной инфраструктуры, в которых может произойти внедрение поддельного платежного поручения.
Элементы Декомпозиция угрозы «У2.1.1. Внедрение злоумышленниками поддельного исходящего платежного поручения в бизнес-процесс обработки платежей»
Операционист банка У2.1.1.1.
Сервер ДБО У2.1.1.2.
Модуль интеграции ДБО-АБС У2.1.1.3.
АБС У2.1.1.4.
Модуль интеграции АБС-КБР У2.1.1.5.
АРМ КБР У2.1.1.6.
Модуль интеграции КБР-УТА У2.1.1.7.
УТА У2.1.1.8.
Канал передачи электронных сообщений У2.1.1.9.

Декомпозиция

У2.1.1.1. <...> в элементе «Операционист банка».
У2.1.1.2. <...> в элементе «Сервер ДБО».
У2.1.1.3. <...> в элементе «Модуль интеграции ДБО-АБС».
У2.1.1.4. <...> в элементе «АБС».
У2.1.1.5. <...> в элементе «Модуль интеграции АБС-КБР».
У2.1.1.6 .<...> в элементе «АРМ КБР».
У2.1.1.7 .<...> в элементе «Модуль интеграции КБР-УТА».
У2.1.1.8. <...> в элементе «УТА».
У2.1.1.9. <...> в элементе «Канал передачи электронных сообщений».

У2.1.1.1. <...> в элементе «Операционист банка»


Пояснения

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

Декомпозиция

У2.1.1.1.1. Операционист банка принял от злоумышленника, представившегося клиентом банка, поддельное платежное поручение на бумажном носителе.
У2.1.1.1.2. От имени операциониста банка в АБС внесено поддельное электронное платежное поручение.
У2.1.1.1.2.1. Операционист действовал по злому умыслу или совершил непреднамеренную ошибку.
У2.1.1.1.2.2. От имени операциониста действовали злоумышленники:
У2.1.1.1.2.2.1. Ссылка: «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер. У1. Совершение злоумышленниками несанкционированных действий от имени легитимного пользователя».

Примечание. Типовые модели угроз будут рассмотрены в следующих статьях.

У2.1.1.2. <...> в элементе «Сервер ДБО»


Декомпозиция

У2.1.1.2.1. Сервер ДБО принял от имени клиента должным образом заверенное платежное поручение, но составленное злоумышленниками без согласия клиента:
У2.1.1.2.1.1. Ссылка: «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер. У1. Совершение злоумышленниками несанкционированных действий от имени легитимного пользователя».
У2.1.1.2.2. Злоумышленники внедрили в сервер ДБО поддельное платежное поручение:
У2.1.1.2.2.1. Ссылка: «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер. У2. Несанкционированная модификация защищаемой информации во время ее обработки серверной частью информационной системы».

У2.1.1.3. <...> в элементе «Модуль интеграции ДБО-АБС»


Декомпозиция

У2.1.1.3.1. Ссылка: «Типовая модель угроз. Модуль интеграции. У1. Внедрение злоумышленниками подложной информации через модуль интеграции».

У2.1.1.4. <...> в элементе «АБС»


Декомпозиция

У2.1.1.4.1. Ссылка: «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер. У2. Несанкционированная модификация защищаемой информации во время ее обработки серверной частью информационной системы».

У2.1.1.5. <...> в элементе «Модуль интеграции АБС-КБР»


Декомпозиция

У2.1.1.5.1. Ссылка: «Типовая модель угроз. Модуль интеграции. У1. Внедрение злоумышленниками подложной информации через модуль интеграции».

У2.1.1.6. <...> в элементе «АРМ КБР»


Пояснения

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

Декомпозиция (И):

У2.1.1.6.1. Шифрование поддельного платежного поручения на открытых ключах Банка России:
У2.1.1.6.1.1. Ссылка: «Типовая модель угроз. Система криптографической защиты информации. У2. Зашифрование подложных данных от имени легитимного отправителя».
У2.1.1.6.2. Электронная подпись поддельного платежного поручения на закрытых ключах банка:
У2.1.1.6.2.1. Ссылка: «Типовая модель угроз. Система криптографической защиты информации. У4. Создание электронной подписи легитимного подписанта под подложными данными».

У2.1.1.7. <...> в элементе «Модуль интеграции КБР-УТА»


Пояснения

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

Декомпозиция (И):

У2.1.1.7.1. Ссылка: «Текущая модель угроз. У2.1.1.6. <...> в элементе «АРМ КБР».
У2.1.1.7.2. Ссылка: «Типовая модель угроз. Модуль интеграции. У1. Внедрение злоумышленниками подложной информации через модуль интеграции».

У2.1.1.8. <...> в элементе «УТА»


Пояснения

УТА — это, по сути, информационный робот, осуществляющий обмен криптографически защищенными электронными сообщениями с ЦБ РФ. Угрозы информационной безопасности данного элемента соответствуют с угрозами модулей интеграции.

Декомпозиция (И):

У2.1.1.8.1. Ссылка: «Текущая модель угроз. У2.1.1.6. <...> в элементе «АРМ КБР».
У2.1.1.8.2. Ссылка: «Типовая модель угроз. Модуль интеграции. У1. Внедрение злоумышленниками подложной информации через модуль интеграции».

У2.1.1.9. <...> в элементе «Канал передачи электронных сообщений»


Декомпозиция (И):

У2.1.1.9.1. Ссылка: «Текущая модель угроз. У2.1.1.6. <...> в элементе «АРМ КБР».
У2.1.1.9.2. Передача злоумышленниками поддельного платежного поручения в Банк России:
У2.1.1.9.2.1. <...> во время сеанса связи с Банком России, установленного от имени банка.
У2.1.1.9.2.2. <...> с помощью курьера на ОМНИ.

У2.2. Исполнение банком поддельного входящего платежного поручения


Декомпозиция

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

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


Пояснения

На участке АРМ КБР — платежная система Банка России платежные поручения зашифрованы и подписаны электронной подписью. На участке АРМ КБР — АБС платежные поручения в общем случае криптографически не защищены.

Поступающие в банк платежные поручения зашифрованы на открытых ключах банка и подписаны закрытыми ключами Банка России. Ключевая система криптографической защиты базируется на частной инфраструктуре открытых ключей (private PKI), реализованной на базе СКЗИ СКАД Сигнатура и включающей в себя: удостоверяющий центр Банка России и пользователей — кредитные организации. Все участники инфраструктуры открытых ключей доверяют сертификатам, выпущенным удостоверяющим центром ЦБ РФ.

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

Декомпозиция данной угрозы будет производиться на основании элементов инфраструктуры, в которых может произойти внедрение поддельных входящих платежных поручений
Элементы Декомпозиция угрозы «У2.2.1. Внедрение злоумышленниками поддельного входящего платежного поручения в бизнес-процесс обработки платежей»
АБС У2.2.1.1.
Модуль интеграции АБС-КБР У2.2.1.2.
АРМ КБР У2.2.1.3.
Модуль интеграции КБР-УТА У2.2.1.4.
УТА У2.2.1.5.
Канал передачи электронных сообщений У2.2.1.6.

Декомпозиция

У2.2.1.1. <...> в элементе «АБС».
У2.2.1.2. <...> в элементе «Модуль интеграции АБС-КБР».
У2.2.1.3 .<...> в элементе «АРМ КБР».
У2.2.1.4 .<...> в элементе «Модуль интеграции КБР-УТА».
У2.2.1.5. <...> в элементе «УТА».
У2.2.1.6. <...> в элементе «Канал передачи электронных сообщений».

У2.2.1.1. <...> в элементе «АБС»


Декомпозиция

У2.2.1.1.1. Ссылка: «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер. У2. Несанкционированная модификация защищаемой информации во время ее обработки серверной частью информационной системы».

У2.2.1.2. <...> в элементе «Модуль интеграции АБС-КБР»


Декомпозиция

У2.2.1.2.1. Ссылка: «Типовая модель угроз. Модуль интеграции. У1. Внедрение злоумышленниками подложной информации через модуль интеграции».

У2.2.1.3. <...> в элементе «АРМ КБР»


Пояснения

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

Декомпозиция

У2.2.1.3.1. Успешная проверка электронной подписи поддельного входящего платежного поручения:
У2.2.1.3.1.1 Ссылка: «Типовая модель угроз. Система криптографической защиты информации. У5. Получение положительного результата проверки электронной подписи подложных данных».

У2.2.1.4. <...> в элементе «Модуль интеграции КБР-УТА»


Пояснения

Начиная с данного элемента и далее, до платежной системы Банка России, злоумышленники теряют возможность несанкционированного воздействия на систему криптографической защиты информации (СКЗИ), поэтому все данные, попадающие из Модуля интеграции в АРМ КБР, должны быть корректно зашифрованы и подписаны. Для зашифрования злоумышленники должны использовать открытые ключи банка, а для электронной подписи закрытые ключи, сертификатам которых доверяет банк.

Декомпозиция (И):

У2.2.1.4.1. Нейтрализация криптографической защиты входящих электронных сообщений (И):
У2.2.1.4.1.1. Шифрование поддельного платежного поручения на открытых ключах банка:
У2.2.1.4.1.1.1. Ссылка: «Типовая модель угроз. Система криптографической защиты информации. У2. Зашифрование подложных данных от имени легитимного отправителя».
У2.2.1.4.1.2. Электронная подпись поддельного платежного поручения на закрытых ключах, сертификатам которых доверяет банк:
У2.2.1.4.1.2.1. Ссылка: «Типовая модель угроз. Система криптографической защиты информации. У4. Создание электронной подписи легитимного подписанта под подложными данными».
У2.2.1.4.2. Ссылка: «Типовая модель угроз. Модуль интеграции. У1. Внедрение злоумышленниками подложной информации через модуль интеграции».

У2.2.1.5. <...> в элементе «УТА»


Декомпозиция:

У2.2.1.5.1. Ссылка: «Текущая модель угроз. У2.2.1.4. <...> в элементе «Модуль интеграции КБР-УТА».

У2.2.1.6. <...> в элементе «Канал передачи электронных сообщений»


Декомпозиция (И):

У2.2.1.6.1. Ссылка: «Текущая модель угроз.У2.2.1.4.1. Нейтрализация криптографической защиты входящих электронных сообщений».
У2.2.1.6.2. Получение поддельного платежного поручения из ЦБ РФ:
У2.2.1.6.2.1. <...> во время сеанса связи с Банком России, установленного от имени банка.
У2.2.1.6.2.2. <...> с помощью курьера на ОМНИ.

Заключение


В следующей статье цикла будут рассмотрены типовые модели угроз:

Поделиться публикацией

Комментарии 20

    +1
    необходимо скомпрометировать открытые ключи шифрования банка-получателя


    Как это выглядит?
      0
      Об этом будет в типовой модели угроз СКЗИ.
        +3
        Отвратительная подача материала — отечественный официозно-бюрократический стиль из ГОСТов и прочей нормативной документации во всей красе. Прямо дежавю — лет пять назад приходилось читывать дипломы по теме ИБ написанные вот таким же языком.
          +1
          Данный документ как раз и претендует на официозно-бюрократический статус. Он сделан таким образом, чтобы на его основании можно было быстро составить свой внутренний документ.

          Хабр — информационно /развлекательный проект. Этот материал информационный, он для работы, поэтому и выбран сухой бюрократический стиль.
            +1
            Вот именно, что хабр информационно-развлекательный портал, а не госучреждение.
              +1
              Проблема в том, что этот самый сухой бюрократический местами напоминает патологическое резонёрство.

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

              Если в нашей отечественной ИБ-школе это считается признаком профессионализма…
                +1
                Ради интереса давайте вместе посмотрим как формировалась фраза.

                Итак, что такое кража денег у банка? Первое, что приходит на ум — врываются люди в масках и забирают наличные из кассы. Хорошо, но не то. Нас интересуют переводы (платежи), то есть деньги в безналичном виде.

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

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

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

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

            Откуда она берется эта необходимиость или ненеобходимость?

              +1
              В модели, когда говорим, например, про АБС, мы не указываем АБС какой фирмы и как используется. Мы просто приводим абстрактную систему, сочетающую в себе основные черты реальных систем и указываем к ней абстрагированные угрозы.

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

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

              Чтобы отразить эти нюансы, специалист, разрабатывающий частную модель должен обладать определенным опытом и знаниями. Если такие опыт и знания есть, он делает уточняющую декомпозицию, если его нет — оставляет описание угроз с текущим уровнем детализации.
                +1
                Чтобы отразить эти нюансы, специалист, разрабатывающий частную модель должен обладать определенным опытом и знаниями. Если такие опыт и знания есть, он делает уточняющую декомпозицию, если его нет — оставляет описание угроз с текущим уровнем детализации.

                А судья кто?
                И что дает это "описание угроз с текущим уровнем детализации"?

                0
                На самом деле необходимость детализации возникает исходя из конкретики деятельности компании.

                Есть типовая модель, характерная для отрасли и чуть уже — для определенного сектора. А дальше — есть сценарии и шаблоны деловых процессов, характерные уже для определенной компании. Их анализ уже позволяет решать — нужна здесь декомпозиция или можно обойтись, так сказать, наработанными отраслевыми стандартами.
                  0

                  Слова, слова, слова…
                  А нельзя просто сказать поставьме то-то и то-то, настройке так и так и получитк тото и тото.


                  Есть типовая модель, характерная для отрасли и чуть уже — для определенного сектора. А дальше — есть сценарии и шаблоны деловых процессов, характерные уже для определенной компании. Их анализ уже позволяет решать — нужна здесь декомпозиция или можно обойтись, так сказать, наработанными отраслевыми стандартами.

                  И вот таких же пустых слов полно во всяких РД, моделях и т.д. А может просто сказать как настроить правильно комп, А?

                    +1
                    >А может просто сказать как настроить правильно комп, А?

                    На самом деле — да, именно это и было бы интересно, даже на примере сферической в вакууме компании, названно, скажем, N (во имя неразглашения, разумеется — тут как раз понятно).

                    Было бы интересно рассмотреть особенности организации взаимодействия собственно СБ и IT-отдела, конкретику по настройке сетей, сертификатов, допусков и т.п.

                    Но увы — я в комментарии выше не случайно упомянул про дипломы. Их просто так учат. И магистерские работы состоят из ~100500 глав воды с обильным цитированием из ФЗ, ГОСТов и, разумеется, учебника, написанного научным руководителем (примерно 90% тщательно систематизированной воды, мудрых мыслей Капитана Очевидность, ...), а только в конце, в приложениях, дай Бог, конкретика.
                      0

                      А мы рассуждаем о какой-то цифровой экономике. И никто не говорит, какой смысл они вкладывают в свои слова!

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

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

                        Затем, в этом посту, мы рассмотрели как вообще люди занимаются моделированием угроз ИБ. Узнали что есть kill chain, MTIRE ATT&CK Matrix и древовидные модели.

                        Теперь собственно сама работа. Мы отсюда и отсюда берем описание объекта защиты. Смотрим тут и тут что с реальными угрозами.

                        В результате данный и следующий пост, в которых в виде заготовок для внутренних документов изложена модель угроз с учетом всего выше перечисленного.
                  +1
                  И что дает это «описание угроз с текущим уровнем детализации»?

                  Данное описание содержит в себе все угрозы, которые были реализованы в реальных банковских преступлениях последних лет. Его будет достаточно для обеспечения должного уровня безопасности большинства банков.
                  А судья кто?

                  Модель угроз — основная часть тех. задания на подсистему обеспечения информационной безопасности. Полнота и корректность модели напрямую влияет на качество создаваемой системы защиты. Соответственно «судьей» будет заказчик этой системы.

                  Но я думаю, что вы хотели спросить про другое.
                  Использованная методика моделирования не содержит ограничений на глубину декомпозиции. Начиная с абстрактного понятия электронный платежный документ мы в итоге можем прийти к XML-файлу, «invoice-20092018.xml», хранящемуся на файловом сервере «prod-fs27-internal.bank.local» с адресом 10.76.23.98. И здесь возникает вопрос как глубоко нужно капать и что считать требуемым уровнем детализации?

                  Для ответа на этот вопрос давайте рассмотрим конечных пользователей модели. Условно этих людей можно представить следующим образом:


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

                  Классические «конечные» модели угроз, оперирующие защитой КДЦ (конфиденциальность, целостность, доступность) абсолютно не подходят для их обсуждения с не IT-специалистами.
                    0
                    Кто будет пользователем этого документа? Если для собственных нужд то это одно, если для внешнего аудита, то нужны как минимум ссылки на БДУ ФСТЭК, модель нарушителя и другие сопутствующие нормативке по КИИ.
                      +1
                      Требования 552-П и 382-П не содержат ограничений на использование различных методик моделирования угроз.

                      Использование БДУ ФСТЭК в обязательном порядке требуется только при формировании угроз для ГИС / МИС и для объектов КИИ.
                        0
                        Банковская сфера как раз подпадает под 187ФЗ, так-что надо учитывать всю нормативку при создании МУ.
                          +1
                          Банки исходя из 187-ФЗ субъекты КИИ. Будет ли «АРМ КБР» объектом КИИ в общем случае сказать нельзя, у кого-то будет, у кого-то нет.

                          Модель угроз ориентирована на практическую безопасность и банковскую нормативку.

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

                    Самое читаемое