CTO Morning Coffee

Dzień dobry wszystkim.

Cześć, cześć, dzień dobry, mam nadzieję, że się słyszymy.

Słyszymy się.

Dzień dobry.

O, Wajtek na kawie faktycznie.

Dobrze, w międzyczasie jak wszyscy dołączają, to może tradycyjne przypomnienie i tradycyjna formułka, która mogłaby pójść na ekranie.

Ale nie słyszeliśmy się przez trzy tygodnie, więc może warto ją rzeczywiście powtórzyć.

Słuchajcie, to jest City of Morning Coffee, nasze co teoretycznie dwutygodniowe programy, w ramach których spotykamy się i rozmawiamy o tematach, które są istotne dla tak zwanych STL, Senior Technical Leaders, czyli CTO i nie tylko, aktualnych i aspirujących.

Podczas tych godzinnych sesji rozmawiamy sobie w sposób zupełnie otwarty.

Każdy może zabrać głos.

Także zachęcamy do używania funkcjonalności Twittera.

Podnieś łapkę.

I wtedy takiego głosu udzielamy.

W ramach takiego odcinka zawsze rozmawiamy o jakimś jednym konkretnym temacie.

Staramy się od tego nie odbiegać.

W ramach takiego odcinka również staramy się przestrzegać jakichś zdroworzsądkowych zasad.

Czyli, wiadomo, dyskusja cywilizowana, nie robimy jakichś osobistych wycieczek, nie krytykujemy osób, nie krytykujemy firm, krytykujemy postawy i zachowania, nie skupiając się na jakichś osobistych gierkach.

Zachowujemy po prostu profesjonalizm jednym słowem.

Jeżeli podobały mi się wam te spotkania, to możecie na cityofmorning.coffee zapisać się na powiadomienia kolejnych.

Zachęcam do śledzenia nas na social mediach, czyli konkretnie na Twitterze i na LinkedInie.

Tam cityofmorning.coffee ma swoje konta i tam też będą się pojawiać nowe informacje.

Również na naszym webpejdżu jest link do archiwum odcinku, gdzie możecie sobie posłuchać stare odcinki w postaci podcastu.

Jeszcze jedno ważne przypomnienie.

Wspomniałem o tym, żeby podnosić łapki, żeby zabierać głos.

My czasami możemy tego nie zauważyć, więc nie zmięcajcie się, podnoście się dalej, bo w ferworze dyskusji może nam po prostu to umknąć.

I myślę, że chyba z najważniejszych tematów powiedziałem na chwilę obecną wszystko.

Zastanawiam się, czy może napisane, czy leci z głowy, ale postaram się to następnym razem może popierw się spróbować nagrać.

Dzisiaj mamy gości.

Jest z nami Kuba i Andrzej, ponieważ my możemy pytać o bezpieczeństwo, a chłopaki coś wiedzą.

Kuba, może powiedz dzień dobry.

Kuba, ty jesteś w tej chwili, bo ty jesteś w firmie produktowej?

Cześć, tak.

Ja prowadzę zespół Product Security w dużej firmie produktowej.

Nie nazywając firm, ale duża i śnieżna.

Andrzej, jesteś z nami?

Jestem, jestem.

Dzień dobry.

Ja z kolei buduję swój własny, mały biznes skupiający się głównie na edukacji i szkoleniach, i konsultingu.

Natomiast z doświadczenia pracowałem w całości procesu wytwórczego i jako programista, i jako bezpiecznik.

Ja chłopaków obu znam, więc tylko powiem, że oczywiście są skromni, nie mają czasu, ale każdy z nich ma tam za pasem trochę lat i różnych funkcji.

Z Andrzejem prywatą możecie posłuchać jakiejś rozmowy na moim podcastie w starym IT.

Polecam, bo jest ciekawa.

No dobrze, to zaczynamy z kopytka.

Panowie, przygotujcie się na listę pytań, bo mamy ją tutaj.

I oczywiście jak ktoś ze słuchających chce się włączyć, to jak najbardziej możecie zarówno dodać rzeczy, jak i zapytać się.

Dobrze, tematem jest dzisiaj bezpieczeństwo, ale kontekst to nasz, to Senior Technical Leadership.

Andrzej, Kuba, co Senior Technical Leader powinien wiedzieć o bezpieczeństwie?

Wszystko.

U nas jest taki koncept w branży, który się nazywa Security Champions.

I to jest jeden ze sposobów na przesunięcie security trochę bardziej w lewo, w lewo na całym pipeline'ie, całej drodze z DLC, czyli procesu utwórczego oprogramowania.

I bardzo dużo Senior Technical Leaders w engineeringu wcześniej albo pracowało blisko, albo sami byli Security Champions.

To dlatego, że Security Champions w zespołach to są te osoby, które odpowiadają za bezpieczeństwo danego zespołu, współpracują z zespołami security i tak dalej.

Więc bardzo często z takiej funkcji technicznego lidera później ta osoba przechodzi na Senior Technical Leader.

To jest jedna sprawa.

A druga, którą chciałem dodać, to taki frazes, ale bezpieczeństwo to nie jest jakaś osobna charakterystyka software'u.

Bezpieczeństwo to jest quality.

W związku z tym jeżeli Technical Leader dba o quality swojego software'u, to również dba o bezpieczeństwo.

I ja tutaj dodam dokładnie to, co Jakub powiedział.

Bezpieczeństwo jest tylko jakąś składową i jest składową tutaj konkretnie jakości.

Każdy produkt, który ma dobrą jakość, będzie miał bezpieczeństwo na jakimś poziomie, bo nie jest to zero jedynkowe.

Nic nigdy nie będzie w 100% bezpieczne.

To jest gradient.

I na bezpieczeństwo należy patrzeć po prostu jako na składową jakości, tak jak jest patrzone przykładowo Site Reliability Engineering.

Oni w pewnym momencie zaczęli się marketować jako coś dodatkowego, niejaka dziedzina i wyszli na tym bardzo dobrze.

Więc ludzie też powinni tak tutaj nauczyć się tej lekcji.

No dobrze, to trochę, żeby nie było tak przytoczyliście bardzo fajny świat idealny, nie?

Ale szczególnie się do tego, co Andrzej powiedziałeś w tej chwili, że ludzie z Security powinni się marketować jako osobna dziedzina.

Dotąd to robiliśmy i to nie za bardzo do końca zadziałało, nie?

Czyli jednak bezpieczeństwo jest postrzegane jako osobna funkcja.

Niekoniecznie zintegrowane z technologicznym procesem i tak dalej.

Więc to teraz to, co powiedzieliście, ale praktycznie dla...

Ja bym wbił tutaj szpilkę, Tomek, i bym powiedział, że czasami jest widziane nawet jako koszt w niektórych organizacjach.

Taki, wiecie, czysty koszt, który trzeba ponieść, żeby coś wytworzyć.

Ja się tutaj zgadzam i może nieodpowiednio to wiarziłem.

Chodzi mi o to, że właśnie bezpieczeństwo, bezpiecznicy powinni i ja widzę, że są te zmiany.

To się łączy z tym, że często gęsto teraz już ludzie, którzy przechodzą przez ścieżkę Security Champion, a potem skakują do bezpieczeństwa, więc oni mają pewien background taki z procesu wytwórczego, więc trochę inaczej patrzą na to.

Natomiast bezpieczeństwo powinno się marketować właśnie tak jak SRE, czyli jako pewna dostawka, żeby nie było widziane jako koszt, tylko jako część większej całości.

Robimy to po to, żeby końcem końców potem mieć obniżony koszt wytwarzania nowych funkcjonalności i żebyśmy nie musieli myśleć o pewnych aspektach bezpieczeństwa, bo one się po prostu dzieją, a nie są taką dostawką, bo dopóki będzie widziana jako dostawka, jako taki dodatek, no to zawsze wtedy będzie widziane jako dodatkowy koszt, a nie coś, co nas przyśpiesza, przyśpiesza działanie.

Co i jak jest widziane w zespół bezpieczeństwa bardzo często zależy od struktury organizacyjnej i jeżeli zespół bezpieczeństwa jest osobno zawiązany gdzieś przy organizacji CIO, przy organizacji IT, jest osobną organizacją security, to wiadomo, to będzie postrzegane jako koszt, bo samo IT jest kosztem, ale w wielu organizacjach, zwłaszcza dojrzałych albo inaczej, w nowych organizacjach, zespoły security albo część zespołów security jest zawiązana w grupie engineering.

No i to jest niesamowicie skuteczny argument za tym, że jednak security jest częścią tej inżynierii i wtedy nie jest bezpośrednio postrzegany jako koszt.

Natomiast jeszcze takie triki, których można użyć do tego, żeby bardziej związać się z deweloperami i współpracować blisko z inżynierkiem, to po prostu używać tych samych procesów.

I tutaj można to robić w wielu różnych aspektach.

W aspektach narzędzi, przykładowo, żeby nie były to osobne narzędzia, tylko żeby te narzędzia integrowały się z istniejącymi narzędziami, których używają deweloperzy.

No ale też procesy, tak?

Na przykład nie ma sensu, żeby uruchamiać osobny proces follow-upów do incydentu bezpieczeństwa, jeżeli grupa engineering już ma swój własny proces retro albo RCA, root cause analysis i tak dalej.

I integracja z tymi procesami, które ma inżynieryjny, to jest bardzo skuteczne rozwiązanie.

Aśmiej Korczy, żeby się spytać, w ilu firmach to widziałeś?

Ale może nie spytam się.

To jest bardzo dobre pytanie.

No dobrze, to Kuba, to w ilu firmach widziałeś to, co powiedziałeś przed chwilą?

Ok. Aśmiej Korczy, w ilu firmach?

Z tej innej krzyżowej.

Ok. Dobre, dobra odpowiedź.

Ok. Dobrze.

Czyli w skrócie w niewielu.

W niewielu.

No właśnie, bo tutaj dotknęłeś jednego takiego tematu, to może Andrzeja pociągnę trochę tutaj dalej.

No bo jeżeli mówimy o bezpieczeństwie, czy przy produkcji, czy w organizacji, to myślisz technologia, proces, czy funkcja?

Nie?

No bo ja się zwykłem z tym, że na przykład to jest postrzegane jako funkcję, nie?

I to jest chyba ten przypadek, o którym mówił Kuba, że dział jest osobno i się patrzy na nich jako taką funkcję, przez którą coś musi przejść.

Albo z drugiej strony patrzy się na to tylko na poziomie sieci i ten, to jak rozwiązać problem z tymi trzema elementami?

Czy to powinna być technologiczny proces, czy funkcja, czy wszystko razem?

Tutaj trudno powiedzieć.

Trudno jednoznacznie odpowiedzieć na to pytanie, dlatego że bezpieczeństwo jest szerokie i najpierw musielibyśmy sobie wprowadzić jasny podział.

To też odnosi się do tego, o czym Jakub przed chwilą powiedział.

Czym innym jest AppSec, czy ProdSec, czyli Application Security i Product Security, a czym innym jest CorpSec, czy NetSec, czyli Corporate Security i Network Security.

Jedno i drugie to Security, ale będą pełniły trochę inne będą pełniły inne role dla organizacji i co innego mają za zadanie robić.

Więc o ile przykładowo CorpSec i NetSec, można powiedzieć, że jest to pewnego rodzaju funkcja i dalej być może oni nie do końca pasują jako część inżynieringu, no to już AppSec, czy ProdSec to jest część inżynierii, więc może niekoniecznie funkcja.

Pomimo tego, i właśnie dlatego się to wszystko miesza, bo po prostu wszystko jest skracane do Security no i tak klasycznie wszystko było osobnym jakimś pionem, więc raczej było funkcją i było skupienie na technologii.

Ale czy ProdSec i AppSec tym czym ja się zajmuję no i też tym czym się Jakub zajmuje, no nie sądzę, że tutaj da się to albo grać samą funkcją, że po prostu mamy jakąś przelotkę, że trzeba teraz pójść do bezpieczników, czy samą jakąś technologią.

Są to ewidentnie zestawy różnych procesów, które muszą się wydarzyć lepiej lub gorzej.

Ja to nazywam praktykami.

Mamy Wojtka, który dołączył do nas, który też według mnie ma coś do powiedzenia.

Wojtek, jak chcesz się włączyć, to wiesz, odmotywujesz się i zaczynasz mówić.

To spróbuję.

Ja tylko chciałem wrócić troszeczkę do tych tematów kosztów, bo jakby dla mnie to, że security jest postrzegane jako kosz, jest czymś normalnym, od czego raczej nie uda się ucieknąć raczej.

Ważne jest, żebyśmy w organizacji pokazywali, co ten kosz daje, co ten kosz umożliwia, przed czym chroni.

Więc wydaje mi się, że to jest najistotniejsze.

Ja myślę, że Wojtku, że tutaj dotknąłeś bardzo fajnej rzeczy.

Ja mogę powiedzieć, jak to wygląda w firmie, w której teraz pracujesz, że faktycznie ta edukacja i edukacja przede wszystkim inżynierów jest bardzo mocna i taka bardzo, tak jak Kuba też wspominałeś, bardzo jest częścią procesu, więc tu naturalnie gdzieś cały czas te aspekty się pokazują, więc tutaj praktycznie podpisuje się pod tymi zdaniami.

No dobrze.

No tak mówimy o tym, że to jest część procesu, kosztów i tak dalej.

Teraz mamy organizację i w organizacji są różne role i wiadomo, że role gdzieś się tam ze sobą albo współpracują, albo ścierają, tak?

Albo każdy ma swój zakres odpowiedzialności.

No i jeżeli patrzymy na organizację i mamy takich ludzi jak CTO właśnie, albo VP of Engineering, albo takiego Wojtka w firmie, w której pracuję.

No i mamy też role CISO.

To czym ta rola jest według Was i jak ona ma relację do tych innych ról inżynierskich właśnie, bo Kuba powiedziałeś, że to powinna być część inżynierii, ale jednak jest to osobna działka często, przynajmniej w tych organizacjach, w których ja się spotykam.

Ja może tak krótko skomentuję.

Obojście rania się tych dwóch organizacji.

Zawsze jest jakieś napięcie, natomiast chodzi o to, żeby to napięcie było zdrowe.

Jeżeli któraś z tych stron ma istotnie mocniejszą pozycję w organizacji, no to jest źle.

Jeżeli akceptują wszystkie wymagania security jak leci, to po prostu będą na tym spędzali zbyt dużo czasu.

No i z drugą strony, jeżeli inżyniery ma całkowitą władzę nad tym, nad dostarczaniem jak największej liczby feature'ów bez żadnych wymagań bez czynności, to też jest źle.

Takie zdrowe tension jest jak najbardziej na miejscu.

Jak to powiedział jeden konsultant, z którym pracowałem, jego rola to jest create competitive tension.

A Andrzej, z Twojego punktu widzenia, jeżeli masz jako, jak pracujesz z organizacjami, no to jeżeli masz CISO, CTO, VP, to adresujesz tylko tego jednego, czy rozmawiasz z wszystkimi?

Wiesz co, z mojej perspektywy, znowu przypomnę, ja się głównie zajmuję APSECiem i PROCECiem, to bliżej mi do i raczej preferuję rozmawianie z CTO, bo końcem końców uważam, że ta rola jest lepsza w wytwarzaniu oprogramowania.

Dla mnie CISO tutaj nie gra pierwszych skrzypiec, bo rola CISO w organizacji jest obrona organizacji, czyli bardziej wracając właśnie do tego corporate security i network security.

APSEC jest tylko pewnym małym wycinkiem, który zajmuje głowę CISO, nawet w firmie produktowej.

Przynajmniej to widzę i nie spotkałem się na razie jeszcze z jakimiś exceptionami od tej reguły.

Być może są i być może właśnie są to firmy z Silicon Valley, ale pracując na naszym rynku raczej CISO zajmuje się tym swoim pionem, dlatego ja preferuję i wydaje mi się, że bliżej mi do rozmawiania, lepiej się rozumiemy z CTO, czyli ludźmi z tech.

Dobrze.

Dołączajcie się, jak macie swoje przemyślenia.

Andrzej Wszedłeś trochę w to, co ja mam przygotowane do swojej liście, bo taką listę gdzieś sobie przygotowałem, oczywiście tematów, no bo teraz bardziej na naszym podwórku to są moje doświadczenia albo obserwacje.

Rola CISO w szczególności jest postrzegana trochę jako taki hamulcowy.

I teraz pytanie, czy ta funkcja w organizacji powinna być pociągowym, czy hamulcowym?

Czyli czy raczej powinna być...

No właśnie, jak się ustawiać, tak?

No bo mój punkt widzenia jest taki, że ja się spotykałem, że w większości to jest traktowane jednak jako blokad do zrobienia czegoś.

Kto się ustawi jako blokad w organizacji ten przegrywa, także to pytanie, odpowiedź raczej niemożliwa.

To ja może zadam to pytanie chłopaki inaczej, tak?

Czyli jak właśnie edukować senior engineering leadership z pierwszego punktu widzenia, tak żeby nie był to blokad?

Ja odmawiam.

Ja powiem tak, myślę, że jest wiele sytuacji, w których zespoły security mogą się wykazać tym, że wcale nie są hamulcowymi.

To są sytuacje, kiedy są nowi klienci z pewnych branż, w których security ma ważniejsze znaczenie, przykładowo z branży bankowej albo z branży rządowej.

Wtedy zdobycie takiego nowego klienta bardzo często oznacza spełnienie pewnych wymagań bezpieczeństwa.

I wtedy ja traktuję taką sytuację jako enablement, a nie bloker.

Ja dodam uwagę, nie mam pełnej odpowiedzi, natomiast jedna uwaga od razu proszę do głowy, mówić językiem korzyści, czyli to, co Jakub przed chwilą wspomniał bardziej, że co nam to otworzy niż językiem niekorzyści.

Czyli po prostu straszenie, bo często gęsto sprowadza się to do straszenia, a wtedy po prostu odcinamy się od drugiej strony, bo druga strona już po prostu w ogóle nas nie słucha.

Znaczymy, że tu każda nowa podatność zrobi to i to i to i w ogóle to pójdziemy do piachu.

No to po pierwszym, drugim, trzecim razie, jeżeli się to nie wydarzy, to zaczynamy być po prostu ignorowani.

Więc rozmowa językiem korzyści.

Co nam to da, a nie co nam to zrobi.

Przykład.

Bezpieczeństwa, w którym wykazać od strony nie hamulcowej, tylko tej drugiej.

Wyszukiwanie podatności w bibliotekach.

Można robić to skanerami ręcznie i później zgłaszać podatności do zespołów inżynierskich, co trwa bardzo dużo czasu, identyfikować ownerów kodu, wyznaczać terminy na załatanie podatności i tak dalej, a można pójść trochę bardziej nowoczesną ścieżką, wpiąć się w te same procesy, których używa engineering, wpiąć się w pipeline na GitHub'ie albo w innym narzędziu i automatycznie wystawiać PR-y, które update'ują wersję danej biblioteki.

Wtedy na pewno będziemy bardziej postrzegani od strony tej, która pozwala na robienie więcej biznesu i przyspieszenie całego SDLC niż od strony hamulcowej.

Słuchajcie, a jak poznać, że tak naprawdę robimy wystarczająco dużo i nie za dużo, jeżeli chodzi o security?

Bo łatwiej jest być świętszym od papieża, to jest akurat taka specyficzna rola, gdzie czasami to, że security robi dobrą robotę, to po pierwsze jest w ogóle totalnie niezauwagalne, to jest jedna sytuacja, a czasami możemy mieć trochę szczęścia, ale nie tylko jest to związane ze szczęściem i security w cudzysłowie może nie być nam potrzebne, być może na przykład dlatego, że jesteśmy małą organizacją, jeszcze się nikt nam nie zainteresował, że mamy taką specyficzną branżę, że te informacje nie są na tle krytyczne i tak dalej.

Jakimi tutaj princypiami czy modelami się kierować tak, żeby robić just enough, nie za dużo i nie za mało?

Czy wy macie tu jakieś porady, sugestie?

Ja wcześniej widziałem, że Wojciech się odwrócił, chyba to po poprzedniego pytania.

Tak, to był rzeczywiście poprzedni wątek, gdzie to jeszcze tak dokończając, bo teraz spadło dosyć trudne pytanie, które dotyczy metryk w pewien sposób, natomiast wracając do poprzedniego jeszcze na chwilę wątku, ja bym trochę jednak straszył.

Znaczy, ja bym jednak starał się mówić o tym, jakie są zagrożenia, ja mam takie bardziej threat-driven approach, że staram się w organizacjach mówić, jakie są zagrożenia dotyczące samej organizacji lub organizacji o podobnym profilu, no i mówić, w jaki, co się stanie, jak ten atak wyjdzie.

Oczywiście tutaj jest taki ryzyko, gdzie też wspominaliście, co się stanie, jak mówimy o tym ileś razy, a tych ataków ciągle nie ma, no w którymś momencie może być rzeczywiście takie pytanie, czy potrzebujemy tych wszystkich kosztów.

Natomiast to trochę zależy od tego, jakie mamy relacje z resztą pewnie C-levelu i jak to przedstawiamy, jaka jest ta dojrzałość też tych osób.

Żebym miał wszystko mówić o tym, jakie są, no to jest nadal jakby takie security, które jest kosztem, natomiast pokazujemy, co dajemy w organizacji przez to, przed jakimi zagrożeniami ją chronimy.

Możliwe, że nie stworzymy dzięki temu nowego biznesu, ale chronimy aktualny.

Ja tutaj wtrącę krótkie pytanie.

Pokazujesz co, czy pokazujesz ile?

To znaczy, czy kwantyfikujesz to języko i próbujesz to przełożyć na język biznesu?

Staram się to przełożyć na język biznesu, inaczej oni znają to to inaczej z tym nie ma jak podchodzić.

Ja też wejdę w Waszą rozmowę z takim dodatkowym pytaniem.

Teraz wrócimy do wątku Sebastiana, ale tutaj Wojtek dotknąłeś ciekawej rzeczy, bo ja jako konsultant gdzieś tam, powiedzmy, czasami zahaczający od security, to na przykład ja bardzo często dostaję takie pytania od ludzi zajmujących się tym jak ja mam pokazać, że to co robię to w ogóle coś robi?

No bo to jest paradoks ubezpieczenia, akurat nawet wczoraj o tym gdzieś pisałem, że tak długo jak robicie swoją robotę, to nic się nie dzieje.

To nie jest tak, że totalnie nic nie widać.

I tutaj chyba płynnie przechodzimy do pytania Sebastiana.

Metryki, dashboardy i jakiekolwiek frameworky, które pomagają ocenić, czy robimy wystarczająco dużo, bo są branżowe frameworki, są CIS, jest OWASPowy SAM, czyli Software Assurance Maturity Model i kilka różnych frameworków, które też można budować sobie samemu i tymi frameworkami oceniać ile robimy w porównaniu do innych organizacji, są dane na temat różnych branż, na temat różnych wielkości firm, sektorów i tak dalej.

Czy robimy tyle, co oni, czy robimy mniej, czy więcej.

Można to robić w bardziej zautomatyzowany sposób.

To jednocześnie też pokazuje pewne liczby.

Przykładowo czas załatania krytycznej podatności.

To już można wtedy porozmawiać na temat konkretów.

Na przykład załóżmy, że przez lata nie było krytycznej podatności, takiej dużej, która by dotykała prawie każdego systemu.

Natomiast mamy dane w naszym frameworku, że średni czas załatania podatności to jest załóżmy w niektórych organizacjach nawet rok, trzy lata.

No i wtedy przychodzi na tapetę taki prezent w postaci na przykład lock for shell, czyli podatności w popularnej bibliotece lock for jail, w której jest jasny impakt i jest łatwo eksploatowana podatność.

Wtedy możemy pokazać wprost z tego frameworku, nam średnio zajmuje załatanie podatności rok.

Gdy wyjdzie kolejny shell, mamy problem.

Krótko mówiąc, czas, no to jest nasz metryk, tak?

A Andrzej i Wojtek, ja wiem, że wy mieliście w jednej z organizacji proces jakoś tam ustawiony, no bo to jest tak jakby mocno organizacja, znaczy mocna metryka nastawiona na rzeczy typu podatności i tak dalej.

A jak pokazać to, że robimy to na przykład w trakcie, czyli jeżeli tak jakby, bo Andrzej chyba wcześniej mówił, że to musi być część procesu, Kuba ty też, to jak na przykład podejść do tego, że wiemy, że robimy to, co trzeba, ale w trakcie wytwarzania?

To już konkretnie zależy od praktyki, o jakiej mówimy, przykładowo to się będzie trochę różnić dla fast czy dla dust, czy dla innych, więc zależne od praktyki.

Natomiast tutaj tak jak Kuba powiedział, są ewidentnie są różne dane, które możemy sobie wyciągać z tych praktyk i pokazywać je, że one się dzieją.

Natomiast takim szerszym pytaniem jest, czy faktycznie same liczby nam powiedzą, że ma to wpływ.

Przykładowo ostatnio się widzieliśmy z Kubą na Confidence i mieliśmy krótką przecinkę o modelowaniu zagrożeń, chyba nawet Wojtek też był w tej przecince.

I jak pokazać, że modelowanie zagrożeń jako proces faktycznie wpływa na zmniejszoną ilość podatności, które lądują w gotowym produkcie.

No bo możemy mierzyć same sesje, że one się odbywają i przyrastają na modele zagrożeń i wszystko jest ok, ale jak jasno pokazać, że ma to przełożenie potem na końcową zmniejszoną liczbę podatności, albo generalnie, że coś nam to w procesie usprawnia i na koniec dnia mamy mniejszy koszt.

To są trudniejsze pytania.

Ja jeszcze na nie nie mam takiej dokładnej odpowiedzi.

Też te procesy mierzę, ale jeszcze nie mam takiego jasnego połączenia do kosztów.

Natomiast, żeby tutaj nie zostawiać takiej otwartej pętli, to dodam, że dużo łatwiej jest używać wartość, znowu mówiąc o bezpieczeństwie, jako części takiego szerszego procesu wytwarzania, oprogramowania i procesu, który jest wypadkową jakości.

Czyli nie sprzedawanie samego bezpieczeństwa, że tyle, tyle i mamy podatności i je łatamy, tylko patrzeć też na nie jako po prostu zwykłe bugi.

I...

Bo każda podatność to jest też zwykły po prostu bug i tak można też pokazywać, że po prostu szybkość, szybciej szybciej naprawiamy różnego rodzaju błędy.

No, ale temat metryk generalnie jest dość ciężki, tak jak Wojtek zauważył.

Nie jest łatwe, żeby pokazać wartość dodaną bezpieczeństwa.

To tutaj trochę wejdę z takim pytaniem pomocniczym przy tematem, bo pytanie Sebastiana trochę było takie, skąd wiemy, że robimy enough, tak?

I nie wkładamy za dużo.

Trochę skręciliśmy od razu w stronę metryk, bo wy wiecie, co mierzycie i tak dalej.

No ale popatrzmy z punktu widzenia takiej organizacji, wiesz, która się rozwija i...

To był na przykład mały startup.

Tajemnicą PoliSzynala jest, że bezpieczeństwo się odwracaje na końcu, nie?

I teraz ktoś musi zdecydować, że w ogóle zaczynamy w to inwestować.

Przeważnie na początku tego nie robimy, nie?

To jak z Waszego punktu widzenia...

Jak podejść do stwierdzenia, jaka inwestycja na początku jest wystarczająca?

Na przykład, nie?

Czyli jestem w city of startupie, dotąd robiliśmy, to nie robiliśmy i tak dalej.

No i teraz, okej, drapi się po głowie i myślę, coś muszę z tym zrobić.

To jaki poziom na początek jest dobry?

Ja przed momentem miałem powiedzieć, że czasy, w których przez rok, dwa lata zespół kilkudziesięciu programistów siedział nad softwarem i gdzieś na koniec być może robił testy bezpieczeństwa minęły, bo teraz widać dosyć szybko, czy dobrze zainwestowaliśmy w bezpieczeństwo, bo jeżeli jest deployment co dwa tygodnie, albo nawet części w niektórych firmach codziennie, wiele rady, to w sumie widać od razu, jeżeli pominęliśmy którąś z części procesu bezpieczeństwa, to być może dostajemy sygnały w postaci podatności, ale właśnie podałeś przykład, bo startup jest takim przykładem tutaj.

Jeszcze ja spotkałem się nawet z firmami bardziej zaawansowanymi, które wiesz, na przykład wchodząc w jakąś nową działkę, nie, no ktoś zadaje to pytanie i się orientują, okej, nie robimy nic, nie, i też nie wiedzą, ile powinni zrobić, żeby było dobrze.

Prawda jest taka, wiadomo, każdy bardziej związany z bezpieczeństwem, ktoś, kto kocha tą dziedzinę, powie od razu, im wcześniej, tym lepiej.

Natomiast prawda jest taka, że w takim naturalnym cyklu startupów, startupy najpierw budują jakąkolwiek wartość, żeby pokazać tą wartość inwestorom, później, żeby zacząć sprzedawać tą usługę, czy produkt do pierwszych klientów, być może muszą zacząć spełniać pewne podstawowe normy, jakieś tam ISO i tak dalej, i zazwyczaj wtedy zawiązuje się pierwsza funkcja bezpieczeństwa i to jest właśnie CorpSec, NetSec, czy Global Security, o którym mówił Andrzej.

I to jest zazwyczaj moment, w którym zatrudnia się kogoś, kto docelowo będzie CISO.

Natomiast problemy upsecowe, czy product security zazwyczaj rozwiązuje się dopiero później, natomiast najczęściej w takim startupie pojawiają się osoby, które rozumieją, które były już w branży wystarczająco dużo i rozumieją to, że bezpieczeństwo to jest tak naprawdę quality.

No i w quality trzeba, znaczy trzeba, można już inwestować od samego początku i zazwyczaj jeżeli, tutaj nie mówiąc dużo o bezpieczeństwie, tylko mówiąc o quality, jeżeli w quality zainwestuje się od samego początku, dobry design, dobrą architekturę, bo wiadomo, architekturę jest najtrudniej później zmienić, później zmienić, no to wtedy też pojawiają się pierwsze inwestycje w bezpieczeństwo, w secure design rozwiązania, w dobry układ ról, uprawnienia i tak dalej.

Kuba, pociągnę cię trochę za język, ale Andrzej albo Wojtek, jak chcete, to wskoczcie, bo ty dotknąłeś fajnej rzeczy.

Możemy teraz zagrać roleplay taki, przy swoich rzeczach, o których się trzeba zmodelować, czasami takie robiłeś, ale bo powiedziałeś, że w zespole najważniejsza jest osoba, która gdzieś coś to robiła, dotknęła i tak dalej, nie?

I teraz jeżeli masz taki zespół albo wchodzisz w nawet większy zespół, widzisz, że nie jest robione cokolwiek, nie chcesz być tym doomsday, który przychodzi i mówi, słuchajcie, jutro niebo zapali się na głowę, to jak byś podszedł do tego, żeby wprowadzić ten temat na agendę?

Czyli masz zespół, który produkuje produkt, masz, wiesz, jakąś roadmapę i tak dalej, orientujesz się, że jakieś rzeczy są niezadresowane, no i teraz musisz przekonać ten zespół albo wziąć on board, żeby jednak wprowadzić na agendę przynajmniej jakieś minimalne wymagania, to jak byś do tego podszedł?

Wcześniej od Andrzeja padło hasło modelowania zagrożeń i ja traktuję tę sesję modelowania zagrożeń jako też pewną formę edukacji.

Modelowanie zagrożeń to jest taka sesja z zespołem, z różnymi osobami, z architektami, być może ludźmi biznesu na temat tego, co może pójść nie tak w danym rozwiązaniu albo w danym biznesie i to bardzo często uświadamia ludziom problemy, o których wcześniej nie mieli żadnego pojęcia.

Co jeśli dany użytkownik przyjdzie i zacznie robić różne dziwne akcje w naszym systemie?

Co jeśli przykładowo ten serwer, który miałby gdzieś ukryty z OETM-em, nagle się okaże, że on jest w internecie?

Na taką sesję bardzo łatwo jest przekonać ludzi, żeby dołączyli.

Oni bardzo często wtedy uświadamiają sobie pewne ryzyka.

Później to jest taki trochę ping-pong polegający na tym, że trzeba im uświadomić, że te ryzyka rzeczywiście są realne.

Trzeba wykonać jakąś pracę techniczną i dowieść przynajmniej jeden atak, który realizuje dany zagrożeń.

Wtedy układ sił mocno się zmienia.

Bo mamy już ludzi, którzy są zainteresowani tematem, mamy ludzi, którzy rozumieją te ryzyka, praktycznie sami je podali w tej sesji modelowania zagrożeń i mamy potwierdzenie w postaci tego, że te ryzyka rzeczywiście są rzeczywiste.

Ja bym na tego odpowiedział.

Ja jeszcze dodam do tego, co Jakub powiedział, co myślę, że spora część słuchaczy się domyśliła.

W takim wypadku tą osobą, która wprowadza to bezpieczeństwo do zespołu czy do organizacji, raczej powinna być osoba, która ma, może niekoniecznie talent, ale chociażby jakieś predyspozycje.

Posiada umiejętności miękkie.

Potrafi rozmawiać i potrafi rozmawiać.

Bo to jest po prostu ważne, żeby rozpocząć i potem umieć kontynuować ten dialog, szczególnie jeżeli chcemy przekonać tą drugą stronę.

Często, gęsto bezpiecznicy mają z tym problem i wydaje mi się, że raczej to wynika z takiej własnej jakiejś decyzji, że nie chce rozmawiać i ja wiem lepiej, niż z nieumiejętności.

Po prostu nie chcą rozwijać tych umiejętności miękkich.

A one są ważne, żeby przekonać zespół, szczególnie właśnie techniczny, zespół czy organizację do jakiejś wizji.

To ja mam dwa punkty, zanim pójdę dalej.

Jeden to jest pytanie, kto z Was słyszał o modelowaniu zagrożeń z threat modeling?

Możecie zrobić łapkę, tam taką reakcję.

Zobaczymy, ile osób się z tym spotkało.

A druga rzecz, to będzie kryptoreklama.

Kuba ma bardzo fajne nagrania na temat threat modeling, pokazujące, że threat modeling może być też fun.

Jak będziecie mieli okazję, nie wiem, czy Kuba dalej to robisz, ale takie sesje live, rzucania zagrożeń i modelowania tego, to polecam.

Ja tutaj mogę też dodać z drugiej strony, czyli na przykład senior engineer w DeSzyku, bo z Kubą się też poznaliśmy w takich okolicznościach, gdzie ja mogę zdradzić ze swojej perspektywy, też potrzebowałem zwiększyć świadomość bezpieczeństwa w firmie, w której pracowałem.

I coś, co bardzo fajnie się sprawdziło, to było tak naprawdę zrobienie tak praktycznie już rzecz biorąc, pełnych ten testów aplikacji na produkcji i z takim fajnym raportem, jak poszedłem do zarządu, no to dyskusja na temat bezpieczeństwa była dużo, dużo prostsza, tak mogę zdradzić, więc polecam też takie podejście, więc można się wspomóc wiedzą ekspertów i później dzięki temu też mieć dużo prostszą dyskusję, jeżeli chodzi o pewne aspekty, bo to było wyciekane na ławie, szczególnie w momencie, kiedy GDPR wchodził wtedy i wycieki danych były takim przerażającym aspektem na horyzoncie, więc taką praktykę mogę polecić serdecznie.

Widzisz, i tutaj wróciłeś trochę do tematu, bo mamy dwa podejście tak trochę, nie, Kuba to, co powiedział i jak ja widziałem, jak on to robi, na przykład to wiesz, tutaj możesz street modeling zrobić pan i zaangażować zespół, to, co powiedziałeś, to jest trochę to, o co Wojtek mówił wcześniej, postraszmy zarząd, że coś się stanie, nie?

To nawet nie było straszenie, tylko to było takie pokazanie faktów bardzo, bardzo dobitnie, gdzie jesteśmy i jakie to stwarza ryzyko, więc w sumie dobra.

Ale jako, że dotknąłeś...

Mogło być straszenie.

Ale to nie jest straszenie, Wojtek tutaj poruszył ważną kwestię, dlatego, że wcześniej też rozmawialiśmy o tym, jak rozpoczynać takie security w organizacjach, szczególnie w mniejszych startupach.

Często, gęsto to jest jeden z tych pierwszych kroków, czyli wykonanie takiego pentestu produktu czy jakiegoś, jakiejś aplikacji mniejszej, zależy od organizacji wielkości i pokazanie dobitnie tym osobom na C-level, że mamy problemy, mamy problemy i faktycznie powinniśmy w to zainwestować i to może już zrobić sam CTO, no bo takie pentesty może po prostu zlecić i to może rozpocząć taką konwersację na temat właśnie tego, co powinniśmy zrobić w temacie security.

No i właśnie, tutaj zarówno Wojtek, jak i Ty dotknęliście takiego tematu, który nazywa się pentest i nie będziemy rozmawiać o pentestach, ale z mojego punktu widzenia i takich doświadczeń, które ja widziałem, to on się...

To jest często punkt startowy, ktoś mówi zatrudnijmy firmę, żeby zrobiła nam pentesty, nie?

I teraz pytanie to w organizacji jak zatrudniać ludzi od security i czy to właśnie powinny być takie rzeczy jednorazowe typu zatrudnijmy ludzi do pentestu i potem skupmy się na załataniu tego, co znaleźli i to nam wystarczy na początek czy na przykład od ręki radzilibyście wciągnąć kogoś do organizacji, kto cały ten temat rozumie i zacznie ogarniać i na przykład będzie współpracował z takimi firmami typu pentesty.

Z mojej perspektywy to drugie podejście na pewno przyniesie więcej wartości, bo temat jest skomplikowany i nie jest łatwy z różnych powodów, natomiast raczej wygląda to w ten pierwszy sposób, więc ten drugi jest bardziej rozsądny i przyniesie więcej wartości, ale jest też trudniejszy do zrealizowania, czyli zatrudnienie kogoś, kto będzie takim buforem pomiędzy zewnętrznymi dostawcami usług pentestów.

Nie jest to łatwe, ale na pewno przynosi więcej wartości.

Wydaje mi się, że tak jak Andrzej mówi, że rzeczywiście ten punkt o podejściu drugim może dawać więcej wartości, ale też podejście pierwszy to podejście na przykład pentest jest dużo bardziej popularne i może być dużo łatwiejsze w ogóle rozpoczęcie takich rozmow na temat security.

Podejście drugie jest dużo bardziej dojrzałe, wymaga pewnie większej dojrzałości, większego czytania.

Zrobienie pentestu jest dużo łatwiejsze, więc czasem warto zacząć od łatwiejszych rzeczy w ramach baby steps i tyle.

Ja bym chciał zapytać, jak to się zmieniało na przestrzeni lat, bo 10-15 lat temu, zwłaszcza w Polsce fajnie to widać, bo w Polsce jest mało firm produktowych, jest więcej usług, jest dużo banków.

Tak naprawdę w Polsce banki to były pierwsze firmy, które zatrudniały na początku zewnętrznych pentesterów 10-15 lat temu.

Tak wyrosło dużo firm konserwningowych w Polsce.

Później jakieś 10 lat temu te firmy zaczęły zatrudniać swoich wewnętrznych pentesterów, no a teraz widzimy w dojrzałych firmach takie podejście, że pentesterów w całym zespole security jest niewiele.

I chyba też do tego dążymy, bo jak sobie popatrzymy na engineering, to funkcji walidujących jakość produktu, czyli QA, czyli testerzy i tak dalej, no jest kilka procent w całej organizacji.

Większość jest skupiona na designie i na implementacji, a walidacją tego, czy to działa, zajmuje się mniejsza liczba osób.

I do tego też, moim zdaniem, dąży branża security.

Więc jeżeli ktoś jest w stanie i jeszcze tutaj zgadzam się z moim zdaniem z Wojskiem, że drugie podejście zazwyczaj będzie long term bardziej opłacalne.

Więc jeżeli ktoś jest w stanie przyjść do organizacji, która nie ma ani pentesterów, ani zewnętrznych pentesterów, ani wewnętrznych ludzi od bezpieczeństwa, security inżynierów, jest w stanie przekonać organizację do tego, że żeby od razu pójść tą drogą long term, to jest dobrym bezpiecznikiem.

Mhm.

Wiesz co, i tutaj mam taki problem według mnie trochę, że jak jesteśmy taką organizacją, która jeszcze tego nie ma, czyli jesteśmy albo małym startupem, albo według mnie to nie dotyczy tylko małych startupów, ale też takich średnich firm nawet, nawet produktowych, to mamy taki problem, o którym trochę Andrzej mówił na początku, że bezpieczeństwo nie jedno ma imię, no bo jak powiesz, że chcesz zatrudnić, ja w którymś momencie nawet u siebie w firmie powiedziałem, że przestajemy zatrudniać ludzi od cyber security, bo to może znaczyć wszystko.

Ale jak zaczniesz od człowieka od bezpieczeństwa, to znajdziesz ludzi od procesów, znajdziesz ludzi od szczegółowo-dobrych działek, znajdziesz pentesterów i tak dalej, i tak dalej.

No i pytanie jest do Was takie, jak określić, kogo potrzebujemy tak naprawdę, na jakie umiejętności patrzeć, a kogo nie potrzebujemy, i jak z Waszego punktu widzenia taka organizacja, czy jest CTO, czy osoba odpowiedzialna za inżynierik może podejść do zweryfikowania takiej osoby, czyli krótko mówiąc, jak zatrudnić kogoś związanego z bezpieczeństwem, jeżeli nie wiemy jeszcze, kogo zatrudniamy, albo na czym się skupić też wtedy na początku.

Z mojej strony, takimi dobrymi markerami jest spojrzenie po prostu na doświadczenie tej osoby, nie chodzi mi tutaj o ilość lat, chociaż to też ma znaczenie, natomiast pewną różnorodność rol i czy ona pasuje do tego, do tego, do czego potrzebujemy bezpiecznika w naszej organizacji, do naszego kontekstu.

Przykładowo, jeżeli chcemy zatrudnić kogoś, kto będzie nam kierował zespołem Product Security, no to fajnie byłoby mieć kogoś, kto miał jakieś doświadczenie z pisaniem kodu.

Nie jest to konieczne, ale jest to jakiś dodatkowy marker, który może ułatwić wybór odpowiedniej osoby.

Natomiast sama sprawa generalnie jest trudna, bo rozstrzał jest naprawdę, naprawdę duży i nie ma takiej checklisty, która spełniłaby tutaj swoją funkcję.

Przykładowo na pewno nie należałoby patrzeć, przez inwersję możemy tutaj pójść, nie należałoby patrzeć na przykład na takie markery, jak certyfikaty, bo ktoś może mieć dużo certyfikatów i po prostu być dobrym w zdobywaniu certyfikatów, a ktoś może nie mieć certyfikatów i być dobrym w ciągnięciu zespołu Product Security.

Więc niestety certyfikaty są tutaj raczej szumem, niż sygnałem.

Raczej trzeba patrzeć na jego doświadczenie i przy rozmowie, czy rozumie ten aspekt inżynierii.

Znowu, jeżeli mówimy o APSEC i PROCSEC, to czy rozumie ten proces sam IT, sam tech, sam po prostu proces budowania software'u, no to to na pewno jest wymagane.

Przykładowo powinna rozumieć proces SDLC.

Andrzej, tutaj kontynuując to, co mówisz, to moje pytanie jest takie na przykład okej, wiecie, mam zespół, załóżmy, 20, 40, 50 programistów i mam zapewne jakiegoś Cloud-opsa, Sys-opsa, DevOpsa z VW-Valve.

Tutaj oczywiście z szacunkiem do osób, tu chodzi mi bardziej o nazwę roli i pytanie moje do was jest takie, no na przykład nie mogę znaleźć albo nie stać mnie, żeby znaleźć, albo nie mam może potrzeby na taką osobę full-time ze stole, to moje pytanie do was jest takie, czy i jak upskillować, czyli w jakiś sposób edukować, trenować osoby, które są bliskie tej infrastruktury, szczególnie tej cloudowej na przykład i w takim razie jeżeli tak, to jak to robić?

To było bardzo odważne przeprowadzać wewnętrzną edukację i prowadzić tak naprawdę program, czegoś co brzmi jak Security Champions, bez żadnej osoby wewnętrznie, która zajmuje się bezpieczeństwem, natomiast jest opcji multum, można rozpocząć od zewnętrznych konsultantów, od szkoleń, można mieć, są takie laby, w których dla devopsów albo dla programistów są przygotowane pewne zadania związane z security, tam są takie elementy gamification, żeby cała ta edukacja też sprawiała wewnętrzny fun, natomiast chyba bym się obawiał robić to tak całkowicie bez długoterminowej wizji i strategii, którą powinna dostarczyć ta osoba odpowiedzialna za bezpieczeństwo w organizacji.

Andrzej, bo ja tutaj chętnie pociągnę ten wątek.

Wojtek, tak, to przyszły mi tylko, Andrzej, że ci tak wyjadę na słowo, przyszły mi dwie rzeczy do głowy.

Po pierwsze z moich doświadczeń wśród tych powiedzmy 40 deweloperów, może się okazać, że kilku mają jakąś taką zajawkę bezpieczeństwa i różne platformy, o których Kuba tutaj wspominał, typu jak The Box, TryHackMe, które możemy jakby dostarczyć, mogą pomóc w znalezieniu tych ludzi.

Wydaje mi się, że rozmowa z zespołem, jakie oni widzą zagrożenia, tak właśnie tutaj wcześniej wspomnianym w modelingu, też może pomóc znaleźć osoby, które mają odpowiedni mindset.

Natomiast tu trudno się nie zgodzić z Kubą, że może się okazać, że takich osób nie mamy albo mamy problem z, żeby pomóc im w rozwoju, więc tu bez zewnętrznej pomocy może być ciężka.

Ja trochę skontruję, bo wspomnieliście o pewnej analogii do QA swego czasu, a są bardzo duże organizacje, dosłownie tysiące inżynierów, gdzie nie ma QA, gdzie właśnie quality jest tematem wszystkich i tylko jest to w odpowiedni sposób zewnętrznie weryfikowane.

Mogę powiedzieć, że potwierdzam.

To czy analogicznie nie można byłoby zrobić organizacji, w których nie ma security, czyli security jest problemem wszystkich, natomiast to, o czym powiedział bodajże Kuba, czyli tam ogólnie strategia i ogólnie jakość, jest właśnie weryfikowane regularnymi audytami.

I audyty tworzą pewnego rodzaju pętlę feedbackową i mówią tak naprawdę tym ludziom, tym zespołom, czego im brakuje, czego się mają douczyć, na czym się mają skoncentrować.

Czy taki model według was ma szansę bytu?

Jest racjonalny?

I czy widzieliście taki model w praktyce?

Powiem tak.

Nie widziałem, ale to jest pewnego rodzaju ideał, do którego się dąży.

Tylko tutaj ja widzę ten problem, że dalej musiałoby być, i to trochę nawiązuje do tego, o co pytał Wojtek, dalej musiałaby być taka osoba, która tę wizję niejako najpierw wyznaczyła, a potem ją nałożyła na daną organizację.

Potem ta osoba albo rola, albo zespół może powiedzmy zniknąć i to będzie działać przez jakiś czas.

No i potem przechodzi to w ręce tych audytów, które werfikują, czy dalej jesteśmy w tych ramach, w których wcześniej sobie założyliśmy, ale dalej najpierw ktoś musiałby coś takiego rozpocząć, przy czym tutaj z mojej strony, ja bym dodał, że ja lubię mówić, że bezpieczeństwo jest częścią jakości, bo jest.

Natomiast przynajmniej jeszcze na chwilę obecną, jest trochę bardziej skomplikowane niż niż testowanie takie no po prostu jakości, czy aplikacja mi się gdzieś tam nie wywala.

Wymaga większej, większej jakiejś wiedzy domenowej na temat różnych praktyk i od strony operacyjnej osoby, która wykonuje jakieś pentesty, czy inne rodzaje testów bezpieczeństwa, wymaga trochę większej specjalizacji i większej wiedzy, czyli tak naprawdę więcej lat doświadczenia.

A więc idealnie stałoby się tak zrobić i fajnie, gdyby tak było i zakładam, że w dużych, naprawdę dużych organizacjach być może nawet tak jest, ale ja tego nie widziałem i no, ja jeszcze tego nie widziałem.

Ja powiem tak, nie można, nie jest wykonalne, żeby testować wszystko i audytować na koniec wszystko to, co tworzą deweloperzy, to po prostu będzie kosztowało za dużo.

Więc trzeba mieć jakiś mechanizm, który zdefiniuje, kiedy testujemy i co testujemy, tak.

Być może takim mechanizmem jest modelowanie zagrożeń, to jest coś, co my robimy w organizacji.

Modelowanie zagrożeń wskazuje najbardziej krytyczne elementy systemu i w tych punktach uruchamiamy pewien zestaw akcji, tak, jednym z nich na koniec być może jest pentest, czy audyt.

Natomiast, to co do tego, czy by to działało, my poniekąd do tego trochę dążymy, to znaczy jedną z naszych, my w ogóle z leadershipem i z inżynierami rozmawiamy takim językiem pewnych pryncypiów, principles, na temat tego, co w ogóle powinno się dziać w organizacji.

Jednym z takich principles jest to, że high quality code is secure code, czyli kod wysokiej jakości jest bezpieczny, tutaj wracamy do rozmowy, że bezpieczeństwo jest częścią quality, w związku z czym deweloperom też jednocześnie zależy, żeby, powinno zależeć, żeby kod był bezpieczny, bo to jest jakimś wyznacznikiem tego, że kod jest wysokiej jakości, plus to, że oni są ownerami tego ryzyka, tak, to jest jeden z drugich naszych principles, czyli engineers own security.

No i w takim zestawie, w takim układzie, jeżeli mamy jakiś proces, przykładowo modelowanie zagrożeń, który pokazuje kluczowe elementy systemu, pokazuje kluczowe ryzyka, można wtedy rzeczywiście punktowo odpalać pen test i weryfikować, czy idziemy w dobrą stronę i wtedy minimalnie korzystać z zespołu security.

I jeszcze tak szybko na koniec, żeby nie zajmować zbyt dużo czasu, program security champion, o którym wspominałem, czyli takiej funkcji bezpieczeństwa realizowanej przez jednego z inżynierów zespołu, docelowo, jeżeli tak się zastanowić, do czego to dąży, dąży to do tego, żeby tak naprawdę każdy inżynier był security championem w swoim zespole, więc poniekąd być może ta wizja jest zrealizowana.

To ja tutaj gładko wejdę jeszcze kontynuując ten wątek, słuchajcie, szczególnie dla mniejszych organizacji, załóżmy, że właśnie startuję, czy wystartowałem jakiś produkt, mam kilkadziesiąt osób w swojej firmie, jestem zapewne użytkownikiem Chmury, od których wędora, i moje pytanie do was jest takie, co warto, co byście polecili, żeby koniecznie skorzystać z produktów wędorów, a co na pewno warto zachować in-house, jeżeli chodzi o warstwę bezpieczeństwa?

Może zacznę, Wojtek, od ciebie.

Uch, dobre pytanie, wydaje mi się, znaczy, jeżeli jesteśmy w środowisku crowdowym, to jest po prostu już dosyć dużo produktów, które mają spojrzeć na całe crowd maturity i w ażurowej Chmurze aktualnie to jest, co chodzi o Microsoft Defender for Cloud, który ma pomóc w znalezieniu wszystkich mis configuration, które mamy i trochę nie wyobrażam sobie tego robić własnymi rękoma, więc natomiast od strony produktu, czy chcemy pisać własne skanery, wydaje mi się, że to też może być trudna droga, bazując na moich doświadczeniach, więc tu jest kilka produktów, które po prostu chyba lepiej kupić.

To może ja rozszerzę tutaj też to pytanie i Kuba i Andrzej też was poproszę o komentarz.

Też chodzi mi o role i funkcje w zespole, tak, które, więc produkty, role i funkcje, które warto zachować właśnie wewnątrz firmy, a które warto zaobserwować wtedy.

Kuba, może ciebie poproszę.

Moim zdaniem to bardzo zależy od etapu rozwoju danej organizacji i tutaj mam na myśli kontekst dojrzałości pod kątem bezpieczeństwa.

Ja to obserwuję w branży i wspomniałem o tych bankach, które 10-15 lat temu zaczęły zatrudniać zewnętrznych tentesterów, z 10 lat temu zaczęły zatrudniać swoje własne zespoły i teraz widzę gdzieś od 5 lat, że banki zaczynają inwestować w swoje wewnętrzne zespoły inżynierów bezpieczeństwa.

Na pewno najprościej na zewnątrz jest wyoutsourcować walidacje, czyli pentesty, audyty i tego typu rzeczy.

Co jest trudno wyoutsourcować?

Te funkcje, które wymagają ciągłego kontaktu z inżynierią.

Czyli zazwyczaj będzie to edukacja, modelowanie zagrożeń.

Tutaj jeszcze się cały czas bacham nad odpowiedzią.

Na pewno te funkcje, których trzeba bardzo często utrzymywać kontakt z deweloperami, konsultować rozwiązania, czyli security reviews i tak dalej, to warto otrzymać in-house.

Dobrze.

Czas nam się kończy.

My tu mamy gorącą debatę, o której kilkudziesięciu pytań mam jeszcze zadać, ale mamy pięć minut, więc krótką to teraz takie trochę inne.

Jak mówimy o technologii i o to ogólnie cały czas mamy coś nowego.

Czyli mamy nowe technologie, nowe wektory ataku, mamy nowe zależności, ktoś wymyśli coś nowego i tak dalej.

I teraz pytanie, czy w praktyce da się to ogarnąć, to wszystko co się dzieje, czy da się patrzeć na te wszystkie zmiany i dostosowywać cały czas firmę do tego, czy raczej trzeba się skupić na tym, żeby jakiś tam baseline zatrzymać?

Czyli czy przy tych wszystkich zmianach i szybkości jak to się rusza, to to jest realne, żeby nadążyć za tym, czy to jest wishful thinking?

Krótka opinia dla tych z Was.

Dobra, to krótka opinia.

Wiesz co, tak, wszystko się rusza bardzo szybko, natomiast to jest podobnie jak przy inżynierii, oprogramowaniu i ogólnie IT.

Wszystko rusza się bardzo szybko, natomiast fundamenty są niezmienne.

I tak samo jak pewne fundamenty powstały w latach 70-tych, 80-tych i do tej pory z nich korzystamy, pewne paradygmy, tak samo w bezpieczeństwie też są pewne paradygmy, które powstały lata temu i one dalej się przewijają.

I po prostu jeżeli zrobimy, jeżeli zadbamy o te fundamenty, to te nowe rzeczy, ryzyko z nimi związane jest mocno, mocno, mocno obniżone.

Więc tutaj wracamy do tego straszenia, że jeżeli chcemy postraszyć, to jednak i ja zakładam, że Wojtek tak raczej straszy w ten sposób, że nie jest to takie wishful thinking, tylko faktycznie jest to gdzieś przełożone na jakieś prawdopodobieństwo, na to, co może się faktycznie wydarzyć, no bo to jest w końcu ryzyko, jakieś prawdopodobieństwo, więc jeżeli mamy fundamenty i zadbamy o fundamenty, o fundamentalne pryncypia i zasady bezpieczeństwa, to te wszystkie nowe rzeczy i ryzyko z nimi związane jest po prostu mocno, mocno, mocno obniżone.

Trochę nie wiem, czy chciałbym zostać zapamiętany z tej rozmowy jako Wojtek, który straszy, tutaj bardziej nie mogę się pokazywać, jak wygląda taki landscape, natomiast te fundamenty, o których tutaj wspomniał Andrzej, wydaje mi się, że takie rzeczy jak jakiekolwiek MFA, backupy, jakiekolwiek patch management, są takimi rzeczami, które są dosyć uniwersalne i jak patrzymy na różne konkretne sposoby, które atakujący stosują, no to jakieś gro, choćby takimi prostszymi podejściami, fundamentami, jak to wspominał Andrzej, powstrzymane.

Więc wydaje mi się, że to jest dobre rozwiązanie.

No to jak krótko dodam, że jeżeli ktoś chce, jeżeli ktoś, celem danej osoby jest uzyskanie stuprocentowego bezpieczeństwa, zabezpieczenia się przed wszystkimi bieżącymi atakami i tak dalej, to jest skazane na porażkę, także udział w wyścigu trzeba brać proporcjonalnie do możliwości, do budżetu.

Być może jest to utrzymywanie tylko jakiegoś baseline'u, natomiast nie ma żadnej firmy, która jest w stuprocentach wytyczna.

Dobrze.

Czas się kończy, będziemy zabijać, ale mam jedno pytanie, które muszę zadać.

Możecie odpowiedzieć, znaczy 15 sekund na odpowiedź możemy ustalić.

Ludzie straszą generatyw AI, że zacznie hakować masowo banki, nie wiem, wymyślać exploity i tak dalej.

Generatyw AI, co o tym myślicie?

Dobra, to akurat ja się tutaj szybko ustosunkuję.

Ostatnio dwa albo trzy odcinki temu Szana w Pali Patetia, czy jak to się tam mówi, w podcastie All In, który zresztą polecam, mówił właśnie o tym, jak to chat GPT być może napisze exploity na nowszego 0day'a na indelce i zaczął jakąś taką tyradę, co według mnie i wielu innych bezpieczników pokazuje dogłębne niezrozumienie tematu.

Nie jest tak łatwo napisać exploity na 0day'a w Windowsie, czy w jakimkolwiek innym systemie operacyjnym, więc na chwilę obecną nam to nie grozi.

Trudno jest mi sobie wyobrazić sytuację, w której chat GPT pisze exploity na podatność, której nikt nie zna w Windowsie.

Jest to możliwe, jest to possible, ale probability tego jest, przynajmniej na chwilę obecną, ja oceniam na bardzo niskie, więc nie ma się przejmować.

Zabiję od strony bezpieczeństwa.

Ja mam może nieprzeciwne zdanie, natomiast widziałem na tyle dużo exploity, które są proste, nadal mamy w security 0day'e krytyczne, które polegają na dodaniu odpowiedniego fragmentu w headerze żądania, że LLM, który sobie przeczyta dokumentację i znajdzie w niej dziurę, to jest coś, co jest całkowicie realne, natomiast ja bym się zastanawiał nad czym innym, bo my musimy myśleć też nad przyszłością.

Jak użyć LLM'ów do tego, żeby robić bezpieczeństwo?

To jest superciekawy temat i myślę, że tutaj dużo Wydaje mi się, że to będzie wsparcie dla obu stron, zarówno dla atakujących, jak i broniących, na takiej zasadzie właśnie wsparcia.

Jeżeli atakujący ma do przejrzenia ilość systemów, to możliwe, że chat GPT podobne będzie ułatwiać mu znalezienie systemów, nad którymi warto się zastanowić.

Z drugiej strony, jako obrońca, ja widzę duży potencjał w takim elemencie, że jest jakiś incydent i jakiś AI dostarcza dodatkowe enrichment do tego incydentu.

Microsoft próbuje to po lekko zająć z security copilot.

No właśnie, więc wydaje mi się, że to jest fajne rozwiązanie, że z obu stron będę korzystał z tego rozwiązania.

Dobrze, panowie.

Dziękuję wam bardzo za udział, dziękuję wszystkim za wytłuchanie.

Tak jak mówię, lista była dłuższa, może kiedyś zrobimy dogrywkę nawet na jeden konkretny temat, który miałem tam gdzieś na liście.

A dzisiaj naprawdę bardzo dziękuję za to, że uczestniczyliście.

Ja ze swojej strony na koniec jeden komentarz.

Bezpieczeństwo i deweloperzy, jak ja to mówię, give a hug, nie?

Zacznijcie się przytulać i tam nie będzie lepiej.

Dzięki jeszcze raz i super było was gościć u nas.

Dziękujemy bardzo.

Dzięki bardzo za udział.

Dzięki, trzymajcie się.

Do usłyszenia.