Eksperci są zgodni: wymagania bezpieczeństwa powinny być uwzględniane już na wczesnych etapach cyklu rozwoju oprogramowania. W przeciwnym razie pozostają jedynie działania „na ostatniej prostej”, które oznaczają albo wysokie koszty, albo konieczność akceptowania dużego ryzyka. W prezentacjach i rozmowach na temat związku bezpieczeństwa systemów z procesem ich tworzenia i cyklem rozwoju aplikacji przewijały się, poza prewencją, dwa inne hasła: automatyzacja systemów zabezpieczeń oraz współpraca pomiędzy działami programistycznymi, operacyjnymi, biznesowymi i bezpieczeństwa.

Wycieki danych na skutek „dziur” w aplikacjach to poważne zagrożenie. Niedawny przypadek amerykańskiej firmy Equifax pokazał, jak niezałatana podatność w Apache Struts2 spowodowała ujawnienie 143 mln wrażliwych danych osobowych. Taki wyciek w kontekście wchodzącego wkrótce w życie rozporządzenia RODO wiązałby się ze znaczącymi konsekwencjami finansowymi. Straty bezpośrednie w wysokości 9 mln USD, które były efektem wycieku danych z RBS Worldpay przed blisko dekadą, dzisiaj z pewnością osiągnęłyby wyższy poziom.

„Statystyki są zatrważające. Doświadczenia ekspertów KPMG wskazują, że aż 83% testowanych aplikacji zawiera podatności o priorytecie wysokim lub krytycznym. Przykładowo, pozwalają one na uzyskanie pełnego dostępu do bazy danych, wykonywanie poleceń na serwerze albo przejęcie sesji użytkowników. Natomiast z raportu ‚High Tech Bridge App Security Trends Reports 2017’ wynika, że fundamentalne luki w bezpieczeństwie zawiera aż 98% paneli administracyjnych IoT” – mówił Michał Kurek, partner KPMG Cyber Security, Lider OWASP (Open Web Application Security Project) Warszawa, występujący z prezentacją: Jak włączać bezpieczeństwo w procesy wytwarzania aplikacji w kontekście RODO.

Przytoczone dane pokazują, że organizacje mają poważny problem z identyfikacją i eliminowaniem podatności. Potwierdzają to również inne badania. Niemal połowa aplikacji jest stale podatna na atak. Średni czas usunięcia podatności oznaczonych jako krytyczne wynosi 126 dni lub nawet 196 dni dla podatności o priorytecie wysokim. Takie dane podaje raport „2017 WhiteHat Security – Application Security Statistics”.

„Właśnie dlatego kwestie bezpieczeństwa należy włączyć jak najwcześniej do prac nad oprogramowaniem, najlepiej na początkowym etapie cyklu SDLC – Software Development Lifecycle. Wykonanie testu penetracyjnego nie zapewni bezpieczeństwa, a przy tym działanie na końcowym etapie będzie bardzo kosztowne. Naprawa po wdrożeniu może wiązać się nawet ze stukrotnie większymi kosztami, niż gdyby udało się wprowadzić poprawki na początku cyklu” – ocenia Michał Kurek.

Promowanie bezpieczeństwa nie może ograniczać się wyłącznie do deweloperów. Pełne zrozumienie zagrożeń i konieczności uwzględnienia odpowiednich wymagań musi pojawić się także po stronie osób zlecających projekty. Funkcjonalność i czas nie mogą stanowić jedynych priorytetów podczas tworzenia oprogramowania.

Dobre praktyki

Co można zatem zrobić? Jakie zastosować mechanizmy kontrolne? Po pierwsze, należy postawić na edukację. Świadomość cyberzagrożeń pozwala zwiększyć czujność. Nie sprawdzają się bowiem ani prośby, ani groźby. Znacznie lepszym rozwiązaniem są szkolenia – w pierwszej kolejności dla deweloperów. „Nie powinny one mieć technicznego charakteru, ale zamiast tego skupiać się na budowaniu świadomości. Jeśli uda się przekonać deweloperów, że bezpieczeństwo musi pojawić się na wczesnych etapach procesu tworzenia oprogramowania, sukces będzie znacznie bliżej. Prewencja jest zawsze lepsza niż reagowanie” – przekonywał podczas dyskusji w jednej z sesji Roundtables Wojciech Dworakowski, IT Security Expert, SecuRing.

Promowanie bezpieczeństwa i podnoszenie świadomości nie może przy tym ograniczać się wyłącznie do deweloperów. Pełne zrozumienie zagrożeń i konieczności uwzględnienia odpowiednich wymagań musi pojawić się także po stronie osób zlecających projekty. Funkcjonalność i czas nie mogą stanowić jedynych priorytetów podczas tworzenia oprogramowania.

Kolejnym środkiem zapobiegawczym jest modelowanie zagrożeń. „Mając przeanalizowane zagrożenia, można stworzyć specyfikację wymagań bezpieczeństwa, co pozwala najmniejszym kosztem zwiększyć bezpieczeństwo. Zamawiając rozwój systemu w firmie zewnętrznej, nie wolno zakładać, że bezpieczeństwo zostanie włączone w projekt. Niestety, tak nie jest. Wszystko trzeba wyspecyfikować. Nie wystarczy zapis, że aplikacja ma być bezpieczna. Najlepiej przygotować listę wymagań jako załącznik do umowy” – radził Michał Kurek.

Dobrą praktyką są testy automatyczne już na etapie tworzenia kodu. Istnieją gotowe narzędzia, które pozwalają je zrealizować. Na koniec należy przeprowadzić audyt bezpieczeństwa. Najbardziej efektywne kosztowo są testy penetracyjne. Jeśli natomiast oprogramowanie stanowi istotny z biznesowego punktu widzenia system, przydatne jest zlecenie inspekcji kodu. Pośród najlepszych praktyk w tym zakresie wskazywano na: OWASP SAMM (Software Assurance Maturity Model), SDL (Security Development Model – Microsoft) oraz BSIMM (Builidng Security In Maturity Model).

Michał Kurek zwracał szczególną uwagę na OWASP SAMM v 1.5, który dzieli proces SDLC na 12 obszarów (4 funkcje i 3 poziomy dojrzałości). W jaki sposób SAMM może pomóc organizacji? Przede wszystkim umożliwia weryfikację bezpieczeństwa w obecnie realizowanym procesie wytwarzania oprogramowania. Budowa programu podniesienia bezpieczeństwa odbywa się w zdefiniowanych iteracjach. Można zaplanować dojście do idealnego stanu na dłuższy, kilkuletni okres. SAMM dostarcza także definicje i narzędzia do pomiaru skuteczności działań związanych z bezpieczeństwem aplikacji. W wersji 2.0 (planowanej na 2018/2019 rok) pojawi się też możliwość porównywania z innymi organizacjami. Zanonimizowane dane z różnych organizacji pozwolą każdemu na benchmarking.

Jeśli uda się przekonać deweloperów, że bezpieczeństwo musi pojawić się na wczesnych etapach procesu tworzenia oprogramowania, sukces będzie znacznie bliżej. Prewencja jest zawsze lepsza niż reagowanie.

Metoda małych kroków

Paweł Krawczyk, specjalista bezpieczeństwa informacji w Krawczyk Industries Ltd, podczas prezentacji „Wdrażanie strategii bezpieczeństwa oprogramowania” zwracał uwagę, że na bezpieczeństwo SDLC warto spojrzeć z różnych perspektyw. Wielu ekspertów ds. bezpieczeństwa dostrzega jedynie luki. Tymczasem warto przyjrzeć się kwestiom bezpieczeństwa także z perspektywy deweloperów.

„Większość realizowanych projektów to nie są nowe przedsięwzięcia. Mamy działające, krytyczne systemy biznesowe w produkcji. Są aplikacje, które powstały ponad 20 lat temu na potrzeby wewnętrzne, w bezpiecznej sieci, a dziś zaczyna im się stawiać zupełnie inne wymagania. Systemy napisane dla niewielkiej organizacji z czasem zaczynają obsługiwać ogromne przedsiębiorstwa” – mówił Paweł Krawczyk.

Czy takie systemy są bezpieczne? Czy do środka sieci można przeniknąć? Zdaniem Pawła Krawczyka, można. „Niezależnie od tego, jak zabezpieczymy perymetr, jest prawdopodobne, że ktoś i tak będzie w stanie dokonać włamania. Przepisanie takiego systemu jest nierealne. Do tego system musi cały czas działać. Dlatego w większości przypadków najlepszym rozwiązaniem są działania polegające na stopniowym podnoszeniu bezpieczeństwa poprzez wykonywanie małych kroków. Przykładowo, można wyizolować sieci wrażliwe, co pozwala takie starsze aplikacje ukryć” – uważa Paweł Krawczyk.

Co konkretnie można zrobić? Pierwszym krokiem może być odizolowanie sieci stacji roboczych od sieci serwerowych oraz ograniczenie dostępu do aplikacji wrażliwych poprzez uruchomienie firewalla na serwerze. Takie działania są łatwe do realizacji. Choć nie zapewnią od razu wysokiego poziomu bezpieczeństwa, to pozwolą na jego znaczące podniesienie – w prosty sposób, bez przerywania pracy aplikacji.

Można także izolować procesy. Starsze aplikacje czasem działają na przestarzałych, niebezpiecznych frameworkach. W takich przypadkach można użyć np. Dockera, który pozwala na izolowanie przy zachowaniu starego środowiska, starej aplikacji i bilioteki, ale przy użyciu współczesnego kernela, polityki bezpieczeństwa AppArmor czy SELinux. Inny przykład to Waratek oferujący AppArmor dla JAVA JRE, emulację starych wersji API, polityki bezpieczeństwa oraz RASP – Run Time Self Protection.

Warto także usuwać nieużywane komponenty oraz czyścić kod. Duże aplikacje kumulują stary kod. Chodzi więc o blokowanie odwołań na poziomie web proxy, logowanie odwołań funkcji planowanych do usunięcia, a także usuwanie kodu źródłowego.

Dobrą praktyką są testy automatyczne już na etapie tworzenia kodu. Istnieją gotowe narzędzia, które pozwalają je zrealizować.

Bezpieczne DevOps

Na szczególną uwagę zasługuje coraz bardziej popularna metodyka DevOps. „Wykorzystywane na różnych etapach ‚linii produkcyjnych’ DevOps klucze i hasła do uwierzytelniania wymagają odpowiedniego zabezpieczenia. Dlatego bezpieczeństwo w tym kontekście staje się coraz bardziej krytycznym zagadnieniem” – tłumaczył Alex Wilson, DevSecOps Lead w CyberArk.

DevOps realizuje się przez współpracę i zautomatyzowane zadania. Wymagana jest także odpowiednio przygotowana, działająca automatycznie infrastruktura. Przynosi to ogromne korzyści. Analitycy z Gartnera przekonują o 46-krotnym zwiększeniu częstotliwości wdrożeń, 96-krotnie szybszym odtwarzaniu po błędach, 440-krotnie szybszym czasie wprowadzania zmian, a przy tym 5-krotnie mniejszym wskaźniku awaryjności. Ze względu na te ogromne korzyści DevOps powoli staje się normą.

Organizacje stawiają na DevOps, żeby przyspieszać innowacje. Tradycyjne rozwiązania do zarządzania tożsamością i dostępem nie są jednak w stanie obsłużyć takich przepływów pracy. Dlatego potrzebne są nowe rozwiązania, które zapewnią bezpieczeństwo bez spowalniania tempa dostarczania oprogramowania.

Powszechne wykorzystywanie narzędzi pozwalających na automatyzowanie procesów DevOps oznacza, że realizowane do niedawna przez człowieka w formie interaktywnego procesu obecnie zaczynają być wykonywane przez automaty, boty. To właśnie dzięki narzędziom automatyzującym można osiągnąć wspomniane wcześniej korzyści. Te roboty stają się w praktyce uprzywilejowanymi użytkownikami – jeszcze kilka lat temu byli to ludzie.

W efekcie cały ten proces w zakresie tworzenia aplikacji i usług nie jest zabezpieczony na odpowiednim poziomie, m.in. pod względem podziału obowiązków, czy jeśli chodzi o audyt obejmujący roboty. Jest to doskonale widoczne, gdy porównany istniejące w tym zakresie mechanizmy do środków zabezpieczających, jakie stosowane są w przypadku interaktywnych użytkowników będących ludźmi.

W stosunkowo krótkim czasie udało się zaobserwować pierwsze efekty tego stanu rzeczy. Można wskazać przynajmniej kilka znanych przykładów organizacji, które były niedostatecznie pod tym względem zabezpieczone i dające ogromne uprawnienia klucze uwierzytelniające zostały przez pomyłkę udostępnione publicznie. Istnieją także udokumentowane przypadki wycieków danych, które były efektem upublicznienia kluczy API dających szeroki dostęp do infrastruktury organizacji. Pomyłkowo przesłano je do publicznych repozytoriów kodu. W takim przypadku atakujący nie potrzebuje szczególnych umiejętności technicznych, żeby zyskać dostęp do środowiska i wszystkich znajdujących się w nim wrażliwych danych.

Powszechne wykorzystywanie narzędzi pozwalających na automatyzowanie procesów DevOps oznacza, że zadania realizowane do niedawna przez człowieka w formie interaktywnego procesu obecnie zaczynają być wykonywane przez automaty. Te roboty stają się w praktyce uprzywilejowanymi użytkownikami. To wymaga nowego podejścia do bezpieczeństwa.

Narzędzia nowej generacji

„W świecie DevOps wykorzystuje się mnóstwo nowych narzędzi wymagających uwierzytelniania. Rzadko jednak stosuje się do nich takie same zasady jak do innych używanych w organizacji systemów. Przez to powstają ‘wyspy bezpieczeństwa” – mówił Alex Wilson. I dodawał: „Linie DevOps są w pełni zautomatyzowane. W wielu miejscach trzeba umieścić tajne informacje służące do uwierzytelniania, żeby przepływ mógł być realizowany bez interwencji człowieka. To ogromne pole ataku”.

CyberArk Conjur to zautomatyzowane rozwiązanie do zarządzania sekretnymi informacjami uwierzytelniającymi. Narzędzie dostosowane jest do wymagań chmury oraz środowisk DevOps. Pomaga zespołom IT oraz pionu bezpieczeństwa zarządzać kluczami i hasłami używanymi przez „maszyny” (aplikacje, mikrousługi, narzędzia, interfejsy API) oraz użytkowników w skali całej linii DevOps.

Conjur jest w stanie obsłużyć środowiska skonteneryzowane, a przy tym może być uruchomiony lokalnie lub w dowolnej chmurze. Opiera się na mechanizmach RBAC (Role Based Access Control), dzięki czemu zróżnicowane przywileje mogą być przyznawane grupom użytkowników lub maszyn. Rozwiązanie integruje się z narzędziami Continuous Integration/Continuous Deployment (Ansible, Ched, Jenkins, Puppet) oraz platformami kontenerowymi, takimi jak Docker. Integruje się także z istniejącymi systemami i praktykami bezpieczeństwa.

„Włączenie bezpieczeństwa w procesy DevOps bez utraty korzyści płynących z tego modelu jest możliwe” – twierdzi Alex Wilson. Przede wszystkim należy zrozumieć, że celem DevOps jest zwiększenie szybkości procesów wytwarzania oprogramowania. Trzeba uważać, żeby stosowane zabezpieczenia nie wpłynęły na zatrzymanie procesów i nie zniwelowały zysków czasowych wynikających z ciągłej integracji oraz ciągłego dostarczania rozwiązań. Kluczowe znaczenie, zdaniem Alexa Wilsona, ma zatem to, żeby włączyć zespół bezpieczeństwa na takich samych zasadach, które pozwalają automatyzować i przyspieszać współpracę pomiędzy zespołami programistów i operacyjnymi. Należy dostarczyć usługi bezpieczeństwa, które nie spowolnią procesów i przepływów pracy.