Obserwując różne incydenty bezpieczeństwa na przełomie ostatnich miesięcy, możemy zauważyć jak duży odsetek zespołów programistycznych przyznał się do pomijania wykonywania testów bezpieczeństwa tworzonych aplikacji. Istnieje ok. 70% szans, że tak również może być w Twojej firmie. Poniżej zebraliśmy 7 potencjalnych powodów, które powinieneś zbadać w swojej organizacji i ewentualnie wprowadzić pomysły i działania zaradcze.

Powód 1: Brak przykładów idących z góry

Głównym powodem, dla którego zespoły programistyczne pomijają kroki bezpieczeństwa, jest to, że nie uważają tych kroków za ważne. A przykład jak zawsze idzie z góry. Jeśli liderzy biznesowi szukają wymówek i nie dbają wystarczająco o bezpieczeństwo aplikacji internetowych, programiści i ich menedżerowie rzadko sami się tym zajmują. Są wystarczająco przepracowani, mają mnóstwo harmonogramów i deadline’ów aby myśleć o dodatkowej pracy nad bezpieczeństwem. Oczywiście można to zmienić a wszystko zaczyna się od uświadomienia sobie faktu bezpieczeństwa aplikacji i odróżnienia od innych obszarów cyberbezpieczeństwa. Jeśli Twoja firma inwestuje w rozwiązania zabezpieczające punkty końcowe – Endpoint Protection i rozwiązania zabezpieczające sieci – Firewall , ale nie inwestuje w zabezpieczenia aplikacji internetowych, to dokładnie tego samego możesz oczekiwać od swoich zespołów programistycznych. Aby to naprawić:

• Jeśli jesteś liderem biznesowym, podkreśl swoje zainteresowanie bezpieczeństwem aplikacji internetowych.
• Upewnij się, że zarówno Ty, jak i Twoje zespoły jesteście świadomi, że zabezpieczenia aplikacji internetowych nie są w ogóle objęte zabezpieczeniami punktów końcowych/sieci.
• Wspieraj i promuj inwestycje w zautomatyzowane narzędzia, takie jak Acunetix, aby chronić Twoje witryny i aplikacje internetowe.

Powód 2: Nieprawidłowe założenia bezpieczeństwa

Wielu liderów w organizacjach jest świadomych bezpieczeństwa aplikacji, wiedzą, że należy traktować ten problem poważnie a nawet rozumieją, że aplikacje nie są chronione przez zabezpieczenia punktów końcowych i sieci. Często jednak osoby decyzyjne uważają, że ich aplikacje nie wymagają żadnych dodatkowych narzędzi ani podejmowania innych kroków bezpieczeństwa, przede wszystkim dlatego, że:

• Założenie 1: Zewnętrzne aplikacje są bezpieczne, ponieważ dostawca aplikacji dba o ich bezpieczeństwo za pomocą swoich systemów. Jeśli Twoja aplikacja jest tworzona przez firmę trzecią lub korzystasz z rozwiązań open-source, to możesz zakładać, że rozwiązania te są wystarczająco bezpieczne. Niestety takie założenie jest często mylne.
• Założenie 2: Aplikacja wykorzystywana tylko do użytku wewnętrznego na pewno jest bezpieczna, bo kontrolujesz dostęp do niej wśród pracowników Twojej firmy. Niestety założenie to nie jest prawdziwe, dlatego że większość ataków inicjowanych jest od wewnątrz, najczęściej przez samych pracowników.
• Założenie 3: Aplikacja nie jest narażona na atak ponieważ jej struktura jest prosta. Jest to częste założenie zwłaszcza, jeśli dotyczy aplikacji i witryn internetowych, które nie przechowują wrażliwych danych. Jednak takie witryny, jeśli posiadają podatności w swoim kodzie, mogą prowadzić do eskalacji uprawnień i umożliwić atakującemu dostęp do innych, bardziej krytycznych systemów.

W wyniku takich założeń, zespoły programistyczne nie mają czasu ani odpowiednich narzędzi, aby zadbać o bezpieczeństwo tworzonych aplikacji. Oczywiście może zdarzyć się, że pojedyncze osoby w całym zespole będą próbowały wpleść pewne mechanizmy bezpieczeństwa do budowanych elementów aplikacji, ale nie ma co liczyć na szczęście, trzeba zmienić podejście do problemu.

Aby to naprawić:

• Weź odpowiedzialność za bezpieczeństwo aplikacji na siebie, nawet jeśli uważasz, że twórcy oprogramowania przestrzegają wszystkich standardów i dobrych praktyk bezpieczeństwa aplikacji.
• Zainwestuj we własne narzędzia badające bezpieczeństwo aplikacji lub zatrudnij firmę, która zrobi takie testy za Ciebie
• Traktuj każdą aplikację tak samo – niezależnie czy jest to mała aplikacja informacyjna czy aplikacja wewnętrzna, czy najważniejszy portal w Twojej organizacji

Powód 3: Brak czasu i zasobów

Załóżmy, że liderzy biznesu są świadomi znaczenia bezpieczeństwa aplikacji internetowych i są gotowi zainwestować w narzędzia, ale nie zdają sobie sprawy, że bezpieczeństwo aplikacji internetowych wymaga dodatkowego czasu i zasobów. Na przykład napisanie prostego formularza zajmuje kilka sekund. Napisanie tego samego formularza z odpowiednimi procedurami ochrony przed skryptami zajmuje co najmniej kilka minut.

Tak samo jest z dobrymi narzędziami. Chociaż najwyższej klasy narzędzia DAST używane w SDLC nie obciążają samego oprogramowania, nadal wymagają dodatkowego czasu na testowanie i kontrolę jakości bezpieczeństwa. Liderzy organizacji muszą mieć świadomość, aby utrzymać bezpieczeństwo aplikacji internetowych, zespoły programistyczne potrzebują dodatkowego czasu a często także większych zasobów. Aby programiści mogli zająć się także bezpieczeństwem wymagają komfortowego podejścia do tworzenia aplikacji – muszą mieć czas nie tylko na napisanie kodu ale zweryfikowanie jego optymalizacji i bezpieczeństwa – w innym wypadku o bezpieczeństwie możemy tylko pomarzyć.

Aby to naprawić:

• Pozwól na niewielkie opóźnienia podczas tworzenia aplikacji, zwłaszcza gdy Twoje zespoły dopiero uczą się zwracania uwagi na bezpieczeństwo.
• Zapewnij swoim zespołom programistycznym komfort, wyrażając, że wolisz, aby spędzały więcej czasu na pisaniu bezpiecznych aplikacji, niż przyspieszaniu wydania przez kopiowanie i wklejanie wrażliwego kodu znalezionego w Internecie

Powód 4: Bezpieczeństwo ≠ Development

Wiele firm widząc termin „bezpieczeństwo”, automatycznie zakłada, że ​​wszystkim, co jest związane z tym terminem, powinien zająć się wyspecjalizowany zespół IT. Niestety nie jest to najlepszy wybór dla bezpieczeństwa aplikacji internetowych. Innym błędem popełnianym przez wielu szefów organizacji jest zakładanie, że eksperci ds. bezpieczeństwa, zajmującymi się stacjami roboczymi i siecią, wiedzą, jak radzić sobie z bezpieczeństwem aplikacji internetowych, ponieważ rzadko to robią.

W wyniku tych błędnych przekonań wiele firm kończy z zespołem ds. cyberbezpieczeństwa, który działa całkowicie niezależnie od zespołu programistów. Jeśli zespół ds. cyberbezpieczeństwa w ogóle zajmuje się bezpieczeństwem aplikacji internetowych, robi to dopiero na późnych etapach (często gdy aplikacja jest już wydana). W rezultacie problemy z bezpieczeństwem aplikacji internetowych zostają naprawione tygodnie lub miesiące po tym, jak zostały faktycznie wprowadzone, a nikt tak naprawdę nie wiedział, co się stało.

Aby to naprawić:

• Upewnij się, że zespoły ds. cyberbezpieczeństwa i zespoły programistyczne nie są rozdzielone. Możesz nawet przydzielić eksperta ds. bezpieczeństwa aplikacji internetowych do pracy bezpośrednio w zespołach programistycznych.
• Powierz zespołom programistycznym rozwiązywanie problemów wykrytych na wczesnym etapie cyklu życia oprogramowania za pomocą zautomatyzowanych narzędzi, takich jak Acunetix. Zespoły bezpieczeństwa powinny być zaangażowane tylko we wstępną konfigurację i/lub konserwację takich narzędzi, a nie w ich codzienne działanie.

Powód 5: Brak odpowiedniej wiedzy

Programiści są najczęściej doskonale wykształceni w językach programowania i budowie optymalnego kodu. Jednak wiele szkół programistyczny nie ma w planie nauczania zagadnień bezpieczeństwa i testowania aplikacji ze względu na lukę w zakresie cyberbezpieczeństwa. Uczelniom trudno konkurować na rynku pracy z komercyjnymi firmami, dlatego rzadko zatrudniają ekspertów w dziedzinie cyberbezpieczeństwa, zwłaszcza na wydziałach programowania. W wyniku braku odpowiedniej kadry, programiści uczą się wszystkiego tylko nie tworzenia bezpiecznego kodu.

Jako lider swojej firmy, świadomy bezpieczeństwa aplikacji, oprócz wymagania od programistów takiego samego podejścia powinieneś zapewnić im możliwość rozwijania się w tym zakresie, czy organizując szkolenia, czy zatrudniając specjalistę, który poprowadzi zespół przez zawiłości aspektów bezpieczeństwa aplikacji. Starsi programiści wraz z zespołem ds. cyberbezpieczeństwa, powinni współpracować z młodszymi programistami, aby zapewnić im praktyczne instrukcje dotyczące unikania lub w zabezpieczeniach w pisanym kodzie.

Aby to naprawić:

• Upewnij się, że młodsi programiści nie są karani za brak wiedzy/doświadczenia w zakresie bezpieczeństwa i nie boją się prosić o pomoc.
• Wspieraj specjalistów ds. bezpieczeństwa w zespole programistów i daj im czas i narzędzia, których potrzebują, aby nauczyć innych, jak unikać i naprawiać luki w zabezpieczeniach aplikacji internetowych.
• Korzystaj z istniejących zasobów, takich jak artykuły na blogu Acunetix, aby uczyć juniorów o różnych lukach w zabezpieczeniach i sposobach ich unikania/naprawiania. Zacznij od wyszukania nazwy luki w witrynie Acunetix.

Powód 6: Konieczność naprawiania cudzych błędów

Nawet jeśli starsi programiści edukują młodszych kolegów, bez odpowiedniej kontroli, proces budowania bezpiecznej aplikacji będzie bardzo powolny. W środowisku, w którym aplikacje testuje się na finalnym etapie produkcji, przed jej publikacją, programiści nie mają świadomości czy popełnili jakiś błąd związany z bezpieczeństwem. Zwłaszcza, że podatności aplikacji mogą pojawić się kilka tygodni po zakończeniu projektu, programiści mogą już nie pamiętać tego kodu.

W idealnym środowisku kod powinien być testowany pod kątem luk w zabezpieczeniach w tym samym czasie, gdy jest testowany pod kątem poprawności działania. Oznacza to, że weryfikacja bezpieczeństwa powinna być przeprowadzana wraz z testami QA. Twoje narzędzie bezpieczeństwa powinno działać tuż przed lub zaraz po testach Selenium (lub jakiejkolwiek innej automatyzacji testów, której używasz).

Aby to naprawić:

• Zintegruj swoje narzędzie bezpieczeństwa, takie jak Acunetix, ze środowiskiem CI/CD, aby było ono częścią procedury programistycznej.
• Uruchom skanowanie bezpieczeństwa aplikacji internetowej nie tylko dla głównych wersji, ale dla każdego nowego modułu lub podwersji, które trafiają do publikacji.

Powód 7: Nieodpowiednie narzędzia

Zakładamy, że wyeliminowałeś już wszystkie powyższe problemy. Jeśli jednak wybierzesz nieodpowiednie narzędzie do testowania bezpieczeństwa, nadal może okazać się, że programiści pomijają kroki związane z bezpieczeństwem, ze względu na uciążliwość rozwiązania, które otrzymali od organizacji.

Największym problemem dla programistów są fałszywe podatności (False Positive). Jeśli każdy raport z Twojego narzędzia może być fałszywie pozytywny, programiści często marnują mnóstwo czasu, próbując znaleźć problemy, których w ogóle nie ma. Jeden fałszywy alarm może oznaczać dziesięć razy więcej pracy dla programisty niż prawdziwa podatność!

Aby to naprawić:

• Nie opieraj swojego bezpieczeństwa na samych narzędziach SAST – jeśli musisz użyć SAST, używaj go razem z DAST. Narzędzia SAST z dużym prawdopodobieństwem wygenerują wiele fałszywych alarmów.
• Zainwestuj w narzędzia, które mają na celu eliminację lub pomoc w kontrolowaniu fałszywych alarmów. Na przykład Acunetix wykorzystuje autorską technologię Proof-Of-Exploit (dowód istnienia podatności) i oceny każdej podatności, aby pokazać, które luki zdecydowanie nie są fałszywymi alarmami, więc nie tracisz czasu na ściganie podatności-widm.

Skuteczne bezpieczeństwo wywodzi się od świadomych liderów firm

Jak widać, chociaż to zespoły programistyczne faktycznie pomijają kroki związane z bezpieczeństwem, to ich szefowie popełniają podstawowe błędy, które prowadzą do takiej sytuacji. Dlatego nie można po prostu zakładać, że posiadanie środków bezpieczeństwa jest równoznaczne z posiadaniem skutecznych zabezpieczeń aplikacji internetowych i dlaczego nie można po prostu obwiniać zespołów programistycznych za niewłaściwe postępowanie. Na szczęście możesz naprawić tę sytuację za pomocą prostych środków, jednocześnie zwiększając bezpieczeństwo, wybierając odpowiednie narzędzie do pracy. Acunetix to rozwiązanie zabezpieczające, które Cię tam zaprowadzi – d23security.pl/acunetix

Zainteresował Cię ten temat? Skontaktuj się z nami: sales@d23security.pl

Artukuł przygotowany przez Invicti: Oryginał znajdziesz tutaj