Zarządzanie bezpieczeństwem w modelu DevOps
Aktywność przestępców w sieci Orange Polska w ostatnim czasie nieco spada, czyżby cisza przed świąteczną burzą? Dowiemy się niebawem, a póki co – wykorzystajmy sytuację i poczytajcie o zarządzaniu bezpieczeństwem w modelu DevSecOps. Materiał autorstwa Grzegorza Siewruka to jeden z ostatnich nieopublikowanych jeszcze tekstów z Raportu CERT Orange Polska 2018. Oczywiście jak zawsze zapraszamy do lektury całego raportu, który znajdziecie tutaj.
W ciągu ostatnich lat prowadzenie projektów informatycznych w trybie DevOps (development and operations) zdobyło bardzo dużą popularność, która ciągle rośnie (wystarczy spojrzeć na liczbę ofert pracy na stanowisku DevOps Engineer). Głównym celem tej metodyki jest połączenie obszarów rozwoju oprogramowania oraz ról operatorskich (administracyjnych) po to, aby poprawić komunikację między tymi zespołami. Efektem jest bezpośrednie przełożenie na czas dostarczania nowego rozwiązania oraz wdrażania zmian na środowiskach produkcyjnych.
Już w 2011 roku firma Amazon chwaliła się, że wykonuje zmiany na środowiskach produkcyjnych średnio co 11.6 sekundy (co daje niemal 7500 zmian w ciągu jednego dnia) (O’Reilly Conference Velocity, 2011 – Jon Jenkins “Velocity Culture”). Za tymi cyframi kryje się niezliczona ilość powstałych przez ostatnie lata narzędzi, które wspierają zarówno organizację projektu, komunikację, testowanie, automatyzację i ciągłą integrację. Wprowadza to wiele nowych możliwości takich jak automatyzacja operacji np. stworzenie nowej maszyny wirtualnej, jej konfiguracja, a na końcu umieszczenie na niej aplikacji. Działania te są powtarzalne i wykonywane przez ten sam mechanizm, więc ryzyko popełnienia błędu w konfiguracji, który spowoduje nieprawidłowe działanie lub wystąpienie podatności bezpieczeństwa w tym obszarze jest minimalne. Pod warunkiem, że automat posiada zaimplementowaną weryfikację – czy obraz systemu jest aktualny i czy biblioteki, które zostały zawarte nie posiadają opublikowanych podatności bezpieczeństwa. Kolejną, powinna być weryfikacja działania i poprawy zabezpieczeń tj. hardeningu systemu operacyjnego oraz upewnienie się, że aplikacja, która zostanie uruchomiona jest odpowiednio bezpieczna. Przy takim tempie wprowadzania zmian w na środowiskach informatycznych, ciężko sobie wyobrazić testerów, którzy weryfikują sposób działania aplikacji przy każdej zmianie. Niestety prędkość rozwoju narzędzi zapewniających bezpieczeństwo nie jest tak szybkie, a już na pewno nie tych udostępnianych w trybie OpenSource. Bardzo często bezpieczeństwo teleinformatyczne nie jest uwzględniane podczas tworzenia narzędzi automatyzujących pracę, a jeżeli takie się znajdą pokrywają niewielki obszar problemu.
Rys. 1: Ekosystem narzędzi DevOps (za Bowman, James. 2017. „Continuous delivery tool landscape.” January 30. Dostęp 2018-12-
Wyraźnie widać to na powyższym rysunku, gdzie przedstawiony został cykl życia zmiany w modelu DevOps. Często jedynym miejscem, w którym uwzględniane jest tu bezpieczeństwo teleinformatyczne to etap wdrożenia, gdzie okresowo wykonywane są testy bezpieczeństwa lub odpowiedni audyt.
Im wcześniej uświadomimy sobie, że takie podejście nie jest wystarczające, tym lepiej dla naszej firmy. Szczególnie, że opisywana metodyka opisuje zarówno kilka obszarów, które są szczególnie narażone na ataki, jak i umożliwia dodanie w generyczny sposób mechanizmów zapewniających bezpieczeństwo. Rozpoczynając od rozwiązań, które pozwalają na zarządzanie podatnościami w warstwie systemu operacyjnego oraz zainstalowanych bibliotek i aplikacji (w tym serwerów aplikacyjnych), kończąc na skryptach weryfikujących konfiguracje środowiska np. CIS Benchmark (https://github.com/topics/cis-benchmark). Należy pamiętać, że nie wszystkie naruszenia bezpieczeństwa powinny przerywać łańcuch dostarczenia oprogramowania. W szczególnych przypadkach ryzyka związane z wykrytymi podatnościami mogą być mitygowane przez automatyczną konfigurację rozwiązań typu WAF (Web Application Firewall) zgodnie z coraz częściej pojawiającym się paradygmatem Security as a Code.
Sporą wartość wprowadzi włączenie skanerów typu SAST (Static Application Security Testing) oraz DAST (Dynamic Application Security Testing) w łańcuch dostarczania oprogramowania. Skanery statyczne, często analiza kodu źródłowego pod kątem podatności bezpieczeństwa, mogą być wyzwalane przy każdym wykonanym merge request przez programistę. W efekcie najbardziej krytyczne błędy nawet nie trafią do produkcyjnego repozytorium kodu co uniemożliwi ich dalszą propagację w projekcie. Skanery dynamiczne mogą być konfigurowane w tym samym momencie, w którym uruchamiane są testy funkcjonalnościowe. Pozwoli to często na uniknięcie problemów związanych z odpowiednią konfiguracją narzędzi tak, aby uwierzytelnianie w aplikacji następowało w odpowiedni sposób – skrypty testujące już posiadają informację na temat aktywnej sesji i kontekstu użytkownika, wystarczy je tylko wykorzystać w innym celu. Programiści pod presją czasu często ignorują zalecenia lub zostawiają „na później” kwestie związane z bezpieczeństwem teleinformatycznym. A jest na co uważać. Według analizy przeprowadzonej przez Orange Polska średnio na 10000 linii kodu wprowadzonych zostaje 400 potencjalnych podatności.
Tab. 1: Najpopularniejsze podatności znalezione podczas analizy kodu źródłowego
W tabeli 1 umieszczona została lista najczęściej znajdowanych podatności w kodzie źródłowym dla aplikacji stworzonych w technologiach JAVA i PHP oraz aplikacji mobilnych przeznaczonych na platformę Android. Przeanalizowanych zostało około 100 aplikacji, w których w skład wchodziły aplikacje webowe, API oraz aplikacje mobilne. Jedną z najczęściej występujących podatności jest Weak XML Schema, na którą składa się wiele błędów w implementacji SOAP API. Tego typu interfejsy programistyczne wykorzystywane są często przez systemy typu Legacy, co znacznie utrudnia jej definitywne usunięcie. Na pewno alarmującym jest fakt pojawienia się na liście podatności związanych z szyfrowaniem – Weak Encryption oraz Insecure SSL. Pierwsza podatność odnosi się do wykorzystania słabych algorytmów do tworzenia np. haseł OTP, druga natomiast bardzo często wiąże się z wyłączeniem weryfikacji ścieżki certyfikacji hosta, z którym aplikacja nawiązuje (lub otrzymuje) połączenie. Są to podatności, które niezwykle łatwo poprawić a które znacząco wpływają na poziom bezpieczeństwa rozwiązania.
Metodyki takie jak DevOps w kolejnych latach będą zyskiwały jeszcze większą popularność. Sposób zarządzania podatnościami w takich środowiskach musi odpowiednio ewoluować aby organizacje świadomie zarządzały bezpieczeństwem. Już nie wystarczy okresowo testować konkretne rozwiązania lub skonfigurować kilka skanerów, aby wykonywały zdefiniowane testy. Konieczna jest integracja z narzędziami wykorzystywanymi w procesie dostarczania oprogramowania oraz posiadania przynajmniej jednego mechanizmu w każdym z łańcuchów.
