Społeczność zajmująca się bezpieczeństwem IT powszechnie uznaje, że istnieje bezpośrednia korelacja między jakością kodu – wyrażoną jako odsetek błędów kodowania na tysiąc linii kodu – a bezpieczeństwem cybernetycznym. Mówiąc najprościej, im więcej błędów w kodzie, tym większa szansa, że zostaną wykorzystane jako wektor ataku. Presja na poprawę jakości kodu jest wywierana wewnętrznie przez liderów biznesowych i IT, a zewnętrznie przez organy regulacyjne i decydentów.
Istnieją bezpośrednie i pośrednie korzyści z poprawy jakości programowania. Oprócz ryzyka związanego z bezpieczeństwem cybernetycznym, błędy kodowania występujące w środowiskach produkcyjnych są kosztowne do naprawienia w porównaniu z błędami wykrytymi na wczesnym etapie cyklu życia projektu. Oprogramowanie niskiej jakości wpływa na doświadczenia klientów i pracowników, co potencjalnie ogranicza produktywność i może prowadzić do utraty przychodów.
IDC niedawno opublikowane Ogólnoświatowy półroczny program do śledzenia oprogramowania informuje, że istnieje zapotrzebowanie na poprawę odporności. Dane IDC pokazują wzrost wydatków na jakość oprogramowania i narzędzia związane z cyklem życia — które wzrosły o ponad 26% w stałej walucie.
Bardzo nagłośnione exploity, takie jak Log4Shell – exploit, który wykorzystywał lukę w Log4js, narzędziu do rejestrowania opartym na Javie, które jest wbudowane w wiele aplikacji – wywołał falę wstrząsów w sektorze technologicznym, podkreślając ryzyko związane z osadzeniem kodu strony trzeciej w projektach rozwoju oprogramowania. Te komponenty, usługi sieciowe lub biblioteki innych firm przyspieszają tworzenie oprogramowania, nie tylko oszczędzając czas, ale także zmniejszając liczbę błędów kodowania, ponieważ programiści mogą polegać na innych w tworzeniu potrzebnych im uzupełnień, bez konieczności tworzenia wszystkiego od zera.
Bardziej popularne biblioteki są intensywnie testowane w setkach tysięcy projektów, co oznacza, że błędy można szybko usunąć. Jednak, podobnie jak w przypadku Log4Shell, niektóre z nich mogą pozostać niezidentyfikowane, więc pierwsze organizacje dowiadują się o problemie, gdy jest on wykorzystywany.
W celu ochrony Internetu i krytycznej infrastruktury krajowej rząd USA Narodowa Strategia Cyberbezpieczeństwa nakłada odpowiedzialność za bezpieczeństwo IT na organizacje, które zarządzają i obsługują ekosystemy cyfrowe, przenosząc odpowiedzialność za słabe bezpieczeństwo cybernetyczne z użytkowników na firmy obsługujące te platformy.
Na blogu omawiającym nowe zasady Tidelift ostrzega, że jednym z najważniejszych skutków nowej polityki, jakie organizacje prawdopodobnie zobaczą, jest to, że rząd proponuje bardziej otwarte, aktywne podejście do poprawy bezpieczeństwa cybernetycznego poprzez zwiększenie regulacji i obowiązkowych wymagania.
Aby zachować zgodność z najnowszymi standardami, Joseph Foote, ekspert ds. bezpieczeństwa cybernetycznego w PA Consulting, mówi, że organizacje w sektorach regulowanych muszą przedstawić dowód, że ich kluczowa infrastruktura została poddana pewnej formie dogłębnego zapewnienia bezpieczeństwa. „Jeśli te firmy nie przestrzegają przepisów, ryzykują grzywny i kary, a ubezpieczyciele mogą nie być już skłonni do przedłużania umów” – dodaje.
Redukcja ryzyka i potencjalnego wpływu na firmę, zarówno pod względem finansowym, jak i reputacyjnym, będzie głównym celem wielu firm i dotyczy to oprogramowania, sposobu jego opracowywania oraz bezpieczeństwa usług stron trzecich, których organizacja potrzebuje, aby osiągnąć cel biznesowy.
Bezpieczeństwo z perspektywy kodowania, zaczyna się od zestawu wytycznych, które według Foote’a mają na celu zarządzanie i egzekwowanie metodologii, której należy przestrzegać podczas wdrażania nowych funkcji obsługiwanych przez oprogramowanie. Wytyczne te, jak mówi, obejmują zarówno proste sugestie, takie jak zapewnienie tworzenia dokumentacji podczas rozszerzania istniejącej bazy kodu, jak i szczegółowe uszczegółowienie struktury i układu samego kodu.
Kontrola jakości
Z doświadczenia Foote wynika, że programiści często dostosowują swoje podstawy kodu do określonego paradygmatu projektowego w celu zabezpieczenia na przyszłość, zwiększenia modułowości i zmniejszenia prawdopodobieństwa wystąpienia błędów z powodu ogólnej złożoności kodu. Ale nawet najbardziej solidne wytyczne mogą nadal dopuszczać błędy i pomyłki w końcowym kodzie, chociaż częstotliwość problemów zazwyczaj maleje wraz z dojrzewaniem wytycznych.
„Niektóre luki w zabezpieczeniach, które spowodowały największy wpływ, można przypisać niedopatrzeniom w praktykach bezpiecznego kodowania, a niektóre z najbardziej problematycznych słabości w naszym najpopularniejszym oprogramowaniu można było wykryć dzięki ścisłej kontroli jakości i wytycznym dotyczącym bezpiecznego kodowania” — mówi. .
Weźmy na przykład EternalBlue, którego celem była luka w systemie operacyjnym Microsoft Windows i jego podstawowych komponentach, aby umożliwić wykonanie złośliwego kodu. Chociaż exploit EternalBlue – oficjalnie nazwany przez firmę Microsoft MS17-010 – dotyczy tylko systemów operacyjnych Windows, wszystko, co wykorzystuje protokół udostępniania plików SMBv1 (Server Message Block version 1), jest technicznie narażone na ryzyko ataków ransomware i innych cyberataków.
W poście opisującym EternalBlue, firma ochroniarska Avast cytuje a New York Times artykuł, w którym zarzuca się, że Agencja Bezpieczeństwa Narodowego USA (NSA) potrzebowała roku na zidentyfikowanie błędu w systemie operacyjnym Windows, a następnie opracowała EternalBlue, aby wykorzystać lukę. Według New York Times artykuł, NSA używała EternalBlue przez pięć lat, zanim powiadomiła Microsoft o swoim istnieniu. Włamano się do NSA, a EternalBlue dostało się w ręce hakerów, co doprowadziło do ataku ransomware WannaCry.
Jak wskazuje Foote, EternalBlue był problemem z kodowaniem.
Charles Beadnall, dyrektor ds. technologii (CTO) w GoDaddy, apeluje do liderów IT o upewnienie się, że opracowywany kod jest napisany na najwyższym poziomie jakości.
Ponieważ kod staje się coraz bardziej złożony i korzysta z usług i bibliotek oprogramowania innych firm lub komponentów open source, coraz trudniej jest zidentyfikować problemy z kodowaniem i podjąć działania naprawcze.
Ankieta przeprowadzona wśród 1300 CISO w dużych przedsiębiorstwach zatrudniających ponad 1000 pracowników, przeprowadzona przez Coleman Parkes na zlecenie Dynatrace w marcu 2023 r., wykazała, że ponad trzy czwarte (77%) CISO twierdzi, że priorytetyzacja luk w zabezpieczeniach jest dużym wyzwaniem ze względu na brak informacje o zagrożeniu, jakie stwarzają dla otoczenia.
Omawiając wyniki, Bernd Greifeneder, CTO w Dynatrace, mówi: „Rosnąca złożoność łańcuchów dostaw oprogramowania i stosy technologii natywnych dla chmury, które stanowią podstawę innowacji cyfrowych, sprawiają, że coraz trudniej jest szybko identyfikować, oceniać i ustalać priorytety reakcji na nowe pojawiają się słabe punkty.
„Te zadania wyrosły poza ludzkie możliwości zarządzania. Zespoły ds. rozwoju, bezpieczeństwa i IT odkrywają, że stosowane przez nie środki kontroli zarządzania lukami w zabezpieczeniach nie są już odpowiednie w dzisiejszym dynamicznym cyfrowym świecie, który naraża ich firmy na niedopuszczalne ryzyko”.
Zmniejszenie ryzyka złej jakości oprogramowania
Beadnall mówi, że jedną z ważnych rzeczy związanych z bezpieczeństwem jest upewnij się, że istnieją kontrole dla tego, co wdrażasz i jak monitorujesz.
Jest wielkim fanem prowadzenia projektów kodowania, takich jak eksperyment laboratoryjny, w którym testowana jest hipoteza, a wyniki są mierzone i porównywane z kontrolnym zbiorem danych. „Eksperymenty są pomocne w określaniu ilościowym i klasyfikowaniu typów wdrażanego kodu, wpływie na klientów i lepszym zrozumieniu wdrażania” — mówi.
Badacze Trustwave niedawno przetestowali zdolność ChatGPT do pisania kodu i identyfikowali typowe błędy programistyczne, takie jak przepełnienie bufora, które mogą być łatwo wykorzystane przez hakerów. Karl Sigler, kierownik ds. analizy zagrożeń w firmie Trustwave, oczekuje ChatGPT i inne generatywne systemy sztucznej inteligencji, aby stały się częścią cyklu życia oprogramowania.
Beadnall postrzega generatywną sztuczną inteligencję jako coś, co można wykorzystać do nadzorowania pracy programistów, w taki sam sposób, jak programowanie równorzędne. „Eksperymentujemy z wieloma różnymi technikami, w których sztuczna inteligencja jest wykorzystywana jako równorzędny programista, aby upewnić się, że piszemy kod wyższej jakości” — mówi. „Myślę, że to bardzo logiczny pierwszy krok”.
W krótkim okresie poprawiają się same narzędzia, aby kodowanie było bezpieczniejsze. „Automatyzacja i bezpieczeństwo leżą u podstaw możliwości. Narzędzia sztucznej inteligencji umożliwiają pracownikom tworzenie i produkowanie w nowy, kreatywny sposób, podczas gdy bezpieczeństwo jest podstawową fortyfikacją, która umożliwia ich wprowadzenie do przedsiębiorstwa” — mówi Tom Vavra, szef zespołu danych i analiz IDC ds. oprogramowania europejskiego.
Foote z PA mówi, że firmy z dużymi zespołami programistów stopniowo przechodzą na bezpieczniejsze standardy i bezpieczniejsze języki programowania, takie jak Rust. To częściowo rozwiązuje problem, wymuszając a bezpieczne z założenia paradygmat, w którym każda operacja uznana za niebezpieczną musi zostać wyraźnie zadeklarowana, co zmniejsza prawdopodobieństwo niebezpiecznej operacji w wyniku przeoczeń.
„Paradygmaty bezpiecznego projektowania stanowią krok naprzód w praktykach programistycznych, wraz z nowoczesnymi postępami w bezpiecznych praktykach kodowania” — dodaje.
Aby wykazać, że ich organizacje są bezpieczne i godne zaufania, Foote uważa, że liderzy IT będą musieli przeprowadzać szczegółowe oceny bezpieczeństwa.