Natknęliśmy się ostatnio na ciekawe badania, które mówią, że programiści spędzają więcej czasu na utrzymywaniu, testowaniu i zabezpieczaniu istniejącego kodu niż na tworzeniu nowego. Luki w zabezpieczeniach są niestety kreowane podczas procesu tworzenia oprogramowania, ale zwykle ujawniają się dopiero po wdrożeniu aplikacji. Wiele błędów bezpieczeństwa można jednak rozwiązać na wcześniejszym etapie i istnieją odpowiednie metody i narzędzia do ich wykrycia.

Aby lepiej zrozumieć problem, warto spróbować odpowiedzieć na pytania, które każdy programista powinien sam sobie zadać: „Ile czasu poświęciłem nauce pisania funkcjonalnego kodu?”, „Ile zasobów poświęcam na edukację o bezpieczeństwie kodu?”, „Czy kiedykolwiek ktoś nauczył mnie, jak NIE programować?”.

Każdy popełnia błędy, nawet najlepsi programiści. Luki w softwarze są nieuniknione i powinny być wliczone i akceptowane jako koszt prowadzenia działalności w dziedzinie tworzenia oprogramowania. Jednakże z punktu widzenia bezpieczeństwa wszelkie nienaprawione błędy w kodzie są siłą napędową atakujących. Jeśli uda im się znaleźć w systemie przynajmniej jeden bug, który można wykorzystać, z pewnością to zrobią, aby wyrządzić ogromne szkody. Dobrze wiemy, chociażby z nagłówków gazet, że jedna mała podatność może spowodować straty setek milionów lub pogrążyć całą korporację.

Czy nie byłoby w takim razie lepiej zainwestować i wydać te pieniądze na wykrycie i usunięcie problemu w zarodku, zanim jeszcze ujrzy światło dzienne? Z autopsji wiemy, że lepiej zapobiegać, niż leczyć. Lepiej wykryć i zatrzymać atak lub usunąć podatność, niż naprawiać jego skutki i borykać się z problemami zepsucia reputacji.


Dlaczego aktualne podejście do bezpieczeństwa oprogramowania nie działa?

1. Zbyt duże poleganie na technologii (a za małe na ludziach)
Narzędzia do automatyzacji i bezpieczeństwa mają zmniejszyć obciążenie programistów i testerów poprzez skanowanie, wykrywanie i niwelowanie luk w oprogramowaniu. Jednak, chociaż narzędzia te przyczyniają się do polepszenia cyberbezpieczeństwa, badania pokazują, że wykrywają one tylko 45% ze wszystkich luk istniejących w kodzie.
Mogą też generować alarmy fałszywie dodatnie, co prowadzi do niepotrzebnych obaw, opóźnień i przeróbek kodu. Gorsze oczywiście są wyniki fałszywie ujemne, które dają niesłuszne poczucie bezpieczeństwa.

2. Rozłączna rola DevSec
DevSec jest to dość nowy trend w dziedzinie tworzenie oprogramowania, którego celem jest zatrudnianie pracowników znających się zarówno na programowaniu, jak i na bezpieczeństwie aplikacji i bezpieczeństwie końcowym użytkownika. Niestety zespoły deweloperów i zespoły bezpieczeństwa w znacznej większości pracują oddzielnie i mają inne, często sprzeczne, priorytety. Z tego powodu dochodzi do napięć pomiędzy tymi dwiema rolami.
W wyniku tego konfliktu prawdopodobnie połowa programistów regularnie wprowadza do środowiska produkcyjnego podatny kod. Luki wykryte później w cyklu rozwoju często nie są łagodzone lub kończą się dodatkowymi kosztami, opóźnieniami i dalszym ryzykiem. Takie są konsekwencje myślenia krótkoterminowego – ostatecznie lepiej byłoby naprawić problem u źródła, zamiast tracić czas i zasoby na znajdowanie błędów w kodzie w późniejszej części cyklu życia oprogramowania.

3. Monitorowanie łańcucha dostaw zamiast własnego kodu
Inny częsty błąd to skupianie się wyłącznie na bezpieczeństwie łańcucha dostaw oprogramowania i zajmowanie się tylko znanymi lukami w istniejących produktach i pakietach. Niezbędne jest radzenie sobie z wszelkimi lukami w komponentach innych firm, zależnościami lub środowiskiem operacyjnym, ale to nie pomoże w przypadku luk we własnym kodzie. Monitorowanie potencjalnych ataków za pomocą systemów IDS, IPS czy NGFW jest dobrym pomysłem, ale działania te dotyczą tylko konsekwencji cyberataków, a nie szukania przyczyny.


Kilka wskazówek

Liczba odkrywanych luk w zabezpieczeniach rośnie, a zagrożenia stwarzane przez hakerów stają się coraz bardziej wyrafinowane. Większość organizacji rozpoczyna wdrażanie bezpiecznego cyklu życia produktu po incydencie, tymczasem powinno to dziać się tak szybko, jak to tylko możliwe. W przypadku krytycznych podatności nawet godziny mogą oznaczać różnicę między brakiem trwałych szkód a katastrofą finansową.
Poniżej kilka rad i zaleceń „best practices”, zebranych od kilku znanych audytorów oraz wynikających ze wspomnianych przez nas wcześniej raportów.

1 — „Przewiń w lewo”, czyli rozszerz perspektywę bezpieczeństwa na wczesne fazy rozwoju oprogramowania
Samo poleganie na automatyzacji narzędzi bezpieczeństwa w stylu DevSecOps nie wystarczy, trzeba wdrożyć prawdziwą zmianę kultury pracy. SAST, DAST lub testy penetracyjne znajdują się już na końcu całego procesu tworzenia. Aby zwiększyć zakres działania, trzeba „przesunąć go w lewo” w całym cyklu i interesować się bezpieczeństwem już od samego początku.

2 — Przyjęcie podejścia opartego na bezpiecznym cyklu życia oprogramowania
Na przykład MS SDL lub OWASP SAMM zapewnią odpowiednie ramy procesów i będą dobrym punktem wyjścia do inicjatywy w zakresie cyberbezpieczeństwa.

3 — Obejmij cały swój ekosystem IT
Luki w zabezpieczeniach stron trzecich stanowią ogromne zagrożenie dla cyberbezpieczeństwa firmy, ale wewnętrzni programiści również mogą wprowadzać błędy do aplikacji. Musisz być w stanie wykrywać i usuwać luki w zabezpieczeniach lokalnie, w chmurze i w środowiskach innych firm, gdzie oprogramowanie działa już produkcyjnie.

4 — Przejdź od reakcji do zapobiegania
Dodaj defensywne koncepcje programowania do swoich wytycznych dotyczących pisania kodu. Potrzebna jest konkretna polityka z twardymi założeniami, która trafi do programistów na wszystkich szczeblach.

5 — Nastawienie na bezpieczeństwo ma większe znaczenie niż technologia
Zapory sieciowe i systemy IDS same w sobie nie ochronią stworzonego oprogramowania przed hakerami. Po prostu radzą sobie z konsekwencjami już istniejących luk w zabezpieczeniach. Rozwiąż problem u samego źródła – postawy programistów i osobistej odpowiedzialności.

6 — Zainwestuj w szkolenie z bezpiecznego kodu
Poszukaj szkolenia, które obejmuje szeroki zakres języków programowania i zapewnia dokładne omówienie standardów bezpiecznego kodowania, baz danych, luk w zabezpieczeniach i znanych w branży krytycznych typów słabości oprogramowania. Praktyczne ćwiczenia laboratoryjne w natywnych środowiskach programistów są ogromnie przydatne, jeśli chodzi o wypełnienie tej luki w wiedzy i doświadczeniu.


Podsumowanie

Cyberbezpieczeństwo organizacji jest tak silne, jak jej najsłabsze ogniwo. Tworzenie oprogramowania nie jest pracą na linii produkcyjnej i (wbrew wszelkim przewidywaniom) nie zostanie w najbliższym czasie w pełni zautomatyzowane. Programiści to kreatywne osoby z umiejętnością rozwiązywania problemów, które każdego dnia muszą podejmować setki decyzji podczas pisania kodu.
To, czy fragment kodu jest bezpieczny, zależy przede wszystkim od umiejętności i standardu pracy poszczególnych programistów.
Procesy i narzędzia mogą wspierać i wzmacniać najlepsze praktyki, ale jeśli programista nie wie o konkretnym rodzaju błędu, prawdopodobnie będzie nadal go popełniał i w rezultacie wprowadzał podatności do aplikacji.

Podziel się z innymi tym artykułem!