W tym odcinku podcastu gościmy Macieja Markiewicza, Product Security Managera w Egnyte, który dzieli się swoim bogatym doświadczeniem w cyberbezpieczeństwie i bezpieczeństwie oprogramowania. Maciej opowiada o różnicach w podejściu do bezpieczeństwa między firmami typu software house a firmami produktowymi, podkreślając inną dynamikę planowania i wdrażania rozwiązań AppSec w obu modelach. Dowiemy się, dlaczego w firmach produktowych możliwe jest długofalowe planowanie strategii bezpieczeństwa, a w software house’ach kluczowe jest dynamiczne dopasowanie do krótkich cykli wytwarzania MVP.

W podcaście mowa m.in. o:

• Różnicach w podejściu do bezpieczeństwa między firmami typu software house a firmami produktowymi w kontekście planowania i wdrażania rozwiązań AppSec.
• Efektywnym zarządzaniu podatnościami poprzez współpracę z deweloperami i menedżerami oraz dostosowywanie komunikacji o ryzyku do odbiorcy.
• Budowaniu kultury bezpieczeństwa (na przykładzie Netguru) oraz znaczeniu Threat Modeling i analizy ryzyka dla zapewnienia Secure by Design w nowych projektach.

Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.

Transkrypcja

Krzysztof: Cześć, witamy. Jest z nami Maciej Markiewicz. Macieju, myślę, że nie trzeba Ciebie przedstawiać, jeżeli chodzi o polski świat cybersecurity, w szczególności patrząc na Twoje doświadczenie i drogę, którą przebyłeś przez ostatnie lata od software house’u w Netguru, gdzie siedziałeś przez blisko 7 lat, po teraz firmę produktową, w której pracujesz. doświadczenie również speakera na wielu konferencjach, winąłeś się przez The Hack Summit for Developers, o ile dobrze kojarzę i pewnie jeszcze wiele innych fajnych eventów, na których miałeś okazję się udzielać, ale myślę, że najpierw było jakbyś naszym słuchaczom o sobie opowiedział krótko ty sam.

Maciej: Nie spodziewałem się tego pytania. Cześć, witam serdecznie, miło mi, że mogę tu gościć u Was. Nazywam się Maciej Markiewicz i zajmuję się cyberbezpieczeństwem, szczególnie tym skupionym wokół bezpieczeństwa oprogramowania, bezpieczeństwa produktów cyfrowych, doradztwem w tym zakresie szkoleniach i tak dalej. Obecnie pracuję jako Product Security Manager w Egnyte, gdzie właśnie razem z moim zespołem, którym kieruję, pomagamy deweloperom identyfikować słabości, podatności w aplikacjach i systemach i produktach i je usuwać jak najbardziej. optymalny sposób na różnych etapach całego cyklu wytwarzania.

Krzysztof: I właśnie, bo ja wspomniałem o twoim doświadczeniu z Netguru, który jest software housem, teraz patrzysz w firmie produktowej w Egnyte. Powiedz mi, jakie widzisz różnice w podejściu do bezpieczeństwa między tymi dwoma kategoriami firm?

Maciej: Wiesz co, przede wszystkim trochę inna dynamika tego, jakie jest podejście do bezpieczeństwa. W firmach produktowych to skupienie i ta dynamika może się bardziej rozłożyć w czasie, bo masz więcej możliwości długofalowego planowania. Netguru, zresztą każdym w tym o podobnym profilu, czyli Software House czy Netguru w zasadzie było bardziej firmą konsultingową, że ten element Software House był tylko jakby częścią. Tutaj ta dynamika jest zupełnie inna, bo wynika z tego, że projekty bardzo często są pisane od zera i głównym zadaniem jest w zbudowanie takiego MVP, czyli pierwsza najbardziej istotna dla biznesu część systemu. Pierwszy element, który wychodzi na rynek ma być tak naprawdę pokazywać to, jaką wartość dla klientów końcowych musi dostarczać ten produkt. I z tego wynika taż specyfika, ta różnica, tej dynamiki. Tutaj planowanie tych, planowanie usuwania czy identyfikowania podatności, czy zajmowanie się bezpieczeństwem, bardziej sprowadza się do tego, żeby idealnie, jak najbardziej idealnie dopasować te elementy bezpieczeństwa do tych stosunkowo bardzo krótkich cykli wytwarzania i bardziej dynamicznie to planować. Ciężko jest zbudować długofalowy plan i go implementować przez lata, bo nie wiadomo ile ten projekt potrwa tak naprawdę. Mogą to być trzy miesiące, może to być pięć czy dziesięć lat. i tak naprawdę to planowanie musi uwzględniać ten czynnik, więc ta dynamika jest zupełnie inna, inne są też potrzeby klientów, tych klientów jest o wiele więcej niż tylko jakby kilka grup produktów jak w firmie produktowej. i z tej charakterystyki całego biznesu czy modelu biznesowego wynikają ta dynamika planowania implementacji bezpieczeństwa.

Krzysztof: Ok, czyli teraz lepiej czujesz się w produkcie?

Maciej: Wiesz co? Czy lepiej, czy nie lepiej? Ciężko mi to powiedzieć. Na pewno inaczej, bo to nie jest tak, że to jest po prostu zupełnie, może nie zupełnie coś innego, ale coś innego i inaczej się do tego podchodzi. To są inne rodzaje wyzwań. I przez 7 lat pracy w Netguru świetnie mi się pracowało. Nauczyłem się tej dynamiki, dało mi to bardzo wiele doświadczeń, bo taka dynamika też pozwala bardzo szybko się uczyć, bo masz wielu klientów, jednego dnia rozmawiasz z bankiem, drugiego dnia rozmawiasz z firmą produkującą software. analizy parametrów życia, zdrowia i tak dalej, w innym dla sklepów, więc musisz się dostosowywać i szybko przełączać kontekstów.

Krzysztof: Dużo różnych kontekstów.

Maciej: Tak, bardzo dużo różnych kontekstów i bardzo to mi się podobało, ale też z czasem jakby Planowanie, rozbudowywanie procesów wokół takiej dynamiki zbudowało we mnie taką potrzebę, że OK, chciałbym popracować nad czymś dłużej, bo lubię oprócz rozwiązywania takich szybkich problemów planować jakieś takie bardzo średnioterminowe i długoterminowe strategie.

Andrzej: Ja właśnie tutaj mam pytanie, bo z tego co mówisz to ja wnioskuję, że właśnie w takiej firmie jak Netguru, bardziej nastawionej na wytwarzanie produktu, który ma tylko zwalidować to dostarczanie wartości tego MVP, a pomiędzy firmą produktową, w której teraz pracujesz, że w tej pierwszym rodzaju, czyli tym przykładowo Souther House, nie jesteś w stanie zobaczyć tych długopalowych efektów swojej pracy, bo niejako te pętle zwrotne często gęsto albo w ogóle się utną, bo na przykład jest projekt ucięty, bo nie dostarcza jednak wartości, albo jest tak zwany piwot, co też często, często można zauważyć, a w firmie produktowej możesz na przykład zaplanować, wdrożyć i patrzeć jak działa jakaś inicjatywa szersza przez wiele lat. I na podstawie tego możesz budować i wyciągać pewne wnioski, których nie byłbyś w stanie zbudować w tym pierwszym rodzaju firmy.

Maciej: Tak, zgadza się. Jeżeli chodzi o poziom takiego projektu, jest dokładnie tak jak mówisz. Czasami po prostu planowanie długofalowych strategii kończyło się… Ono było wartościowe dla klientów, bo oni i tak dostawali tą strategię zdefiniowane, takie powiedzmy roadmapy. wiedzieli co mogą dalej zrobić, ale z punktu widzenia inżyniera, konsultanta, który pracował przy tym projekcie, on mógł nie dostać nigdy doświadczeń z tej satysfakcji, że wszystkie elementy z tej roadmap zostały zaimplementowane. i jest to problem, jest to jakieś tam wyzwanie, z którym musisz sobie poradzić i jakby przywyknąć do tego, że tak wygląda specyfika tej pracy. Do końca nie jest tak, że ze wszystkim tak jest w firmie takiej konsultingowo-software house’owej. Bo oprócz tego, że masz pracę typowo na projekcie w tych wyizolowanych, odseparowanych, że tak powiem działających ze współpracy z klientem takich enklawach małych, możesz planować długofalowo czy średniofalowo procesy wokół całego procesu developmentu, który jest w jakimś stopniu ustandaryzowany tak pomiędzy wszystkimi produktami, liniami produktowymi. I wtedy z mojej perspektywy jako kogoś, kto jakby nadzorował, projektował tego typu procesy i strategie, No to tam ja dostawałem tą satysfakcję, że widziałem, że to działa, przekłada się na to, co się później na przykład działo w projektach, jak kształtowały się wymagania dla projektów, jak przebiegały rozmowy inżynierów pre-sales, czy sprzedawców, czy wszystkich po kolei w całym łańcuchu z klientami. Jakby rosła ta świadomość właśnie dzięki implementacji takich strategii, więc częściowo można dostać to tylko po prostu na innym poziomie. Tutaj możemy dostać to właśnie w większej liczbie obszarów, bo możesz dostać to i na poziomie projektowania tych procesów, praktyk, budowania kultury, ale również też w tych produktach, gdzie masz większą sprawczość do tego, jak długofalowo ta strategia implementacji bezpieczeństwa, usuwania podatności, mitygacji ryzyki i tak dalej będzie wyglądała. Więc jest to dodatkowe takie pole, gdzie można tego doświadczyć.

Krzysztof: Na początku naszej rozmowy wspomniałeś Maciej o elemencie, o którym z Andrzejem też często rozmawiamy, czy to z naszymi gośćmi, czy w naszym podcaście, który prowadzimy, na temat efektywnego z punktu widzenia biznesu wyprowadzania podatności. Czy mógłbyś rozwinąć ten wątek, co masz na myśli mówiąc efektywne wyprowadzanie podatności z punktu widzenia biznesu?

Maciej: No to jest moja ulubiona odpowiedź na wszystkie pytania, czyli to zależy.

Andrzej: No tam, tam, wiesz, konsulting tam się pojawił.

Krzysztof: Z konsultingu możesz wyjść, ale konsulting nigdy nie wyjdzie z ciebie.

Maciej: Dokładnie tak. Widzę, że się rozumiemy, także to by było na tyle. A tak serio, no dosłownie to zależy od bardzo wielu czynników, od tego czego oczekuje od ciebie klient, jakie są obecne sytuacje w projekcie, jakie są obecne priorytety wyzwania. i z jakimi podatnościami czy z jakiej skali ryzykami mamy do czynienia. i te wszystkie rzeczy trzeba tak naprawdę wrzucić do jednego worka, trochę pomieszać i zobaczyć co będzie najoptymalniejsze dla danego projektu w danym momencie, zwłaszcza w takim podejściu konsultingowym dla wielu firm. Różnie to może się kształtować. Wiadomo, są jakieś takie skale podatności, które są tak wielkie, że musicie zaciągnąć ręczny i zatrzymać wszystko natychmiast i wtedy nie ma dyskusji na temat strategii, planowania i analizowania, co możemy zrobić i jak to wszystko pogodzić. Ale to mimo wszystko nie jest częste. Najczęstsze są takie podatności, które mają duży wpływ, ale jednak w połączeniu z tym, co klient chce osiągnąć, dokąd zmierza biznes, jakie mamy projekty i co najważniejsze ile mamy na to pieniędzy, musimy sobie to rozplanować i najczęściej sprowadza się to do planowania tego właśnie w tym podejściu konsultingowym, do planowania z jakimś takim product ownerem czy kimś odpowiedzialnym za definiowanie priorytetów. trochę takiego negocjacji, co możemy, ile mamy czasu, ile mamy przestrzeni i znalezienie takiego wspólnego pola, jak to wszystko ze sobą pogodzić i tak żeby, przynajmniej ja wychodzę z takiego założenia, żeby jednak dogadać się i znaleźć ten wspólny mianownik, żeby ta druga strona, nie wiem, inżyniering managerowie czy product ownerzy, też chcieli to zrobić, żeby to była nasza wspólna decyzja, a nie tylko zewnętrznie przychodzi security i mówi, to ma być zrobione, bo to się kończy źle.

Andrzej: Ale jak to? Maciej, to ty nie lubisz security, które chodzi po firmie i pałuje wszystkich?

Maciej: No. To nie tak to się robi?

Andrzej: To nie na tym polega skuteczne, efektywne działanie bezpieczeństwa?

Maciej: Odpowiem politycznie poprawnie. To zależy. Jak długo masz pałkę.

Andrzej: Tak, ale ja też się z tym zgadzam, że raczej tutaj w Security wszyscy gramy tutaj do jednej bramki i trzeba po prostu znajdować te wspólne mianowniki, na tyle na ile też pozwala nam właśnie ogólny koszt i biznes, bo na koniec dnia liczy się zysk.

Maciej: Zgadza się, ale to jest też. To jest też o tyle istotne, że koniec końców to security potem przychodzi do inżynierów, do deweloperów i tak dalej i coś od nich chce, więc to nie może być tak, że przychodzę z pałką, bo oni będą zawsze nastawieni do mnie wroga. Więc ja tak naprawdę muszę być zawsze otwarty na to, żeby im pomagać i budować takie poczucie, że faktycznie to podejście skupione na współpracy jest jedyną możliwą drogą. I to, co jest najważniejsze, to to, że ten zespół inżynieryjny musi być o tym przekonany, musi wiedzieć, że w każdym momencie mogą do mnie przyjść i do mnie, czy do całego zespołu, bo to nie jest tylko moja personalna, jak gdyby, sprawa, tylko dla całego zespołu, że to security zawsze jest i zawsze jest w stanie im pomóc, bo w ten sposób oni będą wiedzieli, że faktycznie gramy do jednej bramki, nie? To jest bardziej, powiedziałbym, że to jest nawet bardziej istotne niż to, żebyśmy skupiali się na na jakby sami we własnym gronie rozwiązywaniu tam jakichś problemów. One mają drugorzędne znaczenie niż to, żeby pomóc deweloperom, bo to oni ostatecznie dostarczają tą kluczową wartość dla nas bezpieczników. A niestety ten mit, o którym wspomniałeś tutaj, on cały czas pokutuje. I kiedy rozmawiasz pierwszy raz z deweloperem, który nie miał wcześniej do czynienia ze współpracy w takim, powiedziałbym, nie wiem, nazwijmy to nowoczesnym podejściu opartym o współpracę, zawsze da się wyczuć gdzieś taki ten pushback, że jest security i tak dalej. Ja zawsze staram się robić trochę, wiesz, obracać to w żart i robić z tego mema, bo to jest świetny sposób na rozładowanie napięcia i rozbrojenie tej sytuacji. Da się to wyczuć. Widziałem to kiedy pracowałem w Netguru. Deweloperzy z którymi pracowałem wewnątrz firmy szybko się tego nauczyli i już wiedzieli jak do tego podchodzić. Natomiast często pracowaliśmy z zespołami zewnętrznymi i było widać to podejście. że ok, lecimy tutaj razem, jesteśmy w tym razem i szukamy samych rozwiązania, no to zawsze było takie sceptyczne podejście, że security przychodzi i zacznie coś tutaj marudzić. A to nie o to chodzi, bo wtedy nikt nie przyjdzie prosić o pomoc, jeżeli będzie wiedział, że za rogiem czeka ktoś z security, z pałką czy paralizatorem.

Krzysztof: Właśnie, bo wspomniałeś o product ownerach, o engineering managerach i trzeba gdzieś lawirować między tym światem właśnie inżynierii, biznesu. Jak uświadamiasz te dwie role, że bezpieczeństwo jest istotne i jaką wartość może im przynieść w kontekście tego co oni robią? Bo wiesz, bo przeważnie jest tak, że dla tego typowego product ownera przyjście z zadaniem w stylu musimy wyprowadzić podatność w twojej części aplikacji, w twoim featurze, w twoim wertykalu, którym się zajmujesz, właśnie spotyka się z takim pushbackiem, jakby bezpieczeństwo to nie jest nasza odpowiedzialność.

Maciej: To jest problem na takim poziomie już komunikacyjnym, że jakby mówiąc to w ten sposób, jak to określiłeś, już od razu stawiasz sobie barierę, że oni nie rozumieją, bo muszą mówić, co to jest podatność. To nie są słowa, które oni używają na co dzień, więc jakby jednym, to gdzieś tam staram się o tym mówić, że jednym z kluczowych cech inżyniera bezpieczeństwa pracującego przy rozwoju oprogramowania, przy produktach, czy konsultanta jest nie skille techniczne, ale skille komunikacyjne, bo Musisz umieć dostosować poziom swojej komunikacji do odbiorców. Nie możesz oczekiwać, że ty im powiesz, że musimy załatać podatność o severity critical według CVSS. Nikt tego nie zrozumie. Nikt nie ma czasu na to, żeby googlować co to jest CVSS i tak dalej, a potem jeszcze ci wrócić z odpowiedzią, a najlepiej żeby to się wydarzyło na jednym colu czy przy jednym stole. To się nigdy nie wydarzy. Więc jak ty do nich przychodzisz, to ty musisz mówić w ich języku. Jeżeli przychodzisz do inżynierów, no to możesz namacalnie pokazać, że tutaj twoja ulubiona działka. Jak zostawisz ten klucz w kodzie, to on tam wycieknie i ten deweloper z Chin, co to mu wyciekło, to już go nikt nie znalazł. To ma jakby lepszą szansę powodzenia. po pierwsze jak ty mówisz do nich w ich języku? albo drugie jak im pokazasz przykłady namacalne co się wydarzyło? jeżeli ktoś tak zrobił. A najlepiej jak te przykłady będą nie z właśnie z Chin tylko z podwórka obok. A kojarzysz tego gościa? tam on pracuje w innym projekcie. No piliśmy w zeszłym tygodniu kawę razem czy byliśmy na piwie. No to on zrobił tak i tak. i się rozlało mleko, nie? A jeszcze najlepiej jakby on to opowiedział, bo wtedy już w ogóle, wiesz, budujesz takie przeświadczenie, okej, to jest okej o tym mówić, to są namacalne rzeczy, one się dzieją, super, że możemy dzielić się wiedzą i ta świadomość cały czas rośnie. Analogicznie jak pójdziesz do product ownerów, product managerów, musisz przekładać to na ich język, że jeżeli to się wydarzy, no to klient może w taki i taki sposób ucierpać. Jeżeli doimplementujemy to MFA w tym i w tym miejscu, to będziemy mogli iść i powiedzieć na zewnątrz, słuchajcie podnieśliśmy wartość naszego produktu, od dzisiaj możesz stosować MFA gdzie tylko chcesz i tak dalej, bo jesteśmy super bezpiecznym produktem. Jeżeli pójdziesz do C-levelu czy do biznesu, to musisz im najlepiej to przetłumaczyć na pieniądze. Jeżeli nie usuniemy tych pięciu podatności, to będzie to ciebie kosztować tyle i tyle, bo tutaj podatność ta, bo tutaj jest RODO, bo tutaj jest HIPA, milion innych regulacji i one mają cenniki. To jest akurat taka dygresja, to jest świetna rola regulacji, że one dostarczają cenniki. Łatwo można przeliczyć sobie ile cię będzie kosztował konkretnie.

Andrzej: Dokładnie i możesz wtedy podjąć już faktyczną decyzję czy kupujesz to czy nie, bo może być tak, że biznes to po prostu kupi.

Maciej: Może być tak, tylko to jest bardzo kluczowa, istotna sprawa, że bardzo często firmy, które pracują z biznesem Mają to samo założenie, że niekoniecznie musimy wszystkie elementy bezpieczeństwa implementować, nie musimy usuwać wszystkich rzeczy, więc to security jest niepotrzebne. I tu jest bardzo poważny problem, że z jednej strony tak, nie musimy wszystkiego implementować, ale decyzja musi być podjęta świadomie. a nie potrzebujemy security, bo tak nam się wydaje.

Andrzej: Tak, to jest to w ogóle zahaczał taki meta koncept, który się nazywa complexity on the other side of simplicity. Więc jak mamy jakiś koncept i uczymy się go jako osoba nowicjusz, to może nam się wydawać o pewnym czasie, że już dość dużo wiemy. Potem oczywiście zjedziemy i zaczniemy dostrzegać, że naprawdę to nic nie wiemy, ale potem znowu wchodzimy coraz wyżej i to już jesteśmy po tej drugiej stronie złożoności, gdzie wiemy co wiemy, wiemy czego nie wiemy i niejako coś już czujemy i wtedy jesteśmy w stanie podejmować świadome decyzje. I tak samo właśnie tutaj, Ja w pełni się zgadzam. Jest fundamentalna różnica pomiędzy podjęciem decyzji świadomie, a nieświadomie. Nawet jeżeli końcem końców to będzie ta sama decyzja. To jest duża różnica, jeżeli mamy ten łańcuch myślowy i możemy to jasno uargumentować, czemu postąpiliśmy tak, a nie inaczej.

Maciej: Zgadza się. Podpisuję się pod tym. To jest taka dygresja, że Na początku jak zaczynałem moją pracę w Netguru, pracowałem jako deweloper, ale z uwagi na to, że miałem gdzieś tam zainteresowania związane z cyberbezpieczeństwem, skończyłem politechnikę na specjalizacji związane z bezpieczeństwem systemów IT, to byłem jedną z niewielu osób, które coś wiedziała w tym temacie i zacząłem najpierw to implementować w jednym projekcie, potem w kilku, a potem zaczęliśmy, w sensie ja zacząłem drążyć temat. jak to wygląda w szerszej skali, jeżeli chodzi o całą firmę. Mieliśmy wtedy taki kanał na Slacku, który nazywał się Security. No i pojawiło się pytanie, OK, na tym kanale pojawia się bardzo mało pytań dotyczących Security, w ogóle ruch tam jest bardzo niewielki. I teraz pytanie jest, skoro prowadzimy w jednym momencie powiedzmy 100 projektów, to dlaczego nikt nie rozmawia na kanale Security na tematy związane z Security? Postawiłem sobie taką hipotezę, Czy pytanie, czy jesteśmy tak świetni w security, że nie musimy o nic pytać, czy może jest dokładnie odwrotnie, że my nie mamy pojęcia o co pytać i jak o tym rozmawiać. No i zacząłem od rozmawiania z deweloperami, różnego rodzaju sesje, szkolenia. pytania, zapewnianie ich, że ok, teraz jeżeli macie problemy, czy pytajcie klienta o to, czy myślą o security. Jeżeli nie będziecie znali na jakiekolwiek pytanie odpowiedzi, to przychodźcie do mnie. Tu mamy grupę konsultantów, którzy będą w stanie się Wam pomóc i zajmować. Budujemy takie community. Ale wszystko wrzucajcie na ten kanał po to, żebyśmy zmierzyli, jak zmienia się świadomość organizacji i to będzie naszą metryką ilość rzeczy, które będą się pojawiać na tym kanale. I przez rok stała się rzecz po prostu niesłychana. Ten kanał był jednym z bardziej żywych kanałów w ogóle w całej firmie, bo nagle się okazało, że można zadawać pytania, nie musi odpowiadać nawet security, Ludzie pomiędzy projektami mieli podobne wyzwania, ale świadomość sama tego, że można to robić, że to jest okej, że można nie wiedzieć, nie znać odpowiedzi i że ktoś pomoże, zrobiła tutaj rewelacyjną różnicę i jakby była podwaliną pod rozbudowę całego całego procesu utwardzania, procesu dewelopmentu, podbudowę komercyjnego zespołu itd. Wszystko się zaczęło właśnie od tej jednej konkretnej metryki, która zdefiniowała budowę kultury związanej z bezpieczeństwem.

Andrzej: Właśnie to, dokładnie to, to mi się w tym wszystkim mega spodobało, że tym początkiem było zaszczepienie jakiegoś ziarna odnośnie kultury i tak prostej metryki jak jak bardzo aktywny mamy kanał związany z security. Tak. Coś co tak naprawdę każdy jest w stanie zrobić, jeśli w organizacji w ogóle nie ma myślenia o bezpieczeństwie i nie wymaga to żadnej specyficznej, specjalistycznej wiedzy, po prostu chęci i zainteresowania tematem. No a jak sam mówisz, to był świetny krok, no bo to tak naprawdę zaszczepiło to ziarno do tego, że potem ten program się rozrósł i już nawet macie dedykowaną, no już nie wy, bo ty już nie działasz na góru, ale ja pamiętam jak to się działo. Ja oczywiście tylko obserwowałem z zewnątrz, ale zaobserwowałem. Pojawiają się blog posty na blogu NetGuru o security. O jakiś gość tam Maciek coś tam pisze. Więc z zewnątrz też było widać taki wzrost tego, że to się już tam buduje, kiełkuje, a potem rośnie do takiego już powiedzmy lasu, bo też zacząłem widzieć ludzi, którzy się zaczęli pojawiać w NetGuru od bezpieczeństwa. Między innymi Pawła. Pozdrawiamy.

Maciej: Tak pozdrawiamy Pawła.

Krzysztof: Jeżeli chodzi o ten kanał, o, chcesz coś powiedzieć?

Maciej: Nie, chciałem tylko dodać, że wiesz co, że tak i to było ciekawe, że ta budowa, jakby budowa i rozwój tego, tej społeczności pokazał też, że ludzie w inżynieringu, czy ludzie, deweloperzy QA i tak dalej, oni sami z siebie chcieli się rozwijać w tym i to było świetne, że Jeżeli dało się przestrzeń i platformę do rozwoju, to nagle się okazało, że możemy budować grupy robocze, które nie są stricte security engineer, nie mają pozycji security engineer czy security consultant, tylko pracują w QA, pracują w developmencie i nagle są w stanie robić projekty, identyfikować, usuwać delegacji, poprawiać procesy, poprawiać, rozbudowywać macierzy kompetencji dla ich stanowisk o rzeczy związane z security, czy robić takie testowo hobbystyczne hakowanie innych projektów, które przynosiło super wartość dla poprawiania tych projektów. I to dało super paliwo i super wartość dla dalszego rozwoju, więc warto inwestować w budowę właśnie kultury, bo to jest super wartość, a tak naprawdę za budową tego i dlaczego to się od tego zaczęło wynika prosta przesłanka. Jak zaczynasz pracę nad zupełnie nowym obszarem takim jak security w firmie, która się dynamicznie rozwija, to nikt ci nie da nagle pieniędzy, żeby zatrudnił pięciu, dziesięciu bo przychodzi jakiś gościu, który coś tam gada o security i mówi ok, musimy to zrobić, bo to jest ważne, najpierw musisz pokazać, że to jest ważne, więc z tak czysto pragmatycznego punktu widzenia, Takie były podwaliny, ale świetnie się to złożyło, bo to był świetny efekt i świetna decyzja patrząc z perspektywy czasu.

Andrzej: I ja tutaj dorzucę jeszcze taki po prostu przykład anegdotyczny, który każdy będzie znał ze swojego życia, że nie należy się oburzać na to, że najpierw muszę udowodnić wartość, a dopiero potem ktoś da mi zabawki, bo wszyscy w życiu postępują dokładnie tak samo. Jeśli ktoś do nas podejdzie z ulicy i powie, że ma super pomysł, tylko musisz mu dać 10 tysięcy złotych teraz, no to nikt racjonalny nie odda tych dziesięciu tysięcy. Więc w własnym życiu osobistym działamy na takich zasadach, a nagle potem możemy o tym zapominać będąc w środowisku pracy, że a czemu ktoś mi nie da tego, przecież to jest takie bardzo ważne. Spróbuj to udowodnić, spróbuj zbudować jakiś MVP dla tego, dla takiego case’u i potem zobaczymy.

Maciej: Ale wiesz co, to o czym powiedziałeś wynika trochę, bo widziałem to wielokrotnie i sam też miałem takie kiedyś podejście, że okej, no przecież widać jak na dłoni tyle i jakby ten, ale to wynika z tego o czym powiedziałeś, ten wykres, o którym mówisz, to chyba jest krzywa królbiaka Dunninga, o ile dobrze pamiętam. że jak mało wiesz, to nie rozumiesz, dlaczego to się dzieje. Jak zaczynasz wiedzieć więcej, to dopiero dociera do ciebie, że sam byś nie dał komuś pieniędzy, bo przyszedł i mówi, że to jest oczywiste. No może jest oczywiste, ale musisz mieć twarde dowody na to, no bo to koniec końców musi generować jakieś zyski, generować pieniądze, no bo na tym polega biznes. Twarda i smutna prawda, ale niestety po to istnieją firmy, żeby generować pieniądze, nie po to, żeby je wydawać na security, bo bez tego biznesu nie ma tego security.

Andrzej: Dokładnie, ja tu oczywiście też mówię z doświadczenia, to nie jest tak, że… Ja oczywiście też byłem. Najpierw byłem w obozie w którym ale jak to przecież każdy każdy widzi trzeba naprawić się dopiero potem. Zdałem sobie sprawę że jednak nie.

Krzysztof: Mi też nie chcieli dać.

Andrzej: Jedyne co to mnie ignorowali i nie chcieli ze mną rozmawiać.

Krzysztof: To jest świetna dyskusja w którą moglibyśmy toczyć tutaj jeszcze dobre kilka godzin na temat budowania w ogóle kultury bezpieczeństwa w organizacji. I to co powiedziałeś z tym kanałem jako taki single point of contact i taka bezpieczna przestrzeń, bezpieczna dla deweloperów, dla QA’ów i miejsce w którym oni też zaczynają się czuć pewni i zdobywają Między innymi przez ten kanał dodatkowy skillset, którym mogą się po prostu później w tych projektach pochwalić. Odchodząc troszeczkę od takich szerzyk strategii i kultur budowania bezpieczeństwa, takie pytanie do ciebie Maciej, które zadaję w ramach serii naszych wywiadów z Andrzejem dosyć często.

Andrzej: Ale tylko wybranym osobom.

Krzysztof: Tak, tylko specjalistom.

Maciej: To jest prawdziwy komunizm, widzicie?

Andrzej: O, snap!

Krzysztof: Kolejny punch.

Maciej: Trzeba wyciąć teraz.

Krzysztof: Zakładając, że wchodzimy w taki greenfieldowy projekt, jakie narzędzia, jakie pierwsze wdrożyłbyś w potok CI, CD z zakresu bezpieczeństwa? Wybierz takie narzędzie, które w Twojej opinii daje największy zwrot kosztów z inwestycji na początku.

Andrzej: I szczególnie bo użyłeś słowa narzędzie, ale to oczywiście może być ogólnie praktyka proces. Czyli masz Greenfield’owy projekt, wchodzisz w niego, on nie ma totalnie nic. security. What’s first?

Maciej: Według Ciebie. Tread modeling i analiza ryzyka na samym początku.

Andrzej: Miód na moje serce.

Maciej: Dlatego, że to jest najtańsze rozwiązanie, jakie możecie zastosować i przekłada się na najlepszą, najbardziej skuteczną implementację bezpieczeństwa i walidowanie i definiowanie tego. Później. Bo możemy oczywiście myśleć o narzędziach typu SAST i to jest super i to pomaga deweloperom, SAST, SCA i tak dalej. Ale jeżeli mówimy o tym o czym, jeżeli zaczynamy od zera i jeżeli mówimy o tym co będzie najtańsze i najbardziej skuteczne to na pewno to. Tylko musi być to dobrze wdrożone i wszyscy muszą rozumieć co robią.

Andrzej: To czy mógłbyś w dwóch słowach taki TLDR po prostu powiedzieć? o analizie ryzyka, o modelowaniu zagrożeń, ewentualnie jakie widzisz różnice pomiędzy tym. Naprawdę takie skrótowo, żeby widzowie mieli wyrównanie. Jasne.

Maciej: Więc generalnie chodzi o to, że jeżeli siadamy sobie przed projektem, który zaczyna się od zera i jest zupełnie czystą kartką, to musimy sobie spisać, co ten projekt ma robić. Czy on ma wyświetlać zdjęcia kotów, czy ma robić przelewy do banku. I jak sobie to naszkicujemy, to do tego pojawiają się kolejne pytania, które doprecyzowują, no dobra, ale jak on to ma robić? Czy to wszystko co ma robić? Czy to jest najistotniejsze? Gdzie jest największa wartość? Co ma najmniejszą wartość? Jakie są priorytety? I tak dalej. I generują nam się dodatkowe pytania, które doszczegółują tak naprawdę wymagania funkcjonalne i pozafunkcjonalne tego projektu. To, co wygenerujemy na tej kartce, będzie później przekomponowane na zadania dla deweloperów, na jakieś user stories, trafi do GREs, będzie implementowane. Od tego się wszystko zaczyna, od tej naszej mitycznej, powiedzmy, czystej kartki. I teraz to, co jest bardzo istotne, to to, że jak mamy naszkicowane już te wymagania, to zanim pójdziemy dalej, to warto by było poświęcić trochę czasu na to, żeby zastanowić się nad tym, jakie są ryzyka dla tej aplikacji, kto może tym aplikacjom zaszkodzić, dlaczego może chcieć to zrobić, z czego to może wynikać i gdzie są najsłabsze punkty tego systemu i tej naszej kartki, bo to nam pozwoli później wygenerować modele zagrożeń, a na modele zagrożeń będziemy mogli przygotować odpowiedzi. bronimy się przed konkretnymi zagrożeniami. Nie ma jak gdyby złotego środka, pewnie nie jedna osoba już to tutaj powiedziała, że nie ma jednego złotego środka, który zabezpieczy aplikację. Musi to być taka para odpowiedź na konkretne zagrożenia i to jeszcze musi to być integralna część całego systemu. Dlatego to jest tak istotne, żeby zacząć od tej pustej kartki, bo wtedy mamy pewność, że to będzie integralną częścią każdego z zadań. Że to nie będzie tak, że dokleimy MFA później, tylko to będzie Całym cyklem, całym integralną częścią flow. Jest większa szansa, że nikt nie znajdzie obejścia, bo to nie jest doklejone, tylko po prostu tak zostało to zaprojektowane. Tak zaprojektował został UX przez UX designerów. Takie były wymagania spisane, więc potem ktoś to zaimplementuje, QA będą mieli test case’y do testowania itd. Wtedy staje się tą integralną częścią i to jest ten mityczny, idealny stan Secure by Design, bo zaczynamy od samego początku i wszystko jest spójną częścią.

Krzysztof: Szyte na miarę.

Andrzej: I ja tutaj dodam, że albo nawet mając taki właśnie model zagrożeń możemy po prostu Go zaakceptować i powiedzieć, że tego nie bierzemy i co często jest taką odpowiedzią. Po prostu vendor mówi że OK to jest problem ale to wykracza poza nasz model zagrożeń i dla nas to nie jest tak naprawdę duży problem. Nie powinieneś przykładowo zostawiać swojego hasła i kluczyka w komputerze. to nie możesz potem oczekiwać że to jest podatność. To nie jest podatność.

Maciej: Ale to jest zadanie jak każde inne. właśnie często problemem zespołów produktowych, deweloperskich czy klientów, którzy chcą aplikacji jest to, że oni nie wiedzą z czym to się wiąże, nie są w stanie znów podjąć tej świadomej decyzji, a jeżeli masz to na kartce i masz to potem w taskach na Jeezy, to ty jesteś w stanie przypisać temu priorytet, wycenić ile cię to konkretnie będzie kosztować mendejsów, czy tam w czym wyceniasz, ile to story zajmie, ile tutaj tych rzeczy. Te stories, które wchodzą, bo np. są logowaniem i muszą być, to po prostu rozbudowujesz definition of done, nie dorobisz osobnego taska, zrób logowanie bezpieczne, bo to trafi na koniec backlogu i się nie wydarzy nigdzie. Mod do. Mam na presce właśnie taki przykład, ta historia się wydarzyła naprawdę, że mieliśmy projekt, no i jakby po długich rozmowach i z klientem, i z developerami utworzono taska, zrób ten projekt bezpieczny, No i to było max, co moglibyśmy uzyskać. No dobra, jest task, jest chociaż szansa, że ktoś się kiedyś tym zajmie, ale jak zostały 3 dni do deadline’u, a task był wyceniony na 5 dni, no to tylko można zrobić z tym want to do, no bo jakby co. Ale jak skleisz to z taskiem na zrób logowanie bezpieczne, no to nie urwiesz tego, bo nie ma jak, to po prostu zostanie zrobione. To jest tak banalna rzecz, ale niestety tak bardzo często pomijana pewnie ze względu na to, że jest po pierwsze niska świadomość, a po drugie, że jest to dość trywialne, więc łatwo to przeoczyć. Więc to jest taki trochę paradoks tego wszystkiego.

Krzysztof: Dokładnie, dokładnie to co powiedziałeś i to, że jeżeli siadamy od samego początku i zbudujemy sobie ten profil ryzyka, to wiemy potem jakie decyzje możemy podejmować, jaki jest apetyt na ryzyko i co z tych zagrożeń, które powstają w ramach modeli jest dla nas istotne, a co nie. Bo jeżeli koszt mitygacji jest większy jak koszt materializacji ryzyka, no to sprawa jest prosta.

Maciej: No zgadza się, ale no ważna jest ta świadomość.

Andrzej: Dokładnie, świadome decyzje, ale żeby właśnie podejmować… Praca musi zostać wykonana.

Maciej: Musi zostać wykonana i nie wiem czy macie takie podobne doświadczenia, ale dotarło do mnie kiedyś, że jeżeli w procesie bierze udział Quality Assurance Inżynier czy tam specjalista i on generuje bugi, tikety na bugi, to one są fiksowane. albo jeżeli tiket jest rejektowany z uwagi na to, że nie spełnia wymagań, nikt z tym nie polemizuje. To jest oczywista rzecz, że no bug no to trzeba naprawić. Ale jeżeli w tym samym pipeline pojawi się podatność, To podatność, to trzeba już się zastanowić, co nie wiadomo. I zobaczcie, że jakby moje sposób nie był taki, że sam fakt tego, że to się nazywa podatność, a nie po prostu bug, jest już pewnego rodzaju czymś, co sprawia, że Podchodzimy do tego jak do czegoś obcego, do czegoś z zewnątrz i już nie będzie to tak łatwo przyjmowane. No i to też wynika z tej świadomości to po pierwsze, a po drugie z tego jak kluczowa jest w tym całym procesie komunikacja i tak drobne rzeczy.

Krzysztof: Tak, no i nasza w tym rola, żeby trochę odczarować to, że bezpieczeństwo to nie jest rocket science, a niestety środowisko zbudowało przez wiele lat dookoła tego trochę taką mityczną otoczkę.

Andrzej: Tak i to środowisko bezpieczników, bo to nie jest tak, że ktoś przyszedł z zewnątrz i zaczął czarować. To sami bezpiecznicy tak trochę specjalnie, tak mi się wydaje z moich obserwacji, czarowali, żeby wyglądało to na bardziej skomplikowane niż jest. A z mojego doświadczenia każdy inżynier, czy to właśnie QA czy Dev czy Ops nie ma większych problemów, żeby posiąść skillset związany z bezpieczeństwem.

Krzysztof: Bo wiecie, bo zobaczcie na przykład w kontekście bugów. Czym jest podatność? To jest nic innego jak bug, który ma po prostu implikację w poufności, integralności albo dostępności, tak? Nie musimy tego tak naprawdę przekładać na jakieś inne słownictwo.

Andrzej: Tak, nic magicznego.

Maciej: Ja się tak zastanawiam trochę, czy to nie jest tak, że sami sobie to zrobiliśmy, że wiecie, że kiedyś było tak, że inżynier bezpieczeństwa, czy ktoś od bezpieczeństwa, to była taka osoba, która posiadała wiedzę tajemną. trochę lepsza niż inni, bo ona wie jak to rozwiązać. I teraz to trochę budowanie takiego zamkniętego, hermetycznego środowiska sprawiło, że powstały te mity, że to jest, wiecie, budowanie takich silosów, w których nie dzielisz się wiedzą, tylko przychodzi ktoś i kładzie ręce i cudownie uzdrawia. Oczywiście trochę to podkoloryzowuje, ale trochę tak to wygląda, że przez lata Tak to się zadziało, no i brak tej wymiany wiedzy spowodował właśnie takie zamknięcie, które skutkuje tymi mitami.

Krzysztof: Wiem, znowu The Phoenix Project.

Andrzej: The Phoenix Project, ale ja generalnie do IT wchodziłem od strony bezpieczeństwa i z mojej perspektywy…

Maciej: Czyli to twoja wina.

Andrzej: Można właśnie tak powiedzieć, albo moich kolegów i koleżanek. Ale trochę tak, że ludzie, którzy nie mają backgroundu inżynieryjnego, czyli właśnie nie pracowali wcześniej jako deweloper OPS, ale OPS a nie administrator tylko sieci, czy właśnie QA, czy generalnie nie uczestniczyli aktywnie w procesie wytwórczym. To są ci klasycznie ludzie, którzy wcześniej działali w bezpieczeństwie i oni lubili taki jasny podział pomiędzy my bezpiecznicy, a wy reszta. Natomiast ja widzę, obserwuję, że im więcej osób w branży pojawia się z backgroundem właśnie inżynieryjnym, tym to się zmienia, no bo ty doskonale rozumiesz Czym to się je? Dlatego, że pełniłeś rolę inżynieryjną i teraz pełniąc rolę bezpiecznika jesteś w stanie się wczuć w rolę inżynieryjną.

Maciej: To pomaga na pewno.

Andrzej: I ja ze swoich doświadczeń też dopiero po doświadczeniu inżynieryjnym trochę inaczej spojrzałem na całe bezpieczeństwo.

Maciej: No to zdecydowanie, jakby mam podobne obserwacje, że trochę tak to wyglądało, ale to też wynika prawdopodobnie z tego, że rośnie sama świadomość tego, rośnie jak gdyby cała gałąź rozwoju oprogramowania cały czas, a wraz z tym dużo wolniej niestety rośnie bezpieczeństwo tego oprogramowania. Teraz widać, że też wyrasta obok np. wzrostu AI jako takiej podgałęzi, wzrasta też AI security. Nie wszyscy wiemy jak działa AI dokładnie, jest dużo niewiadomych procesów jak to w ogóle spiąć, po prostu jest hype duży i tak dalej, no ale obok tego rośnie security, które też próbuje jakby poskładać w całość jak zabezpieczyć te modele AI, mimo, że nie wszyscy nawet wiemy jak one działają. co dopiero i jak zabezpieczyć to. To jest bardzo złożone, ale widać ten trend, że też już rośnie, już kiełkuje i gdzieś tam pojawiają się bardzo ciekawe projekty, które mają adresować właśnie to. Więc cieszy mnie to, że wystartowaliśmy jako społeczność dużo szybciej z rozwojem bezpieczeństwa AI niż ogólnie z rozwojem bezpieczeństwa produktu. Bo cały czas mam wrażenie, że to stosunkowo wolno rosło.

Andrzej: Uczymy się. Uczymy się na błędach.

Maciej: Dobrze jest się uczyć na błędach.

Andrzej: Idealnie. To niedobrze jest się nie uczyć na błędach.

Krzysztof: Krzysiek.

Andrzej: Pytania? Czy się wypstrykałeś? Ja się wypstrykałem.

Krzysztof: Ja już się wypstrykałem. Chociaż ja czuję, że tutaj można by było zrobić dogryweczki.

Andrzej: No to liczba mnoga. Do gryweczki. Do gryweczki. No dobra niech stanie na do gryweczkach. Liczba mnoga.

Maciej: Nie wiem jak często będziecie tutaj w Poznaniu.

Krzysztof: Zrobimy całą serię w ogóle z Maćkiem.

Andrzej: Tak Maciej dla ciebie przyjedziemy i zrobimy serię ekspercką.

Maciej: O proszę.

Andrzej: Przygotujemy się do niej bardziej porządnie sobie rozpiszemy o czym chcielibyśmy porozmawiać i nasi widzowie otrzymają jeszcze więcej wartości.

Maciej: Świetnie to brzmi jak świetny plan na cały weekend.

Andrzej: Więcej niż u mnie.

Krzysztof: A pierwsza seria ekspercka będzie o budowaniu kultury bezpieczeństwa w organizacji.

Andrzej: No to jest pierwszy krok.

Maciej: To Andrzej możesz być wtedy adwokatem diabła, że ty przychodzisz z pałką?

Andrzej: Dobrze. Niech będzie. Tam wcześniej wspomniałeś, zrobiłeś pewien kwalifikator. Ja się kwalifikuję.

Krzysztof: Przebierzemy go za policjanta.

Maciej: Zgadza się.

Krzysztof: Dobrze, Macieju. Bardzo ci dziękujemy za twój czas i za tą rozmowę.

Andrzej: Dzięki i do zobaczenia w przyszłości na Dogrywkach.

Krzysztof: Na razie.

---