Връзки към други части на изследването
- (Вие сте тук)
Тази статия завършва цикъла публикации, посветени на осигуряването на информационната сигурност на банковите безналични плащания. Тук ще разгледаме стандартните модели на заплахи, на които се позовава в :
- .
- .
- .
- .
ХАБРО-WARNING !!! Уважаеми хабровчани, това не е развлекателна публикация.
Скритите под кат 40+ страници материали са предназначени да помогнат в работата или обучението на хора, специализирани в банковото дело или осигуряването на информационна сигурност. Тези материали са окончателният продукт на изследването и са написани в сух официален тон. По същество те са подготвителни текстове за вътрешни документи по ИБ.Някои традиционни — „употребата на данни от статията за неправомерни цели се преследва по закон“. Приятно четене!
Информация за читателите, които се запознават с изследването, започвайки от тази публикация.
За какво е изследването
Вие четете наръчник за специалиста, отговорен за осигуряване на информационната сигурност на плащанията в банката.
Логика на изложението
В началото в и дава описание на обекта на защита. После това в се обсъжда как да се изградят системи за защита и се говори за необходимостта от формулиране на модели на заплахи. В се обсъжда какви модели на заплахи съществуват и как се формулират. В и се предоставя анализ на реални атаки. и съдържат описание на модела на заплаха, изградена с оглед на информацията от всички предходни части.
ТИПОВ МОДЕЛ НА ЗАПЛАХИТЕ. МРЕЖОВА СВЪРЗАНОСТ
Обект на защита, за който се прилага модел на заплахи (scope)
Обект на защита са данните, предавани през мрежова свързаност, функционираща в мрежи за предаване на данни, изградени на базата на стека TCP/IP.
Архитектура
Описание на елементите на архитектурата:
- «Крайните възли» — възли, разменящи защитена информация.
- «Промеждутъчни възли» — елементи на мрежата за предаване на данни: маршрутизатори, комутатори, сървъри за достъп, прокси сървъри и друго оборудване, през които преминава трафикът на мрежовата свързаност. В общия случай мрежовата свързаност може да функционира без промеждутъчни възли (напр. директно между крайните възли).
Заплахи за безопасността на високото ниво
Декомпозиция
У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.
Например, предаване на паролите в неприкрит вид по имейл.
U1.1.8. Злоумышленниците са научили идентификационните данни, наблюдавайки работната сесия на потребителя чрез системи за отдалечено администриране.
U1.1.9. Злоумышленниците извлекли идентификационните данни в резултат на тяхното изтичане по технически канали (ТКУИ):
U1.1.9.1. Злоумышленниците подслушали как потребителят въвежда идентификационни данни с клавиатурата:
U1.1.9.1.1 Злоумышленниците са се намирали в непосредствена близост до потребителя и са виждали как се въвеждат идентификационните данни с очите си.
Пояснения U1.1.9.1.1
Подобни случаи включват действия на колеги на работа или случай, когато клавиатурата на потребителя е видима за посетителите на организацията.
U1.1.9.1.2 Злоумышленниците са използвали допълнителни технически средства, като бинокли или безпилотни летателни апарати, и са виждали как се въвеждат идентификационните данни през прозореца.
U1.1.9.2. Злоумышленниците извлекли идентификационните данни от записите на радиовръзката между клавиатурата и системния блок на компютъра в случай на свързване чрез радиоинтерфейс (например, Bluetooth).
U1.1.9.3. Злоумышленниците осъществили прихващането на идентификационни данни чрез тяхното изтичане по канал с вторични електромагнитни излъчвания и наведени (ПЭМИН).
Пояснения U1.1.9.3.
Примери за атака и .
U1.1.9.4. Злоумышленникът е осъществил прихващането на въвеждането на идентификационни данни чрез използване на специализирани технически средства (СТС), предназначени за тайно записване на информация.
Пояснения U1.1.9.4.
Примери .
U1.1.9.5. Злоумышленниците осъществили прихващането на въвеждането на идентификационни данни с клавиатурата чрез
анализ на Wi-Fi сигнала, модулиран от процеса на натискане на клавишите от потребителя.
Пояснения U1.1.9.5.
Пример .
U1.1.9.6. Злоумышленниците осъществили прихващането на въвеждането на идентификационни данни с клавиатурата чрез анализ на звуците от натискането на клавишите.
Пояснения U1.1.9.6.
Пример .
U1.1.9.7. Злоумышленниците осъществили прихващането на въвеждането на идентификационни данни с клавиатурата на мобилно устройство чрез анализ на показанията на акселерометъра.
Пояснения U1.1.9.7.
Пример .
U1.1.10. , предварително запазени на Клиента.
Пояснения U1.1.10.
Например, потребителят може да е запазил в браузъра логин и парола за достъп до определен сайт.
U1.1.11. Злоумышленниците скомпрометирали идентификационните данни поради недостатъци в процеса на отзив на достъпи на потребителите.
Пояснения U1.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, приложният софтуер и криптокорът работят в рамките на една и съща среда на функциониране на криптосредството (СФК), например, на един и същ компютър, под управлението на една и съща операционна система. Потребителят на системата обикновено може да стартира в тази съща среда и други програми, включително съдържащи зловреден код. При такива условия съществува сериозен риск от leakage на закрити криптографски ключове.
За минимизиране на риска се използва схема 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 ще се синхронизират със системните часове на хипервизора, а те, от своя страна, ще се синхронизират през Интернет с публични времеви сървъри.
Извеждане на структурни елементи на СКЗИ
На база на горното описание на ИТ инфраструктурата, ще извлечем структурните елементи на СКЗИ и ще ги запишем в таблица.
Таблица — Съвпадение на елементите на модела на СКЗИ с елементите на информационните системи
Наименование на елемента
Организация 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. Извличане на закрити ключове от работеща оперативна памет чрез замразяване на модулите на RAM, тяхното извличане и последващо прочитане на данни (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
