DevSecOps w 5 krokach

Nie oszukujmy się, integracja zadań bezpieczeństwa z procesem DevOps to kosztowne i wymagające wyzwanie. Jednak specjaliści z organizacji, które podążają tą drogą są zgodni, że korzyści są niezaprzeczalne i warte poniesionych nakładów. Przeanalizujmy jakie kroki podjąć aby zacząć budować kompetencje i procesy DevSecOps od podstaw.

Rośnie liczba organizacji, których departamenty rozwoju oprogramowania ewoluują w kierunku bardziej efektywnych modeli operacyjnych. Pierwsza fala obejmowała adopcję zwinnego modelu wytwarzania (Agile), kolejna fala przyniosła model DevOps, najnowszym trendem z kolei jest integracja funkcji bezpieczeństwa w ramach modelu operacyjnego DevOps – czyli DevSecOps. Bezpośrednią korzyścią widoczną od samego początku są rozwijane iteracyjnie aplikacje lepiej dopasowane do potrzeb biznesu i spełniające przynajmniej początkowe założenia już na wstępnych etapach tworzenia.

Dla równowagi należy jednak zaznaczyć, że badania prowadzone przez firmy analityczne w kontekście wdrożeń DevOps wykazały problemy w tym obszarze w większości przedsiębiorstw. Warto mieć to na uwadze rozpatrując dalej idący poziom integracji – współpraca z zespołami bezpieczeństwa i zarzadzania ryzykiem jest zarówno trudna jak i niezwykle ważna. W badaniu Gartnera z października 2017 roku 59% ekspertów IT z przedsiębiorstw wskazało udaną współpracę DevOps z zespołami bezpieczeństwa IT jako najważniejszy czynnik sukcesu w codziennych operacjach DevOps.

„Nie można dziś myśleć o IT jako o strukturze, w której warstwa bezpieczeństwa funkcjonuje w oderwaniu, jako oddzielny obszar – taki schemat jest nieintuicyjny i nieefektywny. Kierunki, w jakich rozwija się informatyka, a wśród nich integracja, komunikacja i automatyzacja, poniekąd z definicji wymuszają włączanie w procesy rozwiązań i zespołów odpowiedzialnych za zabezpieczenie informacji. Inną kwestią jest konieczność zabezpieczania IT w obliczu rosnącej liczby incydentów i zagrożeń. Organizacje nie mogą pozwolić sobie na to, aby traktować IT security jako niezintegrowany byt, który nie nadąża za resztą obszarów funkcjonujących w modelu DevOps – na szali jest po prostu zbyt dużo: finanse, procesy biznesowe i dobre imię firmy”- mówi Marcin Zmaczyński, Head of Marketing CEE w Aruba Cloud.

Integracja cyberbezpieczeństwa z DevOps znalazła się na czołowym miejscu w agendach IT przedsiębiorstw ze względu na dynamiczny wzrost znaczenia samego bezpieczeństwa IT w organizacjach. Według ubiegłorocznej ankiety DigiCert, “Making Security Agile”, 88 procent ankietowanych wśród priorytetów podało integrację bezpieczeństwa z DevOps. W raporcie zwrócono uwagę na trzy główne zagrożenia związane z brakiem symbiozy bezpieczeństwa IT oraz DevOps: wzrost ekspozycji na ataki i liczby incydentów bezpieczeństwa, zwiększone koszty i dłuższe cykle dostarczania oprogramowania. Mimo, że podejście DevOps z dużym sukcesem zostało wdrożone w wielu firmach, początkowa koncepcja i proces integracji nie brał pod uwagę potrzeby zaangażowania zespołów bezpieczeństwa. I choć realnie w wielu organizacjach występują głębokie kulturowe i organizacyjne podziały między bezpieczeństwem IT a rozwojem oprogramowania, pracującym z wykorzystaniem metodyk zwinnych i/lub w modelu DevOps, to integracja działań tych dwóch zespołów – niezależnie od niechęci czy animozji – staje się koniecznością.

Ewolucja modelu i kultury

Podejście DevSecOps jest obecnie obiektem sporego szumu medialnego, wręcz hype’u, niemniej powinniśmy zdawać sobie sprawę, że to sukces podejścia DevOps determinuje obecny rozwój, ewolucję w kierunku włączenia bezpieczeństwa do modelu. Wielu ekspertów podkreśla wręcz, że ta integracja powinna mieć miejsce już na samym początku. DevOps koncentruje się na takiej organizacji procesu wytwarzania, wdrażania i utrzymania oprogramowania, aby zapewnić jego iteracyjność, cykliczność, poprzez automatyzację procesów integracji, testowania i dostarczania rozwiązań. Wymaga to zmiany kultury organizacji i sposobu działania zespołu tworzącego oprogramowanie, ponieważ kluczową zasadą DevOps jest ciągła integracja / ciągłe dostarczanie (CI / CD) kodu. Ciągły proces rozwoju, włączając w to automatyczne testy oraz informację zwrotną, okazuje się w praktyce znacznie bardziej wydajny dla wielu przedsiębiorstw. Jeśli jednak pominiemy w tym modelu obszar bezpieczeństwa i zarządzania ryzykiem (SRM – Security & Risk Management) to sukces będzie połowiczny a prędzej czy później napotkamy wąskie gardła w modelu współpracy wewnątrz organizacji. Stąd też wielu specjalistów unika stosowania sformułowania DevSecOps twierdząc, że jest to bardziej DevOps 2.0 – ponieważ włączenie bezpieczeństwa IT jest efektem naturalnej ewolucji i jego miejsce w procesie jest oczywiste.

We wdrażaniu DevSecOps zwróć uwagę, aby dostosować narzędzia i procesy weryfikacji bezpieczeństwa do programistów, nie na odwrót. Źródło: Gartner

Filozofia DevOps jest zakorzeniona w idei burzenia tradycyjnych silosów IT stworzonych przede wszystkim przez rozwój (development) i operacje IT. Bezpieczeństwo stanowi jednak kolejny silos, który czeka na usunięcie i integrację. Wg Gartnera, jeśli komponent „sec” jest poprawnie wkomponowany, powinien być prawie niedostrzegalny. Celem powinno być zapewnienie bezpieczeństwa w procesie tworzenia oprogramowania w możliwie najprostszy i najbardziej przejrzysty sposób.

DevSecOps – dobre praktyki

Nie należy narzucać zespołom DevOps dotychczasowych zasad bezpieczeństwa informacji. Prawidłowe podejście polega na integracji zasad zapewnienia bezpieczeństwa z istniejącym procesem CI/CD, wkomponowanie ich do tego procesu poprzez wykorzystanie stosowanych narzędzi DevOps. To stanowcza zmiana w sposobie myślenia stanowiąca niekiedy wyzwanie dla specjalistów bezpieczeństwa IT, przyzwyczajonych do narzucania swoich reguł i procesów. To podejście będzie wymuszać pewne zmiany:

Zapewnienie programistom natywnego środowiska narzędziowego, w którym działają w ramach DevOps. Wprowadzenie testów bezpieczeństwa powinno być częścią natywnego środowiska.
Wkomponowanie procesu weryfikacji bezpieczeństwa w proces CD/CI tak aby odbywała się automatycznie, potrzeba ingerencji ze strony specjalisty bezpieczeństwa powinna być wyjątkowym przypadkiem
Automatyczne skanowanie zabezpieczeń i zapewnienie zgodności powinno odbywać się w sposób automatyczny z wykorzystaniem API narzędzi dostawcy. Testy i ich wyniki powinny być raportowane w panelach narzędzi natywnych procesu CD/CI.
W ramach analizy wymagań niefunkcjonalnych dla nowych aplikacji należy zbierać wymagania związane z bezpieczeństwem przy użyciu narzędzi do modelowania zagrożeń, umożliwiając w ten sposób automatyzację ich weryfikacji
Rozwiązywanie zidentyfikowanych problemów z bezpieczeństwem za pośrednictwem istniejącego procesu śledzenia błędów (oraz narzędzi takich jak JIRA lub BugTraq).
Zmiana sposobu myślenia: testowanie bezpieczeństwa jako element ciągłego procesu zamiast tradycyjnie, obecnie postrzegany etap skanów bezpieczeństwa aplikacji po jej ukończeniu.

5 kroków do sukcesu

1. Zaplanuj zmianę kulturową

Kadra zarządcza ds. IT, w tym CIO, CTO czy CISO, podkreśla krytyczne znaczenie zmian kulturowych i organizacyjnych dla sukcesu wdrożenia DevSecOps. W pierwszym kroku głównym celem jest promowanie kultury odpowiedzialności wszystkie trzy obszary – rozwoju, bezpieczeństwa i operacji – w której bezpieczeństwo IT partycypuje na równorzędnych zasadach. Będzie to wymagało pewnych zmian w myśleniu we wszystkich trzech działach. Aspekt kulturowy wymaga własnego planu gry. Oto kilka kroków, które mogą pomóc CSO / CISO w walce z procesem:

Edukacja: poznaj zasady DevOps i DevSecOps, za i przeciw, narzędzia itd., aby mieć argumenty w dyskusjach i przekonywaniu kierownictwa.
Ścisła współpraca z szefami rozwoju produktu oraz ds. technologii.
Komunikacja: zorganizuj spotkania w celu przeglądu wyzwań związanych z bezpieczeństwem w ramach procesu DevOps.
Zrozumienie i poparcie ze strony zespołu bezpieczeństwa IT: ich rola w modelu DevSecOps musi ewoluować w kierunku doradczej i konsultacyjnej. Choć to na inżynierach oprogramowania spoczywa odpowiedzialność za bezpieczeństwo dostarczanego kodu, każda zmiana modelu działania bezpieczeństwa IT może być trudna do zaakceptowania.
Zmiana mentalności „nie” i „nie da się”: zespoły ds. bezpieczeństwa często są przyzwyczajone do pełnienia roli bramki akceptacyjnej w procesie dostarczania rozwiązań. W przypadku DevSecOps “kulturę nie” zastąpić trzeba wspólną pracą nad rozwiązywaniem problemów i wzmacnianiem zespołów mając na celu szybkie dostarczanie i udoskonalanie.
Współpraca i jej wsparcie jest najwyższym priorytetem: wszystkie metody i narzędzia budowy kultury współpracy są warte zastosowania.
Zastosowanie sprawdzonych metod zarządzania zmianą wspierających pracowników podczas przejścia na DevSecOps
Reorganizacja, zatrudnianie nowych pracowników z doświadczeniem DevOps.

2. Reorganizuj procesy

Z punktu widzenia organizacji procesów model DevSecOps wymaga od zespołów ds. bezpieczeństwa IT, ryzyka i zgodności, aby zintegrować procesy i reguły działania w ramach tych samych przepływów pracy wykorzystywanych przez dostarczanie i operacje (DevOps). Jedną z najważniejszych zasad DevSecOps i kluczową zmianą w stosunku do tradycyjnego procesu rozwoju oprogramowania jest przesunięcie bezpieczeństwa w górę, co oznacza włączenie analizy i testowania bezpieczeństwa już na wczesnym etapie tego procesu. Zespół bezpieczeństwa powinien od samego początku uczestniczyć w projekcie, biorąc współodpowiedzialność za sukces projektu.

Każda organizacja posiada własne, unikalne procesy, zatem zaleca się zastosowanie narzędzi mapowania procesów, jak np. mapy drogowe procesu (Journey Roadmap), obrazujące wszystkie kroki jakie użytkownik przechodzi realizując określoną funkcję lub zadanie.

3. Automatyzuj wszystkie możliwe elementy procesu

Automatyzacja jest głównym atutem wdrożeń DevOps i nie inaczej jest w przypadku wdrożenia komponentu bezpieczeństwa. Security as Code oznacza dostęp do funkcji bezpieczeństwa głównie poprzez API umożliwiające automatyzację testów bezpieczeństwa na różnych poziomach, dostęp do bezpiecznego współdzielonego repozytorium kodu itd., włączając w ten sposób procesy bezpieczeństwa do przepływu CI/CD.

4. Wybierz perspektywicznie narzędzia

Dwa podstawowe czynniki jakie powinny mieć wpływ na dobór narzędzi to łatwość integracji z istniejącym zestawem narzędzi CI/CD DevOps oraz funkcjonalność narzędzia umożliwiająca automatyzację, włączenie w zautomatyzowany proces przepływu. Pomocne będzie tutaj zestawienie przygotowane przez SANS Institute pokazujące szeroki wybór narzędzi DevOps i DevSecOps dla poszczególnych obszarów i zadań. Przykłady z listy kontrolnej zawartej we wspomnianej publikacji dotyczące punktów styku z bezpieczeństwem obejmują m.in.:

Ochrona przez ujawnieniem kluczy – skanowanie kodu pod kątem jawnie zawartych kluczy (kluczy prywatnych, haseł systemowych, kluczy dostępu do chmury itp.) przed zatwierdzeniem kodu do repozytorium.
Skanowanie kodu przed zatwierdzeniem – wtyczki do edytorów kodu umożliwiające uruchamianie testów bezpieczeństwa.
Skanowanie statycznego kodu źródłowego – skanowanie plików kodu źródłowego (infrastruktury, kodu źródłowego aplikacji itp.) w poszukiwaniu typowych luk w zabezpieczeniach.
Testy jednostkowe bezpieczeństwa.
Zarządzania zależnościami – skanowanie bibliotek open source i komponentów aplikacji pod kątem znanych luk.
Skanowanie bezpieczeństwa kontenerów – analiza obrazów kontenerów pod kątem ujawnionych kluczy, podatnej na ataki konfiguracji i zachowania zgodności.
Dynamiczne testy bezpieczeństwa aplikacji – skanowanie uruchomionej aplikacji pod kątem typowych luk w zabezpieczeniach (jak top 10 OWASP).
Zarządzanie kluczami dostępu – automatyzacja udostępniania i przechowywania kluczy za pomocą takich narzędzi, jak Vault, Conjure, AWS KMS, Azure Key Vault.
Ciągłe monitorowanie – monitorowanie środowiska produkcyjnego pod kątem luk w zabezpieczeniach i detekcji anomalii (narzędzia takie jak statsd, grafit, grafana).

5. Zmierz efekty

Projekt obejmujący tak daleko idące zmiany i ingerencję w kulturę organizacyjną powinien posiadać odpowiednio zdefiniowane metryki pozwalające monitorować proces zarządzania zmianą jak i ocenić na poszczególnych etapach czy osiągnęliśmy zamierzony efekt, niekoniecznie wyrażony zwrotem z inwestycji (ROI). Nie ma jednak obecnie znanych i sprawdzonych narzędzi czy gotowych formuł dla mierników dla tego typu procesów i usprawnień. Firmy doradcze, jak Booz Allen zalecają oparcie systemu pomiaru efektów na takich miarach jak:

skrócenie cyklu dostarczania oprogramowania
wzrost częstotliwości wdrożeń
średni czas reakcji na wykryty defekt / podatność
spadek liczby defektów (pre-produkcja i produkcja) [wszystkie wyrażone w %]

Pomóc może zastosowanie narzędzi monitorowania jakości kodu pod kątem bezpieczeństwa dostarczając mierników w odniesieniu do liczby defektów wykrywanych na poszczególnych etapach. Z pewnością warto oprzeć się na kliku kilku metodach pomiaru jakości kodu.

DevSecOps w chmurze

Choć wszyscy najwięksi dostawcy usług chmury publicznej udostępniają narzędzia wspierające DevOps, należy pamiętać o ważnym elemencie bezpieczeństwa jakim jest zapewnienie zgodności (compliance) zwłaszcza w obliczu regulacji GDPR / RODO w ramach Europejskiego Obszaru Gospodarczego.

„Zapewnienie zgodności z dyrektywą RODO, jakkolwiek kłopotliwe dla organizacji, to idealny przykład na to, dlaczego bezpieczeństwo IT powinno być integralną częścią modelu DevOps, stosowaną już na wstępie. Na początku cyklu tworzenia aplikacji zespoły developerów muszą najpierw zrozumieć, jakie wymagania bezpieczeństwa powinny być spełnione: jakie dane osobowe w obliczu RODO są wymagane, a następnie przeprowadzić analizę transferu tych informacji. Przepływają one przez różne kanały, co wymaga odpowiedniego poziomu ochrony. Ryzyko, że dane osobowe mogą zostać przechwycone lub naruszone na różnych etapach architektury aplikacji, wymaga zastosowania wymagań bezpieczeństwa zgodnych z oczekiwanym ryzykiem. Bez wdrożenia metodyki DevSecOps takie zabezpieczenie jest bardzo trudne do osiągnięcia, o ile w ogóle niemożliwe” – mówi Marcin Zmaczyński.