Odnośniki do innych części badania
- (Jesteś tutaj)
Niniejszy artykuł zamyka cykl publikacji poświęconych zapewnieniu bezpieczeństwa informacji w bankowych płatnościach bezgotówkowych. Tutaj omówimy standardowe modele zagrożeń, na które powoływano się w :
- .
- .
- .
- .
HABRO-WARNING !!! Szanowni członkowie Habr, to nie jest post rozrywkowy.
Zamknięte pod katem 40+ stron materiałów mają na celu pomoc w pracy lub nauce osobom specjalizującym się w bankowości lub zapewnieniu bezpieczeństwa informacji. Materiały te stanowią końcowy produkt badania i są napisane w formalnym tonie. W zasadzie są to szkice do wewnętrznych dokumentów dotyczących bezpieczeństwa informacji.No i tradycyjnie — „Wykorzystanie informacji z artykułu w celach niezgodnych z prawem jest ścigane zgodnie z prawem”. Życzliwego czytania!
Informacja dla czytelników, którzy zapoznają się z badaniem, zaczynając od tej publikacji.
Temat badania
Czytasz przewodnik dla specjalisty odpowiedzialnego za zapewnienie bezpieczeństwa płatności w banku.
Logika przedstawienia
Na początku w i zawarte jest opisanie obiektu ochrony. Następnie w Opowiedziano, jak zbudować system ochrony oraz o potrzebie stworzenia modelu zagrożeń. W opisano, jakie są modele zagrożeń i jak je generują. W i przedstawiono analizę rzeczywistych ataków. i zawierają opis modelu zagrożeń, stworzonego z uwzględnieniem danych z wszystkich poprzednich części.
TYPOWY MODEL ZAGROŻEŃ. POŁĄCZENIE SIECIOWE
Obiekt ochrony, dla którego stosowany jest model zagrożeń (scope)
Obiektem ochrony są dane przekazywane przez połączenie sieciowe, działające w sieciach przesyłu danych zbudowanych na podstawie stosu TCP/IP.
Architektura
Opis elementów architektury:
- „Węzły końcowe” — węzły wymieniające się chronionymi informacjami.
- „Węzły pośrednie” — elementy sieci przesyłowej: routery, przełączniki, serwery dostępu, serwery proxy i inne urządzenia, przez które przekazywany jest ruch połączenia sieciowego. W ogólnym przypadku połączenie sieciowe może działać bez węzłów pośrednich (bezpośrednio między końcowymi węzłami).
Zagrożenia bezpieczeństwa z najwyższego poziomu
Dekompzycja
Z1. Nieautoryzowany dostęp do przekazywanych danych.
Z2. Nieautoryzowana modyfikacja przekazywanych danych.
Z3. Naruszenie praw autorskich przekazywanych danych.
Z1. Nieautoryzowany dostęp do przekazywanych danych
Dekompzycja
Z1.1. , realizowane na węzłach końcowych lub pośrednich:
Z1.1.1. poprzez odczytywanie danych, gdy znajdują się w pamięci urządzenia węzła:
Z1.1.1.1. w pamięci operacyjnej.
Wyjaśnienia do Z1.1.1.1.
Na przykład, podczas przetwarzania danych przez stos sieciowy węzła.
Z1.1.1.2. w pamięci nieulotnej.
Wyjaśnienia do Z1.1.1.2.
Na przykład, podczas przechowywania przekazywanych danych w pamięci podręcznej, plikach tymczasowych lub plikach wymiany.
Z1.2. , realizowane na zewnętrznych węzłach sieci przesyłowej:
Z1.2.1. metodą przechwytywania wszystkich pakietów trafiających do interfejsu sieciowego węzła:
Wyjaśnienia do Z1.2.1.
Przechwytywanie wszystkich pakietów odbywa się poprzez przestawienie karty sieciowej w tryb promiscuous (tryb nieporządkujący dla adapterów przewodowych lub w tryb monitorowania dla adapterów Wi-Fi).
Z1.2.2. poprzez przeprowadzanie ataków typu „człowiek w środku (MiTM)”, ale bez modyfikacji przekazywanych danych (poza danymi serwisowymi protokołów sieciowych).
Z1.2.2.1. Link: .
U1.3. , realizowane na skutek wycieku informacji przez kanały techniczne (TKU) z fizycznych węzłów lub linii komunikacyjnych.
U1.4. , realizowane przez instalację na końcowych lub pośrednich węzłach specjalnych środków technicznych (STC), przeznaczonych do niejawnego pozyskiwania informacji.
U2. Nieautoryzowana modyfikacja przesyłanych danych
Dekompzycja
U2.1. , realizowana na końcowych lub pośrednich węzłach:
U2.1.1. poprzez odczyt i wprowadzanie zmian w danych w trakcie ich przechowywania w pamięciach węzłów:
U2.1.1.1. w pamięci operacyjnej:
U2.1.1.2. w pamięci nieulotnej:
U2.2. , realizowana na zewnętrznych węzłach sieci przesyłowej:
U2.2.1. poprzez przeprowadzanie ataków typu „człowiek pośrodku (MiTM)” i przekierowywanie ruchu do węzła napastników:
U2.2.1.1. Fizyczne podłączenie sprzętu napastników w miejsce przerwania połączenia sieciowego.
U2.2.1.2. Realizacja ataków na protokoły sieciowe:
U2.2.1.2.1. zarządzania wirtualnymi lokalnymi sieciami (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Nieautoryzowana modyfikacja ustawień VLAN na przełącznikach lub routerach.
U2.2.1.2.2. routingu ruchu:
U2.2.1.2.2.1. Nieautoryzowana modyfikacja tabel statycznego routingu routerów.
U2.2.1.2.2.2. Ogłaszanie przez napastników fałszywych tras przez protokoły dynamicznego routingu.
U2.2.1.2.3. automatycznego konfigurowania:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. adresowania i rozwiązywania nazw:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Wprowadzenie nieautoryzowanych zmian w lokalnych plikach nazw węzłów (hosts, lmhosts itp.)
U3. Naruszenie autorstwa przesyłanych danych
Dekompzycja
U3.1. Neutralizacja mechanizmów ustalania autorstwa informacji poprzez podanie fałszywych danych o autorze lub źródle danych:
U3.1.1. Zmiana danych o autorze zawartych w przesyłanej informacji.
U3.1.1.1. Neutralizacja kryptograficznej ochrony integralności i autorstwa przesyłanych danych:
U3.1.1.1.1. Odnośnik: .
U3.1.1.2. Neutralizacja ochrony praw autorskich dotyczącej przesyłanych danych realizowanej za pomocą jednorazowych kodów potwierdzenia:
U3.1.1.2.1. .
U3.1.2. Zmiana informacji o źródle przesyłanych danych:
U3.1.2.1. .
U3.1.2.2. .
TYPOWY MODEL ZAGROŻENIA. SYSTEM INFORMACYJNY OPARTY NA ARCHITEKTURZE KLIENT-SERWER
Obiekt ochrony, dla którego stosowany jest model zagrożeń (scope)
Obiektem ochrony jest system informacyjny oparty na architekturze klient-serwer.
Architektura
Opis elementów architektury:
- „Klient” – urządzenie, na którym działa część kliencka systemu informacyjnego.
- „Serwer” – urządzenie, na którym działa część serwerowa systemu informacyjnego.
- „Magazyn danych” — część infrastruktury serwerowej systemu informacyjnego przeznaczona do przechowywania danych przetwarzanych przez system informacyjny.
- „Połączenie sieciowe” — kanał wymiany informacji między Klientem a Serwerem, przechodzący przez sieć transmisji danych. Bardziej szczegółowy opis modelu elementu przedstawiono w .
Ograniczenia
Podczas modelowania obiektu ustalono następujące ograniczenia:
- Użytkownik wchodzi w interakcję z systemem informacyjnym w ramach końcowych przedziałów czasowych, nazywanych sesjami pracy.
- Na początku każdej sesji pracy następuje identyfikacja, autoryzacja i uwierzytelnienie użytkownika.
- Wszystkie chronione informacje przechowywane są na serwerowej części systemu informacyjnego.
Zagrożenia bezpieczeństwa z najwyższego poziomu
Dekompzycja
U1. Działania nieautoryzowane przez przestępców w imieniu legalnego użytkownika.
U2. Nieautoryzowana modyfikacja chronionych informacji podczas ich przetwarzania przez serwerową część systemu informacyjnego.
U1. Działania nieautoryzowane przez przestępców w imieniu legalnego użytkownika
Wyjaśnienia
Zwykle w systemach informacyjnych przyporządkowanie działań do zrealizowanego przez nie użytkownika odbywa się za pomocą:
- dzienników pracy systemu (logs).
- specjalnych atrybutów obiektów danych, zawierających informacje o użytkowniku, który je utworzył lub zmienił.
W odniesieniu do sesji pracy to zagrożenie można dekomponować na:
- wykonane w ramach sesji pracy użytkownika.
- wykonane poza sesją pracy użytkownika.
Sesja pracy użytkownika może być inicjowana przez:
- Samego użytkownika.
- Przestępców.
Na tym etapie, pośrednia dekompozycja tego zagrożenia będzie wyglądać następująco:
U1.1. Działania nieautoryzowane zostały dokonane w ramach sesji pracy użytkownika:
U1.1.1. <…>, zainstalowanego przez zaatakowanego użytkownika.
U1.1.2. <…>, zainstalowanego przez przestępców.
U1.2. Działania nieautoryzowane zostały dokonane poza sesją pracy użytkownika.
Z punktu widzenia obiektów infrastruktury informacyjnej, na które mogą wpływać przestępcy, dekompozycja pośrednich zagrożeń będzie wyglądać następująco:
Elementy
Dekompzycja zagrożeń
U1.1.1.
U1.1.2.
U1.2.
Klient
U1.1.1.1.
U1.1.2.1.
Połączenie sieciowe
U1.1.1.2.
Serwer
U1.2.1.
Dekompzycja
U1.1. Działania nieautoryzowane zostały dokonane w ramach sesji pracy użytkownika:
U1.1.1. <…>, zainstalowanego przez zaatakowanego użytkownika:
U1.1.1.1. Przestępcy działali z Klienta:
U1.1.1.1.1 Przestępcy użyli standardowych narzędzi dostępu do systemu informacyjnego:
U1.1.1.1.1.1. Przestępcy użyli fizycznych urządzeń wejścia-wyjścia Klienta (klawiatura, mysz, monitor lub ekran dotykowy urządzenia mobilnego):
U1.1.1.1.1.1.1. Przestępcy działali w okresach czasu, gdy sesja była aktywna, urządzenia wejścia-wyjścia były dostępne, a użytkownika nie było w pobliżu.
U1.1.1.1.1.2. Przestępcy użyli narzędzi zdalnego zarządzania (standardowych lub dostarczonych przez złośliwy kod) do zarządzania Klientem:
U1.1.1.1.1.2.1. Przestępcy działali w okresach czasu, gdy sesja była aktywna, urządzenia wejścia-wyjścia były dostępne, a użytkownika nie było w pobliżu.
U1.1.1.1.1.2.2. Przestępcy użyli narzędzi zdalnego zarządzania, których działanie było niezauważalne dla zaatakowanego użytkownika.
U1.1.1.2. Przestępcy zmieniali dane w połączeniu sieciowym między Klientem a Serwerem, modyfikując je w taki sposób, aby były postrzegane jako działania legalnego użytkownika:
U1.1.1.2.1. Link: .
U1.1.1.3. Przestępcy zmusili użytkownika do wykonania wskazanych przez nich działań, stosując metody inżynierii społecznej.
U1.1.2 <…> zainstalowanego przez przestępców:
U1.1.2.1. Przestępcy działali z Klienta (I):
U1.1.2.1.1. Przestępcy zneutralizowali system kontroli dostępu do systemu informacyjnego:
U1.1.2.1.1.1. Link: .
U1.1.2.1.2. Hakerzy wykorzystali standardowe środki dostępu do systemu informacji
U1.1.2.2. Hakerzy działali z innych węzłów sieci przesyłu danych, z których można nawiązać połączenie sieciowe z Serwerem (I):
U1.1.2.2.1. Hakerzy zneutralizowali system kontroli dostępu do systemu informacji:
U1.1.2.2.1.1. Link: .
U1.1.2.2.2. Hakerzy wykorzystali nietypowe środki dostępu do systemu informacji.
Wyjaśnienia U1.1.2.2.2.
Hakerzy mogli zainstalować standardowego klienta systemu informacji na zewnętrznym węźle lub mogli użyć nietypowego oprogramowania realizującego standardowe protokoły wymiany między Klientem a Serwerem.
U1.2 Nieautoryzowane działania zostały wykonane poza sesją pracy użytkownika.
U1.2.1 Hakerzy wykonali nieautoryzowane działania, a następnie wprowadzili nieautoryzowane zmiany w dziennikach pracy systemu informacji lub specjalnych atrybutach obiektów danych, wskazując, że ich działania zostały wykonane przez legalnego użytkownika.
U2. Nieautoryzowana modyfikacja chronionych informacji podczas ich przetwarzania przez serwer systemu informacji
Dekompzycja
U2.1. Hakerzy modyfikują chronione informacje za pomocą standardowych środków systemu informacji i dokonują tego w imieniu legalnego użytkownika.
U2.1.1. Link: .
U2.2. Hakerzy modyfikują chronione informacje, wykorzystując mechanizmy dostępu do danych, które nie są przewidziane przez standardowy tryb działania systemu informacji.
U2.2.1. Hakerzy modyfikują pliki zawierające chronione informacje:
U2.2.1.1. , używając mechanizmów pracy z plikami udostępnianych przez system operacyjny.
U2.2.1.2. poprzez wywołanie przywracania plików z nieautoryzowanej modyfikowanej kopii zapasowej.
U2.2.2. Hakerzy modyfikują chronione informacje przechowywane w bazie danych (I):
U2.2.2.1. Napastnicy neutralizują system kontroli dostępu bazy danych.
U2.2.2.1.1. Link: .
U2.2.2.2. Napastnicy modyfikują informacje, wykorzystując standardowe interfejsy bazy danych do dostępu do danych.
U2.3. Napastnicy modyfikują chronione informacje poprzez nieautoryzowaną modyfikację algorytmów działania przetwarzającego je oprogramowania.
U2.3.1. Modyfikowane jest źródłowe kody oprogramowania.
U2.3.1. Modyfikowany jest kod maszynowy oprogramowania.
U2.4. Napastnicy modyfikują chronione informacje, wykorzystując luki w oprogramowaniu systemu informacyjnego.
U2.5. Napastnicy modyfikują chronione informacje podczas ich przesyłania pomiędzy komponentami serwera systemu informacyjnego (na przykład serwerem bazy danych i serwerem aplikacji):
U2.5.1. Link: .
TYPOWY MODEL ZAGROŻENIA. SYSTEM KONTROLI DOSTĘPU
Obiekt ochrony, dla którego stosowany jest model zagrożeń (scope)
Obiekt ochrony, dla którego stosuje się ten model zagrożeń, odpowiada obiektowi ochrony modelu zagrożeń: „Typowy model zagrożeń. System informacyjny oparty na architekturze klient-serwer”.
Pod systemem kontroli dostępu użytkowników w tym modelu zagrożeń rozumie się komponent systemu informacyjnego, który realizuje funkcje:
- Identyfikacji użytkowników.
- Uwierzytelniania użytkowników.
- Autoryzacji użytkowników.
- Protokolowania działań użytkowników.
Zagrożenia bezpieczeństwa z najwyższego poziomu
Dekompzycja
U1. Nieautoryzowane nawiązanie sesji pracy w imieniu legalnego użytkownika.
U2. Nieautoryzowane podniesienie uprawnień użytkownika w systemie informacyjnym.
U1. Nieautoryzowane nawiązanie sesji pracy w imieniu legalnego użytkownika.
Wyjaśnienia
Dekompozycja tego zagrożenia w ogólnym przypadku będzie zależeć od zastosowanego typu systemów identyfikacji i uwierzytelniania użytkowników.
W tym modelu rozważana będzie tylko system identyfikacji i uwierzytelniania użytkowników, wykorzystujący tekstowy login i hasło. Przyjmujemy, że login użytkownika to informacja ogólnodostępna, znana napastnikom.
Dekompzycja
U1.1. poprzez kompromitację danych uwierzytelniających:
U1.1.1. Napastnicy skompromitowali dane uwierzytelniające użytkownika w trakcie ich przechowywania.
Wyjaśnienia U1.1.1.
Na przykład, dane uwierzytelniające mogły być zapisane na karteczce, przyklejonej do monitora.
U1.1.2. Użytkownik przypadkowo lub umyślnie przekazał dane dostępowe osobom trzecim.
U1.1.2.1. Użytkownik głośno mówił swoje dane logowania podczas ich wprowadzania.
U1.1.2.2. Użytkownik celowo przekazał swoje dane logowania:
U1.1.2.2.1. współpracownikom.
Wyjaśnienia U1.1.2.2.1.
Na przykład, aby mogli je zastąpić w czasie nieobecności z powodu choroby.
U1.1.2.2.2. kontrahentom pracodawcy, wykonującym prace nad obiektami infrastruktury informacyjnej.
U1.1.2.2.3. osobom trzecim.
Wyjaśnienia U1.1.2.2.3.
Jednym, ale nie jedynym sposobem realizacji tego zagrożenia, jest wykorzystanie przez cyberprzestępców metod inżynierii społecznej.
U1.1.3. Cyberprzestępcy odgadli dane logowania metodą prób i błędów:
U1.1.3.1. przy użyciu standardowych mechanizmów dostępu.
U1.1.3.2. na podstawie wcześniej przechwyconych kodów (na przykład, haseł przechowywanych w postaci skrótów).
U1.1.4. Cyberprzestępcy wykorzystali złośliwy kod do przechwytywania danych logowania użytkownika.
U1.1.5. Cyberprzestępcy wykradli dane logowania z połączenia sieciowego między Klientem a Serwerem:
U1.1.5.1. Łącze: .
U1.1.6. Cyberprzestępcy wykradli dane logowania z zapisów systemów monitorujących pracę:
U1.1.6.1. systemów monitoringu wideo (jeśli podczas pracy rejestrowano naciśnięcia klawiszy na klawiaturze).
U1.1.6.2. systemów kontroli działań pracowników przy komputerze.
Wyjaśnienia U1.1.6.2.
Przykładem takiego systemu jest — .
U1.1.7. Cyberprzestępcy skompromitowali dane logowania użytkownika z powodu niedociągnięć w procesie ich transmisji.
Wyjaśnienia U1.1.7.
Na przykład, przesyłanie haseł w otwartej formie przez e-mail.
U1.1.8. Cyberprzestępcy poznali dane logowania poprzez obserwację sesji pracy użytkownika za pomocą systemów zdalnego zarządzania.
U1.1.9. Cyberprzestępcy wykradli dane logowania w wyniku ich wycieku przez kanały techniczne (TKUI):
U1.1.9.1. Cyberprzestępcy podglądali, jak użytkownik wprowadza dane logowania z klawiatury:
U1.1.9.1.1 Cyberprzestępcy znajdowali się w bliskim sąsiedztwie użytkownika i na własne oczy widzieli, jak wprowadza dane logowania.
Wyjaśnienia U1.1.9.1.1
Do takich sytuacji można zaliczyć działania współpracowników lub przypadek, gdy klawiatura użytkownika jest widoczna dla odwiedzających organizację.
U1.1.9.1.2 Hakerzy korzystali z dodatkowych środków technicznych, takich jak lornetka lub dron, i dostrzegli wprowadzanie danych logowania przez okno.
U1.1.9.2. Hakerzy wyodrębnili dane logowania z zapisów transmisji radiowej między klawiaturą a jednostką systemową komputera w przypadku podłączenia ich przez interfejs radiowy (np. Bluetooth).
U1.1.9.3. Hakerzy przechwycili dane logowania dzięki ich wyciekowi przez kanał bocznych emisji elektromagnetycznych i zakłóceń (PEM).
Wyjaśnienia U1.1.9.3.
Przykłady ataków i .
U1.1.9.4. Haker przechwycił dane logowania z klawiatury, korzystając z specjalnych środków technicznych (STC), przeznaczonych do niejawnego zbierania informacji.
Wyjaśnienia U1.1.9.4.
Przykłady .
U1.1.9.5. Hakerzy przechwycili dane logowania z klawiatury dzięki
analizie sygnału Wi-Fi, modulowanego procesem naciskania klawiszy przez użytkownika.
Wyjaśnienia U1.1.9.5.
Przykład .
U1.1.9.6. Hakerzy przechwycili dane logowania z klawiatury, analizując dźwięki naciskania klawiszy.
Wyjaśnienia U1.1.9.6.
Przykład .
U1.1.9.7. Hakerzy przechwycili dane logowania z klawiatury urządzenia mobilnego, analizując odczyty z akcelerometru.
Wyjaśnienia U1.1.9.7.
Przykład .
U1.1.10. , wcześniej zapisanych u Klienta.
Wyjaśnienia U1.1.10.
Na przykład użytkownik mógł zapisać w przeglądarce login i hasło do określonej strony internetowej.
U1.1.11. Hakerzy skompromitowali dane logowania z powodu wad procesu wycofywania dostępu użytkowników.
Wyjaśnienia U1.1.11.
Na przykład po zwolnieniu użytkownika jego konta pozostały odblokowane.
U1.2. dzięki wykorzystaniu luk w systemie kontroli dostępu.
U2. Nieautoryzowane podwyższenie uprawnień użytkownika w systemie informacyjnym
Dekompzycja
U2.1 poprzez wprowadzenie nieautoryzowanych zmian w danych dotyczących uprawnień użytkownika.
U2.2 dzięki wykorzystaniu luk w systemie kontroli dostępu.
U2.3. z powodu wad procesu zarządzania dostępem użytkowników.
Wyjaśnienia U2.3.
Przykład 1. Użytkownikowi przyznano dostęp większy, niż to było konieczne do celów służbowych.
Przykład 2. Po przeniesieniu użytkownika na inne stanowisko wcześniej przyznane uprawnienia nie zostały cofnięte.
TYPOWY MODELOWY ZAGROŻENI. MODUŁ INTEGRACJI
Obiekt ochrony, dla którego stosowany jest model zagrożeń (scope)
Moduł integracji to zestaw obiektów infrastruktury informacyjnej przeznaczonych do organizacji wymiany informacji między systemami informacyjnymi.
Biorąc pod uwagę fakt, że w sieciach korporacyjnych nie zawsze można jednoznacznie oddzielić jeden system informacyjny od drugiego, moduł integracji można traktować także jako ogniwo łączące komponenty w ramach jednego systemu informacyjnego.
Architektura
Zarys ogólny modułu integracji wygląda następująco:
Opis elementów architektury:
- «Serwer wymiany (SW)» – węzeł / usługa / komponent systemu informacyjnego, wykonujący funkcję wymiany danych z innym systemem informacyjnym.
- «Mediator» – węzeł / usługa, przeznaczona do organizacji interakcji pomiędzy systemami informacyjnymi, ale nie będąca ich częścią.
Przykłady «Mediatorów» to usługi poczty elektronicznej, przedsiębiorcze szyny usług (enterprise service bus / architektura SoA), zewnętrzne serwery plików itp. W ogólnym przypadku moduł integracji może nie zawierać «Mediatorów». - «Oprogramowanie do przetwarzania danych» – zbiór programów realizujących protokoły wymiany danych oraz konwersję formatów.
Na przykład, konwersja danych z formatu UFEBS do formatu ABS, zmiana statusów wiadomości w trakcie przesyłania itp. - „Połączenie sieciowe” odpowiada obiektowi opisanym w typowym modelu zagrożeń «Połączenie sieciowe». Niektórych połączeń sieciowych z tych przedstawionych na powyższym schemacie może nie być.
Przykłady modułów integracji
Schemat 1. Integracja ABS i ARM KBR poprzez zewnętrzny serwer plików
Aby zrealizować płatności, upoważniony pracownik banku eksportuje z ABS elektroniczne dokumenty płatnicze i zapisuje je w pliku (własnym formacie, np. zrzut SQL) na folderze sieciowym (…SHARE) serwera plików. Następnie ten plik za pomocą skryptu konwertującego jest przekształcany w zestaw plików formatu UFEBS, które następnie odczytuje ARM KBR.
Po tym upoważniony pracownik — użytkownik ARM KBR — szyfruje i podpisuje otrzymany plik, a następnie przesyła go do systemu płatności Banku Rosji.
Po otrzymaniu płatności z Banku Rosji ARM KBR dokonuje ich deszyfrowania oraz weryfikacji podpisu elektronicznego, a następnie zapisuje w postaci zbioru plików formatu UFEBS na serwerze plików. Przed importem dokumentów płatniczych do ABS są one konwertowane za pomocą skryptu-konwertera z formatu UFEBS na format ABS.
Zakładamy, że w tej schemie ABS działa na jednym fizycznym serwerze, ARM KBR działa na dedykowanym komputerze, a skrypt-konwerter pracuje na serwerze plików.
Zgodność obiektów przedstawionej schemy z elementami modelu modułu integracji:
«Serwery wymiany po stronie ABS» – serwer ABS.
«Serwery wymiany po stronie ARM KBR» – komputer ARM KBR.
«Mediator» – zewnętrzny serwer plików.
«Oprogramowanie do przetwarzania danych» – skrypt-konwerter.
Schemat 2. Integracja ABS i ARM KBR przy umieszczaniu wspólnego folderu sieciowego z płatnościami na ARM KBR
Wszystko tak samo jak w Schemacie 1, ale nie jest używany oddzielny serwer plików, zamiast tego wspólny folder (…SHARE) z elektronicznymi dokumentami płatniczymi jest umieszczany na komputerze z ARM KBR. Skrypt-konwerter również działa na ARM KBR.
Zgodność obiektów przedstawionej schemy z elementami modelu modułu integracji:
Podobnie jak w Schemacie 1, ale «Mediator» nie jest używany.
Schemat 3. Integracja ABS i ARM KBR-N przez IBM WebSphere MQ oraz realizacja podpisu elektronicznych dokumentów "po stronie ABS"
ABS działa na platformie, która nie jest wspierana przez SKZI SKAD Podpis. Podpis wychodzących dokumentów elektronicznych przeprowadzany jest na specjalnym serwerze podpisu elektronicznego (Serwer EP). Ten sam serwer weryfikuje podpis elektroniczny dokumentów przychodzących z Banku Rosji.
ABS przesyła na Serwer EP plik z dokumentami płatniczymi w swoim formacie.
Serwer EP za pomocą skryptu-konwertera przekształca plik w elektroniczne wiadomości formatu UFEBS, po czym wiadomości elektroniczne są podpisywane i przesyłane na IBM WebSphere MQ.
ARM KBR-N zwraca się do IBM WebSphere MQ i otrzymuje stamtąd podpisane wiadomości płatnicze, po czym upoważniony pracownik — użytkownik ARM KBR — je szyfruje i przesyła do systemu płatności Banku Rosji.
Po otrzymaniu płatności z Banku Rosji, AРМ KБP-Н deszyfruje je i weryfikuje podpis elektroniczny. Prawidłowo przetworzone płatności w postaci deszyfrowanych i podpisanych wiadomości elektronicznych formatu УФЭБС są przesyłane do IBM WebSphere MQ, skąd odbiera je Serwer EП.
Serwer EП weryfikuje podpis elektroniczny otrzymanych płatności i zapisuje je w pliku formatu АБС. Następnie upoważniony pracownik — użytkownik АБС — w odpowiedni sposób ładuje otrzymany plik do АБС.
Zgodność obiektów przedstawionej schemy z elementami modelu modułu integracji:
„Serwer wymiany ze strony АБС” – serwer ABS.
„Serwer wymiany ze strony AРМ KБP” — komputer AРМ KБP.
«Mediator» – Serwer EП i IBM WebSphere MQ.
«Oprogramowanie do przetwarzania danych» – skrypt-konwerter, СКЗИ СКАД Сигнатура na Serwerze EП.
Schemat 4. Integracja Serwera ДБО i АБС przez API udostępniane przez dedykowany serwer wymiany
Zakładamy, że w banku używane są różne systemy zdalnego bankowości (ДБО):
- „Internet Klient-Bank” dla osób fizycznych (ИКБ ФЛ);
- „Internet Klient-Bank” dla osób prawnych (ИКБ ЮЛ).
W trosce o bezpieczeństwo informacji, całe interakcje АБС z systemami ДБО odbywają się przez dedykowany serwer wymiany, działający w ramach systemu informacyjnego „АБС”.
Następnie omówimy proces interakcji systemu ДБО ИКБ ЮЛ z АБС.
Serwer ДБО, po otrzymaniu od klienta właściwie uwierzytelnionego polecenia płatniczego, powinien na jego podstawie stworzyć odpowiedni dokument w АБС. W tym celu przesyła informacje do serwera wymiany za pomocą API, a ten z kolei wprowadza dane do АБС.
Przy zmianie sald na koncie klienta, АБС generuje elektroniczne powiadomienia, które za pomocą serwera wymiany są przesyłane do serwera ДБО.
Zgodność obiektów przedstawionej schemy z elementami modelu modułu integracji:
„Serwer wymiany ze strony ДБО” – serwer ДБО ИКБ ЮЛ.
„Serwer wymiany ze strony АБС” – serwer wymiany.
«Mediator» – brak.
«Oprogramowanie do przetwarzania danych» – komponenty Serwera ДБО odpowiedzialne za korzystanie z API serwera wymiany, komponenty serwera wymiany odpowiedzialne za korzystanie z API АБС.
Zagrożenia bezpieczeństwa z najwyższego poziomu
Dekompzycja
У1. Wprowadzenie fałszywych informacji przez moduł integracji przez osoby nieuprawnione.
У1. Wprowadzenie fałszywych informacji przez moduł integracji przez osoby nieuprawnione.
Dekompzycja
У1.1. Nieautoryzowana modyfikacja legalnych danych podczas ich przesyłania przez połączenia sieciowe:
У1.1.1 Link: .
У1.2. Przesyłanie fałszywych danych w imieniu legalnego uczestnika wymiany:
У1.1.2 Link: .
U1.3. Nieautoryzowana modyfikacja legalnych danych podczas ich przetwarzania na Serwerach wymiany lub Pośredniku:
U1.3.1. Link: .
U1.4. Tworzenie na Serwerach wymiany lub Pośredniku fałszywych danych w imieniu legalnego uczestnika wymiany:
U1.4.1. Link:
U1.5. Nieautoryzowana modyfikacja danych podczas ich przetwarzania za pomocą oprogramowania do przetwarzania danych:
U1.5.1. poprzez wprowadzenie przez przestępców nieautoryzowanych zmian w ustawieniach (konfiguracji) oprogramowania do przetwarzania danych.
U1.5.2. poprzez wprowadzenie przez przestępców nieautoryzowanych zmian w plikach wykonywalnych oprogramowania do przetwarzania danych.
U1.5.3. poprzez interaktywne zarządzanie pracą oprogramowania do przetwarzania danych przez przestępców.
TYPOWY MODEL ZAGROŻEŃ. SYSTEM KRYPTOGRAFICZNEJ OCHRONY INFORMACJI
Obiekt ochrony, dla którego stosowany jest model zagrożeń (scope)
Obiektem ochrony jest system kryptograficznej ochrony informacji, wykorzystywany do zapewnienia bezpieczeństwa systemu informacyjnego.
Architektura
Podstawą każdego systemu informacyjnego jest oprogramowanie aplikacyjne (AP), które realizuje jego funkcjonalność.
Kryptograficzna ochrona jest zazwyczaj realizowana poprzez wywołanie z logiki biznesowej aplikacyjnego oprogramowania kryptograficznych prymitywów, umieszczanych w specjalizowanych bibliotekach – rdzeniach kryptograficznych.
Do kryptograficznych prymitywów należą niskopoziomowe funkcje kryptograficzne, takie jak:
- szyfrowanie / deszyfrowanie bloku danych;
- tworzenie / weryfikacja elektronicznego podpisu bloku danych;
- obliczanie funkcji haszującej bloku danych;
- formowanie / załadowanie / wyładowanie informacji o kluczu;
- itd.
Logika biznesowa aplikacyjnego oprogramowania przy pomocy kryptograficznych prymitywów realizuje bardziej zaawansowaną funkcjonalność:
- szyfrowanie pliku na kluczach wybranych odbiorców;
- zainstalować bezpieczne połączenie sieciowe;
- informować o wynikach weryfikacji podpisu elektronicznego;
- itd.
Interakcja logiki biznesowej i kryptokernela może odbywać się:
- bezpośrednio, poprzez wywołanie przez logikę biznesową prymitywów kryptograficznych z dynamicznych bibliotek kryptokernela (.DLL – dla Windows, .SO – dla Linux);
- pośrednio, przez kryptograficzne interfejsy – opakowania (wrappers), na przykład MS Crypto API, Java Cryptography Architecture, PKCS#11 itp. W takim przypadku logika biznesowa odwołuje się do interfejsu kryptograficznego, a ten przekazuje wywołanie do odpowiedniego kryptokernela, który w takim przypadku nazywa się dostawcą kryptografii. Użycie interfejsów kryptograficznych umożliwia aplikacjom abstrahowanie od konkretnych algorytmów kryptograficznych i zwiększa elastyczność.
Można wyróżnić dwa typowe schematy organizacji kryptokernela:
Schemat 1 – Monolityczny kryptokernel
Schemat 2 – Podzielony kryptokernel
Elementy na przedstawionych schematach mogą być zarówno oddzielnymi modułami oprogramowania działającymi na jednym komputerze, jak i usługami sieciowymi, które współdziałają w ramach sieci obliczeniowej.
W przypadku systemów zbudowanych według schematu 1, oprogramowanie aplikacyjne i kryptokernel działają w ramach jednego środowiska funkcjonowania kryptoproductu (SFK), na przykład na tym samym komputerze, zarządzanym przez ten sam system operacyjny. Użytkownik systemu zazwyczaj może uruchamiać w ramach tego samego środowiska funkcjonowania inne programy, w tym te zawierające złośliwy kod. W takich warunkach istnieje poważne ryzyko wycieku poufnych kluczy kryptograficznych.
Aby zminimalizować ryzyko, stosuje się schemat 2, w którym kryptokernel dzieli się na dwie części:
- Pierwsza część razem z oprogramowaniem aplikacyjnym działa w niezaufanym środowisku, gdzie istnieje ryzyko zakażenia złośliwym kodem. Nazwijmy tę część – „częścią programową”.
- Druga część działa w zaufanym środowisku na dedykowanym urządzeniu, które zawiera w sobie magazyn kluczy prywatnych. Nazwijmy tę część – „częścią sprzętową”.
Podział rdzenia kryptograficznego na część programową i sprzętową jest dość umowny. Na rynku są systemy zbudowane na schemacie z podzielonym rdzeniem kryptograficznym, gdzie "część sprzętowa" przedstawiona jest w postaci obrazu maszyny wirtualnej — virtual HSM ().
Interakcja obu części rdzenia kryptograficznego przebiega w ten sposób, że klucze kryptograficzne nigdy nie są przekazywane do części programowej i, odpowiednio, nie mogą być skradzione za pomocą złośliwego oprogramowania.
Interfejs interakcji (API) oraz zestaw zasad kryptograficznych dostarczanych przez rdzeń kryptograficzny do aplikacji są w obu przypadkach takie same. Różnica tkwi w sposobie ich realizacji.
Tak więc, przy użyciu schematu z podzielonym rdzeniem kryptograficznym, interakcja części programowej i sprzętowej odbywa się według następującej zasady:
- Zasady kryptograficzne, które nie wymagają użycia klucza prywatnego (np. obliczanie funkcji skrótu, weryfikacja podpisu elektronicznego itd.), są realizowane przez część programową.
- Zasady kryptograficzne, które wykorzystują klucz prywatny (tworzenie podpisu elektronicznego, deszyfrowanie danych itd.), są realizowane przez część sprzętową.
Ilustrujemy działanie podzielonego rdzenia kryptograficznego na przykładzie tworzenia podpisu elektronicznego:
- Część programowa oblicza funkcję skrótu podpisywanych danych i przesyła tę wartość do części sprzętowej za pośrednictwem kanału wymiany między rdzeniami kryptograficznymi.
- Część sprzętowa, używając klucza prywatnego i funkcji skrótu, tworzy wartość podpisu elektronicznego i przesyła ją z powrotem do części programowej przez kanał wymiany.
- Część programowa zwraca otrzymaną wartość do aplikacji.
Cechy weryfikacji poprawności podpisu elektronicznego
Gdy strona odbierająca otrzyma dane podpisane podpisem elektronicznym, musi przeprowadzić kilka etapów weryfikacji. Pozytywny wynik weryfikacji podpisu elektronicznego jest osiągany tylko po pomyślnym zakończeniu wszystkich etapów sprawdzania.
Etap 1. Kontrola integralności danych i autorstwa danych.
Treść etapu. Przeprowadzana jest weryfikacja podpisu elektronicznego danych zgodnie z odpowiednim algorytmem kryptograficznym. Pomyślne przejście tego etapu oznacza, że dane nie zostały zmodyfikowane od momentu ich podpisania, jak również, że podpis został wykonany kluczem prywatnym, odpowiadającym kluczowi publicznemu weryfikacji podpisu elektronicznego.
Miejsce realizacji etapu: kryptojądro.
Etap 2. Kontrola zaufania do klucza publicznego podpisującego i kontrola okresu ważności klucza prywatnego podpisu elektronicznego.
Treść etapu. Etap składa się z dwóch podetapów. W pierwszym ustala się, czy klucz publiczny weryfikacji podpisu elektronicznego był zaufany w momencie podpisania danych. W drugim ustala się, czy klucz prywatny podpisu elektronicznego był ważny w momencie podpisania danych. W ogólnym przypadku okresy ważności tych kluczy mogą się nie pokrywać (na przykład w przypadku kwalifikowanych certyfikatów kluczy weryfikacji podpisu elektronicznego). Sposoby ustalania zaufania do klucza publicznego podpisującego określają zasady elektronicznego obiegu dokumentów, przyjęte przez współdziałające strony.
Miejsce realizacji etapu: oprogramowanie aplikacyjne / kryptojądro.
Etap 3. Kontrola uprawnień podpisującego.
Treść etapu. Zgodnie z ustalonymi zasadami elektronicznego obiegu dokumentów sprawdza się, czy podpisujący miał prawo poświadczać chronione dane. Na przykład rozważmy sytuację naruszenia uprawnień. Załóżmy, że istnieje organizacja, w której wszyscy pracownicy mają podpis elektroniczny. Do wewnętrznego systemu elektronicznego obiegu dokumentów przychodzi polecenie kierownika, ale podpisane podpisem elektronicznym przez kierownika magazynu. W związku z tym taki dokument nie może być uznany za legitymacyjny.
Miejsce realizacji etapu: oprogramowanie aplikacyjne.
Założenia przyjęte podczas opisu obiektu ochrony
- Kanały transmisji informacji, z wyjątkiem kanałów wymiany kluczy, również przechodzą przez oprogramowanie aplikacyjne, API i kryptojądro.
- Informacje o zaufaniu do kluczy publicznych i (lub) certyfikatów, a także informacje o uprawnieniach posiadaczy kluczy publicznych, są umieszczane w magazynie kluczy publicznych.
- Oprogramowanie aplikacyjne współpracuje z magazynem kluczy publicznych za pośrednictwem kryptojądra.
Przykład systemu informacyjnego chronionego za pomocą SKZI
Aby zilustrować wcześniej przedstawione schematy, omówmy hipotetyczny system informacyjny i wyróżnijmy wszystkie jego elementy strukturalne.
Opis systemu informacyjnego
Dwie organizacje zdecydowały się wprowadzić między sobą prawnie wiążący elektroniczny obieg dokumentów (EOD). W tym celu podpisały umowę, w której określiły, że dokumenty będą przesyłane pocztą elektroniczną, a przy tym muszą być zaszyfrowane i podpisane kwalifikowanym podpisem elektronicznym. Jako środki do tworzenia i przetwarzania dokumentów powinny być używane programy biurowe z pakietu Microsoft Office 2016, a jako środki ochrony kryptograficznej — Szyfrowanie KryptoPRO oraz Oprogramowanie szyfrujące KryptoARM.
Opis infrastruktury organizacji 1
Organizacja 1 postanowiła, że zainstaluje Szyfrowanie KryptoPRO i Oprogramowanie KryptoARM na Abennecie użytkownika — fizycznym komputerze. Klucze szyfrujące i podpisu elektronicznego będą przechowywane na nośniku klucza ruToken, działającym w trybie wyjmowanego klucza. Użytkownik będzie lokalnie przygotowywał elektroniczne dokumenty na swoim komputerze, po czym będzie je szyfrował, podpisywał i wysyłał za pomocą lokalnie zainstalowanego klienta poczty.
Opis infrastruktury organizacji 2
Organizacja 2 postanowiła przenieść funkcje szyfrowania i podpisu elektronicznego na dedykowaną maszynę wirtualną. W tym przypadku wszystkie operacje kryptograficzne będą przeprowadzane w trybie automatycznym.
W tym celu na dedykowanej maszynie wirtualnej utworzono dwa foldery sieciowe: „…In”, „…Out”. Do folderu sieciowego „…In” będą automatycznie umieszczane pliki otrzymane od kontrahenta w otwartej formie. Te pliki będą deszyfrowane, a ich podpis elektroniczny będzie weryfikowany.
Do folderu „…Out” użytkownik będzie umieszczał pliki, które należy zaszyfrować, podpisać i wysłać do kontrahenta. Sam użytkownik będzie przygotowywał pliki na swoim Abennecie.
Aby wykonać funkcje szyfrowania i podpisu elektronicznego, na maszyny wirtualne zainstalowano Szyfrowanie KryptoPRO, Oprogramowanie KryptoARM oraz klienta poczty. Automatyczne zarządzanie wszystkimi elementami maszyny wirtualnej będzie realizowane za pomocą skryptów, opracowanych przez administratorów systemu. Praca skryptów będzie protokołowana w plikach dzienników (logs).
Klucze kryptograficzne podpisu elektronicznego będą umieszczane na tokenie z niewydobywalnym kluczem JaCarta GOST, który użytkownik będzie podłączać do swojego lokalnego komputera.
Token będzie przesyłany na maszynę wirtualną za pomocą specjalistycznych narzędzi programowych USB-over-IP zainstalowanych na stanowisku roboczym użytkownika oraz na maszynie wirtualnej.
Zegar systemowy na stanowisku roboczym użytkownika w organizacji 1 będzie calibratowany ręcznie. Zegar systemowy specjalistycznej maszyny wirtualnej w organizacji 2 będzie synchronizowany z zegarem systemowym hyperwizora, który z kolei będzie synchronizowany przez Internet z publicznymi serwerami czasu.
Wydzielenie elementów strukturalnych SKZI
Na podstawie powyższego opisu infrastruktury IT wydzielimy elementy strukturalne SKZI i zapiszemy je w tabeli.
Tabela — Zgodność elementów modelu SKZI z elementami systemów informacyjnych
Nazwa elementu
Organizacja 1
Organizacja 2
Oprogramowanie aplikacyjne
Oprogramowanie CryptoARM
Oprogramowanie CryptoARM
Część programowa kryptojądra
SKZI CryptoPRO CSP
SKZI CryptoPRO CSP
Część sprzętowa kryptojądra
nie istnieje
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Magazyn kluczy publicznych
Stanowisko robocze użytkownika:
— dysk twardy;
— standardowy magazyn certyfikatów Windows.
Hyperwizor:
— dysk twardy.
Maszyna wirtualna:
— dysk twardy;
— standardowy magazyn certyfikatów Windows.
Magazyn kluczy prywatnych
Nośnik kluczy ruToken, pracujący w trybie wydobywalnego klucza
Nośnik kluczy JaCarta GOST, pracujący w trybie niewydobywalnego klucza
Kanał wymiany kluczy publicznych
Stanowisko robocze użytkownika:
— pamięć operacyjna.
Hyperwizor:
— pamięć operacyjna.
Maszyna wirtualna:
— pamięć operacyjna.
Kanał wymiany kluczy prywatnych
Stanowisko robocze użytkownika:
— magistrala USB;
— pamięć operacyjna.
nie istnieje
Kanał wymiany między kryptojądrem
brak (brak części sprzętowej kryptojądra)
Stanowisko robocze użytkownika:
— magistrala USB;
— pamięć operacyjna;
— moduł programowy USB-over-IP;
— interfejs sieciowy.
Sieć korporacyjna organizacji 2.
Hyperwizor:
— pamięć operacyjna;
— interfejs sieciowy.
Maszyna wirtualna:
— interfejs sieciowy;
— pamięć operacyjna;
— moduł programowy USB-over-IP.
Kanał wymiany danych publicznych
Stanowisko robocze użytkownika:
— urządzenia wejścia/wyjścia;
— pamięć operacyjna;
— dysk twardy.
Stanowisko robocze użytkownika:
— urządzenia wejścia/wyjścia;
— pamięć operacyjna;
— dysk twardy;
— interfejs sieciowy.
Sieć korporacyjna organizacji 2.
Hyperwizor:
— interfejs sieciowy;
— pamięć operacyjna;
— dysk twardy.
Maszyna wirtualna:
— interfejs sieciowy;
— pamięć operacyjna;
— dysk twardy.
Kanał wymiany danych zabezpieczonych
Internet.
Sieć korporacyjna organizacji 1.
Stanowisko robocze użytkownika:
— dysk twardy;
— pamięć operacyjna;
— interfejs sieciowy.
Internet.
Sieć korporacyjna organizacji 2.
Hyperwizor:
— interfejs sieciowy;
— pamięć operacyjna;
— dysk twardy.
Maszyna wirtualna:
— interfejs sieciowy;
— pamięć operacyjna;
— dysk twardy.
Kanał transmisji czasu
Stanowisko robocze użytkownika:
— urządzenia wejścia/wyjścia;
— pamięć operacyjna;
— timer systemowy.
Internet.
Sieć korporacyjna organizacji 2,
Hyperwizor:
— interfejs sieciowy;
— pamięć operacyjna;
— timer systemowy.
Maszyna wirtualna:
— pamięć operacyjna;
— timer systemowy.
Kanał transmisji poleceń sterujących
Stanowisko robocze użytkownika:
— urządzenia wejścia/wyjścia;
— pamięć operacyjna.
(Graficzny interfejs użytkownika oprogramowania CryptoARM)
Maszyna wirtualna:
— pamięć operacyjna;
— dysk twardy.
(Skrypty automatyzacji)
Kanał odbioru wyników pracy
Stanowisko robocze użytkownika:
— urządzenia wejścia/wyjścia;
— pamięć operacyjna.
(Graficzny interfejs użytkownika oprogramowania CryptoARM)
Maszyna wirtualna:
— pamięć operacyjna;
— dysk twardy.
(Pliki dzienników pracy skryptów automatyzacji)
Zagrożenia bezpieczeństwa z najwyższego poziomu
Wyjaśnienia
Założenia przyjęte przy dekompozycji zagrożeń:
- Wykorzystywane są trwałe algorytmy kryptograficzne.
- Algorytmy kryptograficzne są stosowane w sposób bezpieczny w odpowiednich trybach działania (na przykład, nie jest stosowany do szyfrowania dużych ilości danych, uwzględnia się dopuszczalne obciążenie klucza itd.).
- Przestępcy znają wszystkie stosowane algorytmy, protokoły i klucze publiczne.
- Przestępcy mają dostęp do wszystkich zaszyfrowanych danych.
- Przestępcy mogą odtworzyć wszelkie elementy oprogramowania w systemie.
Dekompzycja
U1. Kompromitacja tajnych kluczy kryptograficznych.
U2. Szyfrowanie fałszywych danych w imieniu autoryzowanego nadawcy.
U3. Deszyfrowanie zaszyfrowanych danych przez osoby, które nie są autoryzowanymi odbiorcami danych (przestępców).
U4. Tworzenie podpisu elektronicznego autoryzowanego podpisującego na fałszywych danych.
U5. Uzyskanie pozytywnego wyniku weryfikacji podpisu elektronicznego fałszywych danych.
U6. Błędne zaakceptowanie dokumentów elektronicznych do realizacji z powodu problemów w organizacji obiegu dokumentów elektronicznych.
U7. Nieautoryzowany dostęp do chronionych danych podczas ich przetwarzania przez SKZI.
U1. Kompromitacja tajnych kluczy kryptograficznych
U1.1. Uzyskanie klucza prywatnego z magazynu kluczy prywatnych.
U1.2. Uzyskanie klucza prywatnego z obiektów środowiska działania środka kryptograficznego, w którym może on tymczasowo przebywać.
Wyjaśnienia U1.2.
Do obiektów, w których klucz prywatny może być tymczasowo przechowywany, będą należeć:
- pamięć operacyjna,
- pliki tymczasowe,
- pliki stron,
- pliki hibernacji,
- pliki zrzutów «gorącego» stanu maszyn wirtualnych, w tym pliki zawartości pamięci operacyjnej maszyn wirtualnych, które zostały wstrzymane.
U1.2.1. Wydobycie kluczy prywatnych z działającej pamięci operacyjnej poprzez zamrożenie modułów RAM, ich wydobycie i następne odczytanie danych (freeze attack).
Wyjaśnienia U1.2.1.
Przykład .
U1.3. Uzyskanie klucza prywatnego z kanału wymiany kluczy prywatnych.
Wyjaśnienia U1.3.
Przykład realizacji tego zagrożenia zostanie podany .
U1.4. Nieautoryzowana modyfikacja kryptonukleusza, w wyniku której klucze prywatne stają się znane przestępcom.
U1.5. Kompromitacja klucza prywatnego w wyniku wykorzystania technicznych kanałów wycieku informacji (TKUI).
Wyjaśnienia U1.5.
Przykład .
U1.6. Kompromitacja klucza prywatnego w wyniku użycia specjalnych środków technicznych (STK) przeznaczonych do niejawnego pozyskiwania informacji („pluskwy”).
U1.7. Kompromitacja kluczy prywatnych w trakcie ich przechowywania poza SKZI.
Wyjaśnienia U1.7.
Na przykład użytkownik przechowuje swoje nośniki kluczowe w szufladzie biurka, z której mogą być łatwo wydobyte przez przestępców.
U2. Szyfrowanie podrobionych danych w imieniu legalnego nadawcy.
Wyjaśnienia
Zagrożenie to rozpatrywane jest tylko w kontekście schematów szyfrowania danych z uwierzytelnieniem nadawcy. Przykłady takich schematów podano w zaleceniach dotyczących standardyzacji. . Dla pozostałych schematów kryptograficznych to zagrożenie nie istnieje, ponieważ szyfrowanie odbywa się na otwartych kluczach odbiorcy, które w ogólności są znane przestępcom.
Dekompzycja
U2.1. Kompromitacja klucza publicznego nadawcy:
U2.1.1. Link: .
U2.2. Podmiana danych wejściowych w kanale wymiany otwartych danych.
Uwagi U2.2.
Przykłady realizacji tego zagrożenia przedstawiono poniżej. i .
U3. Deszyfrowanie zaszyfrowanych danych przez osoby niebędące legalnymi odbiorcami danych (przestępcami).
Dekompzycja
U3.1. Kompromitacja kluczy prywatnych odbiorcy zaszyfrowanych danych.
U3.1.1 Link: .
U3.2. Podmiana zaszyfrowanych danych w kanale wymiany chronionych danych.
U4. Tworzenie podpisu elektronicznego przez legalnego sygnatariusza na podrobionych danych.
Dekompzycja
U4.1. Kompromitacja kluczy prywatnych elektronicznego podpisu legalnego sygnatariusza.
U4.1.1 Link: .
U4.2. Podmiana danych podpisywanych w kanale wymiany otwartych danych.
Uwagi U4.2.
Przykłady realizacji tego zagrożenia przedstawiono poniżej. i .
U5. Uzyskanie pozytywnego wyniku weryfikacji podpisu elektronicznego podrobionych danych.
Dekompzycja
U5.1. Atakujący przechwytują w kanale transmisji wyniki pracy wiadomość o negatywnym wyniku weryfikacji podpisu elektronicznego i zastępują ją wiadomością z pozytywnym wynikiem.
U5.2. Atakujący prowadzą atak na zaufanie do certyfikatów podpisu (SCENARIUSZ — wszystkie elementy są obowiązkowe):
U5.2.1. Atakujący generują parę kluczy publiczny i prywatny podpisu elektronicznego. Jeśli w systemie stosowane są certyfikaty kluczy podpisu elektronicznego, generują certyfikat podpisu elektronicznego jak najbardziej przypominający certyfikat domniemanego nadawcy danych, którego wiadomość chcą podrobić.
U5.2.2. Atakujący wprowadzają nieautoryzowane zmiany do repozytorium kluczy publicznych, nadając wygenerowanemu przez siebie kluczowi wymagany poziom zaufania i uprawnienia.
U5.2.3. Atakujący podpisują fałszywe dane wcześniej utworzonym kluczem podpisu elektronicznego i wprowadzają je do kanału wymiany chronionych danych.
U5.3. Atakujący przeprowadzają atak za pomocą przestarzałych kluczy podpisu elektronicznego legalnego nadawcy (SCENARIUSZ — wszystkie elementy są obowiązkowe):
U5.3.1. Atakujący kompromitują przestarzałe (niedziałające na ten moment) klucze prywatne podpisu elektronicznego legalnego nadawcy.
U5.3.2. Atakujący zastępują czas w kanale transmisji czasem, w którym skompromitowane klucze były jeszcze ważne.
U5.3.3. Atakujący podpisują fałszywe dane wcześniej skompromitowanym kluczem podpisu elektronicznego i wprowadzają je do kanału wymiany chronionych danych.
U5.4. Atakujący przeprowadzają atak za pomocą skompromitowanych kluczy podpisu elektronicznego legalnego nadawcy (SCENARIUSZ — wszystkie elementy są obowiązkowe):
U5.4.1. Atakujący wykonują kopię repozytorium kluczy publicznych.
U5.4.2. Atakujący kompromitują klucze prywatne jednego z legalnych nadawców. Ten zauważa kompromitację, odwołuje klucze, a informacje o odwołaniu klucza umieszczane są w repozytorium kluczy publicznych.
U5.4.3. Atakujący zastępują repozytorium kluczy publicznych wcześniej skopiowanym.
U5.4.4. Atakujący podpisują fałszywe dane wcześniej skompromitowanym kluczem podpisu elektronicznego i wprowadzają je do kanału wymiany chronionych danych.
U5.5. z powodu występowania błędów w realizacji 2. i 3. etapu weryfikacji podpisu elektronicznego:
Wyjaśnienia U5.5.
Przykład realizacji tego zagrożenia został przedstawiony .
U5.5.1. Weryfikacja zaufania do certyfikatu klucza podpisu elektronicznego tylko na podstawie zaufania do certyfikatu, którym został podpisany, bez sprawdzania CRL lub OCSP.
Wyjaśnienia U5.5.1.
Przykład realizacji .
U5.5.2. Przy budowaniu łańcucha zaufania do certyfikatu nie analizowane są uprawnienia certyfikatów wydających
Wyjaśnienia U5.5.2.
Przykład ataku na certyfikaty SSL/TLS.
Atakujący zakupili legitymację certyfikatu dla swojego e-maila. Następnie stworzyli fałszywy certyfikat strony i podpisali go swoim certyfikatem. Jeśli nie będzie przeprowadzona weryfikacja uprawnień, to podczas weryfikacji łańcucha zaufania okaże się on poprawny, a więc również fałszywy certyfikat będzie uznany za poprawny.
U5.5.3. Przy budowaniu łańcucha zaufania do certyfikatu nie sprawdzają się certyfikaty pośrednie pod kątem odwołania.
U5.5.4. Aktualizacja CRL odbywa się rzadziej niż ich wydawanie przez centrum certyfikacji.
U5.5.5. Decyzja o zaufaniu do podpisu elektronicznego podejmowana jest wcześniej, niż uzyskano odpowiedź OCSP o statusie certyfikatu, przekazaną w wyniku żądania złożonego po czasie utworzenia podpisu lub wcześniej, niż uzyskano następne po utworzeniu podpisu CRL.
Wyjaśnienia U5.5.5.
W regulacjach większości UŻ czas odwołania certyfikatu uznawany jest za czas wydania najbliższego CRL, zawierającego informacje o odwołaniu certyfikatu.
U5.5.6. Przy odbieraniu podpisanych danych nie sprawdzana jest przynależność certyfikatu do nadawcy.
Wyjaśnienia U5.5.6.
Przykład ataku. W kontekście certyfikatów SSL: może nie być sprawdzana zgodność adresu wywoływanego serwera z wartością pola CN w certyfikacie.
Przykład ataku. Atakujący skompromitowali klucze podpisu elektronicznego jednego z uczestników systemu płatności. Następnie włamać się do sieci innego uczestnika i w jego imieniu przesłali na serwer rozliczeniowy dokumenty płatnicze, podpisane skompromitowanymi kluczami. Jeśli serwer analizuje tylko zaufanie i nie sprawdza zgodności, to fałszywe dokumenty będą uważane za legitymne.
U6. Błędne zaakceptowanie dokumentów elektronicznych do realizacji z powodu problemów w organizacji obiegu dokumentów elektronicznych.
Dekompzycja
U6.1. Strona przyjmująca nie wykrywa duplikacji otrzymywanych dokumentów.
Wyjaśnienia U6.1.
Przykład ataku. Cyberprzestępcy mogą przechwycić dokument przesyłany do odbiorcy, nawet jeśli jest on kryptograficznie chroniony, a następnie wielokrotnie wysyłać go w kanale przesyłania chronionych danych. Jeśli odbiorca nie wykrywa duplikatów, wszystkie odbierane dokumenty będą traktowane i przetwarzane jako różne dokumenty.
U7. Nieautoryzowane zapoznanie się z chronionymi danymi podczas ich przetwarzania przez SCZK.
Dekompzycja
U7.1. w wyniku wycieku informacji przez zewnętrzne kanały (atak boczny).
Wyjaśnienia U7.1.
Przykład .
U7.2. w wyniku neutralizacji ochrony przed nieautoryzowanym dostępem do informacji przetwarzanej w SCZK:
U7.2.1. Eksploatacja SCZK z naruszeniem wymagań opisanych w dokumentacji SCZK.
U7.2.2. , dokonana z uwagi na obecność luk w:
U7.2.2.1. środkach ochrony przed nieautoryzowanym dostępem.
U7.2.2.2. samej SCZK.
U7.2.2.3. środowisku funkcjonowania kryptosystemu.
Przykłady ataków
Poniżej omówione scenariusze z założenia zawierają błędy w organizacji bezpieczeństwa informacji i służą tylko do ilustrowania możliwych ataków.
Scenariusz 1. Przykład realizacji zagrożeń U2.2 i U4.2.
Opis obiektu
Oprogramowanie APM KBR i SCZK SKAD jest zainstalowane na fizycznym komputerze, który nie jest podłączony do sieci obliczeniowej. Jako nośnik klucza używany jest FKN vdToken w trybie pracy z nieodwracalnym kluczem.
Regulamin realizacji obliczeń zakłada, że specjalista ds. obliczeń ściąga elektroniczne wiadomości w otwartej formie (schemat starego APM KBR) z specjalnego zabezpieczonego serwera plików, a następnie zapisuje je na nośniku USB i przenosi na APM KBR, gdzie je szyfruje i podpisuje. Po tym specjalista przenosi na nośnik zabezpieczone elektroniczne wiadomości, a następnie przez swój komputer roboczy przesyła je na serwer plików, skąd trafiają do UTA, a następnie do systemu płatności Banku Rosji.
W tym przypadku kanały wymiany otwartych i zabezpieczonych danych będą obejmować: serwer plików, komputer roboczy specjalisty i nośnik wymienny.
Atak
Oszuści nieautoryzowanie instalują na komputerze roboczym specjalisty system zdalnego zarządzania i w trakcie zapisu na nośnik wymienny poleceń płatniczych (wiadomości elektronicznych) w otwartym formacie podmienią treść jednego z nich. Specjalista przenosi polecenia płatnicze do APM KBR, podpisuje je i szyfruje, nie zauważając podmiany (na przykład z powodu dużej liczby poleceń płatniczych, zmęczenia itp.). Następnie fałszywe polecenie płatnicze, przechodząc przez łańcuch technologiczny, trafia do systemu płatniczego Banku Rosji.
Scenariusz 2. Przykład realizacji zagrożeń U2.2 i U4.2.
Opis obiektu
Komputer z zainstalowanym APM KBR, SCADA Sygnatura i podłączonym nośnikiem klucza FKN vdToken działa w wydzielonym pomieszczeniu bez dostępu ze strony personelu.
Specjalista ds. rozliczeń łączy się z APM KBR w trybie zdalnym przez protokół RDP.
Atak
Oszuści przechwytują dane, używając których specjalista ds. rozliczeń nawiązuje połączenie i pracuje z APM KBR (na przykład dzięki złośliwemu kodowi na jego komputerze). Następnie nawiązują połączenie w jego imieniu i wysyłają fałszywe polecenie płatnicze do systemu płatniczego Banku Rosji.
Scenariusz 3. Przykład realizacji zagrożenia U1.3.
Opis obiektu
Rozważmy jeden z hipotetycznych wariantów realizacji modułów integracji „ABS-KBR” dla nowego schematu (APM KBR-N), w którym elektroniczny podpis wychodzących dokumentów jest realizowany po stronie ABS. Przy tym zakładamy, że ABS działa na bazie systemu operacyjnego, który nie jest wspierany przez SKZI SCADA Sygnatura, a tym samym funkcjonalność kryptograficzna została przeniesiona na oddzielną maszynę wirtualną — moduł integracji „ABS-KBR”.
Jako nośnik klucza używany jest zwykły token USB, działający w trybie odłączanego klucza. Przy podłączeniu nośnika klucza do hypervisora okazało się, że w systemie nie ma wolnych portów USB, dlatego postanowiono podłączyć token USB przez sieciowy koncentrator USB, a na maszynie wirtualnej zainstalować klienta USB-over-IP, który będzie nawiązywał połączenie z koncentratorem.
Atak
Cybercriminals intercepted the private key of the electronic signature from the communication channel between the USB hub and the hypervisor (data was transmitted in plain text). With the private key, the criminals formed a forged payment order, signed it with an electronic signature, and sent it to the KBR-N workstation for execution.
Scenario 4. An example of the implementation of threats U5.5.
Opis obiektu
Let's consider the same scheme as in the previous scenario. We will assume that electronic messages coming from the KBR-N workstation go into the folder …SHAREIn, while those sent to the KBR-N workstation and then to the Bank of Russia’s payment system go into …SHAREout.
We will also assume that when implementing the integration module, the lists of revoked certificates are updated only upon reissue of cryptographic keys, and that electronic messages received in the folder …SHAREIn are checked only for integrity control and trust verification of the public key of the electronic signature.
Atak
Cybercriminals, utilizing the keys stolen in the previous scenario, signed a forged payment order containing information about the receipt of funds into the account of a fraudulent client and injected it into the secure data exchange channel. Since there is no verification that the payment order is indeed signed by the Bank of Russia, it is accepted for execution.
Źródło: habr.com
