Посилання на інші частини дослідження
- (Ви тут)
Ця стаття завершує цикл публікацій, присвячених забезпеченню інформаційної безпеки банківських безготівкових платежів. Тут ми розглянемо типові моделі загроз, на які посилалися в :
- .
- .
- .
- .
ХАБРО-WARNING !!! Шановні хабрівчани, це не розважальний пост.
Заховані під катом 40+ сторінок матеріалів покликані допомогти у роботі чи навчанні людям, що спеціалізуються на банківській справі чи забезпеченні інформаційної безпеки. Дані матеріали є кінцевим продуктом дослідження та написані у сухому офіційному тоні. По суті це заготівлі для внутрішніх документів ІБ.Ну і традиційне - «застосування відомостей із статті з протиправною метою переслідується згідно із законом». Продуктивне читання!
Інформація для читачів, які знайомляться із дослідженням, починаючи з цієї публікації.
Про що дослідження
Ви читаєте гайд для спеціаліста, відповідального за забезпечення інформаційної безпеки платежів у банку.
Логіка викладу
На початку в и дається опис об'єкта захисту. Потім у розповідається, як побудувати систему захисту, та йдеться про необхідність формування моделі загроз. У розповідається про те, які моделі погроз бувають і як їх формують. У и наводиться аналіз реальних атак. и містять опис моделі загроз, побудованої з урахуванням відомостей із усіх попередніх частин.
ТИПОВА МОДЕЛЬ ЗАГРОЗ. МЕРЕЖЕВЕ З'ЄДНАННЯ
Об'єкт захисту, до якого застосовується модель загроз (scope)
Об'єктом захисту є дані, що передаються через мережеве з'єднання, що функціонує в мережах передачі даних, побудованих на базі стека TCP/IP.
Архітектура
Опис елементів архітектури:
- «Кінцеві вузли» — вузли, що обмінюються інформацією, що захищається.
- "Проміжні вузли" - Елементи мережі передачі даних: маршрутизатори, комутатори, сервери доступу, proxy-сервера та інше обладнання, - через які передається трафік мережного з'єднання. Загалом мережне з'єднання може функціонувати без проміжних вузлів (прямо між кінцевими вузлами).
Загрози безпеки верхнього рівня
Декомпозиція
У1. Несанкціоноване ознайомлення з даними, що передаються.
У2. Несанкціонована модифікація даних, що передаються.
У3. Порушення авторства даних, що передаються.
У1. Несанкціоноване ознайомлення з даними, що передаються
Декомпозиція
У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. Посилання: .
У1.3. <…>, що здійснюється за рахунок витоку інформації з технічних каналів (ТКУІ) з фізичних вузлів або ліній зв'язку.
У1.4. <…>, що здійснюється за установки на кінцеві або проміжні вузли спеціальних технічних засобів (СТС), призначених для негласного знімання інформації.
У2. Несанкціонована модифікація переданих даних
Декомпозиція
У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. .
У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. .
У2.2.1.2.3.2. .
У2.2.1.2.4. <…> адресації та дозволу імен:
У2.2.1.2.4.1. .
У2.2.1.2.4.2. .
У2.2.1.2.4.3. Внесення несанкціонованих змін у локальні файли імен вузлів (hosts, lmhosts та ін.)
У3. Порушення авторства даних, що передаються
Декомпозиція
У3.1. Нейтралізації механізмів визначення авторства інформації шляхом вказівки підроблених відомостей про автора або джерела даних:
У3.1.1. Зміна відомостей про автора, що містяться в інформації, що передається.
У3.1.1.1. Нейтралізація криптографічного захисту цілісності та авторства переданих даних:
У3.1.1.1.1. Посилання: .
У3.1.1.2. Нейтралізація захисту авторства даних, що передаються, реалізованої за допомогою одноразових кодів підтверджень:
У3.1.1.2.1. .
У3.1.2. Зміна відомостей про джерело інформації, що передається:
У3.1.2.1. .
У3.1.2.2. .
ТИПОВА МОДЕЛЬ ЗАГРОЗ. ІНФОРМАЦІЙНА СИСТЕМА, ПОБУДОВАНА НА БАЗІ АРХІТЕКТУРИ КЛІЄНТ-СЕРВЕР
Об'єкт захисту, до якого застосовується модель загроз (scope)
Об'єктом захисту є інформаційна система, побудована з урахуванням архітектури клієнт-сервер.
Архітектура
Опис елементів архітектури:
- «Клієнт» – пристрій, у якому функціонує клієнтська частина інформаційної системи.
- "Сервер" – пристрій, у якому функціонує серверна частина інформаційної системи.
- "Сховище даних" - Частина серверної інфраструктури інформаційної системи, призначена для зберігання даних, оброблюваних інформаційною системою.
- «Мережне з'єднання» — канал обміну інформацією між Клієнтом та Сервером, який проходить через мережу передачі. Більш детальний опис моделі елемента наведено в .
Обмеження
При моделюванні об'єкта встановлено такі обмеження:
- Користувач взаємодіє з інформаційною системою в рамках кінцевих проміжків часу, які називаються сеансами роботи.
- На початку кожного сеансу роботи відбувається ідентифікація, автентифікація та авторизація користувача.
- Вся інформація, що захищається зберігається на серверній частині інформаційної системи.
Загрози безпеки верхнього рівня
Декомпозиція
У1. Вчинення зловмисниками несанкціонованих дій від імені легітимного користувача.
У2. Несанкціонована модифікація інформації, що захищається під час її обробки серверною частиною інформаційної системи.
У1. Вчинення зловмисниками несанкціонованих дій від імені легітимного користувача
Пояснення
Зазвичай в інформаційних системах співвіднесення дій з користувачем, що їх виконав, проводиться за допомогою:
- журналів роботи системи (logs).
- спеціальних атрибутів об'єктів даних, що містять відомості про користувача, що створив або змінив їх.
Стосовно сеансу роботи ця загроза може декомпозуватися на:
- <…> виконані у рамках сеансу роботи користувача.
- <…> виконані поза сеансом роботи користувача.
Сеанс роботи користувача може бути ініційований:
- Самим користувачем.
- Зловмисниками.
На даному етапі проміжна декомпозиція цієї загрози виглядатиме так:
У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. Посилання: .
У1.1.1.3. Зловмисники змусили користувача до виконання вказаних ними дій, використовуючи методи соціальної інженерії.
У1.1.2 <…> встановленого зловмисниками:
У1.1.2.1. Зловмисники діяли з Клієнта (И):
У1.1.2.1.1. Зловмисники нейтралізували систему розмежування доступу інформаційної системи:
У1.1.2.1.1.1. Посилання: .
У1.1.2.1.2. Зловмисники використовували штатні засоби доступу до інформаційної системи
У1.1.2.2. Зловмисники діяли з інших вузлів мережі передачі даних, з яких можна встановити з'єднання з Сервером (И):
У1.1.2.2.1. Зловмисники нейтралізували систему розмежування доступу інформаційної системи:
У1.1.2.2.1.1. Посилання: .
У1.1.2.2.2. Зловмисники використали нештатні засоби доступу до інформаційної системи.
Пояснення У1.1.2.2.2.
Зловмисники могли встановити штатний клієнт інформаційної системи на сторонній вузол або використовувати позаштатне ПЗ, що реалізує штатні протоколи обміну між Клієнтом і Сервером.
У1.2 Несанкціоновані дії виконані поза сеансом роботи користувача.
У1.2.1 Зловмисники виконали несанкціоновані дії, а потім внесли несанкціоновані зміни до журналів роботи інформаційної системи або спеціальних атрибутів об'єктів даних, вказавши, що вчинені ними дії виконані легітимним користувачем.
У2. Несанкціонована модифікація інформації, що захищається під час її обробки серверною частиною інформаційної системи
Декомпозиція
У2.1. Зловмисники модифікують інформацію, що захищається, за допомогою штатних засобів інформаційної системи і проводять це від імені легітимного користувача.
У2.1.1. Посилання: .
У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. Посилання: .
У2.2.2.2. Зловмисники модифікують інформацію, використовуючи штатні інтерфейси СУБД для доступу до даних.
У2.3. Зловмисники модифікують інформацію, що захищається шляхом несанкціонованої модифікації алгоритмів роботи обробляє її ПЗ.
У2.3.1. Модифікації піддається вихідний код.
У2.3.1. Модифікації піддається машинний код.
У2.4. Зловмисники модифікують інформацію, що захищається шляхом використання вразливостей у програмному забезпеченні інформаційної системи.
У2.5. Зловмисники модифікують інформацію, що захищається при її передачі між компонентами серверної частини інформаційної системи (наприклад, сервером баз даних і сервером додатків):
У2.5.1. Посилання: .
ТИПОВА МОДЕЛЬ ЗАГРОЗ. СИСТЕМА РОЗМЕЖЕННЯ ДОСТУПУ
Об'єкт захисту, до якого застосовується модель загроз (scope)
Об'єкт захисту, для якого застосовується ця модель загроз, відповідає об'єкту захисту моделі загроз: «Типова модель загроз. Інформаційна система, побудована з урахуванням архітектури клієнт-сервер».
Під системою розмежування доступу користувачів цієї моделі загроз мається на увазі компонент інформаційної системи, реалізує функції:
- Ідентифікація користувачів.
- Аутентифікація користувачів.
- Авторизації користувачів.
- Протоколування дій користувачів.
Загрози безпеки верхнього рівня
Декомпозиція
У1. Несанкціоноване встановлення сеансу роботи від імені легального користувача.
У2. Несанкціоноване підвищення привілеїв користувача в інформаційній системі.
У1. Несанкціоноване встановлення сеансу роботи від імені легального користувача
Пояснення
Декомпозиція цієї загрози у випадку буде залежати від застосовуваного типу систем ідентифікації та автентифікації користувачів.
У даній моделі буде розглянута лише система ідентифікації та аутентифікації користувачів, яка використовує текстові логін та пароль. При цьому вважатимемо, що логін користувача є загальнодоступною інформацією, відомою зловмисникам.
Декомпозиція
У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.1.6. Зловмисники витягли облікові дані із записів систем моніторингу роботи:
У1.1.6.1. <…> систем відеоспостереження (якщо під час роботи фіксувалися натискання клавіш на клавіатурі).
У1.1.6.2. <…> систем контролю дій співробітників за комп'ютером
Пояснення У1.1.6.2.
Приклад подібної системи .
У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.
Приклади атаки и .
У1.1.9.4. Зловмисник здійснив перехоплення введення облікових даних з клавіатури за рахунок використання спеціальних технічних засобів (СТС), призначених для негласного знімання інформації.
Пояснення У1.1.9.4.
Приклади .
У1.1.9.5. Зловмисники здійснили перехоплення введення облікових даних із клавіатури за рахунок
аналізу Wi-Fi сигналу, модульованого процесом натискання клавіш користувачем.
Пояснення У1.1.9.5.
Приклад .
У1.1.9.6. Зловмисники перехопили введення облікових даних з клавіатури за рахунок аналізу звуків натискання на клавіші.
Пояснення У1.1.9.6.
Приклад .
У1.1.9.7. Зловмисники здійснили перехоплення введення облікових даних із клавіатури мобільного пристрою за рахунок аналізу показань акселерометра.
Пояснення У1.1.9.7.
Приклад .
У1.1.10. <…>, попередньо збережених на Клієнті.
Пояснення У1.1.10.
Наприклад, користувач міг зберегти в браузері логін та пароль для доступу до певного сайту.
У1.1.11. Зловмисники скомпрометували облікові дані через недоліки процесу відкликання доступів користувачів.
Пояснення У1.1.11.
Наприклад, після звільнення користувача його облікові записи залишилися незаблокованими.
У1.2. <…> за рахунок використання вразливостей у системі розмежування доступу.
У2. Несанкціоноване підвищення привілеїв користувача в інформаційній системі
Декомпозиція
У2.1 <…> шляхом внесення несанкціонованих змін до даних, що містять відомості про привілеї користувача.
У2.2 <…> за рахунок використання вразливостей у системі розмежування доступу.
У2.3. <…> через недоліки процесу управління доступом користувачів.
Пояснення У2.3.
Приклад 1. Користувачеві для роботи було надано доступ більший, ніж йому потрібна була службова необхідність.
Приклад 2. Після переведення користувача на іншу посаду раніше надані права доступу не були відкликані.
ТИПОВА МОДЕЛЬ ЗАГРОЗ. МОДУЛЬ ІНТЕГРАЦІЇ
Об'єкт захисту, до якого застосовується модель загроз (scope)
Модуль інтеграції – набір об'єктів інформаційної інфраструктури, призначений організації обміну інформацією між інформаційними системами.
Враховуючи той факт, що в корпоративних мережах не завжди можливо однозначно відокремити одну інформаційну систему від іншої, модуль інтеграції можна розглядати як зв'язуючу ланку між компонентами всередині однієї інформаційної системи.
Архітектура
Узагальнена схема модуля інтеграції виглядає так:
Опис елементів архітектури:
- "Сервер обміну (СО)" - Вузол / сервіс / компонент інформаційної системи, що виконує функцію обміну даними з іншою інформаційною системою.
- «Посередник» - Вузол / сервіс, призначений для організації взаємодії між інформаційними системами, але не входить до їх складу.
прикладами «Посередників» можуть бути сервіси електронної пошти, сервісні шини підприємства (enterprise service bus/SoA-архітектура), сторонні файлові сервери тощо. У випадку модуль інтеграції може й містити «Посередників». - «З обробки даних» - Сукупність програм, що реалізує протоколи обміну даними та перетворення форматів.
Наприклад, перетворення даних із формату УФЕБС у формат АБС, зміна статусів повідомлень у процесі передачі тощо. - «Мережне з'єднання» відповідає об'єкту, описаному в типовій моделі загроз «Мережне з'єднання». Деяких мережевих з'єднань з тих, що представлені на схемі вище, може не бути.
Приклади модулів інтеграції
Схема 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.1 Посилання: .
У1.2. Передача каналами зв'язку підроблених даних від імені легітимного учасника обміну:
У1.1.2 Посилання: .
У1.3. Несанкціонована модифікація легітимних даних під час їх обробки на серверах обміну або посереднику:
У1.3.1. Посилання: .
У1.4. Створення на серверах обміну або посередника підроблених даних від імені легітимного учасника обміну:
У1.4.1. Посилання:
У1.5. Несанкціонована модифікація даних при їх обробці за допомогою ПЗ обробки даних:
У1.5.1. <…> за рахунок внесення зловмисниками несанкціонованих змін у налаштування (конфігурацію) ПЗ обробки даних.
У1.5.2. <…> за рахунок внесення зловмисниками несанкціонованих змін до виконуваних файлів ПЗ обробки даних.
У1.5.3. <…> за рахунок інтерактивного управління зловмисниками роботою ПЗ обробки даних.
ТИПОВА МОДЕЛЬ ЗАГРОЗ. СИСТЕМА КРИПТОГРАФІЧНОГО ЗАХИСТУ ІНФОРМАЦІЇ
Об'єкт захисту, до якого застосовується модель загроз (scope)
Об'єктом захисту є система криптографічного захисту інформації, що використовується для забезпечення безпеки інформаційної системи.
Архітектура
Основою будь-якої інформаційної системи є прикладне програмне забезпечення, що реалізує її цільовий функціонал.
Криптографічний захист при цьому зазвичай реалізується шляхом виклику з бізнес-логіки прикладного програмного забезпечення криптографічних примітивів, які розміщуються в спеціалізованих бібліотеках – криптоядрах.
До криптографічних примітивів належать низькорівневі криптографічні функції, такі як:
- зашифрувати/розшифрувати блок даних;
- створити/перевірити електронний підпис блоку даних;
- обчислити хеш-функцію блоку даних;
- сформувати/завантажити/вивантажити ключову інформацію;
- тощо.
Бізнес-логіка прикладного програмного забезпечення за допомогою криптографічних примітивів реалізує більш високорівневий функціонал:
- зашифрувати файл на ключі вибраних одержувачів;
- встановити захищене мережне з'єднання;
- інформувати про результати перевірки електронного підпису;
- і т.п.
Взаємодія бізнес-логіки та криптоядра може здійснюватися:
- безпосередньо шляхом виклику бізнес-логікою криптографічних примітивів з динамічних бібліотек криптоядра (.DLL – для Windows, .SO – для Linux);
- опосередковано, через криптографічні інтерфейси – обгортки (wrappers), наприклад, MS Crypto API, Java Cryptography Architecture, PKCS#11 та інших. У разі бізнес-логіка звертається до криптоинтерфейсу, а той транслює виклик до відповідного криптоядру, що у такому разі називається криптопровайдером. Використання криптографічних інтерфейсів дозволяє прикладному програмному забезпечення абстрагуватися від конкретних криптографічних алгоритмів і бути більш гнучким.
Можна виділити дві типові схеми організації криптоядра:
Схема 1 – Монолітне криптоядро
Схема 2 - Розділене криптоядро
Елементи на наведених схемах можуть бути як окремими модулями програмного забезпечення, що працюють на одному комп'ютері, так і мережевими сервісами, що взаємодіють у рамках обчислювальної мережі.
При використанні систем, побудованих за схемою 1, прикладне ПЗ і криптоядро працюють в рамках єдиного середовища функціонування криптосредства (СФК), наприклад, на тому самому комп'ютері, під управлінням однієї і тієї ж операційної системи. Користувач системи, як правило, може запускати в рамках цього ж середовища функціонування та інші програми, у тому числі шкідливий код, що містять. У подібних умовах існує серйозний ризик витоку закритих криптографічних ключів.
Для мінімізації ризику застосовують схему 2, за якої криптоядро поділяється на дві частини:
- Перша частина разом із прикладним ПЗ працює у недовіреному середовищі, де існує ризик зараження шкідливим кодом. Будемо називати цю частину – «програмною частиною».
- Друга частина працює у довіреному середовищі на виділеному пристрої, який містить у своєму складі сховище закритих ключів. Далі називатимемо цю частину – «апаратною частиною».
Поділ криптоядра на програмну та апаратну частини досить умовний. На ринку є системи, побудовані за схемою з розділеним криптоядром, але «апаратна» частина яких представлена у вигляді віртуальної машини — virtual HSM ().
Взаємодія обох частин криптоядра відбувається таким чином, що закриті криптографічні ключі ніколи не передаються в програмну частину і, відповідно, не можуть бути викрадені шкідливим кодом.
Інтерфейс взаємодії (API) та набір криптографічних примітивів, що надаються прикладним ПЗ криптоядром, в обох випадках однаковий. Відмінність у способі реалізації.
Так, при використанні схеми з розділеним криптоядром, взаємодія програмної та апаратної частини виконується за таким принципом:
- Криптографічні примітиви, що не вимагають використання закритого ключа (наприклад, розрахунок хеш-функції, перевірка електронного підпису та ін), виконуються програмною частиною.
- Криптографічні примітиви, що використовують закритий ключ (створення електронного підпису, розшифрування даних та ін.), Виконуються апаратною частиною.
Проілюструємо роботу розділеного криптоядра на прикладі створення електронного підпису:
- Програмна частина розраховує хеш-функцію даних, що підписуються, і по каналу обміну між криптоядрами передає це значення в апаратну частину.
- Апаратна частина, використовуючи закритий ключ і хеш, формує значення електронного підпису і каналом обміну передає їх у програмну частину.
- Програмна частина повертає отримане значення прикладне ПЗ.
Особливості перевірки коректності електронного підпису
Коли сторона, що приймає, отримує дані, підписані електронним підписом, вона повинна провести кілька етапів перевірки. Позитивний результат перевірки електронного підпису досягається лише за успішного проходження всіх етапів перевірки.
Етап 1. Контроль цілісності даних та авторства даних.
Зміст етапу. Проводиться перевірка електронного підпису даних щодо відповідного криптографічного алгоритму. Успішне проходження даного етапу говорить про те, що дані не модифікувалися з моменту їх підписання, а також те, що підпис був зроблений закритим ключем, що відповідає відкритому ключу перевірки електронного підпису.
Місце виконання етапу: кріптоядро.
Етап 2. Контроль довіри до відкритого ключа підписувача та контроль терміну дії закритого ключа електронного підпису.
Зміст етапу. Етап складається із двох проміжних підетапів. На першому встановлюється, чи був відкритий ключ перевірки електронного підпису довіреним під час підписання даних. На другому встановлюється, чи на момент підписання даних діяв закритий ключ електронного підпису. Загалом терміни дії цих ключів можуть не збігатися (наприклад, для кваліфікованих сертифікатів ключів перевірки електронного підпису). Способи встановлення довіри до відкритого ключа підписувача визначаються правилами електронного документообігу, прийнятими сторонами, що взаємодіють.
Місце виконання етапу: прикладне ПЗ/криптоядро.
Етап 3. Контроль повноважень підписувача.
Зміст етапу. Відповідно до встановлених правил електронного документообігу перевіряється, чи мав підписант право завіряти дані, що захищаються. Наприклад наведемо ситуацію порушення повноважень. Припустимо, є організація, де всі працівники мають електронний підпис. До внутрішньої системи електронного документообігу надходить наказ керівника, але підписаний електронним підписом завідувача складу. Відповідно, такий документ не може вважатися легітимним.
Місце виконання етапу: прикладне ПЗ.
Допущення, прийняті під час опису об'єкта захисту
- Канали передачі, крім каналів обміну ключами, зокрема проходять через прикладне ПЗ, API і криптоядро.
- Відомості про довіру до відкритих ключів та (або) сертифікатів, а також інформацію про повноваження власників відкритих ключів розміщуються у сховищі відкритих ключів.
- Прикладне програмне забезпечення працює зі сховищем відкритих ключів через криптоядро.
Приклад інформаційної системи захищеної за допомогою СКЗІ
Для ілюстрації раніше представлених схем розглянемо гіпотетичну інформаційну систему і виділимо у ньому все структурні елементи.
Опис інформаційної системи
Дві організації вирішили запровадити між собою юридично значимий електронний документообіг (ЕДО). Для цього вони уклали угоду, в якій прописали, що документи будуть передаватися електронною поштою, і при цьому вони мають бути зашифровані та підписані кваліфікованим електронним підписом. Як засоби створення та обробки документів повинні використовуватися офісні програми з пакету 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.
Гіпервізор:
- жорсткий диск.
Віртуальна машина:
- жорсткий диск;
— стандартне сховище для сертифікатів Windows.
Сховище закритих ключів
Ключовий носій ruToken, що працює в режимі вилученого ключа
Ключовий носій JaCarta ДЕРЖСТАНДАРТ, що працює в режимі невилученого ключа
Канал обміну відкритими ключами
АРМ користувача:
- оперативна пам'ять.
Гіпервізор:
- оперативна пам'ять.
Віртуальна машина:
- оперативна пам'ять.
Канал обміну закритими ключами
АРМ користувача:
- USB шина;
- оперативна пам'ять.
відсутня
Канал обміну між криптоядрами
відсутня (немає апаратної частини криптоядра)
АРМ користувача:
- USB шина;
- оперативна пам'ять;
- Програмний модуль USB-over-IP;
- Мережевий інтерфейс.
Корпоративна мережа організації 2.
Гіпервізор:
- оперативна пам'ять;
- Мережевий інтерфейс.
Віртуальна машина:
- Мережевий інтерфейс;
- оперативна пам'ять;
- Програмний модуль USB-over-IP.
Канал обміну відкритими даними
АРМ користувача:
- Засоби введення-виведення;
- оперативна пам'ять;
- жорсткий диск.
АРМ користувача:
- Засоби введення-виведення;
- оперативна пам'ять;
- жорсткий диск;
- Мережевий інтерфейс.
Корпоративна мережа організації 2.
Гіпервізор:
- Мережевий інтерфейс;
- оперативна пам'ять;
- жорсткий диск.
Віртуальна машина:
- Мережевий інтерфейс;
- оперативна пам'ять;
- жорсткий диск.
Канал обміну захищеними даними
Інтернет.
Корпоративна мережа організації 1.
АРМ користувача:
- жорсткий диск;
- оперативна пам'ять;
- Мережевий інтерфейс.
Інтернет.
Корпоративна мережа організації 2.
Гіпервізор:
- Мережевий інтерфейс;
- оперативна пам'ять;
- жорсткий диск.
Віртуальна машина:
- Мережевий інтерфейс;
- оперативна пам'ять;
- жорсткий диск.
Канал передачі часу
АРМ користувача:
- Засоби введення-виведення;
- оперативна пам'ять;
- Системний таймер.
Інтернет.
Корпоративна мережа організації 2,
Гіпервізор:
- Мережевий інтерфейс;
- оперативна пам'ять;
- Системний таймер.
Віртуальна машина:
- оперативна пам'ять;
- Системний таймер.
Канал передачі керуючих команд
АРМ користувача:
- Засоби введення-виведення;
- оперативна пам'ять.
(Графічний інтерфейс користувача ПЗ КриптоАРМ)
Віртуальна машина:
- оперативна пам'ять;
- жорсткий диск.
(Скрипти автоматизації)
Канал прийому результатів роботи
АРМ користувача:
- Засоби введення-виведення;
- оперативна пам'ять.
(Графічний інтерфейс користувача ПЗ КриптоАРМ)
Віртуальна машина:
- оперативна пам'ять;
- жорсткий диск.
(Файли журналів роботи скриптів автоматизації)
Загрози безпеки верхнього рівня
Пояснення
Припущення, ухвалені при декомпозиції загроз:
- Використовуються стійкі криптографічні алгоритми.
- Криптографічні алгоритми використовуються безпечним чином у правильних режимах функціонування (наприклад, не застосовується для шифрування великих обсягів даних, враховується допустиме навантаження на ключ тощо).
- Зловмисникам відомі всі застосовувані алгоритми, протоколи та відкриті ключі.
- Зловмисникам доступні для читання всі зашифровані дані.
- Зловмисники можуть відтворити будь-які програмні елементи в системі.
Декомпозиція
У1. Компрометація закритих криптографічних ключів
У2. Зашифрування фальшивих даних від імені легітимного відправника.
У3. Розшифрування зашифрованих даних особами, які є легітимними одержувачами даних (зловмисниками).
У4. Створення електронного підпису легітимного підписувача під фальшивими даними.
У5. Отримання позитивного результату перевірки електронного підпису фальшивих даних.
У6. Помилкове прийняття електронних документів до виконання внаслідок проблем організації електронного документообігу.
У7. Несанкціоноване ознайомлення з даними, що захищаються під час їх обробки СКЗІ.
У1. Компрометація закритих криптографічних ключів
У1.1. Отримання закритого ключа зі сховища закритих ключів.
У1.2. Отримання закритого ключа з об'єктів середовища функціонування криптосредства, у яких може тимчасово перебувати.
Пояснення У1.2.
До об'єктів, у яких може тимчасово зберігатися закритий ключ, належать:
- оперативна пам'ять,
- тимчасові файли,
- файли підкачування,
- файли глибокого сну,
- файли снапшотів гарячого стану віртуальних машин, включаючи файли вмісту оперативної пам'яті віртуальних машин, поставлених на паузу.
У1.2.1. Вилучення закритих ключів із працюючої оперативної пам'яті за рахунок заморожування модулів ОЗУ, їх вилучення та подальше зчитування даних (freeze attack).
Пояснення У1.2.1.
Приклад .
У1.3. Отримання закритого ключа із каналу обміну закритими ключами.
Пояснення У1.3.
Приклад реалізації цієї загрози буде наведено .
У1.4. Несанкціонована модифікація криптоядра, внаслідок якої закриті ключі стають відомими зловмисникам.
У1.5. Компрометація закритого ключа внаслідок використання технічних каналів витоку інформації (ТКУІ).
Пояснення У1.5.
Приклад .
У1.6. Компрометація закритого ключа внаслідок використання спеціальних технічних засобів (СТС), призначених для негласного знімання інформації («жучків»).
У1.7. Компрометація закритих ключів у процесі їх зберігання поза СКЗД.
Пояснення У1.7.
Наприклад, користувач зберігає свої ключові носії в ящику робочого столу, з якого легко можуть бути вилучені зловмисникам.
У2. Зашифрування фальшивих даних від імені легітимного відправника
Пояснення
Ця загроза розглядається лише для схем шифрування даних з автентифікацією відправника. Приклади подібних схем вказані у рекомендаціях щодо стандартизації . Для інших криптографічних схем цієї загрози не існує, оскільки шифрування проводиться на відкритих ключах одержувача, а вони відомі зловмисникам.
Декомпозиція
У2.1. Компрометація закритого ключа відправника:
У2.1.1. Посилання: .
У2.2. Підміна вхідних даних у каналі обміну відкритими даними.
Примітки У2.2.
Приклади реалізації цієї загрози наведені нижче и .
У3. Розшифрування зашифрованих даних особами, які не є легітимними одержувачами даних (зловмисниками)
Декомпозиція
У3.1. Компрометація закритих ключів отримувача зашифрованих даних.
У3.1.1 Посилання: .
У3.2. Підміна зашифрованих даних у каналі обміну захищеними даними.
У4. Створення електронного підпису легітимного підписувача під фальшивими даними
Декомпозиція
У4.1. Компрометація закритих ключів електронного підпису легітимного підписувача.
У4.1.1 Посилання: .
У4.2. Підміна даних, що підписуються в каналі обміну відкритими даними.
Примітка У4.2.
Приклади реалізації цієї загрози наведені нижче и .
У5. Отримання позитивного результату перевірки електронного підпису фальшивих даних
Декомпозиція
У5.1. Зловмисники перехоплюють у каналі передачі результатів роботи повідомлення про негативний результат перевірки електронного підпису та підмінюють його повідомлення з позитивним результатом.
У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.
Приклад реалізації цієї загрози наведено .
У5.5.1. Перевірка довіри до сертифіката ключа електронного підпису лише за наявності довіри до сертифіката, за допомогою якого він підписаний, без перевірок CRL або OCSP.
Пояснення У5.5.1.
Приклад реалізації .
У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. Помилкове прийняття електронних документів до виконання внаслідок проблем організації електронного документообігу.
Декомпозиція
У6.1. Сторона, що приймає, не виявляє дублювання одержуваних документів.
Пояснення У6.1.
Приклад атаки. Зловмисники можуть перехопити документ, що передається одержувачу, нехай навіть криптографічно захищений, а потім багаторазово відправити його в канал передачі захищених даних. Якщо одержувач не виявляє дублі, то всі одержувані документи сприйматимуться і відпрацьовуватимуться як різні документи.
У7. Несанкціоноване ознайомлення з даними під час їх обробки СКЗІ
Декомпозиція
У7.1. <…> внаслідок витоку інформації сторонніми каналами (side channel attack).
Пояснення У7.1.
Приклад .
У7.2. <…> внаслідок нейтралізації захисту від несанкціонованого доступу до інформації, що обробляється на СКЗІ:
У7.2.1. Експлуатація СКЗІ із порушеннями вимог, описаних у документації на СКЗІ.
У7.2.2. <…>, здійсненої за рахунок наявності вразливостей у:
У7.2.2.1. <…> засоби захисту від несанкціонованого доступу.
У7.2.2.2. <…> самої СКЗІ.
У7.2.2.3. <…> середовищі функціонування криптосредства.
Приклади атак
Розглянуті нижче сценарії свідомо містять помилки організації інформаційної безпеки і лише для ілюстрації можливих атак.
Сценарій 1. Приклад реалізації загроз У2.2 та У4.2.
опис об'єкта
ПО АРМ КБР та СКЗІ СКАД Сигнатура встановлені на фізичному комп'ютері, не підключеному до обчислювальної мережі. Як ключовий носій використовується ФКН vdToken в режимі роботи з ключем, що не вилучається.
Регламент здійснення розрахунків передбачає, що фахівець з розрахунків зі свого робочого комп'ютера завантажує електронні повідомлення у відкритому вигляді (схема старого АРМ КБР) зі спеціального захищеного файлового сервера, потім записує їх на USB-флешку, що відчужується, і переносить на АРМ КБР, де їх шифрує і підписує. Після цього фахівець переносить на відчужуваний носій захищені електронні повідомлення, а потім через свій робочий комп'ютер записує їх на файловий сервер, звідки вони потрапляють на УТА і далі платіжну систему Банку Росії.
У цьому випадку канали обміну відкритими та захищеними даними включатимуть: файловий сервер, робочий комп'ютер спеціаліста і відчужуваний носій.
Атака
Зловмисники несанкціонованого встановлюють на робочий комп'ютер спеціаліста систему віддаленого управління і в момент запису на носій платіжних доручень (електронних повідомлень), що відчужується, у відкритому вигляді підмінюють вміст одного з них. Фахівець переносить платіжні доручення на АРМ КБР, підписує та шифрує їх, не помічаючи заміни (наприклад, через велику кількість платіжних доручень у рейсі, втоми тощо). Після цього підроблене платіжне доручення, пройшовши через технологічний ланцюжок, потрапляє до платіжної системи Банку Росії.
Сценарій 2. Приклад реалізації загроз У2.2 та У4.2.
опис об'єкта
Комп'ютер із встановленими АРМ КБР, СКАД Сигнатура та підключеним ключовим носієм ФКН vdToken функціонує у виділеному приміщенні без доступу з боку персоналу.
Фахівець із розрахунків підключається до АРМ КБР у режимі віддаленого доступу за протоколом RDP.
Атака
Зловмисники перехоплюють реквізити, використовуючи які фахівець із розрахунків здійснює підключення та роботу з АРМ КБР (наприклад, за рахунок шкідливого коду на його комп'ютері). Потім проводять підключення від його імені та відправляють до платіжної системи Банку Росії підроблене платіжне доручення.
Сценарій 3. Приклад реалізації загрози У1.3.
опис об'єкта
Розглянемо одне із гіпотетичних варіантів реалізації модулів інтеграції «АБС-КБР» для нової схеми (АРМ КБР-Н), коли він електронний підпис вихідних документів відбувається за АБС. При цьому вважатимемо, що АБС функціонує на базі операційної системи, яка не підтримується СКЗІ СКАД Сигнатура, і, відповідно, криптографічний функціонал винесено на окрему віртуальну машину – модуль інтеграції «АБС-КБР».
Як ключовий носій використовується звичайний USB-токен, що працює в режимі видобутого ключа. При підключенні ключового носія до гіпервізору виявилося, що в системі немає вільних USB-портів, тому було вирішено підключити USB-токен через мережевий USB-концентратор, а на віртуальну машину встановити клієнт USB-over-IP, який здійснюватиме зв'язок із концентратором.
Атака
Зловмисники перехопили закритий ключ електронного підпису з каналу зв'язку між USB-концентратором та гіпервізором (дані передавалися у відкритому вигляді). Маючи закритий ключ, зловмисники сформували підроблене платіжне доручення, підписали його електронним підписом та відправили до АРМ КБР-Н на виконання.
Сценарій 4. Приклад реалізації загроз У5.5.
опис об'єкта
Розглянемо таку ж схему, як у попередньому сценарії. Вважатимемо, що електронні повідомлення, що надходять з АРМ КБР-Н, потрапляють до папки …SHAREIn, а ті, що відправляються до АРМ КБР-Н і далі платіжної системи Банку Росії, — у …SHAREout.
Також будемо вважати, що при реалізації модуля інтеграції списки відкликаних сертифікатів оновлюються лише при перевипуску криптографічних ключів, а також те, що електронні повідомлення, що надійшли до папки …SHAREIn перевіряються лише щодо контролю цілісності та контролю довіри до відкритого ключа електронного підпису.
Атака
Зловмисники, скориставшись викраденими у попередньому сценарії ключами, підписали підроблене платіжне доручення, що містить відомості про надходження грошей на рахунок клієнту-шахраю та впровадили його в канал обміну захищеними даними. Оскільки перевірки того, що платіжне доручення підписано саме Банком Росії, не проводиться, він приймається до виконання.
Джерело: habr.com