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ściPuchalski, R, „Bezpieczeństwo sieci teleinformatycznych”, Przegląd Naukowo-Metodyczny. Edukacja dla Bezpieczeństwa 2020, 2(47), 160-167..
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. thumb|Bankomat z leżącym obok modemem – przykład poważnego zagrożenia
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 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 na ataki typu przepełnienie bufora, nadużycie szablonu formatowania funkcji *printf() (ang. ) 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
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 (), 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.
Projektowanie z myślą o bezpieczeństwie Istnieją dwa podstawowe nurty w walce z zagrożeniami bezpieczeństwa. Pierwszym z nich jest możliwie skuteczne zapobieganie powstawaniu takich usterek. Chociaż wyeliminowanie błędów zabezpieczeń w skomplikowanych systemach teleinformatycznych jest w praktyce niemożliwe (lub przynajmniej nieekonomiczne), zaproponowano szereg metod, które pozwalają na zredukowanie ryzyka pomyłek przy tworzeniu oprogramowania.
Opracowane zostało wiele międzynarodowych standardów opisujących metody oceny bezpieczeństwa architektury systemów teleinformatycznych. Przykładem są normy Common Criteria ISO/IEC 15408, ITSEC czy FIPS, częściowo wywodzące się z dokumentu TCSEC opracowanego przez Departament Obrony Stanów Zjednoczonych. Poniżej znajduje się omówienie kluczowych zagadnień, które zwykle rozpatrywane są przy takich ewaluacjach.
Odpowiednia budowa protokołów i interfejsów W odróżnieniu od drobnych błędów programistycznych, wybór nieprawidłowej i podatnej na ataki architektury rozwiązania często jest problemem, którego skorygowanie okazuje się niezwykle czasochłonne i wymaga znacznych nakładów finansowych. Co więcej, w niektórych przypadkach, na przykład przy nieprawidłowej interpretacji zagrożeń związanych z architekturami klient-serwer, skorygowanie problemu może być po prostu niemożliwe. Typowym przykładem są współczesne kłopoty ze spamem, które w dużej mierze wynikają z historycznej, przyjętej w 1982 roku budowy protokołu SMTP. Ze względu na popularność i znaczenie tego protokołu, znacząca modyfikacja SMTP jest dziś w praktyce niewykonalna.
Podobne zasady dotyczą interfejsów użytkownika – gdy zaprojektowane są w nieintuicyjny i niekonsekwentny sposób, sprzyjają popełnianiu błędów przez operatora. Późniejsze skorygowanie tych błędów może być bardzo trudne.
W związku z tym, zrozumienie i analiza zagrożeń na etapie projektowania platformy są zwykle wymieniane jako kluczowy element budowy bezpiecznych rozwiązań teleinformatycznych. W praktyce problem ten jest często zaniedbywany.
Wybór metod programistycznych thumb|Schemat automatu skończonego, jednej z metod budowania weryfikowalnego kodu Na skutek zmęczenia lub pośpiechu, nawet najlepiej wyszkoleni i doświadczeni programiści mogą popełniać rudymentarne, oczywiste dla innych błędy. Świadczy o tym choćby odnalezienie wielu podatności w tworzonych przez ekspertów programach OpenSSL czy OpenSSH. Pewne sposoby tworzenia aplikacji, przez swoją złożoność lub brak wsparcia dla dodatkowej kontroli kodu, naturalnie sprzyjają pomyłkom tego typu.
Aby zapobiegać temu zjawisku, stworzono języki, które w odróżnieniu np. od C++ lub Javy wymagają od programistów przestrzegania ścisłego rygoru pracy, zmierzającego do wyeliminowania ryzykownych struktur programistycznych. Przykładem takiego języka jest Ada. Postuluje się także liczne bezpieczne metody programistyczne oraz stosowanie niewielkich, przejrzystych i łatwych do weryfikacji bloków funkcjonalnych pracujących jako możliwie niezależne automaty skończone.
Metody te wymagają dodatkowego przeszkolenia programistów i podnoszą koszty oraz czasochłonność wdrożeń, przez co ich zastosowanie komercyjne jest znikome.
Testowanie jakości aplikacji Procesy zapewniania jakości mogą i niemal zawsze powinny uwzględniać także weryfikację bezpieczeństwa zaimplementowanych rozwiązań technologicznych. Podstawowe metody prowadzenia takich analiz są omówione poniżej.
Przegląd kodu źródłowego Przegląd kodu źródłowego to procedura polegająca na inspekcji kodu w poszukiwaniu potencjalnie niebezpiecznych konstrukcji lub oczywistych pomyłek. Może być przeprowadzona ręcznie przez doświadczonego specjalistę, lub dokonana ze wsparciem narzędzi automatycznych (Flawfinder, , Cqual i inne). Często stosowaną nazwą tego drugiego wariantu jest statyczna analiza kodu. W obu przypadkach, zaletą jest wysoka skuteczność, wadą natomiast pozostaje wysoki koszt zatrudnienia eksperta oraz czasochłonność procesu.
Testy typu czarna skrzynka Termin ten opisuje badania zachowania programu binarnego lub platformy, bez dodatkowej wiedzy o sposobie wewnętrznej konstrukcji programu. Może być przeprowadzona ręcznie, często przy wykorzystaniu debuggerów lub – w pewnych sytuacjach – za pomocą specjalizowanych skanerów zabezpieczeń (Nmap, , WebInspect itp.). Zaletą jest możliwość zlecenia takich badań osobie trzeciej bez konieczności przekazania jej kodu źródłowego. Wadą jest trudność w diagnozowaniu subtelnych problemów implementacyjnych.
Testy siłowe
To działania przeprowadzane za pomocą narzędzi zautomatyzowanego losowego testowania (ang. ). Polegają na generacji przypadkowych danych wejściowych i obserwowaniu zachowania programu. Zaletą jest pełna automatyzacja procesu i możliwość ujawnienia bardzo złożonych błędów, np. wynikających z interakcji z systemem operacyjnym. Ich wadą jest niekompatybilność z bardziej skomplikowanymi protokołami komunikacyjnymi (co może prowadzić do odrzucenia wszelkich losowo wygenerowanych sekwencji na bardzo wczesnym etapie obróbki danych przez program).
Najlepsze efekty daje zwykle połączenie kilku spośród tych metod.
Formalne dowodzenie poprawności Dającą potencjalnie największe możliwości, ale współcześnie wciąż nieosiągalną metodą weryfikacji bezpieczeństwa programów jest formalne dowodzenie ich poprawności. W teorii przy szczegółowym opisie oczekiwanego zachowania aplikacji lub platformy oraz danym algorytmie jej działania istnieje potencjalna możliwość wykorzystania systemów automatycznego dowodzenia twierdzeń do zbadania, czy napisany kod spełnia oczekiwania autora.