Bankomat Diebold z leżącym obok modemem – przykład poważnego zagrożenia

Bezpieczeństwo teleinformatyczne – zbiór zagadnień z dziedziny telekomunikacji i informatyki związany z szacowaniem i kontrolą ryzyka wynikającego z korzystania z komputerów, sieci komputerowych i przesyłania danych do zdalnych lokalizacji, rozpatrywany z perspektywy poufności, integralności i dostępności.

Budowanie bezpiecznych systemów teleinformatycznych i aplikacji jest celem starań projektantów sieciowych i programistów, a także przedmiotem studiów teoretycznych, zarówno w dziedzinie telekomunikacji oraz informatyki, jak i ekonomii. Zaowocowało to opracowaniem metod oceny bezpieczeństwa i kontrolowania zagrożeń, których przegląd znajduje się poniżej. Mimo tych starań, ze względu na złożoność i czasochłonność wielu spośród proponowanych procesów, luki zabezpieczeń stanowią jednak poważny i wymierny problem dla użytkowników sieci teleinformatycznych.

Teoria i praktyka bezpiecznych systemów komputerowych

Według powszechnie przytaczanej definicji, prawdziwie bezpieczny system teleinformatyczny jest wyidealizowanym urządzeniem, które poprawnie i w całości realizuje tylko i wyłącznie cele zgodne z intencjami właściciela.

W praktyce, budowa skomplikowanego systemu spełniającego te założenia jest z reguły niemożliwa. Dzieje się tak nie tylko ze względu na ryzyko wystąpienia prozaicznych usterek i błędów, ale także na trudność określenia i sformalizowania często sprzecznych oczekiwań projektanta oprogramowania, programisty, prawowitego właściciela systemu, posiadacza przetwarzanych danych, czy w końcu użytkownika końcowego. Nawet po ich określeniu, w wielu przypadkach trudne lub niemożliwe jest też automatyczne dowiedzenie, że dany program spełnia sformalizowane oczekiwania. Z tych względów, zapewnianie bezpieczeństwa sprowadza się najczęściej do całościowego zarządzania ryzykiem: określane są potencjalne zagrożenia, szacowane prawdopodobieństwo ich wystąpienia, oceniany potencjał strat – a następnie podejmowane są kroki zapobiegawcze w zakresie, który jest racjonalny z uwagi na możliwości techniczne i względy ekonomiczne.

Geneza błędów zabezpieczeń

Sytuacje, w których oprogramowanie nie realizuje prawidłowo funkcji zamierzonych przez autora oraz właściciela systemu, towarzyszą ludziom od zarania dziejów informatyki, często prowadząc do kosztownych wypadków i tragedii. Do przykładów można zaliczyć utratę sondy NASA Mariner 1 w 1962 na skutek błędu w kodzie napisanym w języku FORTRAN, czy śmierć pacjentów na skutek wadliwego oprogramowania maszyn Therac-25 w latach 80.

Szczególnie w dobie łączności modemowej, sieci rozległych i Internetu, problemem stały się także sytuacje, w których chociaż oprogramowanie działa zgodnie z oczekiwaniami autora i właściciela systemu, pozwala oprócz tego osobom trzecim na interakcję z systemem w zakresie, który nie był zamierzony ani oczekiwany. Takie zachowanie określane jest jako błąd zabezpieczeń.

Scenariusze, które mogą prowadzić do nieautoryzowanego wykorzystania systemu są dzielone na kilka grup, w zależności od swego pochodzenia.

Błędy projektowe

Termin ten opisuje sytuacje, w których założenia dla oprogramowania opierały się na błędnych przesłankach, na przykład na mylnym rozumieniu zasad funkcjonowania sieci komputerowych i budowy wykorzystywanych protokołów komunikacyjnych. Do takich błędów można zaliczyć wykorzystanie szyfrów podatnych na ataki, jak miało to miejsce w przypadku protokołu Needhama-Schroedera użytego w usłudze Kerberos; a także nieprawidłowy dobór mechanizmów uwierzytelniania, czy pełne zaufanie informacjom przesyłanym przez klienta w architekturze klient-serwer. Ich skutkiem może być sytuacja, w której nie można ufać wynikom pracy aplikacji i integralności przetwarzanych przez nią danych.

Błędy implementacyjne

Do tej grupy zaliczają się wszelkie pomyłki techniczne popełniane przez programistów na skutek ich niewiedzy lub nieuwagi. Przykładem jest niewystarczające sprawdzanie parametrów lub wyników działania wywołań systemowych, co może prowadzić do podatności na ataki typu przepełnienie bufora, nadużycie szablonu formatowania funkcji *printf() (ang. format string attack) czy przekroczenie zakresu liczb całkowitych. Częstym efektem błędów implementacyjnych jest możliwość przejęcia pełnej kontroli nad procesem przez osoby niepowołane oraz możliwość bezpośredniej interakcji z systemem operacyjnym.

Błędy konfiguracyjne

Kategoria ta obejmuje pomyłki popełniane przez administratorów, którzy przygotowują oprogramowanie do wykorzystania przez użytkowników. Mogą one powstawać na skutek niezrozumienia dokumentacji lub sposobu działania aplikacji, albo zwykłej niestaranności. Przykładem może być ustawienie trywialnych haseł dla uprzywilejowanych kont, albo udostępnienie zbędnej funkcjonalności bez adekwatnej kontroli dostępu.

Błędy operatora

 Zapoznaj się również z: inżynieria społeczna (informatyka).

Do tej klasy zaliczają się zachowania użytkowników, którzy nie rozumieją w pełni funkcji oprogramowania i zasad działania systemów komputerowych. Przykładem może być uruchamianie załączników od niepewnych nadawców przysłanych w poczcie elektronicznej, ignorowanie komunikatów ostrzegawczych, przypadkowa zmiana opcji programu, ale także np. utrata nośnika z kopią zapasową danych.

Warto zaznaczyć, że beztroska ze strony użytkowników jest zwykle bardzo poważnym problemem – na przykład, według głośnych swego czasu badań, ponad 70% ankietowanych deklaruje wolę wymiany swoich haseł do systemów komputerowych za tabliczkę czekolady.

Spory dotyczące kategoryzacji

Dwie ostatnie grupy błędów są przedmiotem trwających debat. Część specjalistów uważa, że winą za nieprawidłowe konfigurowanie i używanie oprogramowania nie można obarczać autora systemu, i w związku z tym nie powinny być rozpatrywane jako techniczne problemy zabezpieczeń. Inny pogląd mówi jednak, że zgodnie z zasadą minimalnego zaskakiwania (ang. principle of least astonishment), jeśli program sprzyja popełnianiu błędów przez użytkownika lub administratora na skutek oferowania nieintuicyjnej funkcjonalności, jest to usterka w samym oprogramowaniu.