Opowiedz nam trochę o SIG-ach. Co kryje się pod tym skrótem? Czy to nowa inicjatywa w firmie?
Jacek Lubziński, Security Lead: SIG oznacza special interest group. Tę koncepcję rozpropagował w Piwik PRO Kosto, nasz Architect. Chodzi w niej o zebranie grupy ludzi zainteresowanych tematem, który później będzie miał przełożenie biznesowe. SIG to formacja bardziej oficjalna niż Ferajny – spotkania, które polegają na luźnych dyskusjach na różne tematy. Zasadnicza różnica między nimi jest taka, że wnioski, które pojawią się w ramach SIG-a, są przekuwane na konkretne zadania w firmie.
Brałem udział w trzech SIG-ach: pierwszy dotyczył ClickHouse’a, ale niestety nie funkcjonował długo, drugi to SIG Security, a trzeci, niedawno założony, dotyczy tematu AI. Ten ostatni przyciąga całą masę ludzi i to nie tylko technicznych. W firmie działa jeszcze liczny SIG Scalability, który również ma duży wpływ na działanie organizacji.
Zaangażowanie w tego typu inicjatywy wykracza poza standardowy zakres obowiązków. Co sprawia, że ludzie chcą się w nie włączać? Co Ciebie do nich przyciąga?
JL: Myślę, że przede wszystkim chęć poszerzania wiedzy i dzielenia się nią. To także okazja do spotkania się na żywo i integracji z innymi.
Widać to było szczególnie po Ferajnach organizowanych po pandemii, podczas których mieliśmy rekordową frekwencję. Po zaplanowanych prezentacjach zawsze kontynuujemy rozmowy w kuluarach. Za każdym razem prowadzimy też transmisję, więc można do nas dołączyć online.
Fajne jest też to, że mamy świetną przestrzeń do spotkań. Początkowo dysponowaliśmy jedynie małą salą. Teraz korzystamy z auli i prezentujemy ze sceny, co tworzy niemal konferencyjny klimat.
SIG-i z kolei są bardziej oficjalne. Odbywają się w godzinach pracy, a omawiane tematy wiążą się z tym, co obecnie dzieje się w firmie. Dyskusje są też bardziej merytoryczne, a spotkania mniej nastawione na integrację.
Plusem jest to, że można trochę oderwać się od aktualnych zadań. Spotykamy się co tydzień z osobami o podobnym sposobie myślenia, o podobnych zainteresowaniach. Omawiamy tematy, które czasem samemu trudno ogarnąć, lub problemy, z którymi zmagamy się w codziennej pracy. Czasem analizujemy coś, co zauważamy w produkcie, a czym nie można się zaopiekować w bieżących sprintach. Wspólnie udaje się znaleźć odpowiedzi nieoczywiste nawet dla sztucznej inteligencji (śmiech).
Z założenia SIG funkcjonuje w oparciu o konkretne wytyczne – wyznaczony cel, określone odpowiedzialności, konkretny framework. Czy z Twojej perspektywy takie ramy ułatwiają życie grupy, czy stanowią ograniczenia?
JL: Wydaje mi się, że ułatwiają. SIG ma wyznaczone konkretne cele, są robione notatki ze spotkań. Z góry wiadomo, czego będzie dotyczył, czy będą dyskusje, czy też prace nad konkretnymi tematami. Dzięki temu łatwiej jest się w tym odnaleźć. Takie założenia raczej nie ograniczają, bo SIG-i są określane przez osoby, które je tworzą. Koniec końców te ramy i sposób funkcjonowania zależą od samych osób zaangażowanych.
Pracujesz w Piwik PRO od początku istnienia firmy, czyli od 2013 roku. Przez kilka lat zajmowałeś stanowisko Admina, później DevOpsa. Dlaczego zaangażowałeś się akurat w SIG Security?
JL: Tematy adminowe od zawsze były u nas powiązane z security. Nie funkcjonował żaden osobny zespół, a bezpieczeństwo produktu zależało od naszego rozeznania w temacie. Powoli okazywało się, że niektórzy pracownicy chętnie angażują się w tematy związane z bezpieczeństwem, jak chociażby certyfikacje na poziomie firmy. SIG Security powstał, żeby ich odciążyć, wesprzeć i wzmocnić ich głos na forum organizacji. Chcieliśmy też mieć grono osób, z którymi można porozmawiać na temat bezpieczeństwa – developerów, adminów, osoby pracujące z klientami. Dzięki temu możemy to złożone zagadnienie rozpatrywać z różnych perspektyw.
Zaczęło się od kilku osób zainteresowanych tematyką bezpieczeństwa. Co działo się dalej? Jak funkcjonowaliście jako SIG?
JL: Odpowiedzialność była dość duża, a zaczęło się robić naprawdę poważnie, gdy pojawiły się certyfikaty bezpieczeństwa dotyczące całej organizacji. Wtedy trzeba było zaangażować się na cały etat. Wdrożenie takich certyfikatów jak ISO czy SOC2 na poziomie firmy i skuteczne przechodzenie audytów wymaga czasu i wysiłku. Były to narzędzia, które miały mieć realny wpływ na organizację, a nie tylko na obszar firmowych best practices.
W którym momencie zaczęliście rozważać przekonwertowanie się z grupy zainteresowań w zespół? Czy wiąże się to z jakimś szczególnym wydarzeniem?
JL: Od wykiełkowania pomysłu do powstania zespołu minęły około 2–3 lata.
To była ewolucja. W momencie kiedy powstał zespół Security mieliśmy już porządne podwaliny w tym temacie – certyfikaty, dobre praktyki itd. Dzięki temu łatwiej też było zrekrutować nowe osoby do zespołu. Na kolejnym etapie trzeba było zadbać o utrzymanie tego, co już mieliśmy, a do tego o sprawne funkcjonowanie i budowanie świadomości w firmie.
Co musiało zostać spełnione, żebyście zaczęli funkcjonować jako zespół?
JL: Musieliśmy zebrać ludzi, którzy zdecydują się przejść do teamu na pełen etat. Dana osoba musiała zaakceptować, że nie będzie już developerem czy devopsem, tylko członkiem zespołu Security. Ostatecznie zapadła decyzja o zewnętrznej rekrutacji.
Moja historia wyglądała tak, że przyszedł do mnie Kuba, nasz CPO, i powiedział, że startujemy z zespołem Security. Zapytał, czy chciałbym zostać jego liderem. Nie była to łatwa decyzja, bo niedawno miałem za sobą zmianę roli. Musiałem też zostawić ukochane bazy danych i Kubernetesa oraz programowanie, którego zaczynałem się uczyć. Wiedziałem, że nie będę mógł zajmować się tymi tematami w tym samym stopniu jak wtedy, gdy byłem w roli devopsa.
Na początku było Was tylko dwóch. Z czasem jednak pojawiła się potrzeba, by zespół powiększyć.
JL: Przygotowania do stworzenia zespołu trochę trwały. Zaczęliśmy od zrobienia road mapy – zastanawialiśmy się, czym zespół miałby się zajmować, czy można coś usprawnić i poprawić. Wtedy zdaliśmy sobie sprawę, że nasz zespół trzeba powiększyć. Mieliśmy na oku jedną osobę z firmy, która przyszła na staż do zespołu DevOps. Otwarcie wyrażała zainteresowanie tematem security, z którego zresztą ma doktorat. Potrzebowaliśmy jeszcze osoby z doświadczeniem z innych firm.
Wystartowaliśmy też z ofertą stażu, na który mieliśmy sporo odpowiedzi.
Czy łatwo było znaleźć nowe osoby do zespołu? Czy temat cyberbezpieczeństwa budzi zainteresowanie, czy może uchodzi za niszowy?
JL: Temat bezpieczeństwa jest teraz bardzo popularny, dlatego otrzymaliśmy wiele zgłoszeń do naszego zespołu.
W procesie rekrutacji pojawiali się różni kandydaci – od mniej po tych bardziej technicznych. My szukaliśmy osoby z wiedzą techniczną, która wniosłaby też praktyczne doświadczenie do zespołu. Nie mieliśmy zapotrzebowania na analityka czy pentestera.
Musieliśmy to wszystko wypośrodkować i znaleźć osobę, która pomoże w certyfikacji, będzie z nami programować, zrozumie koncepty zakładane w firmie, best practices czy budowanie świadomości w organizacji.
Szukaliśmy też kogoś, kto dopasuje się do naszego flow. Nasz zespół jest niewielki i na co dzień ściśle ze sobą współpracuje. Istotne było dla nas to, żeby każdy potrafił się ze sobą dogadać.
W nazwie zespołu pozostała cząstka DevOps. Dlaczego? Jak to się wiąże z tym, czym zajmujecie się na co dzień?
JL: Część techniczna naszej pracy opiera się na koncepcji shift left security. Oznacza to, że w całym procesie deploymentu staramy się wskoczyć z security jak najbardziej z lewej strony, czyli na jak najwcześniejszym etapie – jak najbliżej programisty. Staramy się dać mu narzędzia do sprawdzania kodu, podatności i weryfikowania, czy w procesie nie ma jakichś dziur, które mogą stanowić zagrożenie pod kątem bezpieczeństwa. Dodatkowo, gdy połączymy to z automatyzacją albo customowymi rozwiązaniami, które programujemy, wpasowujemy się w devopsowe flow firmy. Narzędzia do analizy podatności trzeba gdzieś zdeployować, utrzymywać, testować i rozwijać. Mając nasz background techniczny, możemy to robić samodzielnie wewnątrz zespołu.
W obecnym, czteroosobowym zespole zajmujemy się security w całym przekroju. Żeby zrozumieć się z developerami, musimy mówić w ich języku. Wiedza techniczna jest wtedy bardzo przydatna.
Obecnie pełnisz rolę Security Leada. Co składa się na Twoje obowiązki?
JL: Na początku przypadło mi dość czasochłonne zadanie przygotowania road mapy zespołu. Teraz moim zadaniem jest pilnowanie jej realizacji i edytowanie kierunku, w którym zmierzamy, jeśli zajdzie taka potrzeba. Do tego dochodzą zwykłe, codzienne zadania, którymi często też dzielimy się wewnątrz zespołu.
Co jeszcze przed Wami? Jakie zadania macie w backlogu?
JL: Ujawnienie tego złamałoby zasady poufności, więc będę mówił ogólnikami (śmiech). Aktualnie skupiamy się na tematach związanych z wewnętrznymi audytami. Mamy już w tym doświadczenie, ale teraz chcemy skupić się na bardziej technicznych aspektach. Dodatkowo, chcemy położyć mocny nacisk na szkolenie części zespołu w testach penetracyjnych.
