Dlaczego systemy nie są bezpieczne i co programiści mogą z tym zrobić

To może być najbardziej powszechną radą dotyczącą bezpieczeństwa, jaką kiedykolwiek otrzymasz, ale upewnij się, że używasz naprawionego i zaktualizowanego oprogramowania. Jest to dobra rada, zważywszy na to, że każdy system został kiedyś zaprojektowany i wdrożony. Wystarczy przyjrzeć się niedawnej epidemii WannaCry, aby zrozumieć, w jaki sposób pojedyncza luka może siać spustoszenie na skalę globalną.
Ale mniej mówi się o tym, o czym mówił F-Secure Główny Konsultant ds. Bezpieczeństwa, Olle Segerdahl, podczas ubiegłorocznej konferencji T2 – jak opracować systemy, które są bezpieczne w pierwszej kolejności.
Krótko mówiąc, problemem jest to, że wiele firm traktuje bezpieczeństwo jako problem wtórny. Jest to dodatek do produktu lub usługi. Jak wskazuje Olle, firmy mają tendencję do rozwijania czegoś, a następnie testowania, aby sprawdzić, czy jest wystarczająco bezpieczny, aby go użyć.
Istnieją różne sposoby sprawdzania poziomu zabezpieczeń danego systemu lub produktu. Zazwyczaj firmy przeprowadzają szereg testów bezpieczeństwa (penetracji) na prawie gotowym produkcie, aby znaleźć problemy. Następnie po prostu rozwiązują wszelkie problemy zidentyfikowane przez testera i przechodzą dalej.
Testy penetracyjne są cenne, ale bywają ograniczone. Ich efektywność zależy od tego, ile czasu i pieniędzy poświęca się firmom na przeprowadzanie testów, bez względu na to, czy są wykonywane jednorazowo czy okresowo oraz co dokładnie obejmują testy (lub, co ważniejsze, czego nie obejmują) etc.
Według Olle’a testowanie bezpieczeństwa czegoś po jego stworzeniu nie wystarczy, by odpowiedzieć na pytanie za milion dolarów: czy system jest bezpieczny?
Testy mogą dostarczyć użytecznej listy błędów do rozwiązania, ale znajdowanie i naprawianie ich to nie to samo, co mówienie, że system jest bezpieczny. Jak wspomniano powyżej, istnieją problemy z metodami i zasobami, które mogą ograniczyć skuteczność testów i zwiększyć szanse na przeoczenie poważnych problemów bezpieczeństwa. To sprawia, że ​​programiści raczej reagują na już pojawiające się problemy z bezpieczeństwem niż proaktywnie minimalizują błędy, odpowiednio je testując i zawczasu łatając. To wszystko przyczynia się do ułatwienia ewentualnego włamania do systemu przez hakerów, co może narazić zarówno sprzedawców oprogramowania, jak i ich klientów na poważne problemy.

Sprawdzenie bezpieczeństwa systemu
Zatem, jak znaleźć wiarygodną odpowiedź na pytanie “czy ten system jest bezpieczny?” lub – jeszcze lepiej – “czy więcej będzie kosztowało hakera włamanie do systemu i kradzież informacji niż są one warte?”.
Według Olle’a kwestia bezpieczeństwa to praktyka z branży transportowej, która jest przykładem dobrego podejścia do bezpiecznego rozwoju systemu. Sprawa bezpieczeństwa jest rodzajem strukturalnego argumentu mającego na celu wykazanie, że coś jest bezpieczne w użyciu w określonych warunkach i szeroko stosowane w celu ustalenia, czy ​​pojazd lub określone urządzenie jest bezpieczne dla ludzi do użycia w sposób taki, w jaki są do tego przeznaczone.
Podczas rozmowy Olle zwraca uwagę na przypadki zapewnienia bezpieczeństwa – a raczej ich uogólnienie – jako coś, co mogą wykorzystać deweloperzy. Wiąże się to z argumentacją, że oświadczenie dotyczące określonej właściwości systemu jest prawdziwe – to podejście, które Olle określa jako „zapewnienie bezpieczeństwa”.
Korzystając z tego podejścia, zespół programistów zaczyna od określenia wymogów bezpieczeństwa – na przykład tego, że system musi weryfikować tożsamość użytkownika przed udostępnieniem mu poufnych informacji – a następnie tworzy przypadek zapewnienia, który przekonuje ludzi, że system posiada tę właściwość. Weryfikacja polegałaby w dużej mierze na dowodach dostarczonych przez programistów, testerów, konsultantów i inne osoby zaangażowane w jej produkcję, tak aby były one oparte na faktach i zapewniały dokładny opis zabezpieczeń systemu.
Jednak co ważne, przypadek zapewnienia bezpieczeństwa może i powinien być tworzony oraz aktualizowany wraz z rozwojem systemu. Poprzez jednoczesne tworzenie systemu i testowanie, obydwie strony mogą się wzajemnie informować, zasadniczo łącząc ze sobą wymagania bezpieczeństwa z projektowaniem i wdrażaniem systemu. Same prace rozwojowe obejmowałyby kilka różnych kroków ułatwiających ten proces: analizę architektury lub „modelowanie zagrożeń”, aby dowiedzieć się, jakie zagrożenia musi zminimalizować system za pomocą kontroli bezpieczeństwa; prace inżynieryjne w zakresie bezpieczeństwa mające na celu poinformowanie projektu systemu i potwierdzenie, że wdrożono odpowiednie zabezpieczenia; oraz weryfikacja bezpieczeństwa wdrożonych kontroli w celu udowodnienia, że ​​są one rzeczywiście skuteczne.
Proces ten wyeliminowałby konieczność odroczenia prac zabezpieczających do końca fazy opracowywania, w którym to momencie jedyną opcją jest poleganie na testowaniu gotowego produktu, aby dowiedzieć się, co jest z nim nie tak – jest to proces, który może dać nieprzewidywalne wyniki (takie jak niespodziewane koszty, opóźnienia lub brak stwierdzonych niedociągnięć).
Zasadniczo, podejście zapewniające bezpieczeństwo pozwala firmom odpowiedzieć na pytanie „czy system jest bezpieczny?”, pokazując, że twórcy zaprojektowali i przetestowali produkt w sposób minimalizujący ryzyko luk w zabezpieczeniach. W ten sposób możesz upewnić się, że bezpieczeństwo zostało „wbudowane”, a nie „przykręcone” być może już po czasie.

Internet Rzeczy może użyć “gwarancji bezpieczeństwa”
Ciekawie jest zastanowić się nad zalewem “dziurawych” urządzeń Internetu Rzeczy, rozważając korzyści płynące z podejścia zapewniającego bezpieczeństwo. Naukowcy i konsultanci z F-Secure zaobserwowali liczne przypadki luk w kamerach internetowych, routerach i urządzeniach pamięci masowej w ciągu ostatnich 12 miesięcy.
Wiele firm, które nie mają doświadczenia w tworzeniu oprogramowania, obecnie produkuje inteligentne (lub podatne na zagrożenia Hypponena) gadżety. A kryminaliści uczą się wykorzystywać te gadżety, na przykład w bezprecedensowych atakach DDoS.
Niektórzy eksperci sugerują, że tylko i wyłącznie nowe przepisy zmuszą producentów urządzeń IoT do nadania zabezpieczeniom wyższego priorytetu. Ale model bezpieczeństwa, zalecany przez Olle’a podczas jego przemówienia, może być opłacalną alternatywą dla surowych przepisów, czyniąc zabezpieczenia bardziej praktycznymi i łatwiejszymi w obsłudze dla programistów.
Może nie być srebrnej kuli dla bezpieczeństwa, ale wszyscy skorzystają na tym, gdy bezpieczeństwo stanie się czymś więcej niż tylko refleksją.

X

FreshMail.pl