W poprzednim wpisie, starałem się wyjaśnić podstawowe terminy związane z ryzykiem. Jakim ryzykiem - biznesowym. Zaniepokojeni radiosłuchacze wnet zakrzyczą redaktora prowadzącego: “a co z ryzykiem IT, ryzykiem bezpieczeństwa IT”?!
Cały czas piszę o tym samym ryzyku. Ryzyko dla biznesu w dużym skrócie (żeby po raz kolejny nie rozwijać tematu na cały wpis) - to albo niedostarczenie wartości w ogóle albo niedostarczenie na czas - co związane będzie z utratą planowanych korzyści, utratą części rynku (bo konkurencja, czego nie robi? - nie śpi), bądź utrata wartości i straty dla firmy, wynikające z wad, błędów, przerw w działaniu systemów IT, powtarzaniem tych samych czasochłonnych czynności, brak danych, które tenże biznes wspierają i co raz częściej go po prostu realizują.
No tak, tak, włamy, ransomware, późniejsze przestoje, odtwarzanie z backupów, architektura od SOAsa do Lasa, ale i nieudane aktualizacje, ciężko realizowalne migracje, zabałaganione projekty, nieuporządkowane zarządzanie incydentami i problemami, nieaktualizowane procesy rozwoju oprogramowania - słowem, palenie cennego czasu i umiejętności IT na rzeczy które nie przynoszą wartości - są stratą. Przypomina mi się co odpowiadałem każdemu, kto pytał kiedyś - “a ile pali twoje auto” - odpowiadałem: “Wszystko, co wleję to spali.. ale dojeżdża, tam gdzie chcę”.
W każdym razie, są to straty, których bezpieczeństwo często nie widzi, bo ma swoje incydenty bezpieczeństwa, a incydenty IT, czy istny wodospad ticketów w JIRze mało ich już interesuje. Zainteresowanie audytu też kończy się właściwie na tym, czy próbka ticketów, które sobie wylosują podczas audytu, są opisywane i realizowane zgodnie z przyjętym procesem, a nie ile ich jest, i dlaczego tak dużo. Bo w ten sposób, cały DevOps jest w gruncie rzeczy, dla bezpieczeństwa i audytu kompletnie przezroczysty, w tym sensie - że, nierozróżnialny od tego co się do tej pory działo w IT.
Czego nie widzi bezpieczeństwo
O ile samo słowo DevOps jest już popularne i przebija się tu i tam, bywa widziane na Linkedinie (o ile bezpiecznik nie mieszka tam jedynie w swojej bezpieczniackiej bańce). Bezpiecznik zazwyczaj orientuje się, że DevOps to kolejny proces wytwórczy oprogramowania (Agile, może?), ale już może nie kojarzyć, że to proces dość specyficzny. Nie wystarczy na kickoffie spotkać się z architektem, analitykiem biznesowym, jakimś super-adminem, by przekazać im litanię wymagań bezpieczeństwa, a potem wrócić do swojego knucia i spiskowania.
Często, optyka bezpieczeństwa wobec procesu i środowiska DevOpsowego jest dość tradycyjna - taka jak wobec każdego innego systemu czy ekosystemu aplikacji, których powstało już w firmie ileś tam przez ostatnie X lat. Czyli “my się tu nie będziemy wtrącać” - ważne by zachować zgodność z politykami, standardami i procedurami. Jest to optyka niewystarczająca.
Gdzie ma dojechać DevOps
Podejście DevOps ma dostarczyć działające oprogramowanie/rozwiązanie/ekosystem metodą małych kroczących, a częstych zmian. Zaczyna się tradycyjnie od narady z biznesem, analitykami biznesowymi IT, architektem IT i bezpiecznikami - aby ustalić CO ma być. Aczkolwiek nie ma tu tradycyjnego podziału (ulubionego przez działy “Compliance” - ang. separation of duties). Bardzo ważne jest zaangażowanie biznesu, który od samego początku pracuje nad scenariuszami testowymi z testerami, których powodzenie zamyka kolejne etapy wytwarzania aplikacji. Cały zespół to multidyscyplinarna ekipa programistów, adminów, testerów, i (dobrze byłoby) bezpieczników - którzy zajmują sie całym cyklem życia produktu nad którym pracują - czyli: zaprojektowaniem, rozwojem i utrzymaniem (ang. production support), błyskawicznie reagując na pojawiające się nowe wymagania biznesu, zmiany w środowisku IT, błędy w oprogramowaniu, słabości i podatności bezpieczeństwa w aplikacji i jej środowisku.
A żeby było błyskawicznie, efektywnie i ..bezpiecznie (!) praca takiego zespołu opiera się na trzech filarach (za JHumble i DFarley “Continuous Delivery” Addison&Wesley 2011):
- Automatyzacja - im więcej tym lepiej, to co człowiek ma zrobić ręcznie i powielokroć, niechaj zrobi maszyna; Jeśli mamy zapewnić powtarzalność i raportowanie etapów procesu, to lepiej od człowieka zrobi to maszyna. Dotyczy to całego cyklu: budowania, integracji, testowania i wydawania aplikacji . Szybko zrealizowane, powtarzalne etapy są kontrolowalne, mierzalne i zapewniają szybką informację zwrotną - dlaczego coś się “wysypało”. Dla budowania czegokolwiek od prototypu do pełnego produktu, w kolejnych iteracjach - jakość i częstotliwość informacji zwrotnej ma kapitalne znaczenie.
- Częstotliwość - im częściej uruchamiamy nasz cykl (dla każdego nawet małego commitu, zmiany w konfiguracji, integracji, podbicia wersji, itd.), otrzymamy tym niższą deltę różnic miedzy kolejnymi wydaniami. A co za tym idzie, mniej szans na katastrofę, jeśli wydanie się nie powiedzie i trzeba się cofnąć do poprzedniej działającej (ang. rollback).
- Informacja zwrotna - każde wydarzenie w cyklu wytwórczym ma wygenerować właściwą informację zwrotną, na podstawie której nastąpi szybka reakcja (np. w ciągu 15 minut). Monitoring, logi operacji i powiadomienia.
Warunkiem powodzenia działania tych trzech filarów, a szczególnie automatyzacji, jest pełna kontrola (wersjonowanie i audytowalność) nad kodem aplikacji, konfiguracją komponentów aplikacji i samego informatycznego ekosystemu devopsowego, niezależnie czy to chmura czy infrastruktura własna (ang. Configuration as a Code i Infrastructure as a Code, no i kontrola nad danymi.
Nie powinno się dopuścić do tradycyjnego podziału (i silosów) - architekci - projektują, programiści - programują, admini - adminują, wsparcie - obsługuje tickety i eskaluje, a bezpieczeństwo pojawia się tylko na początku (wymagania) i na końcu (skanuje albo pentestuje aplikację). Dlaczego? Bo wtedy DevOps się nie uda. To znaczy, być może się uda, ale produktem takiego podejścia, będzie lekki bałagan. Bo, cóż automatyzacja sama z siebie może zapewnić, skoro nie mamy adresata informacji zwrotnej? Albo mamy i adresata takiej informacji, ale skoro nie brał udziału w cyklu rozwoju aplikacji, to nie rozumie tej informacji? Albo i rozumie, ale nic nie z tym nie zrobi, bo autorzy tej aplikacji poprawkę mogą napisać za pół roku, bo teraz siedzą w innym projekcie. Albo wydanie i tak jest realizowane raz na kilka miesięcy, a za automatyzacją budowania i integracji nie poszła niestety automatyzacja testów, które ciężko jest zautomatyzować, skoro nigdy nie wiadomo co ma być testowane?( anty-wzorce, ang. antipatterns, bedą przedmiotem któregoś z kolejnych odcinków).
Gdzie tu miejsce na bezpieczeństwo
Pominę tu aspekt infrastruktury, bo czy chmurowa czy własna, zazwyczaj jest prawidłowo “obsługiwana” przez działy bezpieczeństwa (czy też bezpieczeństwo usług chmurowych - serverless itd) i zbudowana zgodnie ze sztuką (czyli obowiązującymi politykami, standardami - kontrola dostępu, poufność, dystrybucja kluczy kryptograficznych, 0-trust architecture, ale częściej nadal 3-tier, okresowymi “badaniami”, pentestami, itd.).\
(Etap budowy)
- kod aplikacji - jakość i bezpieczeństwo kodu zależą raczej głównie od autora. A autorowi głównie zależy na tym, aby jego kod - działał, jak mu testy jednostkowe nie zrobią niespodzianki, to jedzie dalej. Owszem, można wysłać autora na kursy bezpiecznego programowania, bombardować codziennie linkami do OWASPa, ale jak bezpiecznik sam nie umie za bardzo programować (nie wszyscy są pentesterami, a i nie wszyscy pentesterzy potrafią programować!) to się z programistą nie dogada,
- zależności i biblioteki - od dawna już, programista sam to już niewiele musi wymyślać, bo ma miliony gotowych bibliotek, napisanych przez innych, jak i przez dostawców, którym zależy by ich produkty dawały się jednak integrować; Biblioteki te mają to do siebie, że są niejednorodnie i niezależnie w czasie rozwijane albo nierozwijane, a w kolejnych wydaniach pojawiają się breaking changes. W dodatku mają różne modele licencyjne (co też może rodzić jakieś problemy natury prawnej),
- platforma - niby możnaby to podciągnąć pod integrację, ale jeśli mamy środowisko zwirtualizowane (kvm, częściej docker), warto przeczesać obraz dockera zbudowany pod aplikację czy nie ma w nim jakichś zatrważających podatności, które same z siebie problemu może i nie robią, ale jak się postawi na tym jakieś kompleksowe rozwiązanie, to pojawiają się szersze możliwości (podatność nabiera kontekstu - a więc, realnej wartości), co więcej wyniki takiego skanowania zmieniają się dynamicznie w czasie (niełatanych podatności jakoś nigdy nie ubywa),
(Etap integracji) - integracje - te zazwyczaj można realizować na wiele sposobów, niekoniecznie w bezpieczny sposób (np. zaszywając jakiegoś tokena w kodzie), zostawiając jakieś “backdoory” na wszelki wypadek, brak obsługi odnowienia certyfikatów, usługi postawione na zbyt wysokich uprawnieniach.
(Etap testowania) - gotowa (do wydania) aplikacja - Po przejściu testów akceptacyjnych i “smoke testów”, można tutaj zautomatyzować pewną opracowaną i utrzymywaną (przez kogo? no kogo?) pulę testów bezpieczeństwa wykorzystując dokładnie to samo oprogramowanie wykorzystywane przez pentesterów.
I to dopiero można spiąć klamrą zaczynającą się od burzy mózgów z architektami i analitykami biznesowymi nad wymaganiami niefunkcjonalnymi, a kończącą się na pentestach czy skanowaniu gotowych wydań aplikacji. W następnym odcinku, będzie o praktycznych rozwiązaniach..