- PVSM.RU - https://www.pvsm.ru -
Данная статья завершает цикл публикаций, посвященных обеспечению информационной безопасности банковских безналичных платежей. Здесь мы рассмотрим типовые модели угроз, на которые ссылались в базовой модели [8]:
ХАБРО-WARNING !!! Уважаемыее, это не развлекательный пост.
Спрятанные под катом 40+ страниц материалов призваны помочь в работе или учебе людям, специализирующимся на банковском деле или обеспечении информационной безопасности. Данные материалы являются конечным продуктом исследования и написаны в сухом официальном тоне. По сути это заготовки для внутренних документов по ИБ.Ну и традиционное — «применение сведений из статьи в противоправных целях преследуется по закону». Продуктивного чтения!
Информация для читателей, которые знакомятся с исследованием, начиная с этой публикации.
О чем исследование
Вы читаете гайд для специалиста, ответственного за обеспечение информационной безопасности платежей в банке.
Логика изложения
В начале в части 1 [2] и части 2 [3] дается описание объекта защиты. Затем в части 3 [4] рассказывается, как построить систему защиты, и говорится о необходимости формирования модели угроз. В части 4 [5] рассказывается о том, какие модели угроз бывают и как их формируют. В части 5 [6] и части 6 [7] приводится анализ реальных атак. Часть 7 [8] и часть 8 [9] содержат описание модели угроз, построенной с учетом сведений из всех предыдущих частей.
Объектом защиты являются данные, передаваемые через сетевое соединение, функционирующее в сетях передачи данных, построенных на базе стека TCP/IP.
Архитектура
Описание элементов архитектуры:
Декомпозиция
У1. Несанкционированное ознакомление с передаваемыми данными.
У2. Несанкционированная модификация передаваемых данных.
У3. Нарушение авторства передаваемых данных.
Декомпозиция
У1.1. <...>, осуществляемое на конечных или промежуточных узлах:
У1.1.1. <...> путем считывания данных во время их нахождения в запоминающих устройствах узла:
У1.1.1.1. <...> в оперативной памяти.
Пояснения к У1.1.1.1.
Например, во время обработки данных сетевым стеком узла.
У1.1.1.2. <...> в энергонезависимой памяти.
Пояснения к У1.1.1.2.
Например, при хранении передаваемых данных в кэше, временных файлах или файлах подкачки.
У1.2. <...>, осуществляемое на сторонних узлах сети передачи данных:
У1.2.1. <...> методом захвата всех пакетов, попадающих на сетевой интерфейс узла:
Пояснения к У1.2.1.
Захват всех пакетов осуществляется путем перевода сетевой карты в неразборчивый режим (promiscuous режим для проводных адаптеров или в режим монитора для wi-fi адаптеров).
У1.2.2. <...> путем осуществления атак типа «человек посередине (MiTM)», но без модификации передаваемых данных (не считая служебных данных сетевых протоколов).
У1.2.2.1. Ссылка: «Типовая модель угроз. Сетевое соединение. У2. Несанкционированная модификация передаваемых данных» [15].
У1.3. <...>, осуществляемое за счет утечки информации по техническим каналам (ТКУИ) с физических узлов или линий связи.
У1.4. <...>, осуществляемое за установки на конечные или промежуточные узлы специальных технических средств (СТС), предназначенных для негласного съема информации.
Декомпозиция
У2.1. <...>, осуществляемая на конечных или промежуточных узлах:
У2.1.1. <...> путем считывания и внесения изменения в данные во время их нахождения в запоминающих устройствах узлов:
У2.1.1.1. <...> в оперативной памяти:
У2.1.1.2. <...> в энергонезависимой памяти:
У2.2. <...>, осуществляемая на сторонних узлах сети передачи данных:
У2.2.1. <...> путем осуществлении атак типа «человек посередине (MiTM)» и перенаправления трафика на узел злоумышленников:
У2.2.1.1. Физическое подключение оборудования злоумышленников в разрыв сетевого соединения.
У2.2.1.2. Осуществление атак на сетевые протоколы:
У2.2.1.2.1. <...> управления виртуальными локальными сетями (VLAN):
У2.2.1.2.1.1. VLAN hopping [16].
У2.2.1.2.1.2. Несанкционированная модификация настроек VLAN на коммутаторах или маршрутизаторах.
У2.2.1.2.2. <...> маршрутизации трафика:
У2.2.1.2.2.1. Несанкционированная модификация таблиц статической маршрутизации роутеров.
У2.2.1.2.2.2. Анонсирование злоумышленниками подложных маршрутов через протоколы динамической маршрутизации.
У2.2.1.2.3. <...> автоматического конфигурирования:
У2.2.1.2.3.1. Rogue DHCP [17].
У2.2.1.2.3.2. Rogue WPAD [18].
У2.2.1.2.4. <...> адресации и разрешения имен:
У2.2.1.2.4.1. ARP spoofing [19].
У2.2.1.2.4.2. DNS spoofing [20].
У2.2.1.2.4.3. Внесение несанкционированных изменений в локальные файлы имен узлов (hosts, lmhosts и др.)
Декомпозиция
У3.1. Нейтрализации механизмов определения авторства информации путем указания подложных сведений об авторе или источнике данных:
У3.1.1. Изменение сведений об авторе, содержащихся в передаваемой информации.
У3.1.1.1. Нейтрализация криптографической защиты целостности и авторства передаваемых данных:
У3.1.1.1.1. Ссылка: «Типовая модель угроз. Система криптографической защиты информации.
У4. Создание электронной подписи легитимного подписанта под подложными данными».
У3.1.1.2. Нейтрализация защиты авторства передаваемых данных, реализованной с помощью одноразовых кодов подтверждений:
У3.1.1.2.1. SIM swap [21].
У3.1.2. Изменение сведений об источнике передаваемой информации:
У3.1.2.1. IP spoofing [22].
У3.1.2.2. MAC spoofing [23].
Объектом защиты является информационная система, построенная на базе архитектуры клиент-сервер.
Архитектура
Описание элементов архитектуры:
Ограничения
При моделировании объекта установлены следующие ограничения:
Декомпозиция
У1. Совершение злоумышленниками несанкционированных действий от имени легитимного пользователя.
У2. Несанкционированная модификация защищаемой информации во время ее обработки серверной частью информационной системы.
Пояснения
Обычно в информационных системах соотнесение действий с выполнившим их пользователем производится с помощью:
По отношению к сеансу работы данная угроза может декомпозироваться на:
Сеанс работы пользователя может быть инициирован:
На данном этапе промежуточная декомпозиция данной угрозы будет выглядеть следующим образом:
У1.1. Несанкционированные действия выполнены в рамках сеанса работы пользователя:
У1.1.1. <...>, установленного атакованным пользователем.
У1.1.2. <...>, установленного злоумышленниками.
У1.2. Несанкционированные действия выполнены вне сеанса работы пользователя.
С точки зрения объектов информационной инфраструктуры, на которые могут воздействовать злоумышленники, декомпозиция промежуточных угроз будет выглядеть следующим образом:
Элементы | Декомпозиция угроз | ||
---|---|---|---|
У1.1.1. | У1.1.2. | У1.2. | |
Клиент | У1.1.1.1. | У1.1.2.1. | |
Сетевое соединение | У1.1.1.2. | ||
Сервер | У1.2.1. |
Декомпозиция
У1.1. Несанкционированные действия выполнены в рамках сеанса работы пользователя:
У1.1.1. <...>, установленного атакованным пользователем:
У1.1.1.1. Злоумышленники самостоятельно действовали с Клиента:
У1.1.1.1.1 Злоумышленники использовали штатные средства доступа информационной системы:
У1.1.1.1.1.1. Злоумышленники использовали физические средства ввода-вывода Клиента (клавиатура, мышь, монитор или сенсорный экран мобильного устройства):
У1.1.1.1.1.1.1. Злоумышленники действовали в периоды времени, когда сеанс активен, средства ввода-вывода доступны, а пользователя нет на месте.
У1.1.1.1.1.2. Злоумышленники использовали средства удаленного администрирования (штатные или предоставленные вредоносным кодом) для управления Клиентом:
У1.1.1.1.1.2.1. Злоумышленники действовали в периоды времени, когда сеанс активен, средства ввода-вывода доступны, а пользователя нет на месте.
У1.1.1.1.1.2.2. Злоумышленники использовали средства удаленного администрирования, работа которых незаметна атакованному пользователю.
У1.1.1.2. Злоумышленники подменяли данные в сетевом соединении между Клиентом и Сервером, модифицируя их таким образом, чтобы они воспринимались как действия легитимного пользователя:
У1.1.1.2.1. Ссылка: «Типовая модель угроз. Сетевое соединение. У2. Несанкционированная модификация передаваемых данных» [15].
У1.1.1.3. Злоумышленники принудили пользователя к выполнению указанных ими действий, используя методы социальной инженерии.
У1.1.2 <...> установленного злоумышленниками:
У1.1.2.1. Злоумышленники действовали с Клиента (И):
У1.1.2.1.1. Злоумышленники нейтрализовали систему разграничения доступа информационной системы:
У1.1.2.1.1.1. Ссылка: «Типовая модель угроз. Система разграничения доступа. У1. Несанкционированное установление сеанса работы от имени легального пользователя» [24].
У1.1.2.1.2. Злоумышленники использовали штатные средства доступа информационной системы
У1.1.2.2. Злоумышленники действовали с других узлов сети передачи данных, с которых можно установить сетевое соединение с Сервером (И):
У1.1.2.2.1. Злоумышленники нейтрализовали систему разграничения доступа информационной системы:
У1.1.2.2.1.1. Ссылка: «Типовая модель угроз. Система разграничения доступа. У1. Несанкционированное установление сеанса работы от имени легального пользователя» [24].
У1.1.2.2.2. Злоумышленники использовали нештатные средства доступа информационной системы.
Пояснения У1.1.2.2.2.
Злоумышленники могли установить штатный клиент информационной системы на сторонний узел или могли использовать нештатное ПО, реализующее штатные протоколы обмена между Клиентом и Сервером.
У1.2 Несанкционированные действия выполнены вне сеанса работы пользователя.
У1.2.1 Злоумышленники выполнили несанкционированные действия, а затем внесли несанкционированные изменения в журналы работы информационной системы или специальные атрибуты объектов данных, указав, что совершенные ими действия выполнены легитимным пользователем.
Декомпозиция
У2.1. Злоумышленники модифицируют защищаемую информацию с помощью штатных средств информационной системы и проводят это от имени легитимного пользователя.
У2.1.1. Ссылка: «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер. У1. Совершение злоумышленниками несанкционированных действий от имени легитимного пользователя» [25].
У2.2. Злоумышленники модифицируют защищаемую информацию путем использования не предусмотренных штатным режимом функционирования информационной системы механизмов доступа к данным.
У2.2.1. Злоумышленники модифицируют файлы, содержащие защищаемую информацию:
У2.2.1.1. <...>, используя механизмы работы с файлами, предоставляемые операционной системой.
У2.2.1.2. <...> путем провокации восстановления файлов из несанкционированно модифицированной резервной копии.
У2.2.2. Злоумышленники модифицируют защищаемую информацию, хранящуюся в базе данных (И):
У2.2.2.1. Злоумышленники нейтрализовывают систему разграничения доступа СУБД:
У2.2.2.1.1. Ссылка: «Типовая модель угроз. Система разграничения доступа. У1. Несанкционированное установление сеанса работы от имени легального пользователя» [24].
У2.2.2.2. Злоумышленники модифицируют информацию, используя штатные интерфейсы СУБД для доступа к данным.
У2.3. Злоумышленники модифицируют защищаемую информацию путем несанкционированной модификации алгоритмов работы обрабатывающего ее ПО.
У2.3.1. Модификации подвергается исходный код ПО.
У2.3.1. Модификации подвергается машинный код ПО.
У2.4. Злоумышленники модифицируют защищаемую информацию путем использования уязвимостей в программном обеспечении информационной системы.
У2.5. Злоумышленники модифицируют защищаемую информацию при ее передаче между компонентами серверной части информационной системы (например, сервером баз данных и сервером приложений):
У2.5.1. Ссылка: «Типовая модель угроз. Сетевое соединение. У2. Несанкционированная модификация передаваемых данных» [15].
Объект защиты, для которого применяется данная модель угроз, соответствует объекту защиты модели угроз: «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер».
Под системой разграничения доступа пользователей в данной модели угроз подразумевается компонент информационной системы, реализующий функции:
Декомпозиция
У1. Несанкционированное установление сеанса работы от имени легального пользователя.
У2. Несанкционированное повышение привилегий пользователя в информационной системе.
Пояснения
Декомпозиция данной угрозы в общем случае будет зависеть от применяемого типа систем идентификации и аутентификации пользователей.
В данной модели будет рассмотрена только система идентификации и аутентификации пользователей, использующая текстовые логин и пароль. При этом будем считать, что логин пользователя — общедоступная информация, известная злоумышленникам.
Декомпозиция
У1.1. <...> за счет компрометации учетных данных:
У1.1.1. Злоумышленники скомпрометировали учетные данные пользователя в процессе их хранения.
Пояснения У1.1.1.
Например, учетные данные могли быть написаны на стикере, приклеенном к монитору.
У1.1.2. Пользователь случайно или по злому умыслу передал реквизиты доступа злоумышленникам.
У1.1.2.1. Пользователь проговаривал учетные данные вслух при вводе.
У1.1.2.2. Пользователь умышлено передал свои учетные данные:
У1.1.2.2.1. <...> коллегам по работе.
Пояснения У1.1.2.2.1.
Например, для того, чтобы они могли его заменить на период болезни.
У1.1.2.2.2. <...> контрагентам работодателя, выполняющим работы над объектами информационной инфраструктуры.
У1.1.2.2.3. <...> третьим лицам.
Пояснения У1.1.2.2.3.
Одним, но не единственными вариантом реализации данной угрозы является использование злоумышленниками методов социальной инженерии.
У1.1.3. Злоумышленники подобрали учетные данные методом перебора:
У1.1.3.1. <...> с использованием штатных механизмов доступа.
У1.1.3.2. <...> по ранее перехваченным кодам (например, хэшам паролей) хранения учетных данных.
У1.1.4. Злоумышленники использовали вредоносный код для перехвата учетных данных пользователя.
У1.1.5. Злоумышленники извлекли учетные данные из сетевого соединения между Клиентом и Сервером:
У1.1.5.1. Ссылка: «Типовая модель угроз. Сетевое соединение. У1. Несанкционированное ознакомление с передаваемыми данными» [26].
У1.1.6. Злоумышленники извлекли учетные данные с записей систем мониторинга работы:
У1.1.6.1. <...> систем видеонаблюдения (в случае, если во время работы фиксировались нажатия клавиш на клавиатуре).
У1.1.6.2. <...> систем контроля действий сотрудников за компьютером
Пояснения У1.1.6.2.
Пример подобной системы — StuffCop [27].
У1.1.7. Злоумышленники скомпрометировали учетные данные пользователя из-за недостатков процесса их передачи.
Пояснения У1.1.7.
Например, передача паролей в открытом виде по электронной почте.
У1.1.8. Злоумышленники узнали учетные данные путем наблюдения за сеансом работы пользователя с помощью систем удаленного администрирования.
У1.1.9. Злоумышленники извлекли учетные данные в результате их утечки по техническим каналам (ТКУИ):
У1.1.9.1. Злоумышленники подглядели, как пользователь вводит учетные данные с клавиатуры:
У1.1.9.1.1 Злоумышленники располагались в непосредственной близости к пользователю и видели ввод учетных данных своими глазами.
Пояснения У1.1.9.1.1
К подобным случаям можно отнести действия коллег по работе или случай, когда клавиатуру пользователя видно посетителям организации.
У1.1.9.1.2 Злоумышленники использовали дополнительные технические средства, такие как бинокль или беспилотный летательный аппарат, и увидели ввод учетных данных через окно.
У1.1.9.2. Злоумышленники извлекли учетные данные из записей радиообмена между клавиатурой и системным блоком компьютера в случае подключения их по радиоинтерфейсу (например, Bluetooth).
У1.1.9.3. Злоумышленники осуществили перехват учетных данных за счет их утечки по каналу побочных электромагнитных излучений и наводок (ПЭМИН).
Пояснения У1.1.9.3.
Примеры атаки тут [28] и тут [29].
У1.1.9.4. Злоумышленник осуществил перехват ввода учетных данных с клавиатуры за счет использования специальных технических средств (СТС), предназначенных для негласного съема информации.
Пояснения У1.1.9.4.
Примеры устройств [30].
У1.1.9.5. Злоумышленники осуществили перехват ввода учетных данных с клавиатуры за счет
анализа Wi-Fi сигнала, модулированного процессом нажатия клавиш пользователем.
Пояснения У1.1.9.5.
Пример атаки [31].
У1.1.9.6. Злоумышленники осуществили перехват ввода учетных данных с клавиатуры за счет анализа звуков нажатия на клавиши.
Пояснения У1.1.9.6.
Пример атаки [32].
У1.1.9.7. Злоумышленники осуществили перехват ввода учетных данных с клавиатуры мобильного устройства за счет анализа показаний акселерометра.
Пояснения У1.1.9.7.
Пример атаки [33].
У1.1.10. <...>, предварительно сохраненных на Клиенте.
Пояснения У1.1.10.
Например, пользователь мог сохранить в браузере логин и пароль для доступа к определенному сайту.
У1.1.11. Злоумышленники скомпрометировали учетные данные из-за недостатков процесса отзыва доступов пользователей.
Пояснения У1.1.11.
Например, после увольнения пользователя его учетные записи остались не заблокированными.
У1.2. <...> за счет использования уязвимостей в системе разграничения доступа.
Декомпозиция
У2.1 <...> путем внесения несанкционированных изменений в данные, содержащие сведения о привилегиях пользователя.
У2.2 <...> за счет использования уязвимостей в системе разграничения доступа.
У2.3. <...> из-за недостатков процесса управления доступом пользоватлей.
Пояснения У2.3.
Пример 1. Пользователю для работы был предоставлен доступ больший, нежели ему требовался по служебной необходимости.
Пример 2. После перевода пользователя на другую должность ранее предоставленные права доступа не были отозваны.
Модуль интеграции – набор объектов информационной инфраструктуры, предназначенный для организации обмена информацией между информационными системами.
Учитывая тот факт, что в корпоративных сетях не всегда возможно однозначно отделить одну информационную систему от другой, модуль интеграции можно рассматривать и как связующее звено между компонентами внутри одной информационной системы.
Архитектура
Обобщенная схема модуля интеграции выглядит следующим образом:
Описание элементов архитектуры:
Примеры модулей интеграции
Схема 1. Интеграция АБС и АРМ КБР через сторонний файловый сервер
Для исполнения платежей уполномоченный работник банка выгружает из АБС электронные платежные документы и сохраняет их в файл (собственного формата, например SQL-дамп) на сетевой папке (\...SHARE) файлового сервера. Затем этот файл с помощью скрипта-конвертера преобразуется в набор файлов формата УФЭБС, которые затем считывает АРМ КБР.
После этого уполномоченный работник — пользователь АРМ КБР — шифрует и подписывает полученные файл и отправляет их в платежную систему Банка России.
При поступлении платежей из Банка России АРМ КБР проводит их расшифровку и проверку электронной подписи, после чего записывает в виде набора файлов формата УФЭБС на файловый сервер. Перед импортом платежных документов в АБС они преобразуются с помощью скрипта-конвертера из формата УФЭБС в формат АБС.
Будем считать, что в данной схеме АБС функционирует на одном физическом сервере, АРМ КБР функционирует на выделенном компьютере, а скрипт-конвертер работает на файловом сервере.
Соответствие объектов рассмотренной схемы элементам модели модуля интеграции:
«Сервера обмена со стороны АБС» – сервер АБС.
«Сервера обмена со стороны АРМ КБР» – компьютер АРМ КБР.
«Посредник» – сторонний файловый сервер.
«ПО обработки данных» – скрипт-конвертер.
Схема 2. Интеграция АБС и АРМ КБР при размещении общей сетевой папки с платежами на АРМ КБР
Все аналогично Схеме 1, но отдельный файловый сервер не используется, вместо этого сетевая папка (\...SHARE) с электронными платежными документами размещается на компьютере с АРМ КБР. Скрипт-конвертер также работает на АРМ КБР.
Соответствие объектов рассмотренной схемы элементам модели модуля интеграции:
Аналогично Схеме 1, но «Посредник» не используется.
Схема 3. Интеграция АБС и АРМ КБР-Н через IBM WebSphera MQ и осуществление подписи электронных документов «на стороне АБС»
АБС работает на платформе, не поддерживаемой СКЗИ СКАД Сигнатура. Подпись исходящих электронных документов проводится на специальном сервере электронной подписи (Сервер ЭП). Этот же сервер проверяет электронную подпись под входящими из Банка России документами.
АБС выгружает на Сервер ЭП файл с платежными документами в собственном формате.
Сервер ЭП с помощью скрипта-конвертера преобразует файл в электронные сообщения формата УФЭБС, после этого электронные сообщения подписываются и передаются на IBM WebSphere MQ.
АРМ КБР-Н обращается к IBM WebSphere MQ и получает оттуда подписанные платежные сообщения, после чего уполномоченный работник — пользователь АРМ КБР — их шифрует и отправляет в платежную систему Банка России.
При поступлении платежей из Банка России АРМ КБР-Н расшифровывает их и проверяет электронную подпись. Успешно обработанные платежи в виде расшифрованных и подписанных электронных сообщений формата УФЭБС передаются в IBM WebSphere MQ, откуда их получает Сервер ЭП.
Сервер ЭП проверяет электронную подпись поступивших платежей и сохраняет их в файл формата АБС. После этого уполномоченный работник — пользователь АБС — загружает получившийся файл в АБС в установленном порядке.
Соответствие объектов рассмотренной схемы элементам модели модуля интеграции:
«Сервер обмена со стороны АБС» – сервер АБС.
«Сервер обмена со стороны АРМ КБР» — компьютер АРМ КБР.
«Посредник» – Сервер ЭП и IBM WebSphere MQ.
«ПО обработки данных» – скрипт-конвертер, СКЗИ СКАД Сигнатура на Сервере ЭП.
Схема 4. Интеграция Сервера ДБО и АБС через API, предоставляемый выделенным сервером обмена
Будем считать, что в банке используется несколько систем дистанционного банковского обслуживания (ДБО):
В целях обеспечения информационной безопасности все взаимодействие АБС с системами ДБО осуществляется через
Далее рассмотрим процесс взаимодействия системы ДБО ИКБ ЮЛ с АБС.
Сервер ДБО, получив от клиента должным образом заверенное платежное поручение, должен на его основе создать соответствующий документ в АБС. Для этого он с помощью API передает информацию в сервер обмена, а тот, в свою очередь, вносит данные в АБС.
При изменении остатков на счете клиента АБС формирует электронные уведомления, которые с помощью сервера обмена передаются на сервер ДБО.
Соответствие объектов рассмотренной схемы элементам модели модуля интеграции:
«Сервер обмена со стороны ДБО» – сервер ДБО ИКБ ЮЛ.
«Сервер обмена со стороны АБС» – сервер обмена.
«Посредник» – отсутствует.
«ПО обработки данных» – компоненты Сервера ДБО, ответственные за использование API сервера обмена, компоненты сервера обмена, ответственные за использование API АБС.
Декомпозиция
У1. Внедрение злоумышленниками подложной информации через модуль интеграции.
Декомпозиция
У1.1. Несанкционированная модификация легитимных данных при их передаче через сетевые соединения:
У1.1.1 Ссылка: «Типовая модель угроз. Сетевое соединение. У2. Несанкционированная модификация передаваемых данных» [15].
У1.2. Передача по каналам связи подложных данных от имени легитимного участника обмена:
У1.1.2 Ссылка: «Типовая модель угроз. Сетевое соединение. У3. Нарушение авторства передаваемых данных» [35].
У1.3. Несанкционированная модификация легитимных данных при их обработке на Серверах обмена или Посреднике:
У1.3.1. Ссылка: «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер. У2. Несанкционированная модификации защищаемой информации во время ее обработки серверной частью информационной системы» [36].
У1.4. Создание на Серверах обмена или Посреднике подложных данных от имени легитимного участника обмена:
У1.4.1. Ссылка: «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер. У1. Совершение злоумышленниками несанкционированных действий от имени легитимного пользователя». [25]
У1.5. Несанкционированная модификация данных при их обработке с помощью ПО обработки данных:
У1.5.1. <...> за счет внесения злоумышленниками несанкционированных изменений в настройки (конфигурацию) ПО обработки данных.
У1.5.2. <...> за счет внесения злоумышленниками несанкционированных изменений в исполняемые файлы ПО обработки данных.
У1.5.3. <...> за счет интерактивного управления злоумышленниками работой ПО обработки данных.
Объектом защиты является система криптографической защиты информации, используемая для обеспечения безопасности информационной системы.
Архитектура
Основой любой информационной системы является прикладное программное обеспечение (ПО), реализующее ее целевой функционал.
Криптографическая защита при этом обычно реализуется путем вызова из бизнес-логики прикладного ПО криптографических примитивов, которые размещаются в специализированных библиотеках – криптоядрах.
К криптографическим примитивам относятся низкоуровневые криптографические функции, такие как:
Бизнес-логика прикладного ПО с помощью криптографических примитивов реализует более высокоуровневый функционал:
Взаимодействие бизнес-логики и криптоядра может производиться:
Можно выделить две типовые схемы организации криптоядра:
Схема 1 – Монолитное криптоядро
Схема 2 – Разделенное криптоядро
Элементы на приведенных схемах могут быть как отдельными модулями ПО, работающими на одном компьютере, так и сетевыми сервисами, взаимодействующими в рамках вычислительной сети.
При использовании систем, построенных по схеме 1, прикладное ПО и криптоядро работают в рамках единой среды функционирования криптосредства (СФК), например, на одном и том же компьютере, под управлением одной и той же операционной системы. Пользователь системы, как правило, может запускать в рамках этой же среды функционирования и другие программы, в том числе содержащие вредоносный код. В подобных условиях существует серьезный риск утечки закрытых криптографических ключей.
Для минимизации риска применяют схему 2, при которой криптоядро разделяется на две части:
Разделение криптоядра на программную и аппаратную части весьма условно. На рынке есть системы, построенные по схеме с разделенным криптоядром, но «аппаратная» часть которых представлена в виде образа виртуальной машины — virtual HSM (пример [37]).
Взаимодействие обеих частей криптоядра происходит таким образом, что закрытые криптографические ключи никогда не передаются в программную часть и, соответственно, не могут быть похищены с помощью вредоносного кода.
Интерфейс взаимодействия (API) и набор криптографических примитивов, предоставляемых прикладному ПО криптоядром, в обоих случаях одинаковый. Различие кроется в способе их реализации.
Так, при использовании схемы с разделенным криптоядром, взаимодействие программной и аппаратной части выполняется по следующему принципу:
Проиллюстрируем работу разделенного криптоядра на примере создания электронной подписи:
Особенности проверки корректности электронной подписи
Когда принимающая сторона получает данные, подписанные электронной подписью, она должна провести несколько этапов проверки. Положительный результат проверки электронной подписи достигается только при успешном прохождении всех этапов проверки.
Этап 1. Контроль целостности данных и авторства данных.
Содержание этапа. Проводится проверка электронной подписи данных по соответствующему криптографическому алгоритму. Успешное прохождение данного этапа говорит о том, что данные не модифицировались с момента их подписания, а также то, что подпись была произведена закрытым ключом, соответствующим открытому ключу проверки электронной подписи.
Место выполнения этапа: криптоядро.
Этап 2. Контроль доверия к открытому ключу подписанта и контроль срока действия закрытого ключа электронной подписи.
Содержание этапа. Этап состоит из двух промежуточных подэтапов. На первом устанавливается, являлся ли открытый ключ проверки электронной подписи доверенным на момент подписания данных. На втором устанавливается, действовал ли на момент подписания данных закрытый ключ электронной подписи. В общем случае сроки действия этих ключей могут не совпадать (например, для квалифицированных сертификатов ключей проверки электронной подписи). Способы установления доверия к открытому ключу подписанта определяются правилами электронного документооборота, принятыми взаимодействующими сторонами.
Место выполнения этапа: прикладное ПО / криптоядро.
Этап 3. Контроль полномочий подписанта.
Содержание этапа. В соответствии с установленными правилами электронного документооборота проверяется, имел ли подписант право заверять защищаемые данные. Для примера приведем ситуацию нарушения полномочий. Предположим, есть организация, где все работники имеют электронную подпись. Во внутреннюю систему электронного документооборота поступает приказ руководителя, но подписанный электронной подписью заведующего складом. Соответственно, подобный документ не может считаться легитимным.
Место выполнения этапа: прикладное ПО.
Допущения, принятые при описании объекта защиты
Для иллюстрации ранее представленных схем рассмотрим гипотетическую информационную систему и выделим на ней все структурные элементы.
Описание информационной системы
Две организации решили внедрить между собой юридически значимый электронный документооборот (ЭДО). Для этого они заключили соглашение, в котором прописали, что документы будут передаваться по электронной почте, и при этом они должны быть зашифрованы и подписаны квалифицированной электронной подписью. В качестве средств создания и обработки документов должны использоваться офисные программы из пакета Microsoft Office 2016, а в качестве средств криптографической защиты — СКЗИ КриптоПРО и ПО шифрования КриптоАРМ.
Описание инфраструктуры организации 1
Организация 1 решила, что установит СКЗИ КриптоПРО и ПО КриптоАРМ на АРМ пользователя — физический компьютер. Ключи шифрования и электронной подписи будут храниться на ключевом носителе ruToken, работающем в режиме извлекаемого ключа. Пользователь будет подготавливать электронные документы локально на своем компьютере, после чего их шифровать, подписывать и отправлять с помощью локально установленного почтового клиента.
Описание инфраструктуры организации 2
Организация 2 решила вынести функции шифрования и электронной подписи на выделенную виртуальную машину. При этом все криптографические операции будут производиться в автоматическом режиме.
Для этого на выделенной виртуальной машине организовано две сетевых папки: "\...In", "\...Out". В сетевую папку "\...In" будут автоматически помещаться полученные от контрагента файлы в открытом виде. Эти файлы будут расшифрованы, и на них будет проверена электронная подпись.
В папку "\...Out" пользователь будет помещать файлы, которые необходимо зашифровать, подписать и отправить контрагенту. Сами файлы пользователь будет готовить на своем АРМе.
Для выполнения функций шифрования и электронной подписи на виртуальную машину установлены СКЗИ КриптоПРО, ПО КриптоАРМ и почтовый клиент. Автоматическое управление всеми элементами виртуальной машины будет осуществляться с помощью скриптов, разработанных системными администраторами. Работа скриптов протоколируется в файлы журналов (logs).
Криптографические ключи электронной подписи будут размещаться на токене с неизвлекаемым ключом JaCarta ГОСТ, который пользователь будет подключать к своему локальному компьютеру.
Токен будет пробрасываться на виртуальную машину с помощью специализированных программных средств USB-over-IP, установленных на АРМе пользователя и на виртуальной машине.
Системные часы на АРМе пользователя в организации 1 будут корректироваться в ручном режиме. Системные часы специализированной виртуальной машины в организации 2 будут синхронизироваться с системными часами гипервизора, а те, в свою очередь, будут синхронизироваться через Интернет с публичными серверами времени.
Выделение структурных элементов СКЗИ
На основании вышеприведенного описания IT-инфраструктуры выделим структурные элементы СКЗИ и запишем их в таблицу.
Таблица — Соответствие элементов модели СКЗИ элементам информационных систем
Наименование элемента | Организация 1 | Организация 2 |
Прикладное ПО | ПО КриптоАРМ | ПО КриптоАРМ |
Программная часть криптоядра | СКЗИ КриптоПРО CSP | СКЗИ КриптоПРО CSP |
Аппаратная часть криптоядра | отсутствует | JaCarta ГОСТ |
API | MS CryptoAPI | MS CryptoAPI |
Хранилище открытых ключей | АРМ пользователя: — жесткий диск; — стандартное хранилище сертификатов Windows. |
Гипервизор: — жесткий диск. Виртуальная машина: |
Хранилище закрытых ключей | Ключевой носитель ruToken, работающий в режиме извлекаемого ключа | Ключевой носитель JaCarta ГОСТ, работающий в режиме неизвлекаемого ключа |
Канал обмена открытыми ключами | АРМ пользователя: — оперативная память. |
Гипервизор: — оперативная память. Виртуальная машина: |
Канал обмена закрытыми ключами | АРМ пользователя: — USB шина; — оперативная память. |
отсутствует |
Канал обмена между криптоядрами | отсутствует (нет аппаратной части криптоядра) | АРМ пользователя: — USB шина; — оперативная память; — программный модуль USB-over-IP; — сетевой интерфейс. Корпоративная сеть организации 2. Гипервизор: Виртуальная машина: |
Канал обмена открытыми данными | АРМ пользователя: — средства ввода-вывода; — оперативная память; — жесткий диск. |
АРМ пользователя: — средства ввода-вывода; — оперативная память; — жесткий диск; — сетевой интерфейс. Корпоративная сеть организации 2. Гипервизор: Виртуальная машина: |
Канал обмена защищенными данными | Интернет.
Корпоративная сеть организации 1. АРМ пользователя: |
Интернет.
Корпоративная сеть организации 2. Гипервизор: Виртуальная машина: |
Канал передачи времени | АРМ пользователя: — средства ввода-вывода; — оперативная память; — системный таймер. |
Интернет. Корпоративная сеть организации 2, Гипервизор: Виртуальная машина: |
Канал передачи управляющих команд | АРМ пользователя: — средства ввода-вывода; — оперативная память. (Графический пользовательский интерфейс ПО КриптоАРМ) |
Виртуальная машина: — оперативная память; — жесткий диск. (Скрипты автоматизации) |
Канал приема результатов работы | АРМ пользователя: — средства ввода-вывода; — оперативная память. (Графический пользовательский интерфейс ПО КриптоАРМ) |
Виртуальная машина: — оперативная память; — жесткий диск. (Файлы журналов работы скриптов автоматизации) |
Пояснения
Допущения, принятые при декомпозиции угроз:
Декомпозиция
У1. Компрометация закрытых криптографических ключей.
У2. Зашифрование подложных данных от имени легитимного отправителя.
У3. Расшифрование зашифрованных данных лицами, не являющимися легитимными получателями данных (злоумышленниками).
У4. Создание электронной подписи легитимного подписанта под подложными данными.
У5. Получение положительного результата проверки электронной подписи подложных данных.
У6. Ошибочное принятие электронных документов к исполнению вследствие проблем в организации электронного документооборота.
У7. Несанкционированное ознакомление с защищаемыми данными во время их обработки СКЗИ.
У1.1. Получение закрытого ключа из хранилища закрытых ключей.
У1.2. Получение закрытого ключа из объектов среды функционирования криптосредства, в которых он может временно находиться.
Пояснения У1.2.
К объектам, в которых может временно храниться закрытый ключ, будут относиться:
У1.2.1. Извлечение закрытых ключей из работающей оперативной памяти за счет заморозки модулей ОЗУ, их извлечения и последующее считывание данных (freeze attack).
Пояснения У1.2.1.
Пример атаки [39].
У1.3. Получение закрытого ключа из канала обмена закрытыми ключами.
Пояснения У1.3.
Пример реализации данной угрозы будет приведен ниже [40].
У1.4. Несанкционированная модификация криптоядра, в результате которой закрытые ключи становятся известны злоумышленникам.
У1.5. Компрометация закрытого ключа в результате использования технических каналов утечки информации (ТКУИ).
Пояснения У1.5.
Пример атаки [41].
У1.6. Компрометация закрытого ключа в результате использования специальных технических средств (СТС), предназначенных для негласного съема информации («жучков»).
У1.7. Компрометация закрытых ключей в процессе их хранения вне СКЗИ.
Пояснения У1.7.
Например, пользователь хранит свои ключевые носители в ящике рабочего стола, из которого те легко могут быть извлечены злоумышленникам.
Пояснения
Данная угроза рассматривается только для схем шифрования данных с аутентификацией отправителя. Примеры подобных схем указаны в рекомендациях по стандартизации Р 1323565.1.004-2017 «Информационная технология. Криптографическая защита информации. Схемы выработки общего ключа с аутентификацией на основе открытого ключа» [42]. Для остальных криптографических схем данной угрозы не существует, поскольку шифрование производится на открытых ключах получателя, а они в общем случае известны злоумышленникам.
Декомпозиция
У2.1. Компрометация закрытого ключа отправителя:
У2.1.1. Ссылка: «Типовая модель угроз. Система криптографической защиты информации.У1. Компрометация закрытых криптографических ключей» [43].
У2.2. Подмена входных данных в канале обмена открытыми данными.
Примечания У2.2.
Примеры реализации данной угрозы приведены ниже тут [44] и тут [45].
Декомпозиция
У3.1. Компрометация закрытых ключей получателя зашифрованных данных.
У3.1.1 Ссылка: «Типовая модель угроз. Система криптографической защиты информации. У1. Компрометация закрытых криптографических ключей» [43].
У3.2. Подмена зашифрованных данных в канале обмена защищенными данными.
Декомпозиция
У4.1. Компрометация закрытых ключей электронной подписи легитимного подписанта.
У4.1.1 Ссылка: «Типовая модель угроз. Система криптографической защиты информации. У1. Компрометация закрытых криптографических ключей» [43].
У4.2. Подмена подписываемых данных в канале обмена открытыми данными.
Примечание У4.2.
Примеры реализации данной угрозы приведены ниже тут [44] и тут [45].
Декомпозиция
У5.1. Злоумышленники перехватывают в канале передачи результатов работы сообщение об отрицательном результате проверки электронной подписи и подменяют его на сообщение c положительным результатом.
У5.2. Злоумышленники осуществляют атаку на доверие к сертификатам подписи (СЦЕНАРИЙ — все элементы обязательны):
У5.2.1. Злоумышленники генерируют открытый и закрытый ключ электронной подписи. Если в системе применяются сертификаты ключей электронной подписи, то они генерируют сертификат электронной подписи максимально похожий на сертификат предполагаемого отправителя данных, чье сообщение они хотят подделать.
У5.2.2. Злоумышленники вносят несанкционированные изменения в хранилище открытых ключей, наделяя сгенерированный ими открытый ключ необходимым уровнем доверия и полномочиями.
У5.2.3. Злоумышленники подписывают подложные данные ранее сформированным ключом электронной подписи и внедряют их в канал обмена защищенными данными.
У5.3. Злоумышленники осуществляют атаку с помощью просроченных ключей электронной подписи легального подписанта (СЦЕНАРИЙ — все элементы обязательны):
У5.3.1. Злоумышленники компрометируют истекшие (не действующие на данный момент) закрытые ключи электронной подписи легитимного отправителя.
У5.3.2. Злоумышленники подменяют время в канале передачи времени на время, при котором скомпрометированные ключи еще действовали.
У5.3.3. Злоумышленники подписывают подложные данные ранее скомпрометированным ключом электронной подписи и внедряют их в канал обмена защищенными данными.
У5.4. Злоумышленники осуществляют атаку с помощью скомпрометированных ключей электронной подписи легального подписанта (СЦЕНАРИЙ — все элементы обязательны):
У5.4.1. Злоумышленники делает копию хранилища открытых ключей.
У5.4.2. Злоумышленники компрометируют закрытые ключи одного из легальных отправителей. Тот замечает компрометацию, отзывает ключи, сведения об отзыве ключа помещаются в хранилище открытых ключей.
У5.4.3. Злоумышленники заменяют хранилище открытых ключей на ранее скопированное.
У5.4.4. Злоумышленники подписывают подложные данные ранее скомпрометированным ключом электронной подписи и внедряют их в канал обмена защищенными данными.
У5.5. <...> за счет наличия ошибок в реализации 2-го и 3-го этапа проверки электронной подписи:
Пояснения У5.5.
Пример реализации данной угрозы приведен ниже [46].
У5.5.1. Проверка доверия к сертификату ключа электронной подписи только по наличию доверия к сертификату, с помощью которого он подписан, без проверок CRL или OCSP.
Пояснения У5.5.1.
Пример реализации угрозы [47].
У5.5.2. При построении цепочки доверия к сертификату не анализируются полномочия выпускающих сертификатов
Пояснения У5.5.2.
Пример атаки в отношении SSL/TLS сертификатов.
Злоумышленники купили легитимный сертификат для своего e-mail. Затем они сделали мошеннический сертификат сайта и подписали его своим сертификатом. Если проверка полномочий проводиться не будет, то при проверке цепочки доверия она окажется корректной, и, соответственно, мошеннический сертификат тоже будет корректным.
У5.5.3. При построении цепочки доверия к сертификату не проверяются промежуточные сертификаты на отзыв.
У5.5.4. Обновление CRL происходит реже, чем их выпускает удостоверяющий центр.
У5.5.5. Решение о доверии к электронной подписи принимается раньше, чем получен OCSP-ответ о статусе сертификата, направленный по запросу, сделанному позже времени формирования подписи или раньше, чем получен следующий после формирования подписи CRL.
Пояснения У5.5.5.
В регламентах большинства УЦ временем отзыва сертификата считается время выпуска ближайшего CRL, содержащего информацию об отзыве сертификата.
У5.5.6. При получении подписанных данных не проверяется принадлежность сертификата отправителю.
Пояснения У5.5.6.
Пример атаки. Применительно к SSL-сертификатам: может не проверяться соответствие адреса вызываемого сервера значению поля CN в сертификате.
Пример атаки. Злоумышленники скомпрометировали ключи электронной подписи одного из участников платежной системы. После этого они взломали сеть другого участника и от его имени направили на расчетный сервер платежной системы платежные документы, подписанные скомпрометированными ключами. Если сервер анализирует только доверие и не проверяет соответствие, то мошеннические документы будут считаться легитимными.
Декомпозиция
У6.1. Принимающая сторона не обнаруживает дублирование получаемых документов.
Пояснения У6.1.
Пример атаки. Злоумышленники могут перехватить передаваемый получателю документ, пусть даже криптографически защищенный, а затем многократно отправить его в канал передачи защищенных данных. Если получатель не выявляет дубли, то все получаемые документы будут восприниматься и отрабатываться как различные документы.
Декомпозиция
У7.1. <...> вследствие утечки информации по сторонним каналам (side channel attack).
Пояснения У7.1.
Пример атаки [48].
У7.2. <...> вследствие нейтрализации защиты от несанкционированного доступа к информации, обрабатываемой на СКЗИ:
У7.2.1. Эксплуатация СКЗИ с нарушениями требований, описанных в документации на СКЗИ.
У7.2.2. <...>, осуществленной в за счет наличия уязвимостей в:
У7.2.2.1. <...> средствах защиты от несанкционированного доступа.
У7.2.2.2. <...> самой СКЗИ.
У7.2.2.3. <...> среде функционирования криптосредства.
Рассмотренные ниже сценарии заведомо содержат ошибки организации информационной безопасности и служат только для иллюстрации возможных атак.
Описание объекта
ПО АРМ КБР и СКЗИ СКАД Сигнатура установлены на физическом компьютере, не подключенном к вычислительной сети. В качестве ключевого носителя используется ФКН vdToken в режиме работы с неизвлекаемым ключом.
Регламент осуществления расчетов предполагает, что специалист по расчетам со своего рабочего компьютера скачивает электронные сообщения в открытом виде (схема старого АРМ КБР) со специального защищенного файлового сервера, затем записывает их на отчуждаемый носитель USB-флешку и переносит на АРМ КБР, где их шифрует и подписывает. После этого специалист переносит на отчуждаемый носитель защищенные электронные сообщения, а потом через свой рабочий компьютер записывает их на файловый сервер, откуда они попадают на УТА и далее в платежную систему Банка России.
В данном случае каналы обмена открытыми и защищенными данными будут включать в себя: файловый сервер, рабочий компьютер специалиста и отчуждаемый носитель.
Атака
Злоумышленники несанкционированного устанавливают на рабочий компьютер специалиста систему удаленного управления и в момент записи на отчуждаемый носитель платежных поручений (электронных сообщений) в открытом виде подменяют содержимое одного из них. Специалист переносит платежные поручения на АРМ КБР, подписывает и шифрует их, не замечая подмены (например, из-за большого количества платежных поручений в рейсе, усталости и т.д. ). После этого поддельное платежное поручение, пройдя через технологическую цепочку, попадает в платежную систему Банка России.
Описание объекта
Компьютер с установленными АРМ КБР, СКАД Сигнатура и подключенным ключевым носителем ФКН vdToken функционирует в выделенном помещении без доступа со стороны персонала.
Специалист по расчетам подключается к АРМ КБР в режиме удаленного доступа по протоколу RDP.
Атака
Злоумышленники перехватывают реквизиты, используя которые специалист по расчетам осуществляет подключение и работу с АРМ КБР (например, за счет вредоносного кода на его компьютере). Затем проводят подключение от его имени и отправляют в платежную систему Банка России поддельное платежное поручение.
Описание объекта
Рассмотрим один из гипотетических вариантов реализации модулей интеграции «АБС-КБР» для новой схемы (АРМ КБР-Н), при которой электронная подпись исходящих документов происходит на стороне АБС. При этом будем считать, что АБС функционирует на базе операционной системы, не поддерживаемой СКЗИ СКАД Сигнатура, и, соответственно, криптографический функционал вынесен на отдельную виртуальную машину — модуль интеграции «АБС-КБР».
В качестве ключевого носителя используется обычный USB-токен, работающий в режиме извлекаемого ключа. При подключении ключевого носителя к гипервизору оказалось, что в системе нет свободных USB-портов, поэтому было решено подключить USB-токен через сетевой USB-концентратор, а на виртуальную машину установить клиент USB-over-IP, который будет осуществлять связь с концентратором.
Атака
Злоумышленники перехватили закрытый ключ электронной подписи из канала связи между USB-концентратором и гипервизором (данные передавались в открытом виде). Имея закрытый ключ, злоумышленники сформировали поддельное платежное поручение, подписали его электронной подписью и отправили в АРМ КБР-Н на исполнение.
Описание объекта
Рассмотрим ту же схему, что и в предыдущем сценарии. Будем считать, что электронные сообщения, поступающие из АРМ КБР-Н, попадают в папку \...SHAREIn, а те, что отправляются в АРМ КБР-Н и дальше в платежную систему Банка России, — в \...SHAREout.
Также будем считать, что при реализации модуля интеграции списки отозванных сертификатов обновляются только при перевыпуске криптографических ключей, а также то, что электронные сообщения, поступившие в папку \...SHAREIn проверяются только на предмет контроля целостности и контроля доверия к открытому ключу электронной подписи.
Атака
Злоумышленники, воспользовавшись похищенными в предыдущем сценарии ключами, подписали поддельное платежное поручение, содержащее сведения о поступлении денег на счет клиенту-мошеннику и внедрили его в канал обмена защищенными данными. Поскольку проверки того, что платежное поручение подписано именно Банком России не проводится, он принимается к исполнению.
Автор: imbasoft
Источник [49]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/bezopasnost/292057
Ссылки в тексте:
[1] О чем исследование: https://habr.com/post/422329/#ABOUT
[2] Информационная безопасность банковских безналичных платежей. Часть 1 — Экономические основы.: https://habr.com/post/344740/
[3] Информационная безопасность банковских безналичных платежей. Часть 2 — Типовая IT-инфраструктура банка.: https://habr.com/post/345194/
[4] Информационная безопасность банковских безналичных платежей. Часть 3 — Формирование требований к системе защиты.: https://habr.com/post/350852/
[5] Информационная безопасность банковских безналичных платежей. Часть 4 — Обзор стандартов моделирования угроз.: https://habr.com/post/351326/
[6] Информационная безопасность банковских безналичных платежей. Часть 5 — 100+ тематических ссылок про взломы банков.: https://habr.com/post/413703/
[7] Информационная безопасность банковских безналичных платежей. Часть 6 — Анализ банковских преступлений.: https://habr.com/post/419027/
[8] Информационная безопасность банковских безналичных платежей. Часть 7 — Базовая модель угроз.: https://habr.com/post/421161/
[9] Информационная безопасность банковских безналичных платежей. Часть 8 — Типовые модели угроз : https://habr.com/post/422329/
[10] Типовая модель угроз. Сетевое соединение: https://habr.com/post/422329/#TMUNC
[11] Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер: https://habr.com/post/422329/#TMUIS
[12] Типовая модель угроз. Система разграничения доступа: https://habr.com/post/422329/#TMUSRD
[13] Типовая модель угроз. Модуль интеграции: https://habr.com/post/422329/#TMUMI
[14] Типовая модель угроз. Система криптографической защиты информации.: https://habr.com/post/422329/#TMUSKZI
[15] «Типовая модель угроз. Сетевое соединение. У2. Несанкционированная модификация передаваемых данных»: https://habr.com/post/422329/#TMUNCU2
[16] VLAN hopping: https://en.wikipedia.org/wiki/VLAN_hopping
[17] Rogue DHCP: https://en.wikipedia.org/wiki/Rogue_DHCP
[18] Rogue WPAD: https://www.securitylab.ru/analytics/379619.php
[19] ARP spoofing: https://ru.wikipedia.org/wiki/ARP-spoofing
[20] DNS spoofing: https://ru.wikipedia.org/wiki/DNS_spoofing
[21] SIM swap: https://www.hdfcbank.com/security/beware_of_frauds/sim_swap_fraud
[22] IP spoofing: https://en.wikipedia.org/wiki/IP_address_spoofing
[23] MAC spoofing: http://xgu.ru/wiki/MAC-spoofing
[24] «Типовая модель угроз. Система разграничения доступа. У1. Несанкционированное установление сеанса работы от имени легального пользователя»: https://habr.com/post/422329/#TMUSRDU1
[25] «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер. У1. Совершение злоумышленниками несанкционированных действий от имени легитимного пользователя»: https://habr.com/post/422329/#TMUISU1
[26] «Типовая модель угроз. Сетевое соединение. У1. Несанкционированное ознакомление с передаваемыми данными»: https://habr.com/post/422329/#TMUNCU1
[27] StuffCop: https://www.staffcop.ru
[28] тут: https://www.youtube.com/watch?v=tMSglPLIDYU
[29] тут: https://www.cl.cam.ac.uk/~mgk25/pet2004-fpd.pdf
[30] устройств: http://mega-spy.ru/category/apparatnye-kejloggery
[31] атаки: https://threatpost.com/keystroke-recognition-uses-wi-fi-signals-to-snoop/120135/
[32] атаки: https://habr.com/post/398545/
[33] атаки: https://habr.com/post/126806/
[34] выделенный сервер: https://www.reg.ru/?rlink=reflink-717
[35] «Типовая модель угроз. Сетевое соединение. У3. Нарушение авторства передаваемых данных»: https://habr.com/post/422329/#TMUNCU3
[36] «Типовая модель угроз. Информационная система, построенная на базе архитектуры клиент-сервер. У2. Несанкционированная модификации защищаемой информации во время ее обработки серверной частью информационной системы»: https://habr.com/post/422329/#TMUISU2
[37] пример: https://www.unboundtech.com/product/unbound-key-control/
[38] ECB: http://cryptowiki.net/index.php?title=Electronic_Code_Book
[39] атаки: https://www.securitylab.ru/analytics/452899.php
[40] ниже: https://habr.com/post/422329/#TMUSKZIA3
[41] атаки: https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-alam.pdf
[42] Р 1323565.1.004-2017 «Информационная технология. Криптографическая защита информации. Схемы выработки общего ключа с аутентификацией на основе открытого ключа»: https://tc26.ru/standarts/rekomendatsii-po-standartizatsii/r-1323565-1-004-2017-informatsionnaya-tekhnologiya-kriptograficheskaya-zashchita-informatsii-skhemy-vyrabotki-obshchego-klyucha-s-autentifikatsiey-na-osnove-otkrytogo-klyucha.html
[43] «Типовая модель угроз. Система криптографической защиты информации.У1. Компрометация закрытых криптографических ключей»: https://habr.com/post/422329/#TMUSKZIU1
[44] тут: https://habr.com/post/422329/#TMUSKZIA1
[45] тут: https://habr.com/post/422329/#TMUSKZIA2
[46] ниже: https://habr.com/post/422329/#TMUSKZIA4
[47] угрозы: https://habr.com/post/332730/
[48] атаки: https://www.cs.tau.ac.il/~tromer/synesthesia/synesthesia.pdf
[49] Источник: https://habr.com/post/422329/?utm_campaign=422329
Нажмите здесь для печати.