Bezpieczny kod – czy to największe wyzwanie IT naszych czasów?

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.