Bezpieczeństwo aplikacji

Image for post
Image for post

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Andrzejem Dyjakiem o bezpieczeństwie aplikacji.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Mój dzisiejszy gość to architekt bezpieczeństwa z kilkunastoletnim doświadczeniem, aktywny konsultant, prelegent i szkoleniowiec. Doświadczenie zdobywał w kraju i za granicą, dostarczając pełne spektrum oceny bezpieczeństwa dla organizacji sektora prywatnego i publicznego.

W przeszłości odkrył wiele krytycznych podatności w popularnym oprogramowaniu firm, takich jak Apple, Adobe, Google czy Mozilla. Bloger i podcaster.

Moim i Waszym gościem jest Andrzej Dyjak.

Cześć, Andrzej! Miło mi gościć cię w podcaście.

Cześć, Krzysztofie! Od razu powiem, że cała przyjemność po mojej stronie. Bardzo, bardzo jestem ucieszony, że udało się trafić do Porozmawiajmy o IT.

Też się bardzo cieszę no i oczywiście tematem naszej dzisiejszej rozmowy nie może być nic innego niż bezpieczeństwo, ale trochę to zawęzimy i porozmawiamy sobie o bezpieczeństwie aplikacji.

Oczywiście nie możemy rozpocząć naszej rozmowy bez standardowego, klasycznego pytania na wejście, czyli czy słuchasz podcastów i jeśli tak, to podziel się proszę swoimi ulubionymi audycjami.

Oczywiście, że słucham podcastów. W zasadzie już od paru lat. Zacząłem w 2016 roku, więc to już 4 rok odkąd słucham — w zasadzie parę razy w tygodniu odsłuchuję jakąś audycję. Słucham zarówno podcastów technicznych i z zagranicznych polecam Software Engineering Daily, od którego w zasadzie zacząłem swoją przygodę z podcastami. A już bliżej bezpieczeństwa, takie twory jak Cyber Security Sauna, The Secure Developer i kilka innych też się znajdzie. Takim wybitnym — ja akurat niezbyt za nim przepadam, natomiast myślę, że dla dużej ilości osób jest bardzo fajny, to Darknet Diaries, to jest podcast, który wyjaśnia różnego rodzaju wydarzenia z cyberbezpieczeństwa z przeszłości i opisuje po prostu ich historie.

Robi to w taki ciekawy sposób, jest dobrze zbudowana narracja, dobrze się tego słucha. Mnie osobiście niezbyt dobrze, bo znam te przypadki od strony technicznej, natomiast znam opinie wielu znajomych, którzy nie siedzą w bezpieczeństwie i im się bardzo podoba właśnie Darknet Diaries. Tu więc też polecam każdemu słuchaczowi na przetestowanie i zobaczenie. Być może siądzie, być może nie.

Natomiast jeszcze z takich nietechnicznych podcastów, ale również zagranicznych słucham przede wszystkim The Joe Rogan Experience. Jestem aktywnym i żywym słuchaczem tego podcastu, w dużej mierze dlatego, że bardzo często zapraszani są ludzie, którzy mnie interesują. Osobiście interesuje mnie ich zdanie na ich działki, bo to czasami jest życie, czasami są ich techniczne domeny. Natomiast również polecam ten podcast.

Oczywiście Tim Ferriss Show, Lex Friedman Podcast, The Art of Manliness czy Smart Passive Income. To są dodatki, które też, jeżeli mam trochę więcej czasu, to staram się przesłuchać, staram się być na bieżąco z tymi podcastami.

Z polskich, no to tutaj myślę, że koronne miejsce zajmuje właśnie Porozmawiajmy o IT, głównie dlatego że w zasadzie słuchania polskich podcastów zacząłem od Porozmawiajmy o IT i jest to jednym z jedynych, polskich podcastów, których dalej słucham. Kilka mi przeleciało i końcem końców przesłuchałem to, co mnie interesowało, ale nie zachęciło mnie to do kontynuacji. Natomiast Porozmawiajmy o IT dalej wiernie słucham. Nie wszystkich odcinków, bo też nie wszystkie są dla mnie interesujące, natomiast większość odcinków myślę, że przesłuchałem.

Jeszcze z polskich, zrobię taką małą reklamę trzech innych podcastów, mianowicie polecam Małą Wielką Firmę od Marka Jankowskiego, to myślę, że akurat większość słuchaczy przynajmniej kojarzy, bo to jest dość duży, polski podcast, następnie Biznes w IT Piotrka Buckiego — to jest fajny podcast, natomiast on jest o biznesie, więc nie każdemu musi podejść i takim ostatnim, taką perełką, którą ostatnio znalazłem a bardzo mi się spodobała, to podcast Nowoczesna Sprzedaż i Marketing od Szymona Negacza.

Jeżeli więc ktoś działa w sprzedaży, w marketingu a myślę, że każdy przedsiębiorca w jakimś zakresie działa w tych dwóch polach, to mocno polecam właśnie ten podcast, bo można się dowiedzieć bardzo wielu, bardzo cennych informacji za darmo, więc nie trzeba nikomu płacić za książkę. Szymon się dzieli.

Tutaj się na to pytanie rozwiodłem, natomiast jak sam widzisz słucham podcastów doc dużo i dość żywo. Jeszcze wspomnę na marginesie jak ja to robię — najczęściej staram się łączyć słuchanie podcastów z innymi pracami czy aktywnościami. To znaczy — o ile dla przykładu trudno oglądać film i jechać samochodem albo iść na spacer, to podcast jest tutaj tą świetną formą, gdzie nie ma z tym problemu.

Podcastów więc słucham jadąc autem, idąc na spacer czy sprzątając w domu. Staram się łączyć te aktywności i dlatego też mam tak dużo czasu na przesłuchanie różnego materiału, więc słuchaczom polecam wypróbowanie tego sposobu, bo ułatwia większe przyswojenie różnorodnego materiału, co końcem końców poprawia naszą wiedzę, nasz światopogląd, a to zawsze tylko plusuje w życiu.

Oczywiście. Sypnąłeś podcastami jak z rękawa! Dzięki za te rekomendacje. Cieszę się, że Porozmawiajmy o IT jest też wysoko na tej liście. Dzięki wielkie.

Na początku zapytam cię, o jaką stawkę my tutaj gramy, jeśli chodzi o bezpieczeństwo aplikacji? Dlaczego to bezpieczeństwo jest tak ważne, dlaczego mówi się.o nim coraz częściej i coraz więcej ostatnio?

Na wstępie chciałbym uwypuklić, że nie chciałbym siać paniki, nie o to mi chodzi. Różne środowiska, aplikacje, systemy, różne organizacje mają różne profile ryzyka i związane z nimi modele zagrożeń, więc tutaj nie jest tak, że cokolwiek powiem, można zastosować u siebie. Natomiast patrząc ogólnie na świat, tak to szeroko ujmijmy, to obecnie systemy IT towarzyszą nam praktycznie we wszystkich czynnościach, które wykonujemy w ciągu dnia. I te systemy IT są większe lub mniejsze. Przez system rozumiem tutaj nawet pojedynczą aplikację, najczęściej zbiór aplikacji, które dostarczają jakąś funkcjonalność, nazwijmy to biznesową, czyli po prostu pozwalają nam zrobić coś.

Tym czymś mogą być różne rzeczy, dla przykładu oprogramowanie w naszym czajniku pozwala nam lepiej sterować czajnikiem. Oprogramowanie w naszej pralce pomaga nam włączyć i nastawić pranie, żeby się zrobiło z samego rana i po wstaniu możemy sobie już wywiesić.

Idąc dalej — woda w kranie leci i tę wodę też musi coś przepompować. Te stacje korzystają z software’u, prąd mamy, ale żeby go mieć to elektrownia musi nam go jakoś przesłać. Te stacje też korzystają z software’u. Software jest wszędzie. Oczywiście nie jest tak, że cały ten software jest tak samo podatny, to co na początku powiedziałem, natomiast zmierza to wszystko w takim kierunku. Dlatego w mojej ocenie — żeby nie wyszło nazbyt dramatycznie, ale od paru lat przechodzimy ze strefy pomarańczowej do czerwonej.

Idąc dalej — woda w kranie leci i tę wodę też musi coś przepompować. Te stacje korzystają z software’u, prąd mamy, ale żeby go mieć to elektrownia musi nam go jakoś przesłać. Te stacje też korzystają z software’u. Software jest wszędzie. Oczywiście nie jest tak, że cały ten software jest tak samo podatny, to co na początku powiedziałem, natomiast zmierza to wszystko w takim kierunku. Dlatego w mojej ocenie — żeby nie wyszło nazbyt dramatycznie, ale od paru lat przechodzimy ze strefy pomarańczowej do czerwonej.

Odpowiadając konkretnie na Twoje pytanie, o jaką stawkę gramy, ta stawka zmienia się po trochu w takie być albo nie być. Co też widać pod kątem regulacji. Nie trzeba wspominać o RODO, bo dotyczy czegoś innego — dotyczy prywatności, ale być może nie każdy jest świadomy, natomiast my w Unii Europejskiej mamy już regulację odnośnie cyberbezpieczeństwa.

U nas to jest KSC, która definiuje, że podmioty z branży krytycznej- właśnie dla przykładu te, które wymieniłem: dostawy wody, prądu, linie kolejowe, samoloty — generalnie wszystkie krytyczne dla działania państwa, dla działania infrastruktury. Te elementy muszą być poddane jakiemuś nie tyle testowi, ile podglądowi od strony bezpieczeństwa. Tutaj też nie każdy słuchacz kojarzy to to jest Security Operations Center, ale tu akurat odsyłam do odpowiedniego odcinka Porozmawiajmy o IT, bo nie pamiętam kiedy, ale wydaje mi się, że to było dwa albo trzy, może cztery miesiące temu. Był o tym odcinek więc tam każdy słuchacz może sobie słuchać co to jest Security Operations Center, ale w dwóch słowach to jest po prostu monitorowanie tego, co się dzieje u nas w sieci, co się dzieje w komputerach.

Dla przykładu właśnie w ramach KSC, mamy już wymóg, że ci wszyscy dostawcy usług krytycznych — one są zdefiniowane, muszą mieć coś takiego jak Security Operations Center. Muszą monitorować samych siebie pod kątem bezpieczeństwa, muszą też zgłaszać incydenty. To też pokazuje, że ten ruch, w tę stronę się odbywa cały czas. My w Polsce — nie tylko w Polsce, nawet w Unii Europejskiej jesteśmy trochę do tyłu za tym, co się dzieje w Stanach Zjednoczonych, za tym, co się dzieje w Australii czy w Chinach. Natomiast do nas to dociera.

I tak jak powiedziałem, zaczynamy wchodzić w nazwijmy to taką strefę być albo nie być. I o ile możemy sobie z tego nie zdawać zawsze sprawy, bo nasza świadomość może być na poziomie takim, że korzystamy sobie z fejsa i tyle, no to jednak większość rzeczy, które po prostu mamy w życiu, które jest nam dostarczane, dzieje się właśnie dzięki software’owi aktualnie. I to bezpieczeństwo software’u, tak jak powiedziałem, przechodzi z takiej strefy pomarańczowej do strefy czerwonej. Oczywiście jeszcze w połączeniu z tzw. Internet of Things, gdzie widać pewien ruch w kierunku podłączania różnego rodzaju sprzętu do internetu, co oczywiście zwiększa i ryzyko, i problemy związane z bezpieczeństwem.

Rozumiem. Okej, pokazałeś w taki przejrzysty sposób istotę problemu, ale też pewnie jakoś nie minę się mocno z rzeczywistością, jeżeli powiem, że często w tym procesie wytwarzania oprogramowania, w procesie tworzenia kodu, tworzenia aplikacji o security myśli się na ostatnim etapie, tuż przed release’em, albo nie daj Boże po release’sie.

W twojej opinii w jakim stopniu programiści i product managerowie, którzy bezpośrednio z programistami pracują, są odpowiedzialni za zapewnienie bezpieczeństwa docelowego tej aplikacji? Jak to też wygląda w praktyce, bo możemy sobie teoretyzować, że powinni być, ale jestem ciekawy, jak z twoich obserwacji wynika w praktyce na ile faktycznie te role są zaangażowane w zapewnienie bezpieczeństwa?

Tutaj najpierw odniosę się do tej pierwszej części, mianowicie niestety tak jest, że o tym bezpieczeństwie myśli się trochę pod koniec całego procesu twórczego, a nie na tych początkowych fazach. Co się zmienia? Nie chciałbym oczywiście przekłamywać sytuacji, więc to się zmienia powoli. Na Zachodzie ta zmiana jest już dość mocno widoczna, w Polsce zaczyna być widoczna chęć zmiany, to znaczy zaczyna być budowana świadomość tego, że bezpieczeństwo powinno się dziać na różnych etapach procesu wytwórczego po to, żeby po pierwsze zapewnić jak najwyższy poziom bezpieczeństwa, oczywiście taki, który sobie ustalimy i który jesteśmy w stanie zaakceptować, ale też, żeby zmniejszyć koszty.

Bo jednak jeżeli o bezpieczeństwie będziemy myśleć w fazie designu, dla przykładu przez modelowanie zagrożeń, no to takie ćwiczenie pozwoli nam wyłapać różne problemy już właśnie na etapie designu. Czyli nie popełnimy błędów, które moglibyśmy popełnić, gdybyśmy tego nie zrobili. To jest jeden z przykładów. To bezpieczeństwo przesuwa się w lewo, w tzw. shift left i ono w każdej z faz — zależy oczywiście jaki mamy proces wytwórczy, ale w każdej z faz, tych początkowych, przed release’em, ma jakieś kontrole, które możemy uruchomić, które możemy wprowadzić w nasz proces wytwórczy, które końcem końców mają nam zapewnić wyższy poziom bezpieczeństwa, ale też oczywiście ze strony biznesowej obniżyć koszt, jakim jest bezpieczeństwo.

Bo jednak jeżeli o bezpieczeństwie będziemy myśleć w fazie designu, dla przykładu przez modelowanie zagrożeń, no to takie ćwiczenie pozwoli nam wyłapać różne problemy już właśnie na etapie designu. Czyli nie popełnimy błędów, które moglibyśmy popełnić, gdybyśmy tego nie zrobili. To jest jeden z przykładów.

Jeżeli wyłapiemy coś wcześniej, to usunięcie problemu kosztuje nas mniej. Zapytałeś konkretnie o programistów i managerów, to znaczy, w jakim stopniu oni są odpowiedzialni za bezpieczeństwo — w zasadzie od managerów, nawet nie tyle managerów, w ogóle od biznesu wydaje mi się, że jedyne czego można wymagać to po prostu świadomości, że pewne kwestie powinny zostać dopięte, to już od programisty, czyli osoby technicznej, więc może rozszerzmy to po prostu od ludzi technicznych w procesie wytwórczym można wymagać już jakiejś głębszej wiedzy na temat typowych problemów bezpieczeństwa występujących w technologii, z której dana firma korzysta. Czyli jeżeli mamy na przykład programistów javowych, no to moglibyśmy od nich wymagać tego, żeby kojarzyli jakie są problemy bezpieczeństwa w typowych aplikacjach javowych.

Tutaj też mówię „wymagać” — dobrze by było. Na wymagania jeszcze, powiedzmy, przyjdzie czas, natomiast wydaje mi się, że już teraz powinniśmy przynajmniej oczekiwać, że programista pewną wiedzę na temat bezpieczeństwa po prostu posiada. Niestety to się trochę rozmija z rzeczywistością, bo jednak jeżeli ktoś wychodzi prosto z uczelni, to poziom uczelni w naszym kraju pod kątem bezpieczeństwa aplikacji pozostawia wiele do życzenia, tak dyplomatycznie to ujmę. Natomiast jak już taki człowiek wyjdzie z tej uczelni, wejdzie w świat IT, zacznie pracować, zacznie wytwarzać kod, to z moich obserwacji wynika, że po kilku latach na poziomie mida, seniora ta świadomość już często po prostu jest. I tutaj zaczynamy mieć trochę inny problem, to znaczy programista zdaje sobie sprawę, że pewne problemy bezpieczeństwa mogą wystąpić, ale biznes jeszcze nie ma tak wysokiej świadomości w tej kwestii, że faktycznie rozpoznanie i wyprowadzenie tych problemów już na poziomie myślenia o jakimś rozwiązaniu informatycznym będzie tańszy, będzie bardziej optymalny.

I wtedy to biznes staje się takim, nazwijmy to, blokerem. Sam byłem w procesie wytwórczym, sam byłem programistą, więc wiem, że na koniec dnia dla biznesu liczy się dowiezienie funkcjonalności, a nie bezpieczeństwo. Zdaję sobie z tego sprawę. Nie chciałbym demonizować ani programistów, ani też biznesu — po prostu idziemy w dobrym kierunku, jeszcze tam nie jesteśmy, myślę, że prędzej czy później będziemy. Tak jak wspomniałeś. To bezpieczeństwo cały czas gdzieś tam zaczyna być bardziej żywym tematem w światku IT i wydaje mi się, że zmierzamy w dobrym kierunku.

Zastanawiam się, czy to nie jest przypadkiem trochę jak z pisaniem testów, które kiedyś były kosztem, stały po stronie kosztów, dopiero z biegiem czasu, z biegiem nabywania jakiejś świadomości zrozumieliśmy, że możemy czerpać z nich realną wartość i że mogą nam się przysłużyć.

Czy podobnie też nie jest na przykład z tematem bezpieczeństwa? Czy dopiero zaczniemy zauważać albo zauważamy powoli wagę, istotność zadbania tego obszaru?

Zmierzam tym pytaniem do tego, żeby spytać, czego obecnie według ciebie brakuje deweloperom, aby włączyć temat security do procesu wytwórczego. Czy to jest edukacja, czy to jest może brak presji odgórnej? Czy to jest jeszcze może niska świadomość? Jak ty to oceniasz?

Musielibyśmy to podzielić na rodzaje programistów. Jeżeli weźmiemy wszystkich i wrzucimy do jednego worka, to wydaje mi się, że świadomość zespołów wytwórczych — a zespół wytwórczy często jest złożony z programistów różnego poziomu, czyli i seniorów, i midów, i juniorów, to jeżeli wzięlibyśmy świadomość zespołów wytwórczych, to wydaje mi się, że jest na poziomie całkiem okej. To znaczy — ludzie z mojego doświadczenia kojarzą co to jest TOP 10, nie wszyscy kojarzą Application Security Verification Standard, o którym pewnie jeszcze uda mi się opowiedzieć w tym podcaście, bo to jest świetny temat, ale żeby odpowiedzieć teraz na to pytanie, to o TOP 10 większość programistów zdaje sobie sprawę, że takie coś istnieje. Natomiast już o SVS nie każdy, ale też nie jest ta świadomość na poziomie zerowym.

Natomiast jeżeli już wejdziemy do edukacji i wymogów z góry, czyli nazwijmy tych wymogów biznesu, no to sytuacja wygląda trochę mniej różowo. Z kilku względów — też nie chcę do końca wchodzić w jakieś detale, ale po pierwsze. Pod kątem edukacji — w zasadzie dużo szkoleń dostępnych na rynku, nie tylko polskim, ale polski jest mi najbardziej znany. Na rynku polskim skupia się raczej na bezpieczeństwie z punktu widzenia bezpiecznika, a nie osoby będącej w procesie wytwórczym. Takiej jak programista czy dla przykładu testerzy QA.

To jest problematyczne, ponieważ często objawia się to omawianiem dużej ilości różnych ataków, ale wtedy brakuje skupienia jak można temu przeciwdziałać. To znaczy — usłyszałem kiedyś takie bardzo ładne porównanie, które wpadło mi w pamięć od razu, mianowicie że szkolenia security pokazują jak wysadzać mosty, a ludzie w procesie wytwórczym, programiści, testerzy, architekci chcą widzieć jak budować bezpieczne mosty. I oczywiście, żeby budować bezpieczne mosty to należy wiedzieć, jak się mosty wysadza.

Ale — ta wiedza nie jest wystarczająca. Ona jest konieczna, ale niewystarczająca. Musimy więc pójść krok dalej, musimy pokazać, jak można to budować, a nie tylko pokazywać problemy, bo takie pokazywanie problemów albo traktowanie sprawy po łebkach ja często przyrównuję do takiej rady jak „Jeżeli chcesz schudnąć, to jedz mniej”. Ta porada jest prawdziwa, ona będzie działać, tylko jeśli człowiek chce schudnąć, to chce wiedzieć, w jaki sposób to zrobić, w jaki sposób jeść mniej, a nie to, że po prostu powinna jeść mniej. To jest informacja, a nie coś, czego można użyć w praktyce.

Ale — ta wiedza nie jest wystarczająca. Ona jest konieczna, ale niewystarczająca. Musimy więc pójść krok dalej, musimy pokazać, jak można to budować, a nie tylko pokazywać problemy, bo takie pokazywanie problemów albo traktowanie sprawy po łebkach ja często przyrównuję do takiej rady jak „Jeżeli chcesz schudnąć, to jedz mniej”. Ta porada jest prawdziwa, ona będzie działać, tylko jeśli człowiek chce schudnąć, to chce wiedzieć, w jaki sposób to zrobić, w jaki sposób jeść mniej, a nie to, że po prostu powinna jeść mniej. To jest informacja, a nie coś, czego można użyć w praktyce.

Odnosząc to do edukacji w kontekście bezpieczeństwa, szkolenia raczej największą wartość mają wtedy, kiedy pokazują jak budować ten bezpieczny most, jak budować bezpieczne oprogramowanie, a nie tylko jak je wysadzać. Nie mówię o tym, że trzeba siedzieć z deweloperami i pisać w ID bezpieczny kod, natomiast po każdym jakimś pokazanym ataku powinno być większe skupienie na to, jak można mu przeciwdziałać, co można zrobić, żeby zastopować taki atak, wyprowadzić podatność — a nie tylko „Tu mamy podatność, pokażemy, jak ją wyexploitować, a potem idziemy do kolejnej.

To jest dobre, żeby zbudować świadomość, ale ten drugi krok, czyli edukacja, wydaje mi się, że powinna być czymś szerszym. Natomiast wracając do wymogów z góry, czyli raczej do biznesu, no to tak jak wcześniej powiedziałem, to się powoli zmienia, natomiast biznes musi być świadomy wagi bezpieczeństwa i znaleźć zasoby, aby je zapewnić na odpowiednim poziomie. Często jest tak, że programiści mogą sobie zdawać sprawę z czegoś, co jest problematyczne, ale jeżeli nie mają odpowiednich środków, no to nie będą w stanie nic z tym zrobić. A nawet mogą po prostu zwrócić się do biznesu i powiedzieć, że będzie problem, a biznes może powiedzieć, że akceptuje to ryzyko. Tylko że taka odpowiedź jest poprawna, jeżeli mamy odpowiednią analizę ryzyka, z czym też jest problem. Jeżeli więc biznes nieodpowiednio analizuje ryzyku albo w ogóle i po prostu się na wszystko zgadza, no to wiemy, że to prowadzi do problemów. Wiemy, że to prowadzi do problemów, bo tutaj dobrym porównaniem jest po prostu dług techniczny. W momencie, kiedy biznes zdaje sobie sprawę z powagi długu technicznego, to możemy coś z nim robić. Jeżeli nie, to będzie rósł do momentu, kiedy jakakolwiek zmiana w systemie będzie tak kosztowna, że każdy będzie się łapał za głowę.

Czegoś takiego byśmy nie chcieli w bezpieczeństwie analogicznym.

Poruszyłeś tutaj istotną kwestię współpracy różnych osób, różnych ról w firmie. O ile promowanie działów technicznych jako nerdów zamkniętych w piwnicy myślę, że możemy sobie włożyć pomiędzy bajki, o tyle ja jeszcze dobrze pamiętam takie czasy, kiedy programiści i administratorzy, czy też ogólnie osoby zajmujące się bezpieczeństwem tworzyły trzy niezależne działy, niezależne obozy z osobnymi celami, działającymi zupełnie odrębnie. Później mieliśmy do czynienia z filozofią DevOps, która powiedzmy, jakoś tam mocno zbliżyła przynajmniej tych programistów i administratorów, ale mówi się też ostatnio o czymś takim, co nazywa się DevSecOps. Dlatego chcę też zapytać, jak to podejście wpasowuje się w nowoczesne zespoły i czym jest, jeśli byś mógł powiedzieć kilka słów?

Dobra! O DevSecOpsie można powiedzieć, że dość dużo rozmawiam. Tak jak DevOps w zasadzie składa się na zmianę mindsetu odnośnie do wytwarzania i utrzymywania oprogramowania, które są bardziej widziane od tej strony samej monety, czyli nie jako dwa osobne silosy, tylko jeżeli piszemy software, to w końcu chcemy go utrzymywać. A utrzymywanie software’u jest też w jakimś stopniu wytwarzaniem go. Nazwijmy to takim podziałem logicznym.

Na marginesie chciałbym zaznaczyć, że zmiany i DevOpsowe i DevSecOpsowe, o którym zaraz powiem, możliwe są w dużej mierze właśnie dzięki chmurze, która napędziła automatyzację.

Tak jak ja widzę historię stojącą za DevOpsem, DevSecOpsem, to właśnie ten kawałek, ten obszar bardzo rzuca mi się w oczy. Mianowicie wzrost chmury, która napędziła automatyzację, a automatyzacja można powiedzieć pozwoliła osobom wcześniej działającym tylko w wytwórstwie, tylko w pisaniu oprogramowania, pozwoliła im też tylko niejako pisanie infrastruktury jako kawałek kodu. Jeżeli mamy automatycznie stawianą infrastrukturę w chmurze, to można popatrzeć, że koniec końców infrastruktura jest kodem. Bardzo podobnie jest właśnie w DevSecOpsie. Często mówię, że składa się on na dwa główne filary — na kulturę i automatyzację. O ile automatyzacja jest bardzo podobna do tej monety, o której mówiłem w DevOpsie, jeżeli mamy różnego rodzaju narzędzia to automatyzując je te narzędzia stają się pewnego rodzaju kodem. Mając kod, to dość naturalne, że programista nagle zaczyna widzieć to jako kawałek swojej odpowiedzialności. Bo skoro jest programistą, to tutaj ma kawałek narzędzia, które w zasadzie może okodować, to w zasadzie robi to samo, tylko po prostu na czymś innym. Nie robi tego w jakimś frameworku, tylko oskeptowuje jakieś narzędzia. Natomiast od jednego do drugiego jest już bardzo blisko.

Pod kątem kultury — i to też łączy się z tym, co powiedziałem przed chwilą — no właśnie, jeżeli mamy programistów, którzy nagle zaczynają widzieć bezpieczeństwo jako kawałek ich własnej odpowiedzialności, jeżeli mamy testerów QA, którzy nagle zaczynają widzieć bezpieczeństwo jako coś, co „W zasadzie jakieś proste testy bezpieczeństwa mógłbym przeprowadzić”, no to ci ludzie w dłuższym procesie zaczynają się bardziej identyfikować z problemami bezpieczeństwa, czyli zaczynają nam dawać taką odpowiedzialność. To też idzie trochę w drugą stronę, mianowicie że bezpieczniacy obecnie zaczynają często do jakiejś roli w procesie wytwórczym i przechodzą niejako do specjalizacji, gdzie zajmują się bezpieczeństwem. I taka osoba naturalnie nawet inaczej będzie patrzyła na bezpieczeństwo, niż osoba, która tak jak było 15, 20 lat temu, która nigdy nie wytwarzała software’u, była typowym bezpiecznikiem. Weszła w IT, tym się zajmuje i tym ma zamiar się zajmować przez kolejnych naście lat. To wszystko więc się łączy i dzięki temu mamy po pierwsze DevOps, to samo tylko w odniesieniu do utrzymania oprogramowania i DevSecOps, czyli w budowaniu tego bezpieczeństwa w DevOps. Jeżeli je wbudowujemy no to musimy zacząć patrzeć bardziej jako na naszą odpowiedzialność i oczywiście musimy automatyzować.

Widzę tak DevSecOps, oczywiście ten mój pogląd cały czas się rozrasta, to znaczy aktywnie czytam, aktywnie poznaję historię, aktywnie uczestniczę też w dyskusjach, więc to nie jest tak, że mój pogląd na tę sprawę jest jedyny słuszny i nie ma żadnego innego, a ja mam to zapisane w kamieniu. To się może zmienić. Obecnie moje zrozumienie tego procesu jest właśnie na tym poziomie.

Niezależnie od tego, jaką odmianę DevOps czy jakie rozszerzenie sobie nie weźmiemy, to można powiedzieć, że istotna jest ta komunikacja. Gdy tak sobie spoglądasz, wcześniej też miałeś okazję uczestniczyć w procesie wytwarzania oprogramowania, gdy spoglądasz jak inni to robią, to czy widzisz, że są jakieś braki w komunikacji, jeśli chodzi o bezpieczeństwo? Albo które role powinny się ściślej komunikować, jeśli chodzi o bezpieczeństwo, a nie robią tego na odpowiednio wysokim poziomie?

W zasadzie to pytanie jest dość mocno połączone z tym poprzednim i pewne wątki, o których powiedziałem przed chwilą mogły być nawet tutaj po prostu wplecione, bez żadnego przetwarzania. Na pewno w bezpieczeństwie można teraz zauważyć złą komunikację lub nawet jej całkowity brak i ten brak może już trochę jest trudniej zauważalny, to znaczy występuje tylko w bardzo dużych podmiotach, które mają długą historię, czyli po prostu dość powoli wchodzą w digitalizację albo w dość małych podmiotach, które po prostu być może niekoniecznie wyciągają tak dużo wartości z całego bezpieczeństwa. Natomiast komunikacja najczęściej pozostawia wiele do życzenia i można byłoby coś pod tym kątem naprawić i w moim odczuciu jest to jeden z głównych problemów bezpieczeństwa. Czyli właśnie zła komunikacja z różnymi częściami organizacji, nie tylko z programistami, biznesem.

Jeżeli weźmiemy sobie taki klasyczny przykład bezpiecznika, no to taka osoba często przychodzi pod koniec procesu wytwórczego, ma jakieś własne podatności, które znalazła i wieszczy wszem i wobec koniec świata z powodu tych podatności, które znalazła. To brzmi bardziej jak taki bloker, bo to jest typowy bloker. I bezpieczeństwo właśnie tak jest widziane, jako typowy bloker dla wytwarzania a końcem końców dla biznesu liczy się tworzenie nowej wartości, robienie biznesu, zarabianie pieniędzy. Jeżeli przychodzi bezpiecznik i krzyczy, mówi, że tak nie można, bo to i tamto, to w pewnym momencie przestanie być zapraszany na spotkania. I nota bene, jeżeli ktoś przeczytał The Phoenix Project to pewnie się teraz uśmiechnie, bo to tak tam wyglądało. Świetna książka, polecam wszystkim. Jeżeli słuchacze jeszcze jej nie czytali, to polecam zrobić to jak najszybciej. Bardzo dobra książka!

Jeżeli weźmiemy sobie taki klasyczny przykład bezpiecznika, no to taka osoba często przychodzi pod koniec procesu wytwórczego, ma jakieś własne podatności, które znalazła i wieszczy wszem i wobec koniec świata z powodu tych podatności, które znalazła. To brzmi bardziej jak taki bloker, bo to jest typowy bloker. I bezpieczeństwo właśnie tak jest widziane, jako typowy bloker dla wytwarzania a końcem końców dla biznesu liczy się tworzenie nowej wartości, robienie biznesu, zarabianie pieniędzy.

Natomiast takie podejście typowego blokera zamyka drzwi do dalszej dyskusji. Wyklucza bezpieczeństwo z aktywnego udziału w procesie wytwórczym. Opowiem, czemu tak się dzieje. Myślę, że każdy z własnego doświadczenia ma lepszą lub gorszą ocenę tej sytuacji, natomiast w zasadzie to nikt nie lubi wykonać jakiejś pracy, tak jak programiści często mają podczas sprintów czy większych releasów, a potem usłyszeć od tej drugiej strony, którą jest bezpieczeństwo, że coś jest do kitu, tak to kolokwialnie ujmijmy. Jeżeli będziemy tak cały czas słyszeć, to prędzej czy później przestaniemy relację koleżeńską i będziemy minimalizować kontakt z taką jednostką w organizacji. To jest typowy problem komunikacji.

Sam widziałbym taki optymalny proces wytwórczy, gdzie bezpieczeństwo jest częścią wytwórstwa i to się powoli dzieje na zachodzie, natomiast powoli, a u nas raczkuje. W idealnym procesie wytwórczym, w momencie, kiedy bezpieczeństwo jest częścią, to zarówno programiści, jak i testerzy powinni mieć stały kontakt z bezpiecznikami i oczywiście na odwrót — bezpieczniki też powinny mieć stały kontakt z ludźmi w procesie wytwórczym, tak by wszyscy czuli się częścią większej całości, która ma wspólny cel.

Jeżeli mamy organizację, to my mamy jakiś cel. I celem nie jest znalezienie podatności, nie jest eksploitacja krytycznej podatności. Celem jest wypuszczenie produktu, który ma określony poziom jakości — tym bezpieczeństwa, bo bezpieczeństwo to jest odnoga jakości. To jest celem nadrzędnym organizacji, więc pomimo tego, że wewnątrz organizacji możemy być podzieleni na pewne grupy, bo nie da się zarządzać bardzo dużą grupą naraz, to naszym wspólnym celem — tych wszystkich grup — jest rozwiązywanie pewnych problemów biznesowych, dostarczanie systemów IT, aplikacji, które pomagają w rozwiązywaniu tych problemów biznesowych i to jest nasz cel nadrzędny. I powinniśmy to robić na jak najlepszym poziomie jakości, żeby było jak najbardziej bezpieczne, ale nie — to jest jak ten cytat, coś musi być proste, ale nie za proste. I tak samo jest z bezpieczeństwem. Coś musi być bezpieczne, a nie musi być za bezpieczne. To znaczy — nic nigdy nie będzie idealnie bezpieczne.

Z tym powinniśmy się pogodzić i powinniśmy po prostu wybierać spójnie te rzeczy, które jesteśmy w stanie rozwiązać, które mają największy impakt i które faktycznie zapewnią nam jakiś poziom systemowy bezpieczeństwa.

I to jest według mnie taka wizja optymalnego procesu wytwórczego. To się już powoli dzieje, natomiast jeszcze tam nie jesteśmy. Na marginesie chciałbym dodać, że podobne problemy mieli Site Reliability Engineers, SRE. Oni mieli podobne problemy. W momencie, kiedy ta rola powstała, chyba jeszcze 15 lat temu, w Google — mieli podobne problemy, ponieważ reliability jest bardzo zbliżone do bezpieczeństwa, security. Oni te problemy rozwiązali — na przykład komunikacyjne z zespołami wytwórczymi, z biznesem. My, jako działka bezpieczeństwa moglibyśmy uczyć się na ich błędach, na ich rozwiązaniach jak oni sobie poradzili z tym, żeby reliability, czyli pewna właściwość wytwarzanych systemów nie była widziana tylko jako koszt, tylko jako coś, co daje faktyczny zysk biznesowi. Przez co biznes oczywiście wtedy dużo poważniej podchodzi do tego, co mówimy. Bo jeżeli tylko krzyczymy, że świat się zapali, świat się potem nie pali, to nikt nie słucha kogoś, kto krzyczy o wilkach, a jak te wilki faktycznie przyjdą, to będzie problem, bo nikt takiej osoby nie będzie brał na poważnie.

👉 Czytaj dalej na:

kkempin’s dev blog

Dev and life blog.

Krzysztof Kempiński

Written by

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Krzysztof Kempiński

Written by

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface.

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox.

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store