Sii Polska

SII UKRAINE

SII SWEDEN

  • Szkolenia
  • Kariera
Dołącz do nas Kontakt
Wstecz

Sii Polska

SII UKRAINE

SII SWEDEN

Wstecz

14.05.2025

Modelowanie zagrożeń dotyczących cyberbezpieczeństwa w systemach wbudowanych

14.05.2025

Modelowanie zagrożeń dotyczących cyberbezpieczeństwa w systemach wbudowanych

Zwiększenie bezpieczeństwa systemów wbudowanych pod kątem cyberzagrożeń wymaga stworzenia szeregów procesów, które będziemy musieli wykonywać, jeśli będzie nam zależało na tym, aby projektowane przez nas systemy wbudowane były bezpieczne i odporne na różnego rodzaju cyberataki. Niezwykle dynamiczny rozwój technologiczny, jaki nastąpił w ostatnich kilku latach, powoduje, że bezpieczeństwo to już nie tylko opcja, ale konieczność.

Żeby wiedzieć, jak zabezpieczyć nasz system, musimy najpierw przeanalizować słabości i zagrożenia, jakie mogą wystąpić w projektowanych przez nas urządzeniach wbudowanych. Jedną z podstawowych i bardzo skutecznych technik pozwalających na wykonanie tego zadania jest modelowanie zagrożeń (ang. threat modeling).

Pojęcia podstawowe

Modelowanie zagrożeń możemy zdefiniować jako proces analizowania systemu w celu poszukiwania jego słabości (ang. weakness), które mogą przeistoczyć się w luki (ang. vulnerabilites). Napastnik poprzez wykorzystanie słabości systemu może spowodować zagrożenie (ang. threat) i uzyskać dostęp do danych w nieautoryzowany sposób. Konsekwencje takiego działania mogą prowadzić do wielu niebezpieczeństw i zagrożeń.

Celem modelowania zagrożeń jest zidentyfikowanie słabości, zanim zostaną one wykorzystane do włamania się do systemu. Proces ten polega na scharakteryzowaniu elementów systemu, które muszą zostać zmodyfikowane w celu zmniejszenia ryzyka i podniesienia poziomu bezpieczeństwa (ang. security level).

Wykonując modelowanie zagrożeń, patrzymy na system jako zbiór komponentów (pamięci, magistrale komunikacyjne, procesory, dane), które ze sobą współpracują w celu realizacji zaprogramowanej logiki. Następnie próbujemy zwizualizować i przewidzieć, jak komponenty oraz wzajemne interakcje mogą zawieść i zostać wykorzystane przez osoby atakujące (ang. threat actors). Najistotniejszym elementem w całym procesie modelowania zagrożeń jest spojrzenie na system z perspektywy napastnika.

Cały proces analizowania i modelowania zagrożeń możemy przyśpieszyć poprzez próbę odpowiedzi na 4 pytania:

  • Nad czym pracujemy?
  • Co może pójść nie tak?
  • Co zamierzamy z tym zrobić?
  • Czy dobrze wykonaliśmy naszą pracę?

Po co nam modelowanie zagrożeń?

Modelowanie zagrożeń w początkowej fazie może zostać potraktowane jako dodatkowy, niezrozumiały koszt. Interpretacja ta wynika z błędnego rozumowania i braku wiedzy na temat korzyści możliwych do osiągnięcia w dłuższej perspektywie:

  • przyśpieszenie prac projektowych i programistycznych,
  • uproszczona architektura, jasno zdefiniowane strefy bezpieczeństwa,
  • szybszy proces testowania,
  • większy poziom bezpieczeństwa systemu,
  • lepsze rozumienie potencjalnych zagrożeń przez zespół,
  • pozytywny wpływ na jakość oprogramowania i czas jego implementacji.

Poprawnie przeprowadzony proces modelowania zagrożeń zmienia podejście zespołu  do tematów bezpieczeństwa pod kątem zrozumienia i poprawnego implementowania poszczególnych elementów.

Musimy pamiętać, że wdrożenie zabezpieczeń w naszych produktach to nie tylko pojedyncze zadanie do wykonania, a cały proces w celu zmiany nastawienia. Z pewnością koszty związane z procesem modelowania zagrożeń będą znacząco niższe niż koszty, jakie będziemy musieli ponieść w przypadku potencjalnego cyberataku, na który systemy wbudowane w ostatnich latach są mocno narażone.

Proces

Proces modelowania zagrożeń powinien być wykonywany jako jedna z czynności w ramach bezpiecznego cyklu rozwoju oprogramowania (ang. secure software development lifecycle). Jeżeli nie zdefiniowaliśmy jeszcze takiego procesu, to należy wykonywać modelowanie zagrożeń w trakcie:

  • procesu projektowania urządzenia,
  • rozwoju programowania jako cyklicznie powtarzana operacja,
  • przygotowywania oficjalnych wydań oprogramowania w związku z nowymi funkcjami lub poprawkami błędów.

Optymalnie modelowanie zagrożeń powinniśmy wykonać do każdej nowo implementowanej funkcji w celu identyfikacji potencjalnych słabości.

Wykonywanie procesu modelowania zagrożeń po raz pierwszy będzie wymagało więcej czasu, który będzie zależny od:

  • skomplikowania systemu,
  • aktualnego stanu sprzętu i oprogramowania,
  • wiedzy i doświadczenia osób odpowiedzialnych za wykonanie procesu.

Czynności w trakcie procesu modelowania zagrożeń

Proces modelowania zagrożeń w zależności od potrzeb może być modyfikowany i dostosowywany do projektu.

Ogólnie możemy scharakteryzować go jako zbiór następujących czynności:

  • Stwórz model systemu – zidentyfikuj najważniejsze elementy systemu, które mogą stać się celem ataku lub zostać wykorzystane do przeprowadzeniu ataku. W ten sposób musimy odnaleźć wszystkie istotne elementy takie jak: dane, magistrale komunikacyjne, pojedyncze komponenty systemy, elementy zewnętrzne.
  • Wykonaj dekompozycję systemu – po stworzeniu listy wszystkich istotnych elementów musimy zdekomponować nasz system na pojedyncze elementy, odkryć logikę, przepływ danych i sterowania oraz to, jaki wpływ poszczególne elementy mogą mieć na system. Do tego celu musimy wykorzystać techniki tworzenia diagramów, które pozwolą nam na narysowanie przepływu danych, logiki oraz elementów istotnych z punktu widzenia poprawności działania całego systemu.
  • Zidentyfikuj zagrożenia – poprzez wykorzystanie jednej z metodologii przedstawionych poniżej zidentyfikuj zagrożenia oraz możliwe ścieżki ataku. Opisz wszystkie wykryte scenariusze.
  • Oceń zagrożenia, wylicz ryzyko i priorytety – dla zidentyfikowanych zagrożeń oceń ryzyko ich wystąpienia, wpływu, jaki mogą mieć na nasz system. Do tego celu należy stworzyć system oceny ryzyka. Standard ISO/IEC 62443 zawiera propozycje, jak taką operację możemy wykonać. Drugą popularną metodą oceny zagrożeń jest wykorzystanie systemu CVSS (ang. Common Vulnerability Scoring System). Jest to standard do oceny wagi luk w zabezpieczeniach systemów komputerowych. Wyniki są obliczane na podstawie wzoru zawierającego kilka wskaźników, które w przybliżeniu określają łatwość i skutki wykorzystania wykrytego zagrożenia.
  • Przygotuj plan łagodzenia zagrożeń (ang. countermeasures, mitigation plan) – znając zagrożenia i ryzyka ich występowania, zidentyfikuj, w jaki sposób można je zminimalizować lub naprawić. Plan implementacji powinien uwzględniać aktualny stan produktu i oprogramowania. Podczas definiowania i projektowania środków zaradczych nie ograniczaj się tylko do zmian programowych. Obecnie istnieje wiele rozwiązań sprzętowych, które pozwalają na skuteczne zwiększenie poziomu bezpieczeństwa i zminimalizowania wykrytych zagrożeń.

Metodologie poszukiwania zagrożeń

Przygotowanie modelu systemu, jego dekompozycja na poszczególne elementy będzie jednym z łatwiejszych zadań w całym procesie. Główna trudność skupi się na modelowaniu potencjalnych zagrożeń, identyfikowaniu słabości.

Z pomocą w tym etapie przychodzą różne metodologie, które poprzez zdefiniowane punkty ułatwiają cały proces w wielu aspektach i pozwalają na odkrywanie niewidocznych dotąd słabości.

Najważniejsze metody

Spośród najważniejszych metod modelowania zagrożeń możemy wymienić:

  • STRIDE (ang. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service i Elevation of Privilege) – opracowany przez Microsoft pomaga identyfikować potencjalne zagrożenia, kategoryzując je do tych sześciu kategorii. Metoda chętnie wykorzystywana w systemach Embedded.
  • DREAD (ang. Damage potential, Reproducibility, Exploitable, Affected users, Discoverability) – metodologia, również opracowana przez Microsoft, ocenia zagrożenia na podstawie pięciu kryteriów;
    • potencjalne szkody,
    • powtarzalność,
    • możliwość wykorzystania,
    • dotknięci użytkownicy,
    • możliwość odlrycia.
      Pomaga ustalać priorytety zagrożeń na podstawie ich potencjalnego wpływu.
  • PASTA (ang. Process for Attack Simulation and Threat Analysis) – ta skoncentrowana na ryzyku metodologia obejmuje siedem etapów, od definiowania celów biznesowych po analizę i modelowanie zagrożeń, a ostatecznie ocenę ryzyka.
  • TRIKE – metodologia prezentuje podejście do modelowania zagrożeń, które kładzie nacisk na ocenę ryzyka z perspektywy aktywów. W przeciwieństwie do innych metod, które koncentrują się na zagrożeniach lub podatnościach, Trike skupia się na tym, co chronimy, a nie na tym, jak ktoś może to zaatakować.
  • VAST (ang. Visual, Agile, and Simple Threat) – ta metodologia ma na celu zintegrowanie modelowania zagrożeń z procesami rozwoju Agile, zapewniając skalowalne podejście, z którego mogą korzystać zarówno programiści jak i specjaliści ds. bezpieczeństwa.
  • OCTAVE (ang. Operationally Critical Threat, Asset, and Vulnerability Evaluation) – opracowana przez Carnegie Mellon University kompleksowa metodologia oceny ryzyka, która koncentruje się na ryzyku organizacyjnym i praktykach bezpieczeństwa.

Każda z opisanych powyżej metodologii niesie ze sobą wiele zalet i ułatwia przeprowadzenie procesu modelowania zagrożeń. Warto eksperymentować i wykonywać modelowanie zagrożeń, używając różnych metod w celu osiągnięcia jak najlepszych wyników.

Raporty

Poza metodologiami, wiele organizacji publikuje cyklicznie raporty przedstawiające aktualny stan zagrożeń (ang. Threat landscape). Mogą one być wykorzystywane jako dodatkowe źródło w celu identyfikacji zagrożeń. Dzięki nim możemy się dowiedzieć, jakie obecnie są trendy, jeśli chodzi o zagrożenia i w którą stronę napastnicy kierują swoją uwagę. Dzięki tym informacjom wiemy, na których elementach systemu musimy się bardziej skupić.

Dobrym przykładem może być tutaj organizacja ENISA (ang. European Union Agency for Cybersecurity), która co roku publikuje bardzo szczegółowy raport zagrożeń, aktualne trendy związane z cyberatakami, a także metody przeciwdziałania im.

Czego szukamy?

Znając podstawy modelowania zagrożeń, procesy i metodologie, dalej będziemy się zastanawiać, czego tak naprawdę szukamy, nad jakimi elementami powinniśmy się skupić bardziej. Wraz ze zdobywaniem doświadczenia pytań będzie coraz mniej i identyfikowanie zagrożeń będzie szybsze i bardziej intuicyjne.

Na początku warto się skupić na wyszukiwaniu obszarów, gdzie występują elementy opisane poniżej:

  • brak szyfrowania protokołów,
  • brak autoryzacji, logowania, autentykacji,
  • brak szyfrowania zapisywanych danych,
  • brak konieczności przejścia dodatkowych autoryzacji w celu dostępu do niektórych usług,
  • brak sprawdzania integralności danych podczas ich przesyłania i przechowywania,
  • błędnie używana kryptografia.

Standardy

Poza metodologiami mamy jeszcze standardy międzynarodowe, które poprzez zdefiniowany i ustrukturyzowany proces wprowadzają dodatkowe czynności, jakie musimy wykonać w ramach modelowania zagrożeń, czym rozszerzają zakres podstawowy modelowania zagrożeń. Są one charakterystyczne dla dziedzin, których dotyczą.

Mają na celu stworzenie powtarzalnego i przewidywalnego procesu ze ściśle określoną kolejnością i zasadami. Do najważniejszych (najbardziej popularnych) możemy zaliczyć:

  • ISO/SAE 21434 – standard popularny w branży motoryzacyjnej,
  • ISA/IEC 62443 – standard używany w branży przemysłu (ang. general industry), chętnie wykorzystywane do urządzeń Internetu rzeczy (ang. IoT),
  • TS 50701 – standard używany w branży kolejowej.
ofery pracy

Podsumowanie

Modelowanie zagrożeń jest procesem, który wymaga ciągłej nauki i doskonalenia. Rozwój technologii i sztucznej inteligencji powoduje, że wciąż pojawiają się nowe zagrożenia. Aby skutecznie im przeciwdziałać, musimy podnosić nasze umiejętności i modyfikować nasz proces modelowania zagrożeń o zdobytą wiedzę i doświadczenie.

Dobrym zobrazowaniem będzie tutaj porównanie modelowania zagrożeń do popularnej zabawy w kotka i myszkę, gdzie napastnicy, poprzez wykorzystanie technologii, będą szukać nowych metod włamania się do naszego systemu. My natomiast, z wykorzystaniem niejednokrotnie tych samych technologii, musimy temu przeciwdziałać.

***

Jeśli interesuje Cię tematyka embedded oraz regulacji prawnych, zajrzyj koniecznie również do innych artykułów naszych specjalistów 🙂

5/5
Ocena
5/5
Avatar

O autorze

Marek Natunewicz

Dzięki ponad 14-letniemu doświadczeniu w programowaniu niskopoziomowym mikrokontrolerów ARM i procesorów DSP Marek posiada dogłębną wiedzę na temat systemów RTOS. Tworzył oprogramowanie do automatyki biurowej i domowej, systemów przeciwpożarowych oraz przenośnych przyrządów pomiarowych. Obecnie koncentruje się na projektowaniu i wdrażaniu rozwiązań z zakresu bezpieczeństwa dla urządzeń wbudowanych. Marek jest doświadczonym trenerem, prelegentem na branżowych spotkaniach i webinarach oraz autorem artykułów technicznych

Wszystkie artykuły autora

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Może Cię również zainteresować

Dołącz do nas

Sprawdź oferty pracy

Pokaż wyniki
Dołącz do nas Kontakt

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?