Връзки към други части на изследването
- (Вие сте тук)
Тази статия завършва цикъла от публикации, посветени на осигуряването на информационната сигурност на банковите безналични плащания. Тук разглеждаме общите модели на заплахи, посочени в :
- .
- .
- .
- .
HABR-ПРЕДУПРЕЖДЕНИЕ!!! Уважаеми хабровци, това не е забавна публикация.
Изискват се 40+ страници с материали, скрити под изрязването помощ при работа или учене хора, специализирани в банково дело или информационна сигурност. Тези материали са крайният продукт на изследването и са написани със сух формален тон. Всъщност това са бланки за вътрешни документи по информационна сигурност.Ами традиционното „Използването на информация от статията за незаконни цели е наказуемо от закона“. Продуктивно четене!
Информация за читателите, които четат проучването, започващо с тази публикация.
За какво е изследването
Четете ръководство за специалист, отговорен за осигуряване на информационната сигурност на плащанията в банка.
Логика на презентацията
В началото в и дадено е описанието на обекта на защита. След това в той разказва как да се изгради система за защита и говори за необходимостта от създаване на модел на заплаха. IN Разказва какво представляват моделите на заплахи и как се формират. IN и даден е анализ на реални атаки. и съдържа описание на модела на заплахата, изграден, като се вземе предвид информацията от всички предишни части.
ТИПИЧЕН МОДЕЛ НА ЗАПЛАХИТЕ. МРЕЖОВА ВРЪЗКА
Защитният обект, за който се прилага моделът на заплахата (обхват)
Обект на защита са данни, предавани чрез мрежова връзка, работеща в мрежи за данни, изградени на базата на TCP/IP стека.
архитектура
Описание на архитектурните елементи:
- "крайни възли" — възли, обменящи защитена информация.
- "Междинни възли" - елементи на мрежата за пренос на данни: рутери, комутатори, сървъри за достъп, прокси сървъри и друго оборудване - чрез което се предава трафикът на мрежовата връзка. Като цяло мрежовата връзка може да функционира без междинни възли (директно между крайните възли).
Заплахи за сигурността от най-високо ниво
Разлагане
U1. Неоторизиран достъп до предадени данни.
U2. Неоторизирана промяна на предадените данни.
U3. Нарушаване на авторството на предадените данни.
U1. Неоторизиран достъп до предадени данни
Разлагане
U1.1. <...>, извършвани на крайни или междинни възли:
U1.1.1. <…> чрез четене на данните, докато са в устройствата за съхранение на възела:
U1.1.1.1. <…> в RAM.
Обяснения към V1.1.1.1.
Например по време на обработка на данни от мрежовия стек на възела.
U1.1.1.2. <…> в енергонезависима памет.
Обяснения към V1.1.1.2.
Например, когато съхранявате предадени данни в кеша, временни файлове или файлове за пейджинг.
Y1.2. <…> извършено на възли на мрежа за данни на трети страни:
U1.2.1. <...> чрез улавяне на всички пакети, които попадат в мрежовия интерфейс на възела:
Обяснения към V1.2.1.
Всички пакети се улавят чрез превключване на мрежовата карта в безразборен режим (безразборен режим за кабелни адаптери или режим на наблюдение за wi-fi адаптери).
U1.2.2. <…> чрез извършване на атаки човек по средата (MiTM), но без промяна на предаваните данни (без да се броят сервизните данни на мрежовите протоколи).
Y1.2.2.1. връзка: .
Y1.3. <...>, извършено поради изтичане на информация по технически канали (TCUI) от физически възли или комуникационни линии.
U1.4. <...>, извършвани за инсталиране на специални технически средства (STS) на крайните или междинни възли, предназначени за скрито премахване на информация.
U2. Неоторизирана промяна на предадени данни
Разлагане
Y2.1. <...>, извършвани на крайни или междинни възли:
Y2.1.1. <...> чрез четене и модифициране на данните, докато са в устройствата за съхранение на възлите:
Y2.1.1.1. <...> в RAM:
Y2.1.1.2. <…> в енергонезависима памет:
Y2.2. <...> извършено на мрежови възли на трети страни за данни:
U2.2.1. <…> чрез извършване на атаки Man-in-the-Middle (MiTM) и пренасочване на трафика към злонамерения хост:
Y2.2.1.1. Физическата връзка на оборудването на нападателите за прекъсване на мрежовата връзка.
Y2.2.1.2. Осъществяване на атаки срещу мрежови протоколи:
Y2.2.1.2.1. <…> управление на виртуална локална мрежа (VLAN):
Y2.2.1.2.1.1. .
Y2.2.1.2.1.2. Неоторизирана промяна на настройките на VLAN на комутатори или рутери.
Y2.2.1.2.2. <…> маршрутизиране на трафика:
Y2.2.1.2.2.1. Неоторизирана модификация на статичните таблици за маршрутизиране на рутери.
Y2.2.1.2.2.2. Обявяване на фалшиви маршрути от нападатели чрез динамични протоколи за маршрутизиране.
Y2.2.1.2.3. <…> автоматична конфигурация:
Y2.2.1.2.3.1. .
Y2.2.1.2.3.2. .
Y2.2.1.2.4. <…> адресиране и разрешаване на имена:
Y2.2.1.2.4.1. .
Y2.2.1.2.4.2. .
Y2.2.1.2.4.3. Извършване на неупълномощени промени в локални файлове с име на хост (hosts, lmhosts и т.н.)
U3. Нарушаване на авторството на предадените данни
Разлагане
Y3.1. Неутрализиране на механизмите за определяне на авторството на информация чрез посочване на невярна информация за автора или източника на данни:
Y3.1.1. Промяна на информацията за автора, съдържаща се в предаваната информация.
Y3.1.1.1. Неутрализиране на криптографската защита на целостта и авторството на предаваните данни:
Y3.1.1.1.1. връзка: .
Y3.1.1.2. Неутрализиране на защитата на авторството на предаваните данни, реализирано чрез еднократни кодове за потвърждение:
Y3.1.1.2.1. .
Y3.1.2. Промяна на информация за източника на предавана информация:
Y3.1.2.1. .
Y3.1.2.2. .
ТИПИЧЕН МОДЕЛ НА ЗАПЛАХИТЕ. ИНФОРМАЦИОННА СИСТЕМА, ИЗГРАДЕНА НА БАЗАТА НА АРХИТЕКТУРА КЛИЕНТ-СЪРВЪР
Защитният обект, за който се прилага моделът на заплахата (обхват)
Обектът на защита е информационна система, изградена на базата на архитектурата клиент-сървър.
архитектура
Описание на архитектурните елементи:
- "клиент" - устройство, на което работи клиентската част на информационната система.
- "Сървър" - устройство, на което работи сървърната част на информационната система.
- "Хранилище за данни" - част от сървърната инфраструктура на информационната система, предназначена да съхранява данни, обработвани от информационната система.
- "Мрежова връзка" — канал за обмен на информация между Клиента и Сървъра, преминаващ през мрежата за предаване на данни. За по-подробно описание на модела на елемента вижте .
Ограничения
При моделиране на обект се задават следните ограничения:
- Потребителят взаимодейства с информационната система в рамките на ограничени периоди от време, наречени работни сесии.
- В началото на всяка сесия потребителят се идентифицира, удостоверява и оторизира.
- Цялата защитена информация се съхранява в сървърната част на информационната система.
Заплахи за сигурността от най-високо ниво
Разлагане
U1. Нападатели, извършващи неразрешени действия от името на законен потребител.
U2. Неоторизирана промяна на защитена информация по време на нейната обработка от сървърната част на информационната система.
U1. Нападатели, извършващи неразрешени действия от името на законен потребител
обяснения
Обикновено в информационните системи корелацията на действията с потребителя, който ги е извършил, се извършва с помощта на:
- системни регистрационни файлове (дневници).
- специални атрибути на обекти с данни, съдържащи информация за потребителя, който ги е създал или модифицирал.
Във връзка с работна сесия тази заплаха може да се разложи на:
- <…> извършено в рамките на потребителската сесия.
- <…> се извършва извън потребителската сесия.
Потребителска сесия може да бъде инициирана:
- От самия потребител.
- Натрапници.
На този етап междинното разлагане на тази заплаха ще изглежда така:
U1.1. Неоторизирани действия, извършени в рамките на потребителската сесия:
U1.1.1. <…> зададен от атакувания потребител.
U1.1.2. <…> инсталиран от нападателите.
Y1.2. Извършени са неразрешени действия извън сесията на потребителя.
От гледна точка на обектите на информационната инфраструктура, които могат да бъдат засегнати от нарушители, декомпозицията на междинните заплахи ще изглежда така:
елементи
Разлагане на заплахи
Y1.1.1.
Y1.1.2.
Y1.2.
клиент
Y1.1.1.1.
Y1.1.2.1.
мрежова връзка
Y1.1.1.2.
сървър
Y1.2.1.
Разлагане
U1.1. Неоторизирани действия, извършени в рамките на потребителската сесия:
U1.1.1. <…> зададен от атакувания потребител:
U1.1.1.1. Нападателите са действали независимо от клиента:
У1.1.1.1.1 Нападателите са използвали стандартни инструменти за достъп до информационната система:
Y1.1.1.1.1.1. Нападателите са използвали физически средства за вход/изход на Клиента (клавиатура, мишка, монитор или сензорен екран на мобилно устройство):
Y1.1.1.1.1.1.1. Нападателите са действали през периоди от време, когато сесията е активна, I/O съоръженията са налични и потребителят е далеч.
Y1.1.1.1.1.2. Нападателите са използвали инструменти за отдалечено администриране (стандартни или предоставени от злонамерен код), за да управляват Клиента:
Y1.1.1.1.1.2.1. Нападателите са действали през периоди от време, когато сесията е активна, I/O съоръженията са налични и потребителят е далеч.
Y1.1.1.1.1.2.2. Нападателите са използвали инструменти за отдалечено администриране, чиято работа е невидима за атакувания потребител.
U1.1.1.2. Нападателите са фалшифицирали данните в мрежовата връзка между клиента и сървъра, като са ги модифицирали по такъв начин, че да бъдат възприети като действия на легитимен потребител:
Y1.1.1.2.1. връзка: .
U1.1.1.3. Нападателите принудиха потребителя да извърши посочените от тях действия, използвайки методи за социално инженерство.
U1.1.2 <…> зададен от нападателите:
Y1.1.2.1. Нападателите са действали от Клиента (И):
Y1.1.2.1.1. Нападателите неутрализираха системата за контрол на достъпа до информационната система:
Y1.1.2.1.1.1. връзка: .
Y1.1.2.1.2. Злосторниците са използвали стандартни средства за достъп до информационната система
U1.1.2.2. Нападателите са действали от други възли на мрежата за предаване на данни, от които е възможно да се установи мрежова връзка със сървъра (И):
Y1.1.2.2.1. Нападателите неутрализираха системата за контрол на достъпа до информационната система:
Y1.1.2.2.1.1. връзка: .
Y1.1.2.2.2. Нападателите са използвали нестандартни средства за достъп до информационната система.
Обяснения Y1.1.2.2.2.
Нападателите биха могли да инсталират обикновен клиент на информационна система на възел на трета страна или биха могли да използват нестандартен софтуер, който прилага стандартни протоколи за обмен между клиента и сървъра.
P1.2 Неоторизирани действия, извършени извън сесията на потребителя.
S1.2.1 Нападателите извършиха неразрешени действия и след това направиха неразрешени промени в регистрационните файлове на информационната система или специални атрибути на обекти с данни, което показва, че извършените от тях действия са извършени от легитимен потребител.
U2. Неоторизирана промяна на защитена информация по време на нейната обработка от сървърната част на информационната система
Разлагане
Y2.1. Нападателите променят защитената информация с помощта на стандартни инструменти на информационната система и правят това от името на легитимен потребител.
Y2.1.1. връзка: .
Y2.2. Нападателите променят защитената информация, като използват механизми за достъп до данни, които не са предвидени от нормалната работа на информационната система.
U2.2.1. Нападателите променят файлове, съдържащи защитена информация:
Y2.2.1.1. <…> с помощта на механизмите за обработка на файлове, предоставени от операционната система.
Y2.2.1.2. <...> като провокира възстановяването на файлове от неоторизирано модифицирано архивиране.
U2.2.2. Злосторниците променят защитената информация, съхранявана в базата данни (И):
Y2.2.2.1. Нападателите неутрализират системата за контрол на достъпа до СУБД:
Y2.2.2.1.1. връзка: .
Y2.2.2.2. Нападателите променят информацията, използвайки стандартни СУБД интерфейси за достъп до данни.
Y2.3. Злосторниците променят защитената информация чрез неоторизирана промяна на алгоритмите на работа на софтуера, който я обработва.
Y2.3.1. Извършват се модификации в изходния код на софтуера.
Y2.3.1. Правят се модификации на машинния код на софтуера.
Y2.4. Нападателите променят защитената информация, като използват уязвимости в софтуера на информационната система.
Y2.5. Нападателите променят защитената информация, когато тя се прехвърля между компонентите на сървърната част на информационната система (например сървър на база данни и сървър на приложения):
Y2.5.1. връзка: .
ТИПИЧЕН МОДЕЛ НА ЗАПЛАХИТЕ. СИСТЕМА ЗА КОНТРОЛ НА ДОСТЪП
Защитният обект, за който се прилага моделът на заплахата (обхват)
Обектът на защита, за който се прилага този модел на заплаха, съответства на обекта на защита на модела на заплаха: „Типичен модел на заплаха. Информационна система, изградена на базата на архитектура клиент-сървър.
Системата за контрол на потребителския достъп в този модел на заплаха се разбира като компонент на информационната система, който изпълнява следните функции:
- Идентификация на потребителя.
- Удостоверяване на потребителя.
- Потребителски права.
- Регистриране на потребителски действия.
Заплахи за сигурността от най-високо ниво
Разлагане
U1. Неоторизирано установяване на сесия от името на легитимен потребител.
U2. Неоторизирано повишаване на правата на потребителите в информационната система.
U1. Неоторизирано установяване на сесия от името на законен потребител
обяснения
Декомпозицията на тази заплаха в общия случай ще зависи от вида на използваните системи за идентификация и удостоверяване на потребителя.
В този модел ще бъдат взети под внимание само системата за идентификация и удостоверяване на потребителя, използваща текстово име за вход и парола. В този случай ще приемем, че входът на потребителя е публична информация, известна на нападателите.
Разлагане
U1.1. <…> чрез компрометиране на идентификационни данни:
U1.1.1. Нападателите са компрометирали идентификационните данни на потребителя, докато са били съхранявани.
Обяснения Y1.1.1.
Например идентификационните данни могат да бъдат написани на лепкава бележка, залепена на монитора.
U1.1.2. Потребителят случайно или злонамерено е предал подробности за достъп на нападателите.
Y1.1.2.1. Потребителят произнесе идентификационните данни на глас, докато влизаше.
U1.1.2.2. Потребителят умишлено предаде своите идентификационни данни:
Y1.1.2.2.1. <…> колеги на работа.
Обяснения Y1.1.2.2.1.
Например, за да могат да го заместят с период на болест.
Y1.1.2.2.2. <…> на контрагентите на работодателя, извършващи работа върху обектите на информационната инфраструктура.
Y1.1.2.2.3. <…> на трети страни.
Обяснения Y1.1.2.2.3.
Един, но не единственият начин за прилагане на тази заплаха е използването на методи за социално инженерство от нападателите.
U1.1.3. Нападателите грубо принудиха идентификационните данни:
Y1.1.3.1. <…> чрез редовни механизми за достъп.
U1.1.3.2. <...> от предварително прихванати кодове (например хешове на пароли) за съхраняване на идентификационни данни.
U1.1.4. Нападателите са използвали зловреден код, за да прихванат идентификационните данни на потребителя.
U1.1.5. Нападателите са извлекли идентификационни данни от мрежова връзка между клиента и сървъра:
Y1.1.5.1. връзка: .
U1.1.6. Нападателите са извлекли идентификационни данни от записи на системи за наблюдение на работата:
U1.1.6.1. <…> системи за видеонаблюдение (в случай, че са записани натискания на клавиши на клавиатурата по време на работа).
U1.1.6.2. <…> системи за наблюдение на действията на служителите пред компютъра
Обяснения Y1.1.6.2.
Пример за такава система е .
U1.1.7. Нападателите са компрометирали идентификационните данни на потребителя поради пропуски в процеса на предаване.
Обяснения Y1.1.7.
Например предаването на пароли в чист текст по имейл.
U1.1.8. Нападателите научиха идентификационните данни, като наблюдаваха сесията на потребителя, използвайки системи за отдалечено администриране.
U1.1.9. Нападателите са извлекли идентификационните данни в резултат на изтичането им през технически канали (TCUE):
U1.1.9.1. Нападателите са шпионирали как потребителят въвежда идентификационни данни от клавиатурата:
E1.1.9.1.1 Нападателите са били разположени в непосредствена близост до потребителя и са видели въвеждането на идентификационни данни със собствените си очи.
C1.1.9.1.1 Обяснения
Такива случаи включват действия на колеги на работа или случай, когато клавиатурата на потребителя е видима за посетителите на организацията.
E1.1.9.1.2 Нападателите са използвали допълнителни технически средства, като бинокъл или безпилотен летателен апарат, и са видели въвеждането на идентификационни данни през прозорец.
U1.1.9.2. Нападателите са извличали идентификационни данни от записите на радиообмена между клавиатурата и системния модул на компютъра, ако са били свързани чрез радиоинтерфейс (например Bluetooth).
U1.1.9.3. Нападателите са прихванали идентификационните данни, като са ги пуснали през канала за фалшиво електромагнитно излъчване и приемници (PEMIN).
Обяснения Y1.1.9.3.
Примери за атака и .
U1.1.9.4. Нападателят е прихванал въвеждането на идентификационни данни от клавиатурата чрез използването на специални технически средства (STS), предназначени за тайно премахване на информация.
Обяснения Y1.1.9.4.
Примеры .
U1.1.9.5. Нападателите са прихванали въвеждането на идентификационни данни от клавиатурата с помощта на
анализ на Wi-Fi сигнала, модулиран от процеса на натискане на клавишите от потребителя.
Обяснения Y1.1.9.5.
Пример .
U1.1.9.6. Нападателите прихванаха въвеждането на идентификационни данни от клавиатурата, като анализираха звуците от натискане на клавиши.
Обяснения Y1.1.9.6.
Пример .
U1.1.9.7. Нападателите прихванаха въвеждането на идентификационни данни от клавиатурата на мобилно устройство, като анализираха показанията на акселерометъра.
Обяснения Y1.1.9.7.
Пример .
U1.1.10. <...> предварително запазени на клиента.
Обяснения Y1.1.10.
Например, потребител може да запише потребителско име и парола в браузъра за достъп до определен сайт.
U1.1.11. Нападателите са компрометирали идентификационни данни поради пропуски в процеса на отнемане на потребителски достъп.
Обяснения Y1.1.11.
Например, след уволнението на даден потребител, акаунтите му остават неблокирани.
Y1.2. <…> чрез използване на уязвимости в системата за контрол на достъпа.
U2. Неоторизирано повишаване на правата на потребителите в информационната система
Разлагане
P2.1 <...> чрез извършване на неоторизирани промени в данни, съдържащи информация за привилегиите на потребителя.
U2.2 <…> чрез използване на уязвимости в системата за контрол на достъпа.
Y2.3. <…> поради недостатъци в процеса на контрол на потребителския достъп.
Обяснения Y2.3.
Пример 1. На потребител е предоставен повече достъп до работа, отколкото му е необходимо поради служебни нужди.
Пример 2: След прехвърляне на потребител на друга позиция, предоставените преди това права за достъп не са отменени.
ТИПИЧЕН МОДЕЛ НА ЗАПЛАХИТЕ. ИНТЕГРАЦИОНЕН МОДУЛ
Защитният обект, за който се прилага моделът на заплахата (обхват)
Интеграционен модул - набор от обекти на информационната инфраструктура, предназначени да организират обмена на информация между информационните системи.
Предвид факта, че в корпоративните мрежи не винаги е възможно еднозначно да се отдели една информационна система от друга, интеграционният модул може да се разглежда и като връзка между компонентите в рамките на една информационна система.
архитектура
Обобщената схема на интеграционния модул изглежда така:
Описание на архитектурните елементи:
- "Exchange Server (CO)" – възел / услуга / компонент на информационна система, който изпълнява функцията за обмен на данни с друга информационна система.
- "Посредник" - възел / услуга, предназначена да организира взаимодействието между информационните системи, но не е част от тях.
примери "Посредници" могат да бъдат услуги за електронна поща, шина за корпоративни услуги / SoA архитектура, файлови сървъри на трети страни и др. В общия случай интеграционният модул може да не съдържа "Посредници". - "Софтуер за обработка на данни" - набор от програми, които изпълняват протоколи за обмен на данни и преобразуване на формати.
Например конвертиране на данни от формат UFEBS във формат ABS, промяна на статусите на съобщения по време на предаване и т.н. - "Мрежова връзка" съответства на обекта, описан в типичния модел на заплаха "Мрежова връзка". Някои мрежови връзки от представените в диаграмата по-горе може да не са.
Примери за интеграционни модули
Схема 1. Интегриране на ABS и AWP KBR чрез файлов сървър на трета страна
За извършване на плащания упълномощен служител на банката качва електронни платежни документи от ABS и ги записва във файл (със собствен формат, например SQL dump) в мрежовата папка (…SHARE) на файловия сървър. След това този файл се преобразува в набор от файлове във формат UFEBS с помощта на скрипт за конвертор, които след това се четат от CBD AWP.
След това упълномощен служител - потребител на AWS CBD - криптира и подписва получения файл и го изпраща до платежната система на Банката на Русия.
При получаване на плащания от Банката на Русия, AWP на ЦБР ги дешифрира и проверява електронния подпис, след което ги записва като набор от файлове във формат UFEBS на файловия сървър. Преди импортиране на платежни документи в ABS, те се конвертират с помощта на скрипт-конвертор от UFEBS формат в ABS формат.
Ще приемем, че в тази схема ABS работи на един физически сървър, работната станция на CBD работи на специален компютър, а конверторът на скриптове работи на файлов сървър.
Съответствие на обектите на разглежданата схема с елементите на модела на интеграционния модул:
„Сървъри за обмен от страна на ABS“ - ABS сървър.
„Сървъри за обмен от страна на AWP KBR“ - компютърна работна станция KBR.
"Посредник" - файлов сървър на трета страна.
"Софтуер за обработка на данни" - конвертор на скриптове.
Схема 2. Интегриране на ABS и AWS KBR при поставяне на споделена мрежова папка с плащания на AWS KBR
Всичко е подобно на Схема 1, но не се използва отделен файлов сървър, вместо това на компютър с AWS CBD се намира мрежова папка (…SHARE) с електронни платежни документи. Конверторът на скриптове също работи на AWP CBD.
Съответствие на обектите на разглежданата схема с елементите на модела на интеграционния модул:
Подобно на схема 1, но "Посредник" не се използва.
Схема 3. Интегриране на ABS и AWS KBR-N чрез IBM WebSphera MQ и подписване на електронни документи "от страна на ABS"
ABS работи на платформа, която не се поддържа от CIPF SKAD Signature. Изходящите електронни документи се подписват на специален сървър за електронен подпис (ES Server). Същият сървър проверява електронния подпис под документи, входящи от Банката на Русия.
АБС качва на ES Server файл с платежни документи в собствен формат.
ES сървърът, използвайки скрипт за конвертиране, преобразува файла в електронни съобщения във формат UFEBS, след което електронните съобщения се подписват и предават на IBM WebSphere MQ.
AWS KBR-N осъществява достъп до IBM WebSphere MQ и получава подписани съобщения за плащане оттам, след което оторизиран служител - потребител на AWS KBR - ги криптира и ги изпраща към платежната система на Банката на Русия.
При получаване на плащания от Банката на Русия, AWP KBR-N ги дешифрира и проверява електронния подпис. Успешно обработените плащания под формата на декриптирани и подписани електронни съобщения във формат UFEBS се прехвърлят към IBM WebSphere MQ, откъдето се получават от ES Server.
ES сървърът проверява електронния подпис на получените плащания и ги записва във файл в ABS формат. След това оторизиран служител - потребител на АБС, качва получения файл в АБС по предписания начин.
Съответствие на обектите на разглежданата схема с елементите на модела на интеграционния модул:
„Сървър за обмен от страна на ABS“ - ABS сървър.
„Сървър за обмен от страна на AWP KBR“ - компютърна работна станция KBR.
"Посредник" – ES сървър и IBM WebSphere MQ.
"Софтуер за обработка на данни" – скрипт-конвертор, CIPF SCAD подпис на ES сървъра.
Схема 4. Интегриране на RBS сървъра и ABS чрез API, предоставен от специален обменен сървър
Предполагаме, че банката използва няколко системи за дистанционно банкиране (RBS):
- "Интернет клиент-банка" за физически лица (ICB FL);
- "Интернет клиент-банка" за юридически лица (ICB LE).
С цел осигуряване на информационна сигурност цялото взаимодействие на АБС с РБ системите се осъществява чрез специален обменен сървър, работещ в рамките на информационната система АБС.
След това ще разгледаме процеса на взаимодействие на системата RBS на ICB LE с ABS.
RBS сървърът, след получаване на надлежно заверено платежно нареждане от клиента, трябва да създаде съответен документ в ABS въз основа на него. За да направите това, използвайки API, той прехвърля информация към сървъра за обмен, който от своя страна въвежда данни в ABS.
При промяна на баланса по сметката на клиента, АБС генерира електронни известия, които се предават на RBS сървъра чрез борсовия сървър.
Съответствие на обектите на разглежданата схема с елементите на модела на интеграционния модул:
„Сървър за обмен от RBS“ – RBS сървър ИКБ ЮЛ.
„Сървър за обмен от страна на ABS“ - сървър за обмен.
"Посредник" - отсъстващ.
"Софтуер за обработка на данни" – Компоненти на RB сървър, отговорни за използването на API на сървъра за обмен, компоненти на сървър за обмен, отговорни за използването на API на ABS.
Заплахи за сигурността от най-високо ниво
Разлагане
U1. Въвеждане на невярна информация от злосторници чрез интеграционния модул.
U1. Въвеждане на невярна информация от нападатели чрез интеграционния модул
Разлагане
U1.1. Неоторизирана промяна на законни данни по време на предаването им през мрежови връзки:
U1.1.1 Връзка: .
Y1.2. Прехвърляне на неверни данни чрез комуникационни канали от името на легитимен участник в обмена:
U1.1.2 Връзка: .
Y1.3. Неоторизирана промяна на легитимни данни по време на обработката им на сървърите на Exchange или посредника:
Y1.3.1. връзка: .
U1.4. Създаване на фалшиви данни на сървърите на Exchange или посредника от името на легитимен участник в обмена:
Y1.4.1. връзка:
Y1.5. Неоторизирана промяна на данни по време на тяхната обработка с помощта на софтуер за обработка на данни:
U1.5.1. <…> поради въвеждането на неоторизирани промени от нарушители в настройките (конфигурацията) на софтуера за обработка на данни.
U1.5.2. <…> поради извършване на неразрешени промени от нарушителите в изпълнимите файлове на софтуера за обработка на данни.
U1.5.3. <...> поради интерактивния контрол на софтуера за обработка на данни от нападателите.
ТИПИЧЕН МОДЕЛ НА ЗАПЛАХИТЕ. СИСТЕМА ЗА ЗАЩИТА НА КРИПТОГРАФСКА ИНФОРМАЦИЯ
Защитният обект, за който се прилага моделът на заплахата (обхват)
Обект на защита е криптографската система за защита на информацията, използвана за осигуряване сигурността на информационната система.
архитектура
Основата на всяка информационна система е приложен софтуер (софтуер), който реализира нейната целева функционалност.
Криптографската защита в този случай обикновено се осъществява чрез извикване на криптографски примитиви от бизнес логиката на приложния софтуер, които се намират в специализирани библиотеки - крипто-ядра.
Криптографските примитиви включват криптографски функции на ниско ниво като:
- криптиране/дешифриране на блок данни;
- създаване / проверка на електронния подпис на блока с данни;
- изчисляване на хеш функцията на блока от данни;
- генериране / качване / качване на ключова информация;
- и т.н.
Бизнес логиката на приложния софтуер, използвайки криптографски примитиви, реализира функционалност от по-високо ниво:
- криптирайте файла с ключовете на избраните получатели;
- установете защитена мрежова връзка;
- информира за резултатите от проверката на електронния подпис;
- и така нататък.
Взаимодействието на бизнес логиката и крипто-ядрото може да се извърши:
- директно, чрез извикване на криптографски примитиви от динамичните библиотеки на криптоядрото (.DLL - за Windows, .SO - за Linux) от бизнес логиката;
- директно, чрез криптографски интерфейси - обвивки, например MS Crypto API, Java Cryptography Architecture, PKCS # 11 и т.н. В този случай бизнес логиката се отнася до крипто интерфейса и превежда повикването към съответното крипто ядро, което в този случай се нарича крипто доставчик. Използването на криптографски интерфейси позволява на приложния софтуер да се абстрахира от конкретни криптографски алгоритми и да бъде по-гъвкав.
Има две типични схеми за организиране на криптоядро:
Схема 1 - Монолитно крипто-ядро
Схема 2 - Разделяне на Crypto Core
Елементите в горните диаграми могат да бъдат или отделни софтуерни модули, работещи на един и същ компютър, или мрежови услуги, взаимодействащи в компютърна мрежа.
Когато се използват системи, изградени съгласно схема 1, приложният софтуер и крипто-ядрото работят в една среда за работа на крипто-средство (CFC), например на един и същ компютър, работещ със същата операционна система. Потребителят на системата, като правило, може да стартира други програми в същата операционна среда, включително такива, съдържащи зловреден код. При такива условия съществува сериозен риск от изтичане на частни криптографски ключове.
За минимизиране на риска се използва схема 2, при която криптоядрото е разделено на две части:
- Първата част, заедно с приложния софтуер, работи в ненадеждна среда, където съществува риск от заразяване със злонамерен код. Ще наричаме тази част „софтуерна част“.
- Втората част работи в доверена среда на специално устройство, което съдържа хранилище за частни ключове. Отсега нататък ще наричаме тази част „хардуерна част“.
Разделянето на крипто-ядрото на софтуерна и хардуерна част е много условно. На пазара има системи, изградени по схемата с разделено крипто-ядро, но чиято "хардуерна" част е представена под формата на образ на виртуална машина - виртуален HSM ().
Взаимодействието на двете части на криптоядрото се осъществява по такъв начин, че частните криптографски ключове никога не се прехвърлят към софтуерната част и съответно не могат да бъдат откраднати с помощта на зловреден код.
Интерфейсът за взаимодействие (API) и наборът от криптографски примитиви, предоставени на приложния софтуер от криптоядрото, са еднакви и в двата случая. Разликата е в начина, по който се прилагат.
Така че, когато се използва схема с разделено криптоядро, взаимодействието между софтуера и хардуера се извършва съгласно следния принцип:
- Криптографските примитиви, които не изискват използването на частен ключ (например изчисляване на хеш функция, проверка на електронен подпис и др.), се извършват от софтуера.
- Криптографските примитиви, които използват частен ключ (създаване на електронен подпис, дешифриране на данни и т.н.), се изпълняват от хардуера.
Нека илюстрираме работата на разделено криптоядро, като използваме примера за създаване на електронен подпис:
- Софтуерната част изчислява хеш функцията на подписаните данни и предава тази стойност на хардуера чрез канала за обмен между крипто-ядрата.
- Хардуерната част, използвайки частния ключ и хеш, генерира стойността на електронния подпис и я прехвърля към софтуерната част чрез канала за обмен.
- Софтуерната част връща получената стойност към приложния софтуер.
Характеристики на проверка на коректността на електронен подпис
Когато получаващата страна получи данни, подписани с електронен подпис, тя трябва да извърши няколко етапа на проверка. Положителен резултат от проверката на електронен подпис се постига само ако всички етапи на проверка са завършени успешно.
Етап 1. Контрол на целостта на данните и авторството на данните.
Сценично съдържание. Електронният подпис на данните се проверява по съответния криптографски алгоритъм. Успешното приключване на този етап показва, че данните не са променяни от подписването им и че подписът е направен с частен ключ, съответстващ на публичния ключ за проверка на електронния подпис.
Местоположение на сцената: криптовалута.
Етап 2. Контрол на доверието в публичния ключ на подписващия и контрол на срока на валидност на частния ключ на електронния подпис.
Сценично съдържание. Етапът се състои от два междинни подетапа. Първият установява дали публичният ключ за проверка на електронния подпис е бил доверен в момента на подписване на данните. Вторият установява дали частният ключ на електронния подпис е бил валиден към момента на подписване на данните. В общия случай периодите на валидност на тези ключове може да не съвпадат (например за квалифицирани сертификати на ключове за проверка на електронен подпис). Методите за установяване на доверие в публичния ключ на подписващия се определят от правилата за управление на електронни документи, приети от взаимодействащите страни.
Местоположение на сцената: приложен софтуер / крипто-ядро.
Етап 3. Контрол на правомощията на подписващия.
Сценично съдържание. В съответствие с установените правила за управление на електронни документи се проверява дали подписалото лице е имало право да удостоверява защитените данни. Например, разгледайте ситуацията на нарушаване на властта. Да предположим, че има организация, в която всички служители имат електронен подпис. Вътрешната система за електронен документооборот получава поръчка от ръководителя, но подписана с електронен подпис на началника на склада. Съответно такъв документ не може да се счита за легитимен.
Местоположение на сцената: приложен софтуер.
Допускания, направени при описание на обекта на защита
- Каналите за пренос на информация, с изключение на каналите за обмен на ключове, също преминават през приложен софтуер, API и крипто-ядро.
- Информация за доверието в публичните ключове и (или) сертификати, както и информация за правомощията на собствениците на публични ключове, се поставят в хранилището на публични ключове.
- Приложният софтуер работи с публичния ключ за съхранение чрез крипто-ядрото.
Пример за информационна система, защитена с CIPF
За да илюстрирате представените по-рано схеми, разгледайте хипотетична информационна система и изберете всички структурни елементи в нея.
Описание на информационната система
Двете организации решиха да въведат правно обвързващо електронно управление на документи (EDF) между тях. За целта те сключват споразумение, в което заявяват, че документите ще се предават по електронна поща, като в същото време трябва да бъдат криптирани и подписани с квалифициран електронен подпис. Като средство за създаване и обработка на документи следва да се използват офис програми от пакета Microsoft Office 2016, а като средство за криптографска защита - CIPF CryptoPRO и софтуер за криптиране CryptoARM.
Описание на инфраструктурата на организацията 1
Организация 1 реши, че ще инсталира софтуера CryptoPRO CIPF и CryptoARM на работната станция на потребителя - физически компютър. Ключовете за криптиране и електронен подпис ще се съхраняват на носителя на ключове ruToken, работещ в режим на извличащ ключ. Потребителят ще подготви електронни документи локално на своя компютър, след което ще бъдат криптирани, подписани и изпратени с помощта на локално инсталиран мейл клиент.
Описание на инфраструктурата на организацията 2
Организация 2 реши да премести функциите на криптиране и електронен подпис на специална виртуална машина. В този случай всички криптографски операции ще се извършват автоматично.
За да направите това, две мрежови папки са организирани на специална виртуална машина: “…In”, “…Out”. Файловете, получени от контрагента в отворена форма, ще бъдат автоматично поставени в мрежовата папка „…В“. Тези файлове ще бъдат дешифрирани и електронният подпис ще бъде проверен върху тях.
В папката „...Out“ потребителят ще постави файлове, които трябва да бъдат криптирани, подписани и изпратени на контрагента. Потребителят сам ще подготви файловете на своята работна станция.
За извършване на функции за криптиране и електронен подпис на виртуалната машина са инсталирани CryptoPRO CIPF, софтуер CryptoARM и пощенски клиент. Автоматичното управление на всички елементи на виртуалната машина ще се извършва с помощта на скриптове, разработени от системните администратори. Работата на скриптовете се регистрира в лог файлове (дневници).
Криптографските ключове на електронния подпис ще бъдат поставени върху токен с невъзстановим ключ JaCarta GOST, който потребителят ще свърже с локалния си компютър.
Токенът ще бъде препратен към виртуалната машина с помощта на специализиран USB-over-IP софтуер, инсталиран на работната станция на потребителя и на виртуалната машина.
Системният часовник на работната станция на потребителя в организация 1 ще бъде коригиран ръчно. Системният часовник на специалната виртуална машина в организация 2 ще бъде синхронизиран със системния часовник на хипервайзора, който от своя страна ще бъде синхронизиран през интернет с публични сървъри за време.
Разпределение на структурните елементи на CIPF
Въз основа на горното описание на ИТ инфраструктурата, ние отделяме структурните елементи на CIPF и ги записваме в таблица.
Таблица - Съответствие на елементите на модела CIPF с елементите на информационните системи
Име на елемент
Организация 1
Организация 2
Приложен софтуер
CryptoARM софтуер
CryptoARM софтуер
Софтуерната част на криптоядрото
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP
Хардуерната част на криптоядрото
Не
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Съхранение на публичен ключ
Потребителска работна станция:
- HDD;
- стандартно хранилище за сертификати на Windows.
Хипервайзор:
- HDD.
Виртуална машина:
- HDD;
- стандартно хранилище за сертификати на Windows.
Съхранение на частен ключ
Ключов носител ruToken, работещ в режим на извличащ се ключ
Носителят на ключове JaCarta GOST, работещ в режим на невъзстановим ключ
Канал за обмен на публичен ключ
Потребителска работна станция:
- RAM.
Хипервайзор:
- RAM.
Виртуална машина:
- RAM.
Канал за обмен на частни ключове
Потребителска работна станция:
- USB шина;
- RAM.
Не
Канал за обмен между крипто-ядра
отсъства (няма криптовалутен хардуер)
Потребителска работна станция:
- USB шина;
- RAM;
- USB-over-IP софтуерен модул;
- мрежов интерфейс.
Корпоративна мрежа на организацията 2.
Хипервайзор:
- RAM;
- мрежов интерфейс.
Виртуална машина:
— мрежов интерфейс;
- RAM;
- USB-over-IP софтуерен модул.
Отворен канал за обмен на данни
Потребителска работна станция:
- средства за вход-изход;
- RAM;
- HDD.
Потребителска работна станция:
- средства за вход-изход;
- RAM;
- HDD;
- мрежов интерфейс.
Корпоративна мрежа на организацията 2.
Хипервайзор:
— мрежов интерфейс;
- RAM;
- HDD.
Виртуална машина:
— мрежов интерфейс;
- RAM;
- HDD.
Сигурен канал за обмен на данни
Internet.
Корпоративна мрежа на организацията 1.
Потребителска работна станция:
- HDD;
- RAM;
- мрежов интерфейс.
Internet.
Корпоративна мрежа на организацията 2.
Хипервайзор:
— мрежов интерфейс;
- RAM;
- HDD.
Виртуална машина:
— мрежов интерфейс;
- RAM;
- HDD.
Времеви канал
Потребителска работна станция:
- средства за вход-изход;
- RAM;
- системен таймер.
Internet.
Корпоративна мрежа на организацията 2,
Хипервайзор:
— мрежов интерфейс;
- RAM;
- системен таймер.
Виртуална машина:
- RAM;
- системен таймер.
Канал за предаване на команди за управление
Потребителска работна станция:
- средства за вход-изход;
- RAM.
(GUI на софтуера CryptoARM)
Виртуална машина:
- RAM;
- HDD.
(Скриптове за автоматизация)
Канал за получаване на резултатите от работата
Потребителска работна станция:
- средства за вход-изход;
- RAM.
(GUI на софтуера CryptoARM)
Виртуална машина:
- RAM;
- HDD.
(Регистрационни файлове за скриптове за автоматизация)
Заплахи за сигурността от най-високо ниво
обяснения
Предположения, направени при декомпозицията на заплахите:
- Използват се силни криптографски алгоритми.
- Криптографските алгоритми се използват сигурно в правилните режими на работа (напр. не се отнася за криптиране на големи количества данни, като се взема предвид допустимото натоварване на ключа и т.н.).
- Злосторниците знаят всички използвани алгоритми, протоколи и публични ключове.
- Нападателите имат достъп до всички криптирани данни.
- Нападателите са в състояние да възпроизведат всякакви програмни елементи в системата.
Разлагане
U1. Компрометиране на частни криптографски ключове.
U2. Криптиране на фалшиви данни от името на легитимен подател.
U3. Декриптиране на криптирани данни от лица, които не са легитимни получатели на данни (натрапници).
U4. Създаване на електронен подпис на легитимен подписал под неверни данни.
U5. Получаване на положителен резултат от проверка на електронния подпис на неверни данни.
U6. Погрешно приемане на електронни документи за изпълнение поради проблеми в организацията на електронния документооборот.
U7. Неоторизиран достъп до защитени данни при обработката им от CIPF.
U1. Компрометиране на частни криптографски ключове
U1.1. Вземете личния ключ от магазина за лични ключове.
Y1.2. Получаване на частен ключ от обектите на средата на функциониране на криптографския инструмент, в която той може да бъде временно разположен.
Обяснения Y1.2.
Обектите, които могат временно да съхраняват частен ключ, включват:
- RAM,
- временни файлове,
- пейджинг файлове,
- файлове за хибернация,
- файлове със снимки на "горещо" състояние на виртуални машини, включително файлове със съдържанието на RAM на виртуални машини, които са били поставени на пауза.
U1.2.1. Извличане на лични ключове от работеща RAM чрез замразяване на RAM модули, извличането им и след това четене на данните (замразяваща атака).
Обяснения Y1.2.1.
Пример .
Y1.3. Получаване на частен ключ от канал за обмен на частни ключове.
Обяснения Y1.3.
Ще бъде даден пример за прилагането на тази заплаха .
U1.4. Неоторизирана модификация на крипто-ядрото, в резултат на което частните ключове стават известни на нападателите.
Y1.5. Компрометиране на частния ключ в резултат на използването на технически канали за изтичане на информация (TCLE).
Обяснения Y1.5.
Пример .
U1.6. Компрометиране на частния ключ в резултат на използването на специални технически средства (STS), предназначени за тайно извличане на информация („бъгове“).
Y1.7. Компрометиране на частни ключове по време на съхранението им извън CIPF.
Обяснения Y1.7.
Например, потребителят държи своя ключов носител в чекмедже на работния плот, откъдето може лесно да бъде извлечен от нарушители.
U2. Криптиране на фалшиви данни от името на легитимен подател
обяснения
Тази заплаха се разглежда само за схеми за криптиране на данни с удостоверяване на подателя. Примери за такива схеми са посочени в препоръките за стандартизация. . За други криптографски схеми тази заплаха не съществува, тъй като криптирането се извършва върху публичните ключове на получателя и те обикновено са известни на атакуващите.
Разлагане
Y2.1. Компрометиране на частния ключ на подателя:
Y2.1.1. връзка: .
Y2.2. Подмяна на входните данни в отворения канал за обмен на данни.
Бележки U2.2.
Примери за прилагане на тази заплаха са дадени по-долу. и .
U3. Декриптиране на криптирани данни от лица, които не са легитимни получатели на данни (нарушители)
Разлагане
Y3.1. Компрометиране на частни ключове на получателя на криптирани данни.
U3.1.1 Връзка: .
Y3.2. Подмяна на криптирани данни в защитен канал за обмен на данни.
U4. Създаване на електронен подпис на легитимен подписал под неверни данни
Разлагане
Y4.1. Компрометиране на частни ключове на електронния подпис на легитимен подписал.
U4.1.1 Връзка: .
Y4.2. Подмяна на подписани данни в отворения канал за обмен на данни.
Забележка U4.2.
Примери за прилагане на тази заплаха са дадени по-долу. и .
U5. Получаване на положителен резултат от проверка на електронния подпис на неверни данни
Разлагане
Y5.1. Злоумышленниците прихващат в канала за предаване на резултатите от работата съобщение за отрицателен резултат от проверката на електронния подпис и го заменят със съобщение с положителен резултат.
Y5.2. Нападателите извършват атака срещу доверието при подписване на сертификати (СЦЕНАРИЙ - всички елементи са задължителни):
Y5.2.1. Нападателите генерират публичен и частен ключ за електронен подпис. Ако системата използва сертификати за ключове за електронен подпис, те генерират сертификат за електронен подпис, който е възможно най-подобен на сертификата на предполагаемия подател на данните, чието съобщение искат да фалшифицират.
U5.2.2. Нападателите правят неразрешени промени в хранилището на публичен ключ, като придават на генерирания от тях публичен ключ необходимото ниво на доверие и авторитет.
Y5.2.3. Нападателите подписват фалшиви данни с предварително генериран ключ за електронен подпис и го вграждат в защитен канал за обмен на данни.
Y5.3. Нападателите извършват атака, използвайки изтекли ключове за електронен подпис на легален подписващ (СЦЕНАРИЙ - всички елементи са задължителни):
Y5.3.1. Нападателите компрометират изтеклите (в момента невалидни) частни ключове на електронния подпис на законния подател.
Y5.3.2. Нападателите заменят времето в канала за предаване на времето с времето, в което компрометираните ключове са били все още валидни.
Y5.3.3. Нападателите подписват фалшиви данни с предварително компрометиран ключ за електронен подпис и го вграждат в защитен канал за обмен на данни.
Y5.4. Нападателите извършват атака, използвайки компрометирани ключове за електронен подпис на легален подписващ (СЦЕНАРИЙ - всички елементи са задължителни):
Y5.4.1. Нападателите правят копие на хранилището на публичен ключ.
Y5.4.2. Нападателите компрометират личните ключове на един от легитимните податели. Той забелязва компромиса, анулира ключовете, информацията за анулирането на ключа се поставя в хранилището на публични ключове.
Y5.4.3. Нападателите заменят хранилището на публичния ключ с предварително копирания.
Y5.4.4. Нападателите подписват фалшиви данни с предварително компрометиран ключ за електронен подпис и го вграждат в защитен канал за обмен на данни.
Y5.5. <...> поради наличие на грешки при изпълнението на 2-ри и 3-ти етап на проверка на електронния подпис:
Обяснения Y5.5.
Даден е пример за реализацията на тази заплаха .
U5.5.1. Проверка на доверие в сертификата на ключа за електронен подпис само чрез наличие на доверие в сертификата, с който е подписан, без CRL или OCSP проверки.
Обяснения Y5.5.1.
Пример за изпълнение .
Y5.5.2. При изграждане на верига на доверие за сертификат не се анализира правомощията за издаване на сертификати
Обяснения Y5.5.2.
Пример за атака срещу SSL/TLS сертификати.
Нападателите са закупили легитимен сертификат за своята електронна поща. След това те направиха измамен сертификат за уебсайт и го подписаха със собствен сертификат. Ако проверката на идентификационните данни не се извърши, тогава при проверка на веригата на доверие тя ще се окаже правилна и съответно измамният сертификат също ще бъде правилен.
Y5.5.3. При изграждане на верига за доверие на сертификати междинните сертификати не се проверяват за отмяна.
Y5.5.4. CRL се актуализират по-рядко, отколкото сертифициращият орган ги издава.
Y5.5.5. Решението за доверие на електронния подпис се взема преди получаването на OCSP отговора за статуса на сертификата, изпратен по заявка, направена по-късно от времето за генериране на подписа или по-рано от следващата след получаване на подписването на CRL.
Обяснения Y5.5.5.
В наредбите на повечето УО за време на анулиране на сертификата се счита моментът на издаване на най-близкия CRL, съдържащ информация за анулирането на сертификата.
U5.5.6. При получаване на подписани данни, собствеността на сертификата от подателя не се проверява.
Обяснения Y5.5.6.
Пример за атака. За SSL сертификати може да не провери дали адресът на извикания сървър съвпада със стойността на полето CN в сертификата.
Пример за атака. Нападателите са компрометирали ключовете за електронен подпис на един от участниците в платежната система. След това те хакнаха мрежата на друг участник и от негово име изпратиха платежни документи, подписани с компрометирани ключове, до сървъра за сетълмент на платежната система. Ако сървърът анализира само доверие и не проверява за съответствие, тогава фалшивите документи ще се считат за легитимни.
U6. Погрешно приемане на електронни документи за изпълнение поради проблеми в организацията на електронния документооборот.
Разлагане
U6.1. Получаващата страна не открива дублиране на получени документи.
Обяснения Y6.1.
Пример за атака. Злоумишлениците могат да прихванат документа, прехвърлен на получателя, дори ако е криптографски защитен, и след това многократно да го изпращат до защитения канал за предаване на данни. Ако получателят не открие дубликати, всички получени документи ще бъдат възприети и обработени като различни документи.
U7. Неоторизиран достъп до защитени данни при обработката им от CIPF
Разлагане
U7.1. <…> поради изтичане на информация през канали на трети страни (атака на страничен канал).
Обяснения Y7.1.
Пример .
U7.2. <...> поради неутрализиране на защитата срещу неоторизиран достъп до информация, обработвана на CIPF:
Y7.2.1. Работа на CIPF с нарушения на изискванията, описани в документацията за CIPF.
Y7.2.2. <…> внедрено поради наличието на уязвимости в:
Y7.2.2.1. <…> средства за защита срещу неоторизиран достъп.
Y7.2.2.2. <…> самата CIPF.
Y7.2.2.3. <...> средата за функциониране на криптографския инструмент.
Примери за атака
Разгледаните по-долу сценарии очевидно съдържат грешки в организацията на информационната сигурност и служат само за илюстрация на възможни атаки.
Сценарий 1. Пример за внедряване на заплахи U2.2 и U4.2.
Описание на обекта
Софтуерът ARM KBR и CIPF SCAD Signature са инсталирани на физически компютър, който не е свързан към компютърна мрежа. FKN vdToken се използва като ключов носител в режим на работа с невъзстановим ключ.
Регламентът за сетълмент предполага, че специалистът по сетълмента от работния си компютър изтегля електронни съобщения в чист текст (схемата на стария KBR AWS) от специален защитен файлов сървър, след което ги записва на сменяемо USB флаш устройство и ги прехвърля в KBR AWP , където са криптирани и знаци. След това специалистът прехвърля защитени електронни съобщения на преносим носител и след това чрез работния си компютър ги записва на файлов сървър, откъдето те стигат до UTA и след това до платежната система на Банката на Русия.
В този случай каналите за обмен на отворени и защитени данни ще включват: файлов сървър, работен компютър на специалист и преносим носител.
атака
Неупълномощени нападатели инсталират система за дистанционно управление на работния компютър на специалиста и в момента на записване на платежни нареждания (електронни съобщения) на преносимия носител, открито заменят съдържанието на едно от тях. Специалистът прехвърля платежните нареждания в AWS на KBR, подписва ги и ги криптира, без да забележи подмяната (например поради големия брой платежни нареждания в полета, умора и др.). След това фалшивото платежно нареждане, преминавайки през технологичната верига, влиза в платежната система на Банката на Русия.
Сценарий 2. Пример за внедряване на заплахи U2.2 и U4.2.
Описание на обекта
Компютърът с инсталираните AWS KBR, SKAD Signature и свързания ключов носител на FKN vdToken работи в специално помещение без достъп от персонала.
Специалистът по сетълмент се свързва към AWS на KBR в режим на отдалечен достъп чрез протокола RDP.
атака
Нападателите прихващат детайлите, чрез които специалистът по сетълмент се свързва и работи с автоматизираното работно място на KBR (например поради злонамерен код на неговия компютър). След това се свързват от негово име и изпращат фалшиво платежно нареждане към платежната система на Банката на Русия.
Сценарий 3. Пример за изпълнение на заплахата U1.3.
Описание на обекта
Нека разгледаме една от хипотетичните опции за внедряване на модули за интеграция на ABS-KBR за новата схема (ARM KBR-N), при която електронният подпис на изходящите документи се извършва от страната на ABS. В същото време ще приемем, че ABS работи на базата на операционна система, която не се поддържа от CIPF SKAD Signature, и съответно криптографската функционалност е поставена на отделна виртуална машина - интеграционния модул ABS-CBR .
Като ключов носител се използва обикновен USB токен, работещ в режим на сменяем ключ. Когато ключовият носител беше свързан към хипервайзора, се оказа, че в системата няма свободни USB портове, така че беше решено USB токенът да се свърже през мрежов USB хъб и да се инсталира USB-over-IP клиент на виртуална машина, която ще комуникира с хъба.
атака
Нападателите са прихванали частния ключ на електронния подпис от комуникационния канал между USB хъба и хипервайзора (данните се предават в чист текст). Разполагайки с частен ключ, нападателите генерират фалшиво платежно нареждане, подписват го с електронен подпис и го изпращат на автоматизираното работно място KBR-N за изпълнение.
Сценарий 4. Пример за внедряване на заплахи U5.5.
Описание на обекта
Помислете за същата верига като в предишния сценарий. Ще приемем, че имейлите, идващи от работната станция KBR-N, завършват в папката …SHAREIn, а тези, които се изпращат до работната станция KBR-N и след това към платежната система на Банката на Русия, отиват в …SHAREout.
Ще приемем също, че при внедряването на модула за интеграция, списъците с отменени сертификати се актуализират само когато криптографските ключове са преиздадени, както и че електронните съобщения, получени в папката …SHAREIn, се проверяват само за контрол на целостта и контрол на доверието към публичния ключ на електронния подпис.
атака
Нападателите, използвайки ключовете, откраднати в предишния сценарий, подписаха фалшиво платежно нареждане, съдържащо информация за получаването на пари по сметката на клиент измама и го въведоха в защитен канал за обмен на данни. Тъй като няма проверка дали платежното нареждане е подписано от Банката на Русия, то се приема за изпълнение.
Източник: www.habr.com