Jak bezpiecznie przenieść się do chmury – Secure Software Development Lifecycle

Secure Software Development Life Cycle (S-SDLC)

Podczas wszystkich faz cyklu tworzenia oprogramowania możemy podjąć szereg działań w celu poprawy bezpieczeństwa aplikacji. Są one opisane szczegółowo w wielu powszechnie znanych i wykorzystywanych metodykach, normach, standardach, podręcznikach m.in.:

Microsoft’s Security Development Lifecycle – zbiór zaleceń do tworzenia bezpiecznego oprogramowania.

NIST 800-64 – Security Considerations in the Information System Development Life Cycle – publikacja opisująca kroki w zabezpieczaniu aplikacji na etapie poszczególnych faz jej rozwoju.

ISO/IEC 27034 – składający się z kilku części standard opisujący praktyki bezpieczeństwa w wielu obszarach związanych z tworzeniem aplikacji z uwzględnieniem zarówno kontekstu technologicznego, jak i informacyjnego, biznesowego oraz zgodnościowego.

pecb.com

OWASP SAMM (Software Assurance Maturity Model) – framework pokazujący, jakie praktyki można wdrożyć w cyklach rozwoju aplikacji, które pozwalają podnieść oraz oceniać poziom jej bezpieczeństwa.

DevOps – termin pochodzący od angielskich określeń rozwoju (development) i operacji (operations). To podejście do rozwoju  oprogramowania i uruchamiania produktów i usług, które opiera się na koncepcji pętli ciągłej integracji, dostarczania i wdrażania (CI/CD pipeline – Continous Integration, Delivery, Deployment) polegającej na współpracy, komunikacji i integracji zespołów rozwoju i utrzymania. Podejście to wspiera coraz większą współzależność rozwoju i operacji. DevSecOps przyświeca idea “każdy jest odpowiedzialny za bezpieczeństwo” i zakłada wdrażanie oraz spełnianie wymagań bezpieczeństwa na każdym z elementów łańcucha DevOps.

Każdy z przedstawionych przykładów zawiera wiele elementów wspólnych, takich jak specyfikacja wymagań, ocena i modelowanie zagrożeń czy weryfikacja i testowanie. W artykule przedstawię  podejście do procesu tworzenia bezpiecznych aplikacji prezentowane przez Cloud Security Alliance (CSA). Jest to próba integracji najważniejszych założeń i działań opisanych w istniejących już modelach. Koncentruje się na aspektach specyficznych dla cloud computing w trzech głównych obszarach:

  • Secure design and development: obejmujący działania od szkolenia, definiowania standardów, pisania i testowania kodu.
  • Secure deployment: działania związane z bezpiecznym przeniesieniem kodu na produkcyjne środowisko.
  • Secure operations: utrzymanie i zabezpieczenie działających aplikacji, uwzględniając również zewnętrzną ochronę jak Web Apllication Firewall czy zarządzanie podatnościami.

Secure Software Development Cycle – Cloud Security Alliance

Sam cykl S-SDLC jest podzielony na 5 faz:

Szkolenie – architektura modelu cloud computingu sprawia, że członkowie zespołów deweloperskich powinni poznać specyficzne dla modelu wymagania bezpieczeństwa i zrozumieć podział odpowiedzialności pomiędzy odbiorcę i dostawcę usług za zabezpieczanie komponentów na poszczególnych warstwach stosu

Definiowanie – odbiorca usług określa architekturę, narzędzia oraz wymagania i standardy bezpieczeństwa dla rozwijanego kodu i wykorzystywanej infrastruktury. Może to być powiązane z wymaganiami zgodności czy prywatności, np. ze standardem PCI DSS lub RODO. Żeby zabezpieczenie cyklu rozwoju miało sens, powinno się opierać na wykorzystaniu narzędzi do automatyzacji procesów takich jak kontrola wersji, integracji i wdrożenia (Jenkins, GitLab, Bamboo, Terraform), testowanie (SOASTA, Selenium), zarządzanie i orkiestracja (np. Puppet, SaltStack) czy monitorowanie wydajności i bezpieczeństwa (CloudWatch, Qualys, Nagios, Ossec). Na tym etapie warto zdefiniować mierniki, które będą punktem odniesienia w cyklu doskonalenia procesu, np. mierniki wydajności, liczba luk, ilość zgłoszeń i incydentów itd.

Projektowanie – na podstawie wymagań zdefiniowanych w poprzednim etapie rozpoczynamy fazę projektowania. Weryfikujemy, jakie możliwości, funkcje i narzędzia jest w stanie dostarczyć dostawca oraz jakie są ograniczenia (np. gromadzenie logów sieciowych, realizacja testów), w szczególności gdy korzystamy z usługi w modelu Platform as a Service. Na tym etapie wykonujemy też analizę zagrożeń dla naszej aplikacji. W tym celu możemy posłużyć się jedną z powszechnie dostępnych i stosowanych metodyk takimi jak model STRIDE, publikacja NIST 800-30 czy OWASP Top Ten. Opracowana przez Microsoft klasyfikacja STRIDE składa się z sześciu kategorii zagrożeń, do których na tym etapie możemy zaprojektować zabezpieczenia, adekwatne do krytyczności naszego systemu:

  • Przejęcie i podszycie się pod czyjąś tożsamość (Spoofing Identity) – ataki polegające na podszywaniu się pod innego użytkownika lub element systemu poprzez celowe niepoprawne użycie protokołów komunikacji lub umieszczenie w sieci spreparowanych pakietów danych. Dobrym sposobem na zabezpieczenie przed tym zagrożeniem jest użycie silnych metod uwierzytelnienia lub kryptograficznych .
  • Manipulowanie danymi (Tampering with Data) – nieautoryzowana modyfikacja danych. Najlepszym sposobem ochrony przed tą grupą zagrożeń jest stosowanie zabezpieczeń kryptograficznych takich jak podpisywane cyfrowo wiadomości lub skróty wiadomości oraz szyfrowane kanały komunikacji i magazyny danych.
  • Zaprzeczanie autorstwu operacji (Repudiation) polega na możliwości wyparcia się użytkownika wykonanej przez niego operacji w systemie. Podstawową i skuteczną ochroną jest stosowanie podpisów i skrótów cyfrowych.
  • Ujawnienie informacji (Information Disclosure) dotyczy naruszenia poufności danych składowanych, przetwarzanych lub przesyłanych. Najczęstszym sposobem ochrony przed tą kategorią zagrożeń jest stosowanie szyfrowania danych podczas przesyłu i w spoczynku oraz zabezpieczenia przed wyciekami pamięci.
  • Ataki odmowy dostępu do usługi (Denial of Service) – przeciążenie systemu informatycznego lub usługi sieciowej w celu uniemożliwienia jej prawidłowego działania, realizowane np. przez wysycanie zasobów procesorowych, połączeniowych lub pamięciowych. Mogą być wykorzystane w tym celu również ataki rozproszone z użyciem botnetów – zainfekowanych maszyn, których właściciele nie są tego nawet świadomi. W modelu chmury istotne jest rozpoznanie, jakie możliwości w zakresie ochrony przed tego typu atakami oferuje nam dostawca, które powinny być zaprojektowane wielowarstwowo. Przed wysyceniem pasma mogą nas obronić usługi klasy operatorskiej polegające na filtrowaniu, blokowaniu lub przekierowaniu złośliwego ruchu. Wielu dostawców ma w swojej ofercie usługi w postaci zintegrowanych bramek bezpieczeństwa, które mają zapewnić obronę na warstwach sieci i aplikacji. Są też oferowane przez dostawców narzędzia open source, które mogą wzmocnić ochronę przed tego typu atakami. Kolejnymi dobrymi praktykami podnoszącymi poziom bezpieczeństwa jest stosowanie silnych metod uwierzytelnienia oraz zarządzanie podatnościami.
  • Elevation of Privilege polega na podniesieniu poziomu uprawnień do zasobów niedostępnych w normalnym trybie. Zagrożenia te wiążą się najczęściej z błędami popełnionymi podczas tworzenia systemu i mogą dotyczyć uzyskania dostępu do zasobów, które wymagają wyższych niż posiadane uprawnienia (vertical privilege escalation) bądź do zasobów innego użytkownika na tym samym poziomie uprawnień (horizontal privilege escalation). Dobrymi praktykami ochrony przed tymi zagrożeniami jest wdrożenie odpowiedniego systemu do zarządzania dostępem i uprawnieniami oraz regularne skanowanie i zarządzanie podatnościami.

Projektując ochronę przed zagrożeniami, należy pamiętać o specyfice architektury modelu chmury i związanej z nią odpowiedzialnością za zabezpieczanie elementów na poszczególnych warstwach stosu SPI oraz w zależności od lokalizacji usług (chmura publiczna lub prywatna). Te zależności można przedstawić za pomocą uproszczonego modelu.

Rozwój i testowanie – biorąc za przykład koncepcję DevSecOps, te dwa etapy cyklu powinny tworzyć łańcuch ciągłej integracji, dostarczenia i wdrożenia (CI/CD pipeline). O automatyzacji tego procesu wspomniałem przy okazji fazy definiowania. Część działań związanych z monitorowaniem procesu i wykonaniem testów również można zautomatyzować. Poniżej przedstawię kilka z nich, które można zintegrować z rutynowymi testami realizowanymi przez zespoły DevOps.

a. Przegląd kodu – można go zrealizować ręcznie lub automatycznie.  Bez uruchomiania kodu (statyczna analiza) lub w trakcie jego wykonania (dynamiczna analiza). Może obejmować analizę podatności oraz fuzzing. Możemy w tym celu wykorzystać rozwiązania znane jako Static Application Security Testing (SAST) lub Dynamic Application Security Testing (DAST). Jest szereg narzędzi w modelu open source m.in. oferowanych przez OWASP (jak SonarQube czy ZAP) oraz dostarczanych w ramach usług przez dostawców.

b. Testy bezpieczeństwa – mogą być zintegrowane z testami jednostkowymi, funkcjonalnymi i niefunkcjonalnymi. Obejmują również testy penetracyjne i mogą weryfikować następujące obszary:

  1. konfiguracja systemu,
  2. logika procedur biznesowych,
  3. proces uwierzytelniania,
  4. proces autoryzacji,
  5. zarządzanie sesją użytkownika,
  6. walidacja danych wejściowych,
  7. obsługa błędów,
  8. web services,
  9. stosowane standardy kryptograficzne,
  10. środowisko uruchomieniowe,
  11. zarządzanie pamięcią,
  12. logowanie zdarzeń,
  13. możliwość eskalacji uprawnień w przypadku środowiska multidzierżawionego.

c. Monitorowanie bezpieczeństwa – polega na obserwacji parametrów działania różnych procesów względem wcześniej zdefiniowanych wskaźników (np. Key Performance Indicators, Key Risk Indicators) i podejmowaniu zaplanowanych akcji. Można monitorować m.in. wydajność środowiska czy aplikacji lub nietypowe zachowania wskazujące na obecność intruza lub działanie złośliwego oprogramowania.

O czym należy pamiętać, projektując proces weryfikacji i monitorowania w modelu cloud computing:

  • Planując testy, musimy mieć świadomość, jaki zakres możemy wykonać zgodnie z warunkami świadczenia usług. Szerzej opisuję to w jednym z artykułówpoświęconych audytowi i testom w chmurze.
  • Testy nie powinny obejmować tylko technologii, ale również świadomość i wiedzę użytkowników oraz procesy, w celu sprawdzenia stosowania i skuteczności procedur i standardów.
  • Większość testów powinna odbywać się już na etapie rozwoju (DEV), aby jak najwcześniej wykryć i naprawić błędy, jeszcze przed wdrożeniem rozwiązania w środowisku produkcyjnym.

Continous deployment pipeline – Cloud Security Alliance 

  • Testy penetracyjne powinny być realizowane przez podmiot, który ma już doświadczenie w testowaniu usług tego dostawcy, w szczególności API.
  • Ze względu na ograniczenie w dostępie do logów na platformach chmurowych należy zadbać, aby aplikacja niwelowała te braki i generowała odpowiednią ilość logów. Ponadto logi powinny być zrozumiałe i tworzone w powszechnie akceptowanym formacie (np. XML), by łatwo podlegać parsowaniu przez zewnętrzny system.

Podsumowanie

  • Zbuduj kulturę bezpieczeństwa i uczyń ją stałym elementem cyklu SDLC na każdym z jego etapów.
  • Testuj wcześnie i często, ale adekwatnie do potrzeb.

Rys. 1. Proporcje testów na fazy cyklu
Rys. 2. Proporcje testów ze względu na techniki (OWASP Testing Guide ver.4)

  • Pamiętaj o współdzielonej odpowiedzialności (dostawca–odbiorca) za zarządzanie i zabezpieczenie elementów na poszczególnych warstwach stosu SPI. Uwzględnij ten aspekt przy modelowaniu zagrożeń i projektowaniu testów oraz monitorowania. Nie wszystko w chmurze jest możliwe i widoczne.
  • Oprócz wyzwań dotyczących rozwoju aplikacji na platformach chmurowych wykorzystaj ich potencjał:
    • Dostawcy kładą duży nacisk na bezpieczeństwo swoich rozwiązań, więc przynajmniej teoretycznie odchodzi nam duża część obszaru do ochrony i możemy więcej uwagi poświęcić na zabezpieczanie samego procesu tworzenia oprogramowania. Ponadto część z nich oferuje dodatkowe narzędzia, które łatwo można wkomponować w cykl rozwoju
    • Skalowalność, elastyczność i łatwa możliwość korzystania z mikroserwisów oraz tworzenia odseparowanych środowisk może być dużym atutem (ale też problemem).
    • Dostawcy, chcąc świadczyć usługi w wielu sektorach, muszą spełnić wiele wymagań dotyczących zgodności z wieloma regulacjami.
    • Jednolite interfejsy, API, narzędzia do orkiestracji i zarządzania infrastrukturą, platformą i aplikacjami, umożliwiają uzyskanie szerszego obrazu i lepszej komunikacji między zespołami DevOps.
Facebooktwittergoogle_pluslinkedin
Facebooklinkedin

Skomentuj