Zarządzanie bezpieczeństwem przy pomocy DevOps

Bezpieczeństwo i ocena ryzyka są jednymi z ważniejszych elementów poddawanym cyklicznym kontrolom. W celu usprawnienia tychże procesów, warto zastanowić się nad ich automatyzacją. Przydatne mogą być praktyki DevOps, które zgodnie z założeniami niosą wiele korzyści i usprawniają proces kontroli w organizacji.

Metodologia definiowana jest przez AWS w sposób następujący:

“ DevOps to połączenie kulturowych filozofii, praktyk i narzędzi, które zwiększają zdolność organizacji do dostarczania aplikacji i usług z dużą prędkością: ewoluują i ulepszają produkty w szybszym tempie niż organizacje wykorzystujące tradycyjne procesy rozwoju oprogramowania i zarządzania infrastrukturą. Ta prędkość umożliwia organizacjom lepszą obsługę klientów i skuteczniejsze konkurowanie na rynku.”

Uzupełnieniem praktyk jest DevSecOps, który koncentruje się na kwestiach bezpieczeństwa:

“ Celem i intencją DevSecOps jest zbudowanie mentalności, że „każdy jest odpowiedzialny za bezpieczeństwo”, mając na celu bezpieczne rozdzielenie decyzji dotyczących bezpieczeństwa w szybkim tempie i dopasowaniu do tych osób, które utrzymują najwyższy poziom kontekstu bez poświęcania wymaganego bezpieczeństwa.”

Więcej o DevSecOps możecie przeczytać w naszym wpisie DevSecOps strażnikiem bezpieczeństwa.

Zarządzając bezpieczeństwem, możemy wykorzystać zasady, które sugerują praktyki DevOps: modelowanie ryzyka oraz ciągła integracja i ocena zabezpieczeń.

Modelowanie ryzyka

Istotną kwestia, od której powinien rozpocząć się proces opracowywania mechanizmów kontroli bezpieczeństwa to modelowanie ryzyka.

Sprawą priorytetową powinno być stworzenie rejestru ryzyka, który zawiera wszystkie informacje o zagrożeniach: ich analizie, przeciwdziałaniu i statusie. Na jego podstawie ocenia się prawdopodobieństwo wystąpienia i wpływu zagrożeń.

W celu ułatwienia realizacji zadania istnieje kilka narzędzi, które z pewnością usprawnią cały proces.

Możemy wyróżnić m.in.:

• STRIDE – model zagrożeń opracowany przez Praerita Garga i Lorena Kohnfeldera, w celu identyfikacji zagrożeń bezpieczeństwa komputerowego. Zapewnia mnemonik dla zagrożeń bezpieczeństwa w sześciu kategoriach: podszywaniu się pod tożsamość użytkownika, manipulację, odrzucenie, ujawnianie informacji, naruszenie prywatności lub wyciek danych, D.o.S, próbę nieuprawnionego dostępu.
• PASTA – proces do symulacji ataków i analizy zagrożeń jest siedmioetapową, skoncentrowaną na ryzyku metodologią.
• DREAD – jest to część systemu do oceny zagrożeń bezpieczeństwa komputerowego, wcześniej wykorzystnych w firmie Microsoft (do 2008 r.). Obecnie jest używany przez OpenStack. Zapewnia mnemonik dla zagrożeń bezpieczeństwa oceny ryzyka przy użyciu pięciu kategorii (wymienionych w punkcie 1).
• VAST – podstawową zasadą metodologii jest konieczność skalowania procesu modelowania zagrożeń w całej infrastrukturze i całym SDLC oraz integrowania go, w prosty sposób, z metodologią rozwoju oprogramowania Agile. Metodologia ma na celu dostarczenie praktycznych rezultatów, dla unikalnych potrzeb, różnych zainteresowanych stron: architektów aplikacji i programistów, pracowników cyberbezpieczeństwa i kadry kierowniczej wyższego szczebla.
• Trike – celem jest wykorzystanie modeli zagrożeń jako narzędzia zarządzania ryzykiem, które wykorzystywane są podczas audytu. Modele zagrożeń są oparte na „modelu wymagań”. Z kolei model wymagań, określa definiowany przez interesariuszy „akceptowalny” poziom ryzyka, przypisany do każdej klasy aktywów. Gotowy model zagrożenia służy do konstruowania modelu ryzyka, na podstawie aktywów, ról, działań i obliczonej ekspozycji na ryzyko.
• OCTAVE – metoda CERT o krytycznym znaczeniu dla zagrożenia, zasobów i oceny zagrożeń (OCTAVE). Jest to podejście do zarządzania ryzykiem bezpieczeństwa informacji. Została zaprojektowana tak, aby była wystarczająco elastyczna dla organizacji i  aby sprostać unikalnym, i wysoce kontekstowym potrzebom, w zakresie analizy dzięki możliwościom dostosowywania.

Oprócz wymienionych modeli, warto zapoznać się z dokumentacją przygotowaną przez AWS – Cloud Adoption Framework. Znajdziecie tam wskazówki dotyczące koordynacji różnych części organizacji, migrującej dane do chmury obliczeniowej. Wytyczne CAF podzielone są na kilka obszarów, istotnych dla wdrożenia systemów, w oparciu o chmurę AWS.

Schemat adopcji AWS Cloud Adoption Framework

Wskazówki  mają na celu usprawnienie i zapewnienie odpowiedniego opracowywania mechanizmów kontroli bezpieczeństwa. Każda regulacja, powinna być starannie sformułowana, aby uniknąć niejasności. Zwykle ma postać pojedynczej instrukcji, wymagającej pewnych czynności lub ich konfiguracji. Wskazówki powodują , że dane ryzyko jest udokumentowane lub całkowicie wyeliminowane. Istnieje również pewne ryzyko rezydualne, którym można zarządzać dalej, za pomocą pozostałych mechanizmów kontroli bezpieczeństwa. Pełną dokumentację odnośnie CAF znajdziecie tutaj.

Ciągła integracja i ocena zabezpieczeń

Kiedy mechanizmy kontroli bezpieczeństwa są już stworzone, można przejść do kolejnego etapu. Jest nim tworzenie scenariusza kryteriów akceptacji działań użytkowników, który następnie zostaje poddany testowi poprawności działania. Po teście, pozostałe kryteria wpisujemy jako reguły do usługi AWS Config, pozwalającej na ciągłą ocenę całego konta w AWS, pod względem zgodności. Zasadniczo ocenia się przestrzeganie zasad kontroli na podstawie odcinka czasowego (<15 min). Zdefiniowane elementy mogą zostać umieszczone w CI / CD Pipeline, dzięki czemu kontrole bezpieczeństwa będą równie szybkie, jak tempo innowacji w procesie DevOps.

Schemat standardowego pipeline’u DevOps

Zalety zastosowanego rozwiązania

Wykorzystanie podejścia DevOps w zarządzaniu bezpieczeństwem, niesie za sobą szereg korzyści:

• W przeciwieństwie do tradycyjnego podejścia (audytu), ciągłość integracji i oceny bezpieczeństwa, pozwala na bycie zgodnym z wymogami/regulacjami prawnymi przez cały czas.
• W celu zaoszczędzenia czasu na pracochłonne audyty, warto skorzystać z usługi AWS Config. Bezproblemowy dostęp do jej panelu, pozwala na szybkie uruchomienie prostych procedur operacyjnych.
• Otrzymujemy natychmiastową informację na temat zgodności działań z naszymi regułami kontroli, a tym samym z regulacjami prawnymi.
• Developerzy otrzymują z wyprzedzeniem informacje zwrotne na temat projektowanych rozwiązań.

AWS zwraca uwagę, aby zachować podział pomiędzy dowodami ryzyka i procesami zarządzania ryzykiem. Wyjątki pojawiające się w kodzie, są trudnymi przypadkami do zarządzania i mogą dawać zniekształconą ocenę zgodności zasobów.

Rozwiązania  chmurowe powoli zaczynają zyskiwać miano powszechnych. Niezwykle istotnym jest zatem, rozwój technologiczny pozostałych elementów komplementarnych dla cloud computingu. Praktyki DevOps pozwalają na szybkie i efektywne tworzenie rozwiązań, przy jednoczesnym wysokim poziomie bezpieczeństwa.