Bezpieczne wytwarzanie kodu
Czy zastanawialiście się kiedyś, co jest potrzebne do wytworzenia bezpiecznego oprogramowania. Jak wiele wektorów ataku pojawia się po drodze i jak im przeciwdziałać?
Historia
Załóżmy, że pan Darek właściciel niedużej, ale dobrze prosperującej szwalni potrzebuje nowego systemu do zarządzania biznesem. Niestety żadne z rozwiązań rynkowych nie spełnia jego potrzeb. Dlatego nasz bohater postanawia postawić na autorskie rozwiązanie. Analizując rynek, okazuje się powierzenie tego odpowiedzialnego zadania firmie, która się specjalizuje, w takich rozwiązaniach będzie zbyt kosztowne. Dlatego pan Darek postanawia zatrudnić swojego bratanka Ryśka, który uczy się programować i obiecał napisać rozwiązanie po kosztach. Czy coś się może nie udać?
OWASP to nie wszystko
Rysiek pomimo niedużego doświadczenia, wie, że pisząc kod powinien pamiętać o zabezpieczeniu się przed SQL Injection, XSS i innym formom ataku opisanym w specyfikacji OWASP. Wytwarzany kod skanuje nawet popularnymi narzędziami do analizy statycznej, mając fałszywe poczucie bezpieczeństwa.
Chwila prawdy
Aplikacja napisana, przetestowana i wdrożona. Można świętować. Jednak po kilkunastu dniach okazuje się, że przestała działać. Zamiast ekranu powitalnego pojawi się napis “hacked” z informacją, że baza klientów została zaszyfrowana i dane w niej zawarte zostaną sprzedane jeżeli pan Darek nie zapłaci okupu. Chyba jednak nie będzie taniej … 🙁.
Jak to możliwe
Pan Darek razem z Ryśkiem zastanawiają się co teraz, jak to możliwe, że pomimo stosowania best practices aplikacja nie przeszła testu bezpieczeństwa na środowisku produkcyjnym. Nasz bohater tym razem decyduje się na wsparcie ze strony specjalistów od bezpieczeństwa. Kolejnego dnia w biurze pojawia się Wojtek z firmy SecureDevelopment, sprawdza aplikację, infrastrukturę i proces wytwórczy. Przywraca aplikację do działania z backup-u (o backupach
pan Darek nauczył się już wcześniej 😉) i przekazuje dokumentację. Opisuje w niej miejsca, w których nadal może dojść do zainfekowania aplikacji.
Na szczęście włamywacz nie dostał się do danych klientów, tylko blefował, żeby wyłudzić pieniądze. Rysiek już wie, że czeka go dużo nauki przed kolejnym projektem.
Salsa i SSDF
Podsumowanie: Bezpieczne wytwarzanie kodu
Możemy pisać super bezpieczny kod, ale jak skorzystamy ze skompromitowanej biblioteki, to nasz aplikacja i tak będzie miała podatności. Możemy robić kod review i analizę statyczna. Jednak gdy ktoś będzie miał dostęp do naszej nieaktualnej aplikacji budującej wynikowe artefakty, to i tak w repozytorium możemy dostać kod z wkładką. Takich miejsc jest wiele, za każdy z obszarów ataku ktoś odpowiada i jeżeli decydujemy się sami tym zarządzać, to powinniśmy być co najmniej świadomi ryzyk oraz jak można je mitygować. Sprawdźcie, czy u Was już się zabezpieczyliście, a jeżeli tak, jeszcze zostają weryfikacja bezpieczeństwa infrastruktury, aktualizacja komponentów, WAF, SIEM, itd. Bo bezpieczeństwo aplikacji to proces ciągły, o którym powinniśmy pamiętać od samego początku, co bardzo fajnie pisuje NIS na stronie Secure by Design.
Happy coding