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

Bezpieczeństwo aplikacji jest szerokim zagadnieniem obejmującym wiele aspektów od wczesnego projektowania i modelowania zagrożeń po utrzymanie i ochronę w środowisku produkcyjnym. Dziś skupimy się na cyklu tworzenia bezpiecznego oprogramowania.

Cykl artykułów

Artykuł jest częścią zaplanowanego na cały rok cyklu artykułów oraz webinarów sponsorowanych przez firmę Aruba Cloud – dostawcę usług chmurowych z centrum przetwarzania w Polsce. Omówiliśmy już sporo tematów:

• • architektura modelu cloud computingu wg NIST SP 800-145,
  • ryzyka natury organizacyjno-prawnej i zarządzania zgodnością na przykładzie pojęcia GRC – Governance, Risk management and Compliance,
  • standardy bezpieczeństwa, jakie powinna spełniać usługa chmurowa i jak możemy sprawdzić, czy te standardy faktycznie spełnia,
  • zarządzanie tożsamością w chmurze i standardy SAML, OpenID, OAuth,
  • wdrożenie i zarządzanie uprawnieniami w chmurze,
  • przygotowania do wielkiej awarii,
  • bezpieczeństwo centrum danych,
  • bezpieczeństwo środowiska wirtualnego,
  • szyfrowanie w chmurze,
  • zarządzanie incydentami w chmurze,
  • interoperacyjność i przenaszalność – jak uniezależnić się od dostawcy

Ważnym elementem naszego cyklu są także webinary, gdzie będzie można nie tylko posłuchać o chmurze, ale także zadać swoje pytania i otrzymać na nie odpowiedzi. Najbliższe już 27 listopada o godzinie 20:00 i 28 listopada o godzinie 12:00. Temat: Bezpieczeństwo chmury – zarządzanie relacjami z dostawcami. Podczas webinara uczestnicy dowiedzą się, jakie są kluczowe czynniki przy wyborze dostawcy chmury z punktu widzenia zapewnienia bezpieczeństwa. Nasz ekspert zaprezentuje też kilka pomocnych narzędzi do oceny dostawcy. Możecie zapisywać się już teraz.

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łów poś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.

Przypominam także o możliwości zapisania się na webinary – najbliższe już 27 listopada o godzinie 20:00 i 28 listopada o godzinie 12:00. W ich trakcie uczestnicy dowiedzą się, jakie są kluczowe czynniki przy wyborze dostawcy chmury z punktu widzenia zapewnienia bezpieczeństwa. Przedstawię też opracowane przez Cloud Security Alliance programy i narzędzia ułatwiające uzyskanie informacji, w jaki sposób dostawca usługi zapewnia bezpieczeństwo i zgodność swoich usług oraz w jaki sposób umożliwia odbiorcy ochronę zaimplementowanych rozwiązań.

Program:

1. Podsumowanie zagadnień poruszanych w poprzednich artykułach
2. Kluczowe czynniki przy wyborze dostawcy usługi z punktu widzenia bezpieczeństwa
3. Omówienie praktyk i narzędzi do oceny dostawcy i usługi chmurowej dostarczanych przez CSA
4. Podsumowanie
5. Sesja pytań od uczestników

Możecie zapisywać się już teraz.

Dla zachowania pełnej przejrzystości: za opublikowanie tego artykułu pobieramy wynagrodzenie.