Szymon Warda: Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka na Patoarchitekci.io lub tak gdzieś tu na dole w opisie, gdzie słuchacie, znajdziecie link do materiałów na stronie.

Szymon Warda: Ogarniecie. Wierzymy w Was. Dobrze Łukaszu, to co dzisiaj na tapecie?

Łukasz Kałużny: Dobra, bierzemy na tapet odczarowywanie standardów bezpieczeństwa. Bo teraz patrząc się jak prowadzę Architekturę 101, to jest zawsze taki mindfuck u uczestników, skąd biorą się wymagania bezpieczeństwa? Jak to jest sprawdzane? Skąd tego tyle? Jak to wygląda? I rynkowo, to jest moje takie spostrzeganie, że jeżeli popatrzymy na ludzi od architektury, wytwarzania softu, znaczną część barykady, że oni patrzą jak na jakieś wydziwiajstwa, na to co robi druga strona. A druga strona myśli bardzo szablonowo, jeżeli popatrzymy, albo powinna…

Szymon Warda: Nie, druga strona patrzy na developerów jak na dzieci, które dostały właśnie zabawki i biegają w samych majtkach dookoła czegoś. W sensie co tam się wydarzyło?

Łukasz Kałużny: Tak, co tam się wydarzyło? I dzisiaj chciałbym, żebyśmy zajęli się takim powiedzeniem, czym są wyświechtane słowa, ale standardy i benchmarki bezpieczeństwa.

Szymon Warda: Czyli powiedzenie tak naprawdę skąd bezpieczniki biorą wszystkie rzeczy, które nakładają, narzucają lub wymagają.

Łukasz Kałużny: Tak. I słuchaj, jak teraz popatrzymy, to te standardy, można byłoby je w niektórych przypadkach określić, że to są przepisy kucharskie dla bezpieczników albo gotowe checklisty. Bo można byłoby wyróżnić z takich gotowych zestawów, z jednej strony benchmarki, czyli to są po prostu konkretne ustawienia, konfiguracje. Czyli na przykład w Kubernetesie ma być, załóżmy, wymuszone i ustawione, żeby POD nie nie był uruchamiany jako privilege, albo żeby miał konto użytkownika powyżej tysiąca albo dziesięciu tysięcy. Z drugiej strony też są frameworki, czyli struktury gdzieś, struktury, standardy, jak to poukładać w organizacji albo jak w danym obszarze powinniśmy czegoś wymagać.

Szymon Warda: Dokładnie, patrzymy tak naprawdę na to z dwóch stron. Jak to ułożyć procesowo i jak to ułożyć też technicznie. Ale o tym to będzie za chwilę. Dobra, tak naprawdę to pogadajmy sobie w ogóle od czego? Bo Ty ruszyłeś fajną opcję właśnie, że Ty mówisz o tym, że to są przepisy. Dużo bardziej skłaniałbym się ku temu, że to są checklisty. Czemu? Bo to jest zbiór rzeczy, przez które trzeba przejść, żeby niczego nie zapomnieć. A właśnie zostawianie takich dziur w bezpieczeństwie jest najgorsze.

Łukasz Kałużny: I wiesz, jak sobie teraz popatrzymy, to też jest tego plusem, że właśnie nie wymyślamy koła na nowo. Idziemy gotowcem. To jest w ogóle w tym. Oczywiście potem trzeba to dostosować do realiów, ale…

Szymon Warda: Tak, chociaż nie zawsze mamy tą elastyczność. Niektóre standardy po prostu narzucają. Na przykład ISO, o którym będziemy mówili, jest to, że po prostu pewne rzeczy mają być i kropka.

Łukasz Kałużny: Czy wiesz co, ale i wtedy pójdziemy sobie też po co to robimy? Po co są te standardy? Zebrane, żeby nie wymyślać koła na nowo. Druga sprawa, nazwijmy to, że możemy łatwo udzielić odpowiedzi. To brzmi głupio, ale możemy odpowiedzieć, czy jesteśmy bezpieczni, że spełniamy jakiś standard. To nie oznacza, że jesteśmy bezpieczni, ale mamy podkładkę trochę prawną, jeżeli tam popatrzymy, że postępowaliśmy w zgodzie z jakimiś standardami i się ich trzymaliśmy.

Szymon Warda: To nawet nie jest tak. Ja brałem udział w pisaniu wielu ofert i odpowiedziach na RFI i tam często ma się taką opcję: albo jest jeden checkbox “tak, mam ISO”, albo ma się 50-100 pytań o każdy poszczególny element. I po prostu ISO ma się po to, żeby ułatwić cały proces, bo to nie ma większego sensu.

Łukasz Kałużny: Tak, od strony i trzeba też rozdzielić, że ISO te jakościowe, data privacy, które mamy, to jest o powiedzeniu sobie, w jaki sposób ten information security management, to jest rzecz mocno, mocno procesowa, która jest inaczej. A inaczej będą te rzeczy, o których sobie zaraz powiemy.

Szymon Warda: Dokładnie. Dobrze, to w takim razie powiedzieliśmy sobie tak naprawdę, po co robimy. To teraz powiedzmy sobie w ogóle, o jakich będziemy obszarach mówili i o jakich standardach.

Łukasz Kałużny: Dobra, jeżeli teraz tam pójdziemy na wszystkie standardy, to można narzucić sobie cztery źródła, które coś nam narzucają. Czyli z jednej strony pomagają, a z drugiej utrudniają, bo ja bym wyróżnił, podzieliłbym to w ten sposób. Czyli ułatwiają, to będą tak zwane CIS. I to jest organizacja non-profit, która gdzieś tam, jak to każdy non-profit, skupia i produkuje. I oni wydają dwie rzeczy: CIS Control, do którego sobie zaraz podejdziemy oraz CIS Benchmark, czyli jak mamy to skatalogować. Z drugiej strony jest NIST, czyli National Institute of Standards and Technology, czyli amerykańska agencja rządowa tworząca różne standardy, które przyjęło się, że z nich sorsujemy. Oraz te ISO, które wspomnieliśmy, gdzie ono jest bardziej po tej stronie proceduralnej. Potem z drugiej strony mamy jeszcze MITRE i OWA SP, 2 takie też frameworki, podejścia, w zależności jak je określimy. I potem z drugiej strony te przeszkadzające to są już rzeczy prawne, które są narzucane, lokalne…

Szymon Warda: Łukasz, prokonsumenckie.

Łukasz Kałużny: Prokonsumenckie. W zależności w jakim jesteśmy kraju, są przeszkadzające albo rozsądnie używane, bo to jest kontekst. Na przykład u nas w kraju prawnicy z urzędnikami za bardzo doszli do głosu i powstały takie patologie jak RODO, to co się dzieje wokół AI Actu, czyli to są te wymogi, które musimy spełnić. Czy jakieś typowe branżówki, gdzie powiedziałbym, że płatności kartą, sławetny PCI DSS, czy pójdziemy, będą w niektórych te standardy medyczne, anglosaskie, które mamy jak HiPA.

Szymon Warda: Dobra, to przejdźmy po kolei. Zacznijmy od ciekawego, bo NISTa właśnie, czyli National Institute of Standards and Technology. Tu jedna ciekawostka, bo to często ludzie mogą znać też z bazy CVE. I tu element polityczny, bo nie wiem czy doszło do Ciebie, bardzo mocno obcięli im finansowanie.

Łukasz Kałużny: Raczej na samą CVE, żeby nie było.

Szymon Warda: Na samą CVE, potem inna agencja to przejęła i tak dalej, ale dzieją się rzeczy dość ciekawe.

Łukasz Kałużny: Dobra, ale to sobie zostawmy. I tam są trzy takie frameworki, zestawy. Jest NIST Cybersecurity Framework, czyli właśnie jak to poukładać. I potem są dwa zestawy. Są właśnie dwa takie katalogi kontrolek, czyli jak coś mamy zrobić, powinniśmy zrobić. Jest to lista 853. W jaki sposób, tam określane, to można powiedzieć, że w jaki sposób technicznie powinno być, zapewnić poufność, integralność, dostępność. To w dużym skrócie, o tak, nie wchodząc teraz już w detale tego. I 800-171 to będzie tam kontrolowanie informacji niejawnej, o tak można to w skrócie określić. I tutaj z tego wszystkiego najbardziej będzie nas interesował ten NIST Cybersecurity Framework, który właśnie pokazuje jak to można ułożyć.

Szymon Warda: Dobra, idziemy sobie dalej. CIS, Center of Internet Security, czyli taki trochę non-profit. I tam mamy co? Mamy CIS Controls, czyli 18 priorytetowych działań w trzech grupach. Pogrupowane jeżeli chodzi o poziomy dojrzałości, co było w poprzednim odcinku i co będziemy jeszcze widzieli w tym odcinku, bo nie wszystko na raz i na spokojnie. I mamy też to chyba, co jest bardziej słyszane, CIS Benchmark, czyli 140 przewodników konfiguracji dla konkretnych systemów, co i jak zrobić. O tym właśnie mówiliśmy odnośnie Kubernetesa między innymi.

Łukasz Kałużny: Tak, Kubernetesa, jak wziąć Red Hata, Azure’a, AWS-a, Google’a czy inną usługę, jak wziąć i do niej podejść.

Szymon Warda: Dobra, zaraz wyjaśnimy, bo o to, żeby to wybrzmiało konkretnie, bo używamy słów kontrolki, używamy słów benchmarki. Różnice?

Łukasz Kałużny: Kontroler, mówią raczej jak popatrzymy dokument, to co robić? Czyli zaadresować jakiś obszar. Czyli że na przykład ma być izolacja sieciowa, o tak, weźmy, to taki najczęściej, bo to strona, bezpieczeństwo, to zaraz padają sieci bardzo blisko. Czyli że workload ma być wyizolowany sieciowo przykładowo. Z drugiej strony mamy benchmarki, czyli on już powie, że żeby zabezpieczyć, wyizolować sieciowo, użyj na Kubernetesie Network Policies. Czyli on mówi nam, benchmark już bardziej detalicznie nam wskazuje co i jak. Jak pójdziemy dalej, to taką rzeczą, która gdzieś mocno zdobyła popularność w ostatnich latach i też jest próba protetyzacji jej przez te wszystkie automatyczne softy, też w cloudach, to jest MITRE Attack and Control. I najważniejszą częścią jest właśnie Matrix for Enterprise, który pokazuje ileś obszarów, które trzeba właśnie zabezpieczyć, monitorować. I w zależności od tego, w jakim obszarze technologicznym pracujemy, są rzeczy dla nas istotne bądź nie. I tutaj jest właśnie powiedziane, że mamy taktyki, czyli dlaczego atakujący to robi? Czyli z jednej strony to może być jakiś rekonesans, inicjalny dostęp, egzekucja czy tak zwany persistence, czyli zachowanie na przykład tego wejścia backdoora, czy z innej strony privilege escalation, czyli zdobycie, podbicie się do wyższych uprawnień. I potem techniki, czyli tam to jest już szczegółowo, do każdej taktyki mamy techniki jak coś zrobić. I to dwojako, z jednej strony na przykład softy cloudowe gdzieś tam zaczynają to pokazywać, jak mapują i zabezpieczają. Z drugiej strony dla nas to jest wskazówka, jak po kolei można byłoby w teorii analizować rozwiązanie, na którym jesteśmy, żeby je zabezpieczyć. Albo że na przykład w tym wypadku w ogóle takie ryzyko nie istnieje i nie powinniśmy się tym interesować.

Szymon Warda: Tak, to jest fajne właśnie w MITRE, to przejście przez, nie będziemy przechodzili, właśnie przez to, dlaczego atakujący to robi. Bo często widzimy te ataki potencjalnie jako “o, zabiorą nam dane”. A ta seria, czemu się robi coś, o czym wspomniałeś, czyli utrzymanie dostępu i tak dalej, i tak dalej, jest dość szerokie i nie powinniśmy patrzeć tak bardzo, bardzo wąsko na to, co się może wydarzyć i po co ktoś coś w ogóle robi. Dobra, lećmy dalej. Tym razem z naszego trochę bardziej ogródka, STRIDE, czyli od MS-u.

Łukasz Kałużny: Tak, ale to jest stary, też 1999 rok. I założenie, to jest też trochę jak MITRE, to jest modelowanie zagrożeń ryzyka. I to STRIDE jest akronimem od Spoofing Tampering, Repudiation, Information Disclosure, Denial of service, Elevation of privilege. Czyli to jest usystematyzowanie, w jaki sposób myśleć, co może pójść nie tak już na etapie projektowania. Czyli to jest modelowanie potencjalnych zagrożeń.

Szymon Warda: Dobra, to idziemy dalej. PCI DSS.

Łukasz Kałużny: DSS, czyli branżówka, taka typowa branżówka. I tutaj, jeżeli teraz popatrzymy, to jeżeli obsługujemy bezpośrednio, przetwarzamy dane z kart płatniczych, to mamy ileś takich głównych wymagań na temat zmiany haseł, aktualizacji, kontroli dostępu, monitoringu, zabezpieczeń, czyli pokrycia wszystkich takich obszarów. I on jest trochę podobny do CIS-a, CIS Controls. Czyli mówimy, że musimy, czy tam do ISO, w zależności jak na nią patrzymy, że musimy jakoś coś zaadresować. I tam są oczywiście poziomy, które mówią w zależności od poziomu ilości transakcji, procesowanych kwot, musimy spełnić coraz bardziej rygorystyczne wymagania.

Szymon Warda: Dobra, to teraz wchodzimy trochę w model, który będzie interesował chyba większość naszych słuchaczy, czyli schematy cloudowe. I czemu, jak, po co i dlaczego? To zacznijmy może od tego w ogóle czemu to w ogóle weszło? Weszło dlatego, że mamy trochę inne środowisko, w którym operujemy. Mamy inną dynamiczność, mamy inną skalę i mamy inne możliwości automatyzacji. Wiele możemy ogarnąć z pudełka, wiele możemy ogarnąć korzystając z całkiem fajnych rzeczy.

Łukasz Kałużny: Wiesz co, ja bym powiedział tak, że to jest trochę zaadresowanie, że vendor, żeby się nie skrzywdzić, stworzył własne standardy i żeby powiedzieć “słuchajcie, tak to bezpiecznie skonfigurować, to jest nasza rekomendacja”.

Szymon Warda: Wydaje mi się też, żeby nie było wtopy, że użyliśmy jakiejś chmury i mieliśmy wyciek, bo potem zawsze nagłówki będą takie, że ktoś, u kogoś coś wyciekło i zły PR mówiąc bardzo prosto.

Łukasz Kałużny: Jak to było? S3-a to najpopularniejsza usługa do wycieków danych.

Szymon Warda: Przecież pamiętam taką sytuację, jak była właśnie, jak sytuacja [niesłyszalne 00:14:34] była domyślnie publiczna. Ile backupów wyciekało przez S3 i potem w końcu AWS to zmienił mimo wszystko.

Łukasz Kałużny: Tak, dokładnie. Ale jak popatrzymy i tam jest… Takie są dwa elementy. Trzeba powiedzieć, który jest najgorszy do zaakceptowania przez wszystkich, to jest ten Shared Responsibility Model, który można porównać, że dostawca chmury jest właścicielem budynku, bloku i zabezpiecza tylko takie podstawowe do niego wejście, a Ty musisz zamknąć drzwi. Możesz je zostawić otwarte, możesz je zamknąć, to tak można powiedzieć.

Szymon Warda: Zgodził bym się.

Łukasz Kałużny: Nie możesz…

Szymon Warda: Wydaje mi się, że to się przesuwa, że coraz częściej ten właściciel budynku mówi “ej, pamiętaj, żeby te drzwi zamknąć”. Coraz więcej jest na przykład na portalu Azure’owym ostrzeżeń, domyślnych konfiguracji jest coraz więcej. To już nie jest takie, że rób co chcesz, tylko że “zalecamy Ci i nalegalibyśmy, żebyś jednak zrobił to w pewien sposób”.

Łukasz Kałużny: Tak, jak tam popatrzymy, AWS ma swoje, Microsoft ma swoje, Google ma swoje. I ja podszedłbym do Microsoftowego, jako że jest z naszej dziedziny na co dzień używany, o tak, tutaj nie ma co się oszukiwać, bo też go wykorzystujemy. Tam była taka duża zmiana dwa lata temu albo trzy, Microsoft go przebrandowił z Azure Security Benchmark na Microsoft Security Benchmark. I oni mają takich dwanaście domen kontroli. I tutaj też Microsoft był leniwy i chciał być leniwy i pomógł też klientom być leniwym, to jest istotne do powiedzenia, bo również mapuje domeny właśnie CIS Control, PCI DSS-a, pokazuje nam zamapowanie. I skupia się, tak jak można zobaczyć na rysunku, który dołączymy, że oni się skupiają na tej części wokół Azure Technical, wyciągając to z PCI Controls, NIST Controls i CIS Controls. Czyli żeby spróbować móc się zamapować na inne kontrolki. I te domeny lecą tam od Network Security, Identity Management, czy lecąc pod DevOps Security i Governance Strategy. Czyli mamy te 12 obszarów, które mają ileś pytań, które są zamapowane. Albo raczej obszarów, które trzeba zmapować i potem pomagają to zrobić.

Szymon Warda: Ja bym nie powiedział, że to jest lenistwo. To jest bardzo prosta strategia Microsoftu, gdzie “zróbcie nasze, to wtedy będziecie zgodni z innymi”.

Łukasz Kałużny: Tak, przy czym ta zgodność jest, czasami w różny sposób można ją odczytywać, o tak. Albo to też Wam, słuchajcie, będę uczciwie mówił jakie mamy czasami rozmowy z klientami, niektóre punkty są typowo marketingowe, żeby je tylko wypełnić, albo…

Szymon Warda: O, tak samo jak inne frameworki i benchmarki, które każdy publikuje.

Łukasz Kałużny: Tak, tylko wiesz, trochę bardziej CIS Controls nie jest na przykład nad wyrost. A jak pójdziesz, Microsoft na przykład uparł się na tą domenę, którą, przepraszam, nienawidzę - DevOps Security i próbuję do, znajdziesz do Azure Storage’u punkt DevOps Security, który nie ma totalnie sensu w tamtym miejscu, jeżeli popatrzymy, bo nie masz custom kodu i innych rzeczy.

Szymon Warda: Tak, ale jedna rzecz jest bardzo ważna odnośnie właśnie Microsoft Security Benchmarku i tych wszystkich chmurowych. Tam coraz częściej można wiele rzeczy wdrożyć za pomocą automatycznych polityk, co właśnie jest bardzo, bardzo ważne i możemy w prosty sposób uzyskać zgodność.

Łukasz Kałużny: Wstęp. Wiesz co? Powiedziałbym tak, wstępną zgodność, to będzie uczciwe.

Szymon Warda: Oczywiście, że nie pełną, ale w sensie niewiele robimy, dużo zyskujemy na starcie. Później swoje musimy zrobić, bo i tak to, co podkreślaliśmy już wcześniej, to jest to, że jest część techniczna i jest też część procesowa i nie wolno o żadnej z nich zapomnieć.

Łukasz Kałużny: Tak. I wiesz co, przeszedłbym teraz znowu do modeli dojrzałości.

Szymon Warda: Jak najbardziej tak.

Łukasz Kałużny: Wiecie co, jest, czyli w jaki sposób, jak wszystko chcielibyśmy zmierzyć, w jaki sposób to robimy, jaką mamy dojrzałość. I tutaj słuchajcie jedna rzecz, o której bym powiedział, kombajn, z którego bierzemy przykład, to jest Cybersecurity Capability Maturity Model. Jest kobyła, do której nawet nie dotykajcie, bo jest potężna. Ona pokazuje bardzo dużo podejść. Ponieważ powstała też w Stanach, zainicjowana przez departament tamtejszej, Departament Energii, Department of Energy, żeby zaadresować firmy z sektora wytwarzania energii, energetycznego. I tam też znajdziemy bezpieczeństwo fizyczne, część taką typowo przemysłową, więc nie ma sensu aż tak zaglądać. Ale pokazuje, jak bardzo może być to szeroki temat, bezpieczeństwo. Przy czym dobrą rzeczą są tam poziomy dojrzałości. Jak z każdej rzeczy warto coś podpatrzeć. I oni wyróżniają cztery poziomy dojrzałości, które mówią, idą sobie tam od zera do trójki. I zero, że czegoś nie robimy. Pierwszy poziom dojrzałości, to są takie podstawowe praktyki. Coś robimy, nie zawsze wiemy co do końca, czyli robimy ad hoc. Dwójka, drugi poziom, to jest zaczynamy to, mamy to udokumentowane, że to robimy. Czyli mamy proces, wiemy co robimy. Trójka, ten najwyższy poziom, jest to audytowalne, są na to zasoby, jest to zaplanowane, sprawdzane, wykonywane, czyli jest taki najwyższy poziom. I to dobrze pokazuje właśnie takie stopnie dojrzałości i że nie w każdym miejscu powinniśmy wchodzić na taki full blown rozwiązanie. Ale też te udokumentowane często, zauważyłem po rozmowach, że dla wszystkich oznacza od razu nie wiadomo jak wielkie dokumenty, rzeczy, zamiast kawałka naprawdę prostego dokumentu, procesu. I gdzieś na przykład tabelki, że wykonaliśmy przegląd na przykład i wyniki tego przeglądu, że było zrealizowane.

Szymon Warda: Tak, ewentualnie że jak coś się dzieje, do kogo zadzwonić. To jest fajne, że właśnie na tym poziomie drugim mamy już to na tyle udokumentowane, jest to na tyle uprocesowione, że można dużo łatwiej wdrażać nowych ludzi, nawet często mniej doświadczonych i po prostu mamy procesy wokół tego wszystkiego.

Łukasz Kałużny: Tak, to już trójka…

Szymon Warda: Agencja się nauczyła.

Łukasz Kałużny: Tak. W trójce, trzeba dodać, że na przykład mamy to powiązane już z ryzykiem, z zarządzaniem ryzyka, co jest już dla wielu bardzo problematyczną częścią.

Szymon Warda: Tak, to nie istnieje w jednym dziale, tylko już to istnieje na całą organizację tak naprawdę, to jest ta różnica.

Łukasz Kałużny: Dobra i ostatnią częścią na dzisiaj to będą, rzecz, która jest bardzo niepojęta, że trzeba rozdzielić w tym cyberbezpieczeństwie bezpieczeństwo, jak to tam sobie nazwiemy, rozdzielić dwie rzeczy. Czyli takie bezpieczeństwo papierowe, proceduralne od technicznego. Bo to jest też bardzo duże niezrozumienie w tym, w mojej opinii, w naszej części, w naszym światku, że bardzo nie rozumiemy, że mamy jedną rzecz, która jest istotna, czyli proceduralna, czyli co zrobić, żeby się nie skrzywdzić. Tak jak powiedziałeś, czyli checklisty i inne rzeczy, żeby tego developera w majtkach z zabawką złapać szybciej. Porównajmy to do ten, porównałbym to do bramki przy schodach, jak ktoś ma małe dziecko, żeby nie wlazło na schody.

Szymon Warda: Ja bym tutaj nie poszedł do developera, bo to często też występuje po prostu na całą organizację. Bo tu mówimy o wszystkich rzeczach, które są odnośnie wyciągania haseł, dostępu, tu już działamy na cały biznes, wciągamy dowolnego pracownika, cokolwiek by on nie robił. A że developer też czasami idzie na szkolenie z wykrywania podejrzanych maili i się nudzi, bo myśli, że wszystko wie…

Łukasz Kałużny: To klasyczny phishing.

Szymon Warda: Tak. To jest, o ile to jest chyba najbardziej widoczne, to jest też super ważne, bo jak widzimy to masa wycieków właśnie wynika z tego, że ktoś coś wysłał, jakiegoś maila i dostał dane, tudzież przelewy i inne rzeczy. W dobie AI-a oczywiście to będzie mega ciekawe co się będzie działo.

Łukasz Kałużny: Tak, gdzie wrzucił, czy w tym, czy utrudniono mu życie i wystawił sobie coś z chmury przez na przykład konta storage’owe czy VM-kę po prostu.

Szymon Warda: Tak, żeby mógł pracować z domu.

Łukasz Kałużny: Tak. I z drugiej strony mamy tą część technologiczną, gdzie faktycznie mamy gdzieś narzędzia, systemy, które tego chronią, monitorują i chronią. I to jest już ta część. Plus tego sposób, w jaki to robimy, jeżeli popatrzymy na to.

Szymon Warda: Tak i one często też patrzą właśnie bardziej na te rzeczy, które wytwarzamy, czyli tam powinny być wirtualki i tak dalej. Ale mimo tego też patrzą właśnie, jak ochronić elementy, jeżeli chodzi właśnie o te rzeczy proceduralne, czyli skanują maile i tak dalej. Dzięki temu mamy zaznaczone co jest spamem, co nie jest spamem.

Łukasz Kałużny: Tak, czyli pójdziemy sobie na LDLP, czy z drugiej strony, jak popatrzymy na chmurę, to te polityki, które wymuszą nam tą konfigurację, czy jakieś wykrywanie rzeczy na firewallach proxy.

Szymon Warda: Dobra, to trochę zbierzmy to w jedną kupę. To od czego w ogóle zacząć? Małe firmy? NIST?

Łukasz Kałużny: Znaczy…

Szymon Warda: Tak naprawdę CIS Controls.

Łukasz Kałużny: CIS i to jest też… NIST wystarczy. Tak jakbym miał być szczery, to można byłoby zacząć od NIST-a, CIS Controls, to w zależności jak idziemy. Potem jak pójdziemy dalej, to można już iść dalej w te frameworki i inne rzeczy, takie jak sławetne ISO, które powiedzieliśmy, bo to jest istotne. A jak jesteś w jakiejś chmurze to security benchmarki od danego dostawcy Cię witają.

Szymon Warda: Tak, nawet te automatyczne, które możemy za pomocą polityk, to warto zrobić jako to absolutne minimum.

Łukasz Kałużny: Tak. I z drugiej strony, jak mówimy tam o konkretnych technologiach, których używasz, to warto zobaczyć, czy nie ma dla nich CIS Benchmarka, bo może jest gotowiec, który pomoże.

Szymon Warda: Tak. Dobra, to jeszcze tak, żeby trochę wylać kubeł zimnej wody. Pamiętajmy, że to są narzędzia, nie są to cele. Ja to bardzo często widuję w kontekście ISO, bo jest najbardziej takie sławetne…

Łukasz Kałużny: Zostałeś tym, brzydko mówiąc…

Szymon Warda: Przeszedłem przez ścieżkę zdrowia.

Łukasz Kałużny: Dorwało Cię to któregoś razu.

Szymon Warda: Tak, bo ISO jako takie to nie jest złe, to pomaga naprawdę uporządkować i sprawdzić, czy firmy mają wszystko, mają wszystko ułożone. To jest trochę jak zdawanie certyfikatów. Nie celem jest danie certyfikatu, ale ułożenie tej wiedzy po drodze. Więc to samo jest z tymi frameworkami. Możemy ponaciągać jak gumka od majtek. Fakt, że mamy ISO, a okaże się, że tak naprawdę gumka puściła i majtki nam zleciały. Tak że…

Łukasz Kałużny: Raczej trzeba znaleźć balans, o tak, to jest taka rzecz trudna. Trzeba znaleźć balans po prostu w tym, w używaniu tego. I to się wyrabia po prostu w zależności od kontekstu. Na przykład nie będzie wewnętrznego systemu, nie można go traktować jak wystawionego do internetu, jeżeli nie jest wystawione do internetu i trzyma…

Szymon Warda: Tak. Ostatnio często właśnie widujemy w kontekście tego, że wszystkie systemy nagle muszą mieć takie same wymagania i to po prostu nie zadziała tak dobrze. Za dużo roboty. To też nie może być zbyt duże obciążenie.

Łukasz Kałużny: Tak i trzeba chyba na koniec, ja bym to podsumował, że te standardy nie są sztuką dla sztuki i nie powinny być tak traktowane, że musimy być koniecznie w stu procentach zgodni, tylko to mają być praktyczne narzędzia, które powinniśmy dopasować do naszego kontekstu.

Szymon Warda: Ja bym jeszcze jedną rzecz dorzucił, bardzo ważną, szczególnie dla osób, które decydują się, co wdrażać albo z czym być zgodnym. To trzeba wdrażać wszystkie standardy, szczególnie jeżeli chodzi o poziomy dojrzałości, zgodnie z tym, jak realnie nasza organizacja działa, a nie ambicjonalnie jak byśmy chcieli, żeby było. Bo przeskoczenie z 0 na 3 nie uda się po prostu, trzeba iść etapami.

Łukasz Kałużny: Tak. A ludzie nie będą chcieli tego robić, jeżeli zostaną tak wrzuceni.

Szymon Warda: Dokładnie. Dobra, tyle.

Łukasz Kałużny: Kończymy. Na razie.

Szymon Warda: Hej.