Natknęliśmy się ostatnio na interesujące badania, które mówią, iż programiści spędzają więcej czasu w 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, choćby 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żeli 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, iż 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, iż 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 systemu 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ą, iż 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 systemu 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 dzięki 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 choćby 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 systemu 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żeli chodzi o wypełnienie tej luki w wiedzy i doświadczeniu.
Podsumowanie
Cyberbezpieczeństwo organizacji jest tak silne, jak jej najsłabsze ogniwo. Tworzenie systemu 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żeli programista nie wie o konkretnym rodzaju błędu, prawdopodobnie będzie przez cały czas go popełniał i w rezultacie wprowadzał podatności do aplikacji.
