Linki do innych części badania
- (Jesteś tu)
Artykuł ten zamyka cykl publikacji poświęconych zapewnieniu bezpieczeństwa informacji w bankowych płatnościach bezgotówkowych. W tym miejscu przyjrzymy się typowym modelom zagrożeń, o których mowa w :
- .
- .
- .
- .
HABRO-UWAGA!!! Drodzy Khabrovity, to nie jest zabawny post.
Służy temu ponad 40 stron materiałów ukrytych pod wycięciem pomoc w pracy lub nauce osoby specjalizujące się w bankowości lub bezpieczeństwie informacji. Materiały te stanowią końcowy produkt badań i są napisane suchym, formalnym tonem. Zasadniczo są to puste miejsca na dokumenty dotyczące wewnętrznego bezpieczeństwa informacji.Cóż, tradycyjne - „wykorzystanie informacji zawartych w artykule do celów niezgodnych z prawem jest karalne”. Produktywna lektura!
Informacja dla czytelników zapoznających się z badaniem rozpoczynającym się od niniejszej publikacji.
O czym jest badanie?
Czytasz poradnik dla specjalisty odpowiedzialnego za zapewnienie bezpieczeństwa informacji w zakresie płatności w banku.
Logika prezentacji
Na początku w и podany jest opis chronionego obiektu. Następnie w opisuje, jak zbudować system bezpieczeństwa i mówi o konieczności stworzenia modelu zagrożenia. W mówi o tym, jakie modele zagrożeń istnieją i jak powstają. W и Przedstawiona jest analiza rzeczywistych ataków. и zawierać opis modelu zagrożenia, zbudowany z uwzględnieniem informacji ze wszystkich poprzednich części.
TYPOWY MODEL ZAGROŻENIA. POŁĄCZENIE INTERNETOWE
Obiekt ochrony, dla którego stosowany jest model zagrożenia (zakres).
Przedmiotem ochrony są dane przesyłane łączem sieciowym działającym w sieciach danych zbudowanych w oparciu o stos TCP/IP.
Architektura
Opis elementów architektonicznych:
- „Węzły końcowe” — węzły wymieniające chronione informacje.
- „Węzły pośrednie” — elementy sieci transmisji danych: routery, przełączniki, serwery dostępowe, serwery proxy i inny sprzęt — za pośrednictwem którego przesyłany jest ruch połączeń sieciowych. Generalnie połączenie sieciowe może funkcjonować bez węzłów pośrednich (bezpośrednio pomiędzy węzłami końcowymi).
Zagrożenia bezpieczeństwa najwyższego poziomu
Rozkład
U1. Nieautoryzowany dostęp do przesyłanych danych.
U2. Nieautoryzowana modyfikacja przesyłanych danych.
U3. Naruszenie autorstwa przesyłanych danych.
U1. Nieautoryzowany dostęp do przesyłanych danych
Rozkład
U1.1. <…>, prowadzone w węzłach końcowych lub pośrednich:
U1.1.1. <…> poprzez odczytanie danych znajdujących się na urządzeniach pamięci hosta:
U1.1.1.1. <…> w pamięci RAM.
Objaśnienia do U1.1.1.1.
Na przykład podczas przetwarzania danych przez stos sieciowy hosta.
U1.1.1.2. <…> w pamięci nieulotnej.
Objaśnienia do U1.1.1.2.
Na przykład podczas przechowywania przesyłanych danych w pamięci podręcznej, plikach tymczasowych lub plikach wymiany.
U1.2. <…>, realizowane na zewnętrznych węzłach sieci danych:
U1.2.1. <…> metodą przechwytywania wszystkich pakietów przychodzących do interfejsu sieciowego hosta:
Objaśnienia do U1.2.1.
Przechwytywanie wszystkich pakietów odbywa się poprzez przełączenie karty sieciowej w tryb rozwiązły (tryb rozwiązły w przypadku adapterów przewodowych lub tryb monitorowania w przypadku adapterów Wi-Fi).
U1.2.2. <…> poprzez przeprowadzanie ataków typu man-in-the-middle (MiTM), ale bez modyfikowania przesyłanych danych (nie licząc danych usługi protokołu sieciowego).
U1.2.2.1. Połączyć: .
U1.3. <…>, przeprowadzone w związku z wyciekiem informacji kanałami technicznymi (TKUI) z węzłów fizycznych lub linii komunikacyjnych.
U1.4. <…>, realizowany poprzez zainstalowanie specjalnych środków technicznych (STS) na węzłach końcowych lub pośrednich, przeznaczonych do tajnego gromadzenia informacji.
U2. Nieautoryzowana modyfikacja przesyłanych danych
Rozkład
U2.1. <…>, prowadzone w węzłach końcowych lub pośrednich:
U2.1.1. <…> odczytując i wprowadzając zmiany w danych znajdujących się na urządzeniach pamięci węzłów:
U2.1.1.1. <…> w pamięci RAM:
U2.1.1.2. <…> w pamięci nieulotnej:
U2.2. <…>, realizowane na zewnętrznych węzłach sieci transmisji danych:
U2.2.1. <…> przeprowadzając ataki typu man-in-the-middle (MiTM) i przekierowując ruch do węzła atakującego:
U2.2.1.1. Fizyczne podłączenie sprzętu atakującego powoduje zerwanie połączenia sieciowego.
U2.2.1.2. Przeprowadzanie ataków na protokoły sieciowe:
U2.2.1.2.1. <…> zarządzanie wirtualnymi sieciami lokalnymi (VLAN):
U2.2.1.2.1.1. .
U2.2.1.2.1.2. Nieautoryzowana modyfikacja ustawień sieci VLAN na przełącznikach lub routerach.
U2.2.1.2.2. <…> kierowanie ruchem:
U2.2.1.2.2.1. Nieautoryzowana modyfikacja statycznych tablic routingu routerów.
U2.2.1.2.2.2. Ogłaszanie fałszywych tras przez atakujących za pośrednictwem dynamicznych protokołów routingu.
U2.2.1.2.3. <…> konfiguracja automatyczna:
U2.2.1.2.3.1. .
U2.2.1.2.3.2. .
U2.2.1.2.4. <…> adresowanie i rozpoznawanie nazw:
U2.2.1.2.4.1. .
U2.2.1.2.4.2. .
U2.2.1.2.4.3. Dokonywanie nieautoryzowanych zmian w plikach nazw lokalnych hostów (hosts, lmhosts itp.)
U3. Naruszenie praw autorskich do przesyłanych danych
Rozkład
U3.1. Neutralizacja mechanizmów ustalania autorstwa informacji poprzez wskazanie fałszywych informacji o autorze lub źródle danych:
U3.1.1. Zmiana informacji o autorze zawartych w przesyłanych informacjach.
U3.1.1.1. Neutralizacja kryptograficznej ochrony integralności i autorstwa przesyłanych danych:
U3.1.1.1.1. Połączyć: .
U3.1.1.2. Neutralizacja ochrony autorskiej przesyłanych danych, realizowana za pomocą jednorazowych kodów potwierdzających:
U3.1.1.2.1. .
U3.1.2. Zmiana informacji o źródle przekazywanych informacji:
U3.1.2.1. .
U3.1.2.2. .
TYPOWY MODEL ZAGROŻENIA. SYSTEM INFORMATYCZNY ZBUDOWANY W BAZIE ARCHITEKTURY KLIENT-SERWER
Obiekt ochrony, dla którego stosowany jest model zagrożenia (zakres).
Przedmiotem ochrony jest system informatyczny zbudowany w oparciu o architekturę klient-serwer.
Architektura
Opis elementów architektonicznych:
- "Klient" – urządzenie, na którym działa część kliencka systemu informatycznego.
- "Serwer" – urządzenie, na którym działa część serwerowa systemu informatycznego.
- "Magazyn danych" — część infrastruktury serwerowej systemu informatycznego, przeznaczona do przechowywania danych przetwarzanych przez system informatyczny.
- "Połączenie internetowe" — kanał wymiany informacji pomiędzy Klientem a Serwerem przechodzący przez sieć danych. Bardziej szczegółowy opis modelu elementu znajduje się w .
Ograniczenia
Podczas modelowania obiektu ustawiane są następujące ograniczenia:
- Użytkownik wchodzi w interakcję z systemem informatycznym w skończonych okresach czasu, zwanych sesjami roboczymi.
- Na początku każdej sesji roboczej użytkownik jest identyfikowany, uwierzytelniany i autoryzowany.
- Wszystkie chronione informacje przechowywane są w serwerowej części systemu informatycznego.
Zagrożenia bezpieczeństwa najwyższego poziomu
Rozkład
U1. Wykonywanie nieautoryzowanych działań przez osoby atakujące w imieniu uprawnionego użytkownika.
U2. Nieuprawniona modyfikacja chronionych informacji podczas ich przetwarzania przez część serwerową systemu informatycznego.
U1. Wykonywanie nieautoryzowanych działań przez osoby atakujące w imieniu uprawnionego użytkownika
Objaśnienia
Zazwyczaj w systemach informatycznych działania są korelowane z użytkownikiem, który je wykonał, za pomocą:
- logi działania systemu (logi).
- specjalne atrybuty obiektów danych zawierające informacje o użytkowniku, który je utworzył lub zmodyfikował.
W odniesieniu do sesji roboczej zagrożenie to można podzielić na:
- <…> wykonywane w ramach sesji użytkownika.
- <…> wykonywany poza sesją użytkownika.
Sesję użytkownika można zainicjować:
- Przez samego użytkownika.
- Złoczyńcy.
Na tym etapie pośredni rozkład tego zagrożenia będzie wyglądał następująco:
U1.1. W sesji użytkownika wykonano nieautoryzowane działania:
U1.1.1. <…> zainstalowany przez zaatakowanego użytkownika.
U1.1.2. <…> zainstalowane przez atakujących.
U1.2. Poza sesją użytkownika wykonano nieautoryzowane działania.
Z punktu widzenia obiektów infrastruktury informatycznej, na które atakujący mogą mieć wpływ, rozkład zagrożeń pośrednich będzie wyglądał następująco:
Przedmioty
Rozkład zagrożenia
U1.1.1.
U1.1.2.
U1.2.
Klient
U1.1.1.1.
U1.1.2.1.
połączenie internetowe
U1.1.1.2.
Server
U1.2.1.
Rozkład
U1.1. W sesji użytkownika wykonano nieautoryzowane działania:
U1.1.1. <…> zainstalowany przez zaatakowanego użytkownika:
U1.1.1.1. Napastnicy działali niezależnie od Klienta:
U1.1.1.1.1 Napastnicy wykorzystali standardowe narzędzia dostępu do systemu informatycznego:
У1.1.1.1.1.1. Osoby atakujące wykorzystały fizyczne środki wejścia/wyjścia Klienta (klawiatura, mysz, monitor lub ekran dotykowy urządzenia mobilnego):
U1.1.1.1.1.1.1. Osoby atakujące działały w okresach, gdy sesja była aktywna, urządzenia we/wy były dostępne, a użytkownik nie był obecny.
У1.1.1.1.1.2. Napastnicy wykorzystali narzędzia do zdalnej administracji (standardowe lub dostarczane przez złośliwy kod) do zarządzania Klientem:
U1.1.1.1.1.2.1. Osoby atakujące działały w okresach, gdy sesja była aktywna, urządzenia we/wy były dostępne, a użytkownik nie był obecny.
У1.1.1.1.1.2.2. Napastnicy wykorzystali narzędzia zdalnej administracji, których działanie jest niewidoczne dla zaatakowanego użytkownika.
U1.1.1.2. Osoby atakujące podmieniały dane w połączeniu sieciowym pomiędzy Klientem a Serwerem, modyfikując je w taki sposób, aby można je było odebrać jako działania uprawnionego użytkownika:
U1.1.1.2.1. Połączyć: .
U1.1.1.3. Osoby atakujące zmusiły użytkownika do wykonania określonych przez siebie działań, wykorzystując metody socjotechniki.
У1.1.2 <…> zainstalowany przez atakujących:
U1.1.2.1. Napastnicy działali z poziomu Klienta (И):
U1.1.2.1.1. Napastnicy zneutralizowali system kontroli dostępu do systemu informatycznego:
U1.1.2.1.1.1. Połączyć: .
У1.1.2.1.2. Napastnicy wykorzystali standardowe narzędzia dostępu do systemów informatycznych
U1.1.2.2. Napastnicy operowali z innych węzłów sieci danych, z których można było nawiązać połączenie sieciowe z Serwerem (И):
U1.1.2.2.1. Napastnicy zneutralizowali system kontroli dostępu do systemu informatycznego:
U1.1.2.2.1.1. Połączyć: .
U1.1.2.2.2. Napastnicy wykorzystali niestandardowe sposoby uzyskania dostępu do systemu informatycznego.
Objaśnienia U1.1.2.2.2.
Osoby atakujące mogą zainstalować standardowego klienta systemu informatycznego na węźle strony trzeciej lub skorzystać z niestandardowego oprogramowania, które implementuje standardowe protokoły wymiany pomiędzy Klientem a Serwerem.
U1.2 Poza sesją użytkownika wykonano nieautoryzowane działania.
U1.2.1 Osoby atakujące dokonały nieautoryzowanych działań, a następnie dokonały nieautoryzowanych zmian w logach działania systemu informatycznego lub specjalnych atrybutach obiektów danych, wskazując, że wykonane przez nich działania zostały wykonane przez uprawnionego użytkownika.
U2. Nieuprawniona modyfikacja chronionych informacji podczas ich przetwarzania przez część serwerową systemu informatycznego
Rozkład
U2.1. Osoby atakujące modyfikują chronione informacje za pomocą standardowych narzędzi systemu informatycznego i robią to w imieniu uprawnionego użytkownika.
U2.1.1. Połączyć: .
U2.2. Osoby atakujące modyfikują chronione informacje, korzystając z mechanizmów dostępu do danych, których nie zapewnia normalne działanie systemu informatycznego.
U2.2.1. Osoby atakujące modyfikują pliki zawierające chronione informacje:
U2.2.1.1. <…>, korzystając z mechanizmów obsługi plików udostępnianych przez system operacyjny.
U2.2.1.2. <…> prowokując przywrócenie plików z nieautoryzowanej zmodyfikowanej kopii zapasowej.
U2.2.2. Osoby atakujące modyfikują chronione informacje przechowywane w bazie danych (И):
U2.2.2.1. Atakujący neutralizują system kontroli dostępu DBMS:
U2.2.2.1.1. Połączyć: .
U2.2.2.2. Osoby atakujące modyfikują informacje przy użyciu standardowych interfejsów DBMS w celu uzyskania dostępu do danych.
U2.3. Osoby atakujące modyfikują chronione informacje poprzez nieuprawnioną modyfikację algorytmów działania oprogramowania, które je przetwarza.
U2.3.1. Kod źródłowy oprogramowania podlega modyfikacjom.
U2.3.1. Kod maszynowy oprogramowania może podlegać modyfikacjom.
U2.4. Osoby atakujące modyfikują chronione informacje, wykorzystując luki w oprogramowaniu systemu informatycznego.
U2.5. Osoby atakujące modyfikują chronione informacje podczas ich przesyłania pomiędzy komponentami serwerowej części systemu informatycznego (na przykład serwerem bazy danych i serwerem aplikacji):
U2.5.1. Połączyć: .
TYPOWY MODEL ZAGROŻENIA. SYSTEM KONTROLI DOSTĘPU
Obiekt ochrony, dla którego stosowany jest model zagrożenia (zakres).
Obiekt ochrony, dla którego zastosowano ten model zagrożenia, odpowiada obiektowi ochrony modelu zagrożenia: „Typowy model zagrożenia. System informatyczny zbudowany w architekturze klient-serwer.”
W tym modelu zagrożenia system kontroli dostępu użytkowników oznacza komponent systemu informatycznego realizujący następujące funkcje:
- Identyfikacja użytkownika.
- Uwierzytelnianie użytkownika.
- Autoryzacje użytkowników.
- Rejestrowanie działań użytkownika.
Zagrożenia bezpieczeństwa najwyższego poziomu
Rozkład
U1. Nieautoryzowane ustanowienie sesji w imieniu uprawnionego użytkownika.
U2. Nieuprawnione zwiększenie uprawnień użytkownika w systemie informatycznym.
U1. Nieautoryzowane ustanowienie sesji w imieniu uprawnionego użytkownika
Objaśnienia
Rozkład tego zagrożenia będzie zasadniczo zależał od rodzaju stosowanych systemów identyfikacji i uwierzytelniania użytkowników.
W tym modelu pod uwagę brany będzie wyłącznie system identyfikacji i uwierzytelniania użytkownika za pomocą loginu tekstowego i hasła. W takim przypadku założymy, że login użytkownika jest informacją publicznie dostępną i znaną atakującym.
Rozkład
U1.1. <…> z powodu naruszenia bezpieczeństwa danych uwierzytelniających:
U1.1.1. Osoby atakujące naruszyły dane uwierzytelniające użytkownika podczas ich przechowywania.
Objaśnienia U1.1.1.
Na przykład dane uwierzytelniające można zapisać na karteczce samoprzylepnej przyklejonej do monitora.
U1.1.2. Użytkownik przypadkowo lub złośliwie przekazał atakującym dane dostępowe.
U1.1.2.1. Wchodząc, użytkownik wypowiedział na głos dane uwierzytelniające.
U1.1.2.2. Użytkownik celowo udostępnił swoje dane uwierzytelniające:
U1.1.2.2.1. <…> współpracownikom.
Objaśnienia U1.1.2.2.1.
Na przykład po to, aby móc go zastąpić w czasie choroby.
U1.1.2.2.2. <…> wykonawcom Zamawiającego wykonującym prace na obiektach infrastruktury informatycznej.
U1.1.2.2.3. <…> osobom trzecim.
Objaśnienia U1.1.2.2.3.
Jedną, ale nie jedyną opcją realizacji tego zagrożenia jest wykorzystanie przez atakujących metod inżynierii społecznej.
U1.1.3. Napastnicy wybierali dane uwierzytelniające za pomocą metod brute-force:
U1.1.3.1. <…> przy użyciu standardowych mechanizmów dostępu.
U1.1.3.2. <…> używanie wcześniej przechwyconych kodów (na przykład skrótów haseł) do przechowywania danych uwierzytelniających.
U1.1.4. Napastnicy wykorzystali złośliwy kod do przechwycenia danych uwierzytelniających użytkownika.
U1.1.5. Osoby atakujące wyodrębniły dane uwierzytelniające z połączenia sieciowego między Klientem a Serwerem:
U1.1.5.1. Połączyć: .
U1.1.6. Atakujący wyodrębnili dane uwierzytelniające z zapisów systemów monitorowania pracy:
U1.1.6.1. <…> systemy monitoringu wizyjnego (jeżeli podczas pracy zarejestrowano naciśnięcia klawiszy na klawiaturze).
U1.1.6.2. <…> systemy monitorowania działań pracowników przy komputerze
Objaśnienia U1.1.6.2.
Przykładem takiego systemu jest .
U1.1.7. Osoby atakujące złamały dane uwierzytelniające użytkownika ze względu na błędy w procesie transmisji.
Objaśnienia U1.1.7.
Na przykład wysyłanie haseł w postaci zwykłego tekstu za pośrednictwem poczty elektronicznej.
U1.1.8. Osoby atakujące uzyskały dane uwierzytelniające poprzez monitorowanie sesji użytkownika za pomocą systemów zdalnej administracji.
U1.1.9. Napastnicy uzyskali dane uwierzytelniające w wyniku wycieku kanałami technicznymi (TCUI):
U1.1.9.1. Osoby atakujące zaobserwowały, w jaki sposób użytkownik wprowadzał dane uwierzytelniające z klawiatury:
U1.1.9.1.1 Osoby atakujące znajdowały się w pobliżu użytkownika i na własne oczy widziały wprowadzanie danych uwierzytelniających.
Objaśnienia U1.1.9.1.1
Do takich przypadków zaliczają się działania współpracowników lub przypadek, gdy klawiatura użytkownika jest widoczna dla osób odwiedzających organizację.
U1.1.9.1.2 Napastnicy wykorzystali dodatkowe środki techniczne, takie jak lornetka lub bezzałogowy statek powietrzny, i przez okno widzieli wprowadzanie dokumentów uwierzytelniających.
U1.1.9.2. Osoby atakujące pobierały dane uwierzytelniające z komunikacji radiowej pomiędzy klawiaturą a jednostką systemową komputera, gdy były one połączone za pośrednictwem interfejsu radiowego (na przykład Bluetooth).
U1.1.9.3. Napastnicy przechwycili dane uwierzytelniające, wyciekając je kanałem fałszywego promieniowania i zakłóceń elektromagnetycznych (PEMIN).
Objaśnienia U1.1.9.3.
Przykłady ataków и .
U1.1.9.4. Osoba atakująca przechwyciła wprowadzanie danych uwierzytelniających z klawiatury za pomocą specjalnych środków technicznych (STS) przeznaczonych do tajnego uzyskiwania informacji.
Objaśnienia U1.1.9.4.
Примеры .
U1.1.9.5. Osoby atakujące przechwyciły wprowadzanie danych uwierzytelniających z klawiatury za pomocą
analiza sygnału Wi-Fi modulowanego przez proces naciśnięcia klawisza przez użytkownika.
Objaśnienia U1.1.9.5.
Przykład .
U1.1.9.6. Osoby atakujące przechwytują wprowadzanie danych uwierzytelniających z klawiatury, analizując dźwięki naciśnięć klawiszy.
Objaśnienia U1.1.9.6.
Przykład .
U1.1.9.7. Napastnicy przechwycili wprowadzanie danych uwierzytelniających z klawiatury urządzenia mobilnego, analizując odczyty akcelerometru.
Objaśnienia U1.1.9.7.
Przykład .
U1.1.10. <…>, zapisane wcześniej na Kliencie.
Objaśnienia U1.1.10.
Na przykład użytkownik może zapisać w przeglądarce login i hasło, aby uzyskać dostęp do określonej witryny.
U1.1.11. Osoby atakujące złamały dane uwierzytelniające ze względu na błędy w procesie odbierania dostępu użytkownika.
Objaśnienia U1.1.11.
Na przykład po zwolnieniu użytkownika jego konta pozostały odblokowane.
U1.2. <…> poprzez wykorzystanie luk w systemie kontroli dostępu.
U2. Nieautoryzowane podniesienie uprawnień użytkownika w systemie informatycznym
Rozkład
U2.1 <…> poprzez dokonanie nieuprawnionych zmian w danych zawierających informację o uprawnieniach użytkownika.
U2.2 <…> poprzez wykorzystanie podatności w systemie kontroli dostępu.
U2.3. <…> ze względu na niedociągnięcia w procesie zarządzania dostępem użytkowników.
Objaśnienia U2.3.
Przykład 1. Użytkownik otrzymał większy dostęp do pracy, niż potrzebował ze względów biznesowych.
Przykład 2: Po przeniesieniu użytkownika na inne stanowisko, wcześniej przyznane mu prawa dostępu nie zostały cofnięte.
TYPOWY MODEL ZAGROŻENIA. MODUŁ INTEGRACYJNY
Obiekt ochrony, dla którego stosowany jest model zagrożenia (zakres).
Moduł integracyjny to zbiór obiektów infrastruktury informatycznej, którego zadaniem jest organizacja wymiany informacji pomiędzy systemami informatycznymi.
Biorąc pod uwagę fakt, że w sieciach korporacyjnych nie zawsze da się jednoznacznie oddzielić jeden system informatyczny od drugiego, moduł integracyjny można rozpatrywać także jako ogniwo łączące pomiędzy komponentami w ramach jednego systemu informatycznego.
Architektura
Uogólniony schemat modułu integracyjnego wygląda następująco:
Opis elementów architektonicznych:
- „Serwer Exchange (SO)” – węzeł/usługa/element systemu informatycznego realizujący funkcję wymiany danych z innym systemem informacyjnym.
- "Mediator" – węzeł/usługa przeznaczona do organizowania interakcji pomiędzy systemami informatycznymi, ale nie będąca ich częścią.
Przykłady „Pośrednicy” mogą istnieć usługi poczty elektronicznej, magistrale usług dla przedsiębiorstw (architektura magistrali usług dla przedsiębiorstw / architektura SoA), serwery plików innych firm itp. Co do zasady moduł integracji nie może zawierać „Pośredników”. - „Oprogramowanie do przetwarzania danych” – zestaw programów realizujących protokoły wymiany danych i konwersji formatów.
Np. konwersja danych z formatu UFEBS do formatu ABS, zmiana statusów wiadomości w trakcie transmisji itp. - "Połączenie internetowe" odpowiada obiektowi opisanemu w standardowym modelu zagrożenia „Połączenie sieciowe”. Niektóre połączenia sieciowe pokazane na powyższym schemacie mogą nie istnieć.
Przykłady modułów integracyjnych
Schemat 1. Integracja ABS i AWS KBR poprzez zewnętrzny serwer plików
W celu realizacji płatności upoważniony pracownik banku pobiera elektroniczne dokumenty płatnicze z centralnego systemu bankowego i zapisuje je do pliku (we własnym formacie, np. zrzut SQL) w folderze sieciowym (...SHARE) na serwerze plików. Następnie plik ten jest konwertowany za pomocą skryptu konwertującego na zestaw plików w formacie UFEBS, które następnie są odczytywane przez stację roboczą CBD.
Następnie upoważniony pracownik - użytkownik zautomatyzowanego stanowiska pracy KBR - szyfruje i podpisuje otrzymane pliki oraz wysyła je do systemu płatniczego Banku Rosji.
Po otrzymaniu płatności z Banku Rosji zautomatyzowane stanowisko KBR odszyfrowuje je i sprawdza podpis elektroniczny, po czym rejestruje je w postaci zestawu plików w formacie UFEBS na serwerze plików. Przed zaimportowaniem dokumentów płatniczych do ABS następuje ich konwersja za pomocą skryptu konwertującego z formatu UFEBS na format ABS.
Załóżmy, że w tym schemacie ABS działa na jednym serwerze fizycznym, stacja robocza KBR na dedykowanym komputerze, a skrypt konwertera działa na serwerze plików.
Zgodność obiektów rozpatrywanego diagramu z elementami modelu modułu integracyjnego:
„Serwer wymiany od strony ABS” – Serwer ABS.
„Serwer Exchange od strony AWS KBR” – stanowisko komputerowe KBR.
"Mediator" – serwer plików innej firmy.
„Oprogramowanie do przetwarzania danych” – skrypt konwertera.
Schemat 2. Integracja ABS i AWS KBR przy umieszczaniu udostępnionego folderu sieciowego z płatnościami na AWS KBR
Wszystko wygląda podobnie jak na schemacie 1, z tą różnicą, że nie wykorzystuje się osobnego serwera plików, zamiast tego na komputerze ze stacją roboczą CBD umieszcza się folder sieciowy (...SHARE) z elektronicznymi dokumentami płatności. Skrypt konwertera działa również na stacji roboczej CBD.
Zgodność obiektów rozpatrywanego diagramu z elementami modelu modułu integracyjnego:
Podobny do schematu 1, ale "Mediator" nieużywany.
Schemat 3. Integracja ABS i zautomatyzowanego stanowiska pracy KBR-N poprzez IBM WebSphera MQ i podpisywanie dokumentów elektronicznych „po stronie ABS”
ABS działa na platformie, która nie jest obsługiwana przez podpis CIPF SCAD. Podpisywanie wychodzących dokumentów elektronicznych odbywa się na specjalnym serwerze podpisu elektronicznego (ES Server). Ten sam serwer sprawdza podpis elektroniczny na dokumentach przychodzących z Banku Rosji.
ABS przesyła plik z dokumentami płatności we własnym formacie na serwer ES.
Serwer ES za pomocą skryptu konwertującego konwertuje plik na wiadomości elektroniczne w formacie UFEBS, po czym wiadomości elektroniczne są podpisywane i przesyłane do IBM WebSphere MQ.
Stacja robocza KBR-N uzyskuje dostęp do IBM WebSphere MQ i odbiera stamtąd podpisane komunikaty płatnicze, po czym upoważniony pracownik – użytkownik stacji roboczej KBR – szyfruje je i wysyła do systemu płatniczego Banku Rosji.
Po otrzymaniu płatności z Banku Rosji zautomatyzowane miejsce pracy KBR-N odszyfrowuje je i weryfikuje podpis elektroniczny. Pomyślnie przetworzone płatności w postaci odszyfrowanych i podpisanych wiadomości elektronicznych w formacie UFEBS przekazywane są do IBM WebSphere MQ, skąd odbierane są przez Serwer Podpisów Elektronicznych.
Serwer podpisu elektronicznego weryfikuje podpis elektroniczny otrzymanych płatności i zapisuje je w pliku w formacie ABS. Następnie upoważniony pracownik – użytkownik ABS – przesyła powstały plik do ABS w zalecany sposób.
Zgodność obiektów rozpatrywanego diagramu z elementami modelu modułu integracyjnego:
„Serwer wymiany od strony ABS” – Serwer ABS.
„Serwer Exchange od strony AWS KBR” — stanowisko komputerowe KBR.
"Mediator" – Serwer ES i IBM WebSphere MQ.
„Oprogramowanie do przetwarzania danych” – konwerter skryptów, podpis CIPF SCAD na serwerze ES.
Schemat 4. Integracja Serwera RBS z centralnym systemem bankowym poprzez API udostępniane przez dedykowany serwer wymiany
Załóżmy, że bank korzysta z kilku systemów bankowości zdalnej (RBS):
- „Internetowy Klient-Bank” dla osób fizycznych (IKB FL);
- „Internetowy Klient-Bank” dla osób prawnych (IKB LE).
W celu zapewnienia bezpieczeństwa informacji wszelka interakcja pomiędzy ABS a systemami bankowości zdalnej odbywa się poprzez dedykowany serwer wymiany działający w ramach systemu informacyjnego ABS.
Następnie rozważymy proces interakcji pomiędzy systemem RBS IKB LE i ABS.
Serwer RBS po otrzymaniu od klienta należycie poświadczonego zlecenia płatniczego musi na jego podstawie utworzyć w ABS odpowiedni dokument. W tym celu za pomocą API przekazuje informacje do serwera wymiany, który z kolei wprowadza dane do ABS.
W przypadku zmiany salda rachunku klienta ABS generuje powiadomienia elektroniczne, które przesyłane są do zdalnego serwera bankowego za pomocą serwera wymiany.
Zgodność obiektów rozpatrywanego diagramu z elementami modelu modułu integracyjnego:
„Serwer Exchange od strony RBS” – Serwer RBS IKB YUL.
„Serwer wymiany od strony ABS” - Wymiana serweru.
"Mediator" - zaginiony.
„Oprogramowanie do przetwarzania danych” – Komponenty serwera RBS odpowiedzialne za korzystanie z API serwera Exchange, komponenty serwera Exchange odpowiedzialne za korzystanie z API core bankowości.
Zagrożenia bezpieczeństwa najwyższego poziomu
Rozkład
U1. Wstrzyknięcie fałszywych informacji przez atakujących poprzez moduł integracji.
U1. Wstrzyknięcie fałszywych informacji przez atakujących poprzez moduł integracji
Rozkład
U1.1. Nieautoryzowana modyfikacja legalnych danych przesyłanych za pośrednictwem połączeń sieciowych:
Łącze U1.1.1: .
U1.2. Przekazywanie fałszywych danych kanałami komunikacji w imieniu uprawnionego uczestnika giełdy:
Łącze U1.1.2: .
U1.3. Nieuprawniona modyfikacja legalnych danych podczas ich przetwarzania na Serwerach Exchange lub u Pośrednika:
U1.3.1. Połączyć: .
U1.4. Tworzenie fałszywych danych na Serwerach Exchange lub Pośredniku w imieniu uprawnionego uczestnika giełdy:
U1.4.1. Połączyć:
U1.5. Nieuprawniona modyfikacja danych przetwarzanych za pomocą oprogramowania do przetwarzania danych:
U1.5.1. <…> na skutek dokonania przez osoby atakujące nieautoryzowanych zmian w ustawieniach (konfiguracji) oprogramowania do przetwarzania danych.
U1.5.2. <…> z powodu dokonania przez atakujących nieautoryzowanych zmian w plikach wykonywalnych oprogramowania do przetwarzania danych.
U1.5.3. <…> ze względu na interaktywną kontrolę oprogramowania do przetwarzania danych przez osoby atakujące.
TYPOWY MODEL ZAGROŻENIA. SYSTEM OCHRONY INFORMACJI KRYPTOGRAFICZNEJ
Obiekt ochrony, dla którego stosowany jest model zagrożenia (zakres).
Przedmiotem ochrony jest system ochrony informacji kryptograficznej służący do zapewnienia bezpieczeństwa systemu informatycznego.
Architektura
Podstawą każdego systemu informatycznego jest oprogramowanie aplikacyjne realizujące jego docelową funkcjonalność.
Ochrona kryptograficzna jest zwykle realizowana poprzez wywoływanie prymitywów kryptograficznych z logiki biznesowej oprogramowania aplikacji, które znajdują się w wyspecjalizowanych bibliotekach - rdzeniach kryptograficznych.
Prymitywy kryptograficzne obejmują funkcje kryptograficzne niskiego poziomu, takie jak:
- szyfrować/odszyfrowywać blok danych;
- utworzyć/zweryfikować podpis elektroniczny bloku danych;
- obliczyć funkcję skrótu bloku danych;
- generuj / ładuj / przesyłaj kluczowe informacje;
- itd.
Logika biznesowa oprogramowania aplikacyjnego implementuje funkcjonalność wyższego poziomu przy użyciu prymitywów kryptograficznych:
- zaszyfrować plik za pomocą kluczy wybranych odbiorców;
- ustanowić bezpieczne połączenie sieciowe;
- informować o wynikach sprawdzenia podpisu elektronicznego;
- i tak dalej.
Interakcję logiki biznesowej i rdzenia kryptograficznego można przeprowadzić:
- bezpośrednio, poprzez logikę biznesową wywołującą prymitywy kryptograficzne z bibliotek dynamicznych jądra kryptograficznego (.DLL dla Windows, .SO dla Linux);
- bezpośrednio, poprzez interfejsy kryptograficzne - wrappery, np. MS Crypto API, Java Cryptography Architecture, PKCS#11 itp. W tym przypadku logika biznesowa uzyskuje dostęp do interfejsu kryptograficznego i tłumaczy wywołanie na odpowiedni rdzeń kryptograficzny, który w ten przypadek nazywa się dostawcą kryptowalut. Zastosowanie interfejsów kryptograficznych umożliwia oprogramowaniu aplikacyjnemu odejście od określonych algorytmów kryptograficznych i zachowanie większej elastyczności.
Istnieją dwa typowe schematy organizacji rdzenia kryptograficznego:
Schemat 1 – Monolityczny rdzeń kryptograficzny
Schemat 2 – Podzielony rdzeń kryptograficzny
Elementami na powyższych schematach mogą być albo pojedyncze moduły oprogramowania działające na jednym komputerze, albo usługi sieciowe współdziałające w ramach sieci komputerowej.
W przypadku korzystania z systemów zbudowanych według Schematu 1 oprogramowanie aplikacyjne i rdzeń kryptograficzny działają w jednym środowisku operacyjnym dla narzędzia kryptograficznego (SFC), na przykład na tym samym komputerze, na którym działa ten sam system operacyjny. Użytkownik systemu z reguły może w tym samym środowisku operacyjnym uruchamiać inne programy, w tym także zawierające szkodliwy kod. W takich warunkach istnieje poważne ryzyko wycieku prywatnych kluczy kryptograficznych.
Aby zminimalizować ryzyko, stosuje się schemat 2, w którym rdzeń kryptograficzny jest podzielony na dwie części:
- Pierwsza część wraz z aplikacją działa w niezaufanym środowisku, w którym istnieje ryzyko infekcji złośliwym kodem. Nazwiemy tę część „częścią oprogramowania”.
- Druga część działa w zaufanym środowisku na dedykowanym urządzeniu, które zawiera magazyn kluczy prywatnych. Odtąd będziemy nazywać tę część „sprzętem”.
Podział rdzenia kryptowaluty na część programową i sprzętową jest bardzo dowolny. Na rynku istnieją systemy zbudowane według schematu z podzielonym rdzeniem kryptograficznym, ale którego część „sprzętowa” prezentowana jest w postaci obrazu maszyny wirtualnej – wirtualnego HSM ().
Interakcja obu części rdzenia kryptograficznego odbywa się w taki sposób, że prywatne klucze kryptograficzne nigdy nie są przekazywane do części programowej i w związku z tym nie mogą zostać skradzione przy użyciu złośliwego kodu.
Interfejs interakcji (API) i zestaw prymitywów kryptograficznych dostarczanych do oprogramowania aplikacji przez rdzeń kryptograficzny są w obu przypadkach takie same. Różnica polega na sposobie ich wdrożenia.
Zatem przy stosowaniu schematu z podzielonym rdzeniem kryptograficznym interakcja oprogramowania i sprzętu odbywa się zgodnie z następującą zasadą:
- Prymitywy kryptograficzne, które nie wymagają użycia klucza prywatnego (np. obliczenie funkcji skrótu, weryfikacja podpisu elektronicznego itp.) realizowane są przez oprogramowanie.
- Operacje kryptograficzne wykorzystujące klucz prywatny (tworzenie podpisu elektronicznego, deszyfrowanie danych itp.) realizowane są sprzętowo.
Zilustrujmy pracę podzielonego rdzenia kryptograficznego na przykładzie tworzenia podpisu elektronicznego:
- Część programowa oblicza funkcję skrótu podpisanych danych i przesyła tę wartość do sprzętu za pośrednictwem kanału wymiany pomiędzy rdzeniami kryptograficznymi.
- Część sprzętowa za pomocą klucza prywatnego i hasha generuje wartość podpisu elektronicznego i przekazuje ją do części programowej kanałem wymiany.
- Część programowa zwraca otrzymaną wartość do oprogramowania aplikacyjnego.
Funkcje sprawdzania poprawności podpisu elektronicznego
Gdy strona otrzymująca otrzymuje dane podpisane elektronicznie, musi przeprowadzić kilka etapów weryfikacji. Pozytywny wynik sprawdzenia podpisu elektronicznego zostanie osiągnięty jedynie w przypadku pomyślnego przejścia wszystkich etapów weryfikacji.
Etap 1. Kontrola integralności i autorstwa danych.
Zawartość sceny. Podpis elektroniczny danych weryfikowany jest za pomocą odpowiedniego algorytmu kryptograficznego. Pomyślne zakończenie tego etapu oznacza, że dane nie były modyfikowane od chwili podpisania, a także, że podpis został złożony kluczem prywatnym odpowiadającym kluczowi publicznemu służącemu do weryfikacji podpisu elektronicznego.
Lokalizacja sceny: rdzeń kryptograficzny.
Etap 2. Kontrola zaufania do klucza publicznego podpisującego oraz kontrola okresu ważności klucza prywatnego podpisu elektronicznego.
Zawartość sceny. Etap składa się z dwóch podetapów pośrednich. Pierwsza polega na ustaleniu, czy w momencie podpisywania danych klucz publiczny służący do weryfikacji podpisu elektronicznego był zaufany. Drugie określa, czy klucz prywatny podpisu elektronicznego był ważny w momencie podpisywania danych. Generalnie okresy ważności tych kluczy mogą się nie pokrywać (np. w przypadku kwalifikowanych certyfikatów kluczy do weryfikacji podpisu elektronicznego). Metody ustanawiania zaufania do klucza publicznego sygnatariusza określają przyjęte przez strony współdziałające zasady elektronicznego zarządzania dokumentami.
Lokalizacja sceny: oprogramowanie aplikacyjne/rdzeń kryptograficzny.
Etap 3. Kontrola władzy podpisującego.
Zawartość sceny. Zgodnie z ustalonymi zasadami elektronicznego zarządzania dokumentami sprawdzane jest, czy podpisujący miał prawo do poświadczenia chronionych danych. Jako przykład podajmy sytuację naruszenia władzy. Załóżmy, że istnieje organizacja, w której wszyscy pracownicy mają podpis elektroniczny. Wewnętrzny system elektronicznego zarządzania dokumentami otrzymuje zamówienie od kierownika, ale podpisane elektronicznym podpisem kierownika magazynu. W związku z tym takiego dokumentu nie można uznać za zgodny z prawem.
Lokalizacja sceny: oprogramowanie.
Założenia przyjęte przy opisie przedmiotu ochrony
- Kanały transmisji informacji, z wyjątkiem kanałów wymiany kluczy, przechodzą także przez oprogramowanie aplikacyjne, API i rdzeń kryptograficzny.
- Informacje o zaufaniu do kluczy publicznych i (lub) certyfikatów, a także informacje o uprawnieniach właścicieli kluczy publicznych znajdują się w magazynie kluczy publicznych.
- Oprogramowanie aplikacji współpracuje z magazynem kluczy publicznych poprzez jądro kryptograficzne.
Przykład systemu informatycznego chronionego za pomocą protokołu CIPF
Aby zilustrować wcześniej zaprezentowane diagramy, rozważmy hipotetyczny system informacyjny i zaznaczmy na nim wszystkie elementy konstrukcyjne.
Opis systemu informatycznego
Obie organizacje postanowiły wprowadzić między sobą istotne z prawnego punktu widzenia elektroniczne zarządzanie dokumentami (EDF). W tym celu zawarli umowę, w której zastrzegli, że dokumenty będą przesyłane drogą elektroniczną, przy czym muszą być szyfrowane i podpisywane kwalifikowanym podpisem elektronicznym. Jako narzędzia do tworzenia i przetwarzania dokumentów należy wykorzystać programy biurowe z pakietu Microsoft Office 2016, a jako środki ochrony kryptograficznej należy zastosować CIPF CryptoPRO i oprogramowanie szyfrujące CryptoARM.
Opis infrastruktury organizacji 1
Organizacja 1 zdecydowała, że zainstaluje oprogramowanie CIPF CryptoPRO i CryptoARM na stacji roboczej użytkownika – komputerze fizycznym. Klucze szyfrowania i podpisu elektronicznego będą przechowywane na nośniku klucza ruToken, działającym w trybie klucza możliwego do odzyskania. Użytkownik przygotuje dokumenty elektroniczne lokalnie na swoim komputerze, następnie zaszyfruje je, podpisze i wyśle za pomocą lokalnie zainstalowanego klienta poczty elektronicznej.
Opis infrastruktury organizacji 2
Organizacja 2 zdecydowała się przenieść funkcje szyfrowania i podpisu elektronicznego na dedykowaną maszynę wirtualną. W takim przypadku wszystkie operacje kryptograficzne będą wykonywane automatycznie.
W tym celu na dedykowanej maszynie wirtualnej organizowane są dwa foldery sieciowe: „...In”, „...Out”. Pliki otrzymane od kontrahenta w formie otwartej zostaną automatycznie umieszczone w folderze sieciowym „…In”. Pliki te zostaną odszyfrowane, a podpis elektroniczny zostanie zweryfikowany.
Użytkownik umieści w folderze „…Out” pliki, które należy zaszyfrować, podpisać i wysłać do kontrahenta. Użytkownik sam przygotuje pliki na swoim stanowisku pracy.
W celu realizacji funkcji szyfrowania i podpisu elektronicznego na maszynie wirtualnej instalowane jest oprogramowanie CIPF CryptoPRO, CryptoARM oraz klient poczty elektronicznej. Automatyczne zarządzanie wszystkimi elementami maszyny wirtualnej odbywać się będzie za pomocą skryptów opracowanych przez administratorów systemu. Praca skryptów jest rejestrowana w plikach logów.
Klucze kryptograficzne do podpisu elektronicznego zostaną umieszczone na tokenie z nieodzyskiwalnym kluczem JaCarta GOST, który użytkownik podłączy do swojego lokalnego komputera.
Token zostanie przekazany do maszyny wirtualnej za pomocą specjalistycznego oprogramowania USB-over-IP zainstalowanego na stacji roboczej użytkownika oraz na maszynie wirtualnej.
Zegar systemowy na stacji roboczej użytkownika w organizacji 1 zostanie ustawiony ręcznie. Zegar systemowy dedykowanej maszyny wirtualnej w Organizacji 2 zostanie zsynchronizowany z zegarem systemowym hypervisora, który z kolei będzie synchronizowany przez Internet z publicznymi serwerami czasu.
Identyfikacja elementów konstrukcyjnych CIPF
Na podstawie powyższego opisu infrastruktury IT wyróżnimy elementy strukturalne CIPF i zapiszemy je w tabeli.
Tabela - Zgodność elementów modelu CIPF z elementami systemu informatycznego
Nazwa przedmiotu
Organizacja 1
Organizacja 2
Oprogramowanie
Oprogramowanie CryptoARM
Oprogramowanie CryptoARM
Część oprogramowania rdzenia kryptograficznego
Dostawca usług kryptograficznych CIPF CryptoPRO
Dostawca usług kryptograficznych CIPF CryptoPRO
Sprzęt z rdzeniem kryptograficznym
Nie
JaCarta GOST
API
MS CryptoAPI
MS CryptoAPI
Magazyn kluczy publicznych
Stacja robocza użytkownika:
- dysk twardy;
- standardowy magazyn certyfikatów Windows.
Hiperwizor:
- dysk twardy.
Maszyna wirtualna:
- dysk twardy;
- standardowy magazyn certyfikatów Windows.
Przechowywanie kluczy prywatnych
Nośnik kluczy ruToken działający w trybie klucza możliwego do odzyskania
Nosidełko na klucze JaCarta GOST działające w trybie klucza niewyjmowanego
Kanał wymiany kluczy publicznych
Stacja robocza użytkownika:
- BARAN.
Hiperwizor:
- BARAN.
Maszyna wirtualna:
- BARAN.
Kanał wymiany kluczy prywatnych
Stacja robocza użytkownika:
— magistrala USB;
- BARAN.
Nie
Kanał wymiany pomiędzy rdzeniami kryptograficznymi
brak (brak sprzętu z rdzeniem kryptograficznym)
Stacja robocza użytkownika:
— magistrala USB;
- BARAN;
— moduł oprogramowania USB-over-IP;
- Interfejs sieciowy.
Sieć korporacyjna organizacji 2.
Hiperwizor:
- BARAN;
- Interfejs sieciowy.
Maszyna wirtualna:
- Interfejs sieciowy;
- BARAN;
— Moduł oprogramowania USB-over-IP.
Otwórz kanał danych
Stacja robocza użytkownika:
— środki wejścia-wyjścia;
- BARAN;
- dysk twardy.
Stacja robocza użytkownika:
— środki wejścia-wyjścia;
- BARAN;
- dysk twardy;
- Interfejs sieciowy.
Sieć korporacyjna organizacji 2.
Hiperwizor:
- Interfejs sieciowy;
- BARAN;
- dysk twardy.
Maszyna wirtualna:
- Interfejs sieciowy;
- BARAN;
- dysk twardy.
Bezpieczny kanał wymiany danych
Internetowe.
Sieć korporacyjna organizacji 1.
Stacja robocza użytkownika:
- dysk twardy;
- BARAN;
- Interfejs sieciowy.
Internetowe.
Sieć korporacyjna organizacji 2.
Hiperwizor:
- Interfejs sieciowy;
- BARAN;
- dysk twardy.
Maszyna wirtualna:
- Interfejs sieciowy;
- BARAN;
- dysk twardy.
Kanał czasowy
Stacja robocza użytkownika:
— środki wejścia-wyjścia;
- BARAN;
- zegar systemowy.
Internetowe.
Sieć korporacyjna organizacji 2,
Hiperwizor:
- Interfejs sieciowy;
- BARAN;
- zegar systemowy.
Maszyna wirtualna:
- BARAN;
- zegar systemowy.
Kanał transmisji poleceń sterujących
Stacja robocza użytkownika:
— środki wejścia-wyjścia;
- BARAN.
(Graficzny interfejs użytkownika oprogramowania CryptoARM)
Maszyna wirtualna:
- BARAN;
- dysk twardy.
(Skrypty automatyzacji)
Kanał do otrzymywania wyników pracy
Stacja robocza użytkownika:
— środki wejścia-wyjścia;
- BARAN.
(Graficzny interfejs użytkownika oprogramowania CryptoARM)
Maszyna wirtualna:
- BARAN;
- dysk twardy.
(Pliki dziennika skryptów automatyzacji)
Zagrożenia bezpieczeństwa najwyższego poziomu
Objaśnienia
Założenia przyjęte podczas rozkładania zagrożeń:
- Stosowane są silne algorytmy kryptograficzne.
- Algorytmy kryptograficzne są bezpiecznie stosowane w odpowiednich trybach działania (np. nie jest używany do szyfrowania dużych ilości danych, uwzględniane jest dopuszczalne obciążenie klucza itp.).
- Atakujący znają wszystkie używane algorytmy, protokoły i klucze publiczne.
- Atakujący mogą odczytać wszystkie zaszyfrowane dane.
- Atakujący są w stanie odtworzyć dowolne elementy oprogramowania w systemie.
Rozkład
U1. Kompromis prywatnych kluczy kryptograficznych.
U2. Szyfrowanie fałszywych danych w imieniu legalnego nadawcy.
U3. Odszyfrowanie zaszyfrowanych danych przez osoby, które nie są prawowitymi odbiorcami danych (osoby atakujące).
U4. Tworzenie podpisu elektronicznego uprawnionego podpisującego pod fałszywymi danymi.
U5. Uzyskanie pozytywnego wyniku sprawdzenia podpisu elektronicznego sfałszowanych danych.
U6. Błędne przyjęcie dokumentów elektronicznych do realizacji spowodowane problemami w organizacji zarządzania dokumentami elektronicznymi.
U7. Nieuprawniony dostęp do danych chronionych w trakcie ich przetwarzania przez CIPF.
U1. Kompromis prywatnych kluczy kryptograficznych
U1.1. Pobieranie klucza prywatnego z magazynu kluczy prywatnych.
U1.2. Uzyskanie klucza prywatnego z obiektów w środowisku operacyjnym narzędzia kryptograficznego, w którym może on tymczasowo przebywać.
Objaśnienia U1.2.
Obiekty, które mogą tymczasowo przechowywać klucz prywatny, obejmują:
- BARAN,
- pliki tymczasowe,
- wymiana plików,
- pliki hibernacji,
- pliki migawek stanu „gorącego” maszyn wirtualnych, w tym pliki zawartości pamięci RAM wstrzymanych maszyn wirtualnych.
U1.2.1. Wyodrębnianie kluczy prywatnych z działającej pamięci RAM poprzez zamrażanie modułów RAM, usuwanie ich, a następnie odczytywanie danych (atak zamrażający).
Objaśnienia U1.2.1.
Przykład .
U1.3. Uzyskanie klucza prywatnego z kanału wymiany kluczy prywatnych.
Objaśnienia U1.3.
Podany zostanie przykład realizacji tego zagrożenia .
U1.4. Nieautoryzowana modyfikacja rdzenia kryptowaluty, w wyniku której klucze prywatne stają się znane atakującym.
U1.5. Naruszenie klucza prywatnego w wyniku wykorzystania kanałów wycieku informacji technicznych (TCIL).
Objaśnienia U1.5.
Przykład .
U1.6. Naruszenie klucza prywatnego w wyniku użycia specjalnych środków technicznych (STS) przeznaczonych do tajnego odzyskiwania informacji („błędów”).
U1.7. Naruszenie kluczy prywatnych podczas ich przechowywania poza CIPF.
Objaśnienia U1.7.
Na przykład użytkownik przechowuje swoje kluczowe multimedia w szufladzie komputera, skąd osoby atakujące mogą je łatwo odzyskać.
U2. Szyfrowanie fałszywych danych w imieniu legalnego nadawcy
Objaśnienia
To zagrożenie jest brane pod uwagę tylko w przypadku schematów szyfrowania danych z uwierzytelnianiem nadawcy. Przykłady takich schematów wskazane są w zaleceniach normalizacyjnych . W przypadku innych schematów kryptograficznych zagrożenie to nie istnieje, ponieważ szyfrowanie odbywa się na kluczach publicznych odbiorcy i są one powszechnie znane atakującym.
Rozkład
U2.1. Naruszenie klucza prywatnego nadawcy:
U2.1.1. Połączyć: .
U2.2. Zastępowanie danych wejściowych w otwartym kanale wymiany danych.
Uwagi U2.2.
Przykłady realizacji tego zagrożenia podano poniżej. и .
U3. Odszyfrowanie zaszyfrowanych danych przez osoby niebędące prawowitymi odbiorcami danych (osoby atakujące)
Rozkład
U3.1. Naruszenie kluczy prywatnych odbiorcy zaszyfrowanych danych.
Łącze U3.1.1: .
U3.2. Podstawienie zaszyfrowanych danych w bezpiecznym kanale wymiany danych.
U4. Tworzenie podpisu elektronicznego uprawnionego podpisującego pod fałszywymi danymi
Rozkład
U4.1. Naruszenie kluczy prywatnych podpisu elektronicznego uprawnionego podpisującego.
Łącze U4.1.1: .
U4.2. Zastąpienie podpisanych danych w otwartym kanale wymiany danych.
Uwaga U4.2.
Przykłady realizacji tego zagrożenia podano poniżej. и .
U5. Uzyskanie pozytywnego wyniku sprawdzenia podpisu elektronicznego sfałszowanych danych
Rozkład
U5.1. Atakujący przechwytują wiadomość w kanale przesyłania wyników pracy o negatywnym wyniku sprawdzenia podpisu elektronicznego i zastępują ją wiadomością z pozytywnym wynikiem.
U5.2. Atakujący atakują zaufanie do podpisywania certyfikatów (SKRYPT - wymagane są wszystkie elementy):
U5.2.1. Atakujący generują klucz publiczny i prywatny do podpisu elektronicznego. Jeżeli system korzysta z certyfikatów kluczy podpisu elektronicznego, to generuje certyfikat podpisu elektronicznego możliwie najbardziej zbliżony do certyfikatu zamierzonego nadawcy danych, którego przekaz chcą sfałszować.
U5.2.2. Atakujący dokonują nieautoryzowanych zmian w magazynie kluczy publicznych, nadając kluczowi publicznemu niezbędny poziom zaufania i uprawnień.
U5.2.3. Atakujący podpisują fałszywe dane wygenerowanym wcześniej kluczem podpisu elektronicznego i wprowadzają go do bezpiecznego kanału wymiany danych.
U5.3. Atakujący przeprowadzają atak, wykorzystując wygasłe klucze podpisu elektronicznego osoby podpisującej (SKRYPT - wymagane są wszystkie elementy):
U5.3.1. Osoby atakujące naruszają wygasłe (obecnie nieważne) klucze prywatne podpisu elektronicznego legalnego nadawcy.
U5.3.2. Atakujący zastępują czas w kanale transmisji czasu czasem, w którym złamane klucze były nadal ważne.
U5.3.3. Atakujący podpisują fałszywe dane za pomocą wcześniej złamanego klucza podpisu elektronicznego i wprowadzają go do bezpiecznego kanału wymiany danych.
U5.4. Atakujący przeprowadzają atak, korzystając ze złamanych kluczy podpisu elektronicznego osoby podpisującej (SKRYPT - wymagane są wszystkie elementy):
U5.4.1. Osoba atakująca tworzy kopię magazynu kluczy publicznych.
U5.4.2. Osoby atakujące naruszają klucze prywatne jednego z legalnych nadawców. Zauważa kompromis, unieważnia klucze, a informacja o unieważnieniu klucza zostaje umieszczona w magazynie kluczy publicznych.
U5.4.3. Atakujący zastępują magazyn kluczy publicznych wcześniej skopiowanym.
U5.4.4. Atakujący podpisują fałszywe dane za pomocą wcześniej złamanego klucza podpisu elektronicznego i wprowadzają go do bezpiecznego kanału wymiany danych.
U5.5. <…> ze względu na występowanie błędów w realizacji II i III etapu weryfikacji podpisu elektronicznego:
Objaśnienia U5.5.
Podano przykład realizacji tego zagrożenia .
U5.5.1. Sprawdzanie zaufania do certyfikatu klucza podpisu elektronicznego jedynie poprzez obecność zaufania do certyfikatu, którym jest podpisany, bez sprawdzania CRL lub OCSP.
Objaśnienia U5.5.1.
Przykład wdrożenia .
U5.5.2. Budując łańcuch zaufania dla certyfikatu, nie analizuje się organów wydających certyfikaty
Objaśnienia U5.5.2.
Przykład ataku na certyfikaty SSL/TLS.
Napastnicy kupili legalny certyfikat do swojej poczty e-mail. Następnie sporządzili fałszywy certyfikat witryny i podpisali go swoim certyfikatem. Jeśli dane uwierzytelniające nie zostaną sprawdzone, to podczas sprawdzania łańcucha zaufania okażą się one prawidłowe, a co za tym idzie, fałszywy certyfikat również będzie poprawny.
U5.5.3. Podczas budowania łańcucha zaufania certyfikatów certyfikaty pośrednie nie są sprawdzane pod kątem unieważnienia.
U5.5.4. Listy CRL są aktualizowane rzadziej niż te wydawane przez urząd certyfikacji.
U5.5.5. Decyzja o zaufaniu podpisowi elektronicznemu podejmowana jest przed otrzymaniem odpowiedzi OCSP o statusie certyfikatu, wysłanej na żądanie złożone później niż w momencie wygenerowania podpisu lub wcześniej niż kolejna lista CRL po wygenerowaniu podpisu.
Objaśnienia U5.5.5.
W regulacjach większości urzędów za moment unieważnienia certyfikatu uważa się moment wystawienia najbliższej listy CRL zawierającej informację o unieważnieniu certyfikatu.
U5.5.6. Przy odbiorze podpisanych danych certyfikat należący do nadawcy nie jest sprawdzany.
Objaśnienia U5.5.6.
Przykład ataku. W odniesieniu do certyfikatów SSL: nie można sprawdzić zgodności adresu wywoływanego serwera z wartością pola CN w certyfikacie.
Przykład ataku. Atakujący złamali klucze podpisu elektronicznego jednego z uczestników systemu płatności. Następnie włamali się do sieci innego uczestnika i w jego imieniu przesłali dokumenty płatnicze podpisane zhakowanymi kluczami na serwer rozliczeniowy systemu płatności. Jeśli serwer jedynie analizuje zaufanie i nie sprawdza zgodności, wówczas fałszywe dokumenty zostaną uznane za uzasadnione.
U6. Błędne przyjęcie dokumentów elektronicznych do realizacji spowodowane problemami w organizacji zarządzania dokumentami elektronicznymi.
Rozkład
U6.1. Odbiorca nie wykrywa duplikacji otrzymanych dokumentów.
Objaśnienia U6.1.
Przykład ataku. Osoby atakujące mogą przechwycić dokument przesyłany do odbiorcy, nawet jeśli jest on chroniony kryptograficznie, a następnie wielokrotnie przesłać go bezpiecznym kanałem transmisji danych. Jeśli odbiorca nie zidentyfikuje duplikatów, wszystkie otrzymane dokumenty będą postrzegane i przetwarzane jako różne dokumenty.
U7. Nieuprawniony dostęp do danych chronionych w trakcie ich przetwarzania przez CIPF
Rozkład
U7.1. <…> z powodu wycieku informacji kanałami bocznymi (atak na kanał boczny).
Objaśnienia U7.1.
Przykład .
U7.2. <…> w związku z neutralizacją zabezpieczeń przed nieuprawnionym dostępem do informacji przetwarzanych na CIPF:
U7.2.1. Działanie CIPF z naruszeniem wymagań opisanych w dokumentacji CIPF.
U7.2.2. <…>, przeprowadzone ze względu na obecność luk w:
U7.2.2.1. <…> środki ochrony przed nieuprawnionym dostępem.
U7.2.2.2. <…> sam CIPF.
U7.2.2.3. <…> środowisko operacyjne narzędzia kryptograficznego.
Przykłady ataków
Omówione poniżej scenariusze zawierają oczywiście błędy związane z bezpieczeństwem informacji i służą jedynie ilustracji możliwych ataków.
Scenariusz 1. Przykład realizacji zagrożeń U2.2 i U4.2.
Opis obiektu
Oprogramowanie AWS KBR i podpis CIPF SCAD instalowane są na komputerze fizycznym, który nie jest podłączony do sieci komputerowej. FKN vdToken służy jako nośnik kluczy w trybie pracy z kluczem niewymiennym.
Regulamin rozliczeń zakłada, że specjalista ds. rozliczeń ze swojego służbowego komputera pobiera wiadomości elektroniczne w postaci zwykłego tekstu (schemat starej stacji roboczej KBR) ze specjalnego bezpiecznego serwera plików, następnie zapisuje je na przenośnym dysku flash USB i przesyła na stację roboczą KBR, gdzie są szyfrowane i podpisane. Następnie specjalista przesyła bezpieczne wiadomości elektroniczne na wyobcowany nośnik, a następnie za pośrednictwem swojego służbowego komputera zapisuje je na serwerze plików, skąd trafiają do UTA, a następnie do systemu płatniczego Banku Rosji.
W tym przypadku kanałami wymiany otwartych i chronionych danych będą: serwer plików, komputer służbowy specjalisty oraz nośniki wyalienowane.
Atak
Nieuprawnieni napastnicy instalują na komputerze służbowym specjalisty system zdalnego sterowania i w momencie zapisywania zleceń płatniczych (wiadomości elektronicznych) na nośnik przenośny zastępują zawartość jednego z nich czystym tekstem. Specjalista przekazuje zlecenia płatnicze do zautomatyzowanego stanowiska KBR, podpisuje je i szyfruje, nie zauważając zamiany (na przykład ze względu na dużą liczbę zleceń płatniczych w samolocie, zmęczenie itp.). Następnie fałszywe zlecenie płatnicze, przechodząc przez łańcuch technologiczny, wchodzi do systemu płatności Banku Rosji.
Scenariusz 2. Przykład realizacji zagrożeń U2.2 i U4.2.
Opis obiektu
Komputer z zainstalowaną stacją roboczą KBR, SCAD Signature i podłączonym nośnikiem kluczy FKN vdToken pracuje w wydzielonym pomieszczeniu bez dostępu personelu.
Specjalista ds. obliczeń łączy się ze stacją roboczą CBD w trybie zdalnego dostępu poprzez protokół RDP.
Atak
Atakujący przechwytują szczegóły, za pomocą których specjalista ds. obliczeń łączy się i współpracuje ze stacją roboczą CBD (np. poprzez złośliwy kod na jego komputerze). Następnie łączą się w jego imieniu i wysyłają fałszywe zlecenie płatnicze do systemu płatniczego Banku Rosji.
Scenariusz 3. Przykład realizacji zagrożenia U1.3.
Opis obiektu
Rozważmy jedną z hipotetycznych opcji wdrożenia modułów integracji ABS-KBR dla nowego schematu (AWS KBR-N), w którym podpis elektroniczny dokumentów wychodzących następuje po stronie ABS. W tym przypadku założymy, że ABS działa w oparciu o system operacyjny nieobsługiwany przez podpis CIPF SKAD i w związku z tym funkcjonalność kryptograficzna jest przenoszona na osobną maszynę wirtualną – integrację „ABS-KBR” moduł.
Jako nośnik klucza używany jest zwykły token USB działający w trybie odzyskiwalnego klucza. Podczas podłączania kluczowych nośników do hypervisora okazało się, że w systemie nie ma wolnych portów USB, dlatego zdecydowano się podłączyć token USB poprzez sieciowy koncentrator USB, a na wirtualnym komputerze zainstalować klienta USB-over-IP maszynę, która komunikowałaby się z koncentratorem.
Atak
Osoby atakujące przechwyciły klucz prywatny podpisu elektronicznego z kanału komunikacji pomiędzy koncentratorem USB a hiperwizorem (dane przesyłane były w postaci zwykłego tekstu). Mając klucz prywatny, napastnicy wygenerowali fałszywe zlecenie płatnicze, podpisali je podpisem elektronicznym i przesłali do zautomatyzowanego stanowiska pracy KBR-N w celu realizacji.
Scenariusz 4. Przykład realizacji zagrożeń U5.5.
Opis obiektu
Rozważmy ten sam obwód, co w poprzednim scenariuszu. Zakładamy, że wiadomości elektroniczne przychodzące ze stacji roboczej KBR-N trafiają do folderu …SHAREIn, a te wysyłane na stację roboczą KBR-N i dalej do systemu płatniczego Banku Rosji trafiają do folderu …SHAREout.
Założymy także, że przy wdrażaniu modułu integracji listy unieważnionych certyfikatów będą aktualizowane dopiero w momencie ponownego wydania kluczy kryptograficznych, a także, że wiadomości elektroniczne otrzymane w folderze …SHAREIn będą sprawdzane jedynie pod kątem kontroli integralności i kontroli zaufania do klucza publicznego podpis elektroniczny.
Atak
Napastnicy, korzystając z kluczy skradzionych w poprzednim scenariuszu, podpisali fałszywe zlecenie płatnicze zawierające informację o wpłynięciu pieniędzy na konto oszukańczego klienta i wprowadzili je do bezpiecznego kanału wymiany danych. Ponieważ nie ma weryfikacji, czy zlecenie płatnicze zostało podpisane przez Bank Rosji, zostaje ono przyjęte do realizacji.
Źródło: www.habr.com