Grupy robocze 2023 - Incident Busters 2024
Relacja grup roboczych 2023 - Incident Busters Forum
Grupa I: Współpraca między IT a zespołami Incident Response – jak ją budować i jak powinna wyglądać?
Grupa składała się w przeważającej większości z osób zajmujących się bezpieczeństwem (SOC, IR, bezpieczeństwo). Mniej liczny udział osób z IT skutkował też słabszą prezentacją punktów widzenia tej strony.
W trakcie spotkania poruszono następujące zagadnienia:
- Wypracowanie wspólnych relacji i współpraca podczas realizacji projektów oraz w trakcie reakcji na incydenty: uczestnicy dyskusji zgodzili się, że kluczem do efektywnej współpracy między IT a zespołami Incident Response jest nawiązanie silnych relacji i wspólna praca w czasie projektów oraz przy reakcji na incydenty. Ważne jest również opracowywanie wspólnych wniosków (lesson learned) po każdym incydencie, co pozwoli na lepsze, wzajemne zrozumienie oraz unikanie nieporozumień w przyszłości.
- Budowa dashboardu dla zarządzania i monitorowania: zalecono budowę lub dostarczenie dashboardu, który pozwoliłby na przeglądanie wspólnych, kluczowych wskaźników wydajności (KPI) zarówno przez zarząd, jak i członków zespołów IT oraz Incident Response. Umożliwiłby lepsze zrozumienie, skąd pochodzą wskaźniki oraz w jaki sposób swoimi działaniami wpływają na nie poszczególne osoby lub działy. Ułatwiałby też wspólną analizę wskaźników oraz wspólną pracę nad ich poprawą.
- Transfer wiedzy i celowość współpracy: podkreślono celowość współpracy między zespołami odpowiedzialnymi za reagowanie na incydenty i działami IT. Jej zacieśnieniu służyć będzie wymiana wiedzy na temat bezpieczeństwa. Dzięki temu zrozumienie zagrożeń i ryzyk oraz odpowiednie działania mogą zostać włączone w procesy i procedury IT.
- Wykorzystanie wyników audytów: członkowie grupy zgodzili się, że wyniki audytów powinny być wykorzystywane jako element szerszej współpracy. Przykładowo, wyniki audytów bezpieczeństwa mogą być analizowane wspólnie przez zespoły IT i Incident Response, co pozwoli na lepsze zrozumienie problemów, zacieśnienie współpracy i podejmowanie skuteczniejszych działań naprawczych.
Grupa była prowadzona przez:
Fortinet
Grupa IV: Jak wykorzystać Threat Intelligence w różnych miejscach organizacji
Uczestnicy spotkania zidentyfikowali następujące zespoły i komórki w organizacji będące potencjalnie odbiorcami analiz o zagrożeniach w cyberprzestrzeni oraz współpracujące z zespołem Cyber Threat Intelligence (CTI):
- zespół monitoringu bezpieczeństwa (ang. security operations centre)
- zespół bezpieczeństwa sieciowego (ang. network security)
- zespół architektów IT (ang. enterprise / security architecture)
- zespół analiz powłamaniowych i reagowania na incydenty komputerowe (ang. digital forensics and incident response)
- zespół zarządzający ryzykiem (ang. governance, risk, compliance)
- zespół bezpieczeństwa ofensywnego (ang. redteam, purpleteam)
- zespół zarządzania podatnościami (ang. vulnerability management)
- zespół komunikacji społecznej (ang. public relations)
- zespół inżynierii detekcji (ang. detection engineering)
- zespół proaktywnie polujący na zagrożenia (ang. threat hunting)
- zespół wykrywania oszustw i nadużyć (ang. fraud security)
- zespół ochrony klientów (ang. client protection)
- zespół budujący świadomość zagrożeń (ang. security awareness)
- działy biznesowe
- zarząd organizacji (ang. board)
Następnie dyskutowano o właściwościach produktów CTI dostosowanych do potrzeb poszczególnych odbiorców. Ustalono, że dla kadry zarządzającej bezpieczeństwem organizacji, architektów, działów biznesowych, threat hunterów odpowiednie będę produkty w postaci raportów (ang. written / finished intelligence), a dla zespołów monitorujących stan bezpieczeństwa właściwymi będą produkty techniczne, takie jak strumień danych o zagrożeniach, wskaźniki kompromitacji (ang. indicators of compromise) i/lub reguły detekcji typu YARA czy Sigma. Zwrócono przy tym uwagę na wymagania jakościowe dla produktów technicznych, które powinny być odpowiednio przetworzone, np. znormalizowane, zwalidowane i opisane zgodnie z przyjętą w organizacji taksonomią zagrożeń.
Wskazane zostały również podstawowe różnice między raportem taktycznym, koncentrującym się na bieżących wydarzeniach i pokazującym aktualne zagrożenia, a raportem strategicznym, podsumowującym trendy, identyfikującym anomalie oraz wskazującym możliwe scenariusze wydarzeń w oparciu o analizy informacji.
Grupa była prowadzona przez:
Standard Chartered
Grupa V: Zarządzanie poziomem rotacji pracowników w działach SOC. Jak sobie z tym radzić i czy jest to wyzwanie?
W spotkaniu uczestniczyły zarówno osoby z dużym doświadczeniem w zarządzaniu zespołami SOC, jak również takie które dopiero planują utworzenie tego typu struktur w swoich organizacjach. Wszyscy zgodzili się co do tego, że rotacja pracowników SOC jest realnym problem, z którym mierzy się większość menedżerów z tego obszaru. Pytanie: jak sobie z tym poradzić?
W pierwszej kolejności skupiliśmy się na omówieniu optymalnego modelu pracy SOC – jak powinien wyglądać, co sprawdza się najlepiej z perspektywy satysfakcji pracowników jak i potrzeb biznesowych firmy. Poglądy w tej kwestii były zróżnicowane. Zgodziliśmy się natomiast co do tego, że praca zdalna jest tym, czego z pewnością oczekują dzisiaj pracownicy SOC. Warto zatem rozważyć, czy w swoich organizacjach mamy możliwość wprowadzenia tego typu rozwiązania lub też zwiększenia wymiaru pracy zdalnej, jeśli pozwala na to środowisko biznesowe. Może mieć to bezpośredni wpływ na poziom satysfakcji pracowników, a tym samym na poziom rotacji w zespole. W zależności od firmy i obowiązujących w niej zasad, mogą być przyjęte różne rozwiązania, na przykład model 50/50, czy też 2 dni pracy z biura, reszta z domu, lub odwrotnie. Ważne jednak, aby maksymalnie ograniczyć odstępstwa od ogólnie ustalonych zasad. Wprowadzanie wyjątków od reguły dla części pracowników, powoduje u reszty frustracje wynikające z nierównego traktowania.
Następnie poruszyliśmy kwestię zakresu odpowiedzialności pracowników SOC. Ustaliliśmy, że odpowiedni przydział zadań może wpływać na zmniejszenie poziomu rotacji. Rozbudowanie standardowego zakresu pracy analityka SOC o elementy typu incident response czy threat hunting, może skutkować pozytywnym odbiorem stanowiska i miejsca pracy. Jesteśmy w stanie motywować ludzi poprzez przydział bardziej zaawansowanych zadań kosztem prostych, powtarzalnych aktywności. Takie rozwiązanie dobrze się sprawdza, gdy pomimo potencjalnego braku perspektyw rozwoju na różnych stanowiskach, pracownicy mogą się dłużej rozwijać w ramach pełnionej roli.
Tematem blisko związanym z poprzednim były ścieżki rozwoju w SOC. Jak je budować, jakie stanowiska powinny funkcjonować w poszczególnych działach SOC-ów? Dyskusja pokazała, że w zależności od organizacji struktura SOC jest konstruowana w bardzo zróżnicowany sposób.
Część działów jest przydzielana do linii wsparcia, inne zbudowane są bez wyraźnego podziału liniowego, na dodatek funkcjonują w nich różne role i funkcje. Nie ma jednego, uniwersalnego rozwiązania, ponieważ struktura zespołu SOC jest w dużej mierze dostosowana do środowiska organizacji i struktury działów bezpieczeństwa. Kluczowym jednak aspektem z perspektywy pracowników są w pełni transparentne perspektywy rozwoju, wymagania dla danej roli i kryteria umożliwiające jej zmianę.
Wymieniliśmy się również dobrymi praktykami z zakresu układania grafiku pracy w SOC. Właściwie funkcjonujący grafik mocno wpływa na satysfakcję pracowników. Odpowiednio skonstruowane zmiany oraz elastyczność w ich tworzeniu są pozytywnie odbierane przez członków zespołu i mogą wpływać na ich decyzję o pozostaniu w obecnym miejscu pracy. W trakcie dyskusji ujawniła się duża różnorodność stosowanych przez uczestników spotkania rozwiązań.
Dużym wyzwaniem, związanym z rotacją pracowników, jest rekrutacja nowych członków zespołów SOC. Dla jej właściwego przeprowadzenia dobrze jest zrobić odpowiednie rozeznanie rynku odnośnie każdej z ról, aby lepiej określić nasze oczekiwania wobec kandydatów. Uzgodniliśmy, że warto poświęcić czas na dokładne sprawdzenie benchmarku w aspekcie stażu pracy na danym stanowisku oraz zakresu odpowiedzialności w ramach określonych pozycji. Pozwoli to na bardziej efektywne podejście do procesu rekrutacji i uspójnienie oczekiwań w stosunku do potencjalnych członków zespołu.
Grupa była prowadzona przez:
Aviva
Aviva
Grupa VI: Jakie kompetencje powinni posiadać analitycy SOC?
By móc rozmawiać o kompetencjach analityków SOC, w pierwszej kolejności ustaliliśmy definicję SOC jako Zespołu Bezpieczeństwa Operacyjnego. Bo to właśnie od tej definicji, a w zasadzie od zakresu wykonywanych zadań, będą zależały wymagania, jakie trzeba stawiać przed poszczególnymi członkami zespołu.
Dla uczestników warsztatów SOC to coś więcej niż pierwsza i druga linia działania skupiona na monitoringu bezpieczeństwa. Współczesny Zespół Bezpieczeństwa Operacyjnego realizuje niemal wszystkie funkcje cybersecurity zdefiniowane w modelu NIST Cybersecurity Framework. Współczesny SOC działa na wielu obszarach: monitoringu zdarzeń bezpieczeństwa (Cybersecurity Monitoring), zarządzania cyberincydentami (Incident Response oraz Forensic Analysis), analizy zagrożeń (Cyber Threat Intelligence), czy też identyfikacji podatności (Vulnerablity Monitoring). W szczególnych sytuacjach ma także za zadanie projektować oraz utrzymywać architekturę cyberbezpieczeństwa organizacji (włączając w to ciągłe dopasowywanie polityk bezpieczeństwa do zmieniającego się krajobrazu zagrożeń).
Ta wielość funkcji w kompletnym SOC-u powoduje, że chcąc zachować jakość świadczonych usług bezpieczeństwa, trzeba zgromadzić zespół osób o głębokiej, merytorycznej wiedzy, które będą potrafiły wzajemnie się uzupełniać. Uczestnicy dyskusji zwrócili uwagę na tzw. kompetencje twarde, czyli:
- wiedza z zakresu IT (w szczególności zagadnienia związane z: sieciami komputerowymi, systemami operacyjnymi, aplikacjami, architekturami aplikacji, kryptografią, czy rozwiązaniami chmurowymi),
- rozległa wiedza z zakresu analizy zagrożeń (techniki ataków komputerowych, metody wykrywania i ochrony przed nimi),
- umiejętność czytania ze zrozumieniem instrukcji, logów, raportów, dokumentów technicznych, jak też regulacji lub aktów prawnych.
Do efektywnej pracy w zespole SOC i w całej organizacji niezbędne są też jednak tzw. kompetencje miękkie. Ze względu na fakt, iż cyberbezpieczeństwo to „gra zespołowa”, posiadanie tych umiejętności może być znacznie ważniejsze dla skutecznego działania zespołu. Niezmiernie ważnymi w pracy Zespołu Bezpieczeństwa Operacyjnego są:
- umiejętność komunikacji w zespole i w organizacji,
- umiejętność pracy zespołowej, rozumiana jako wspólna praca nad zadaniami, czy spójne wykonywanie zadań komplementarnych,
- determinacja, w szczególności rozumiana jako dążenie do celu lub rozwiązania problemu,
- umiejętność pracy pod presją, w szczególnosci w sytuacji wystąpienia incydentu lub zagrożenia
- wymiana wiedzy, jako czynnik niezbędny do stałego rozwoju zespołu i wypracowywania najlepszych metod pracy,
- doświadczenie, niezbędne do krytycznej oceny sytuacji.
W jaki sposób pozyskiwać osoby, które mogłyby pracować w SOC spełniając wymienione wymagania? Jest to bardzo trudne, Najlepszym podejściem, jak uznano, jest właściwe kształtowanie pracowników poprzez włączanie osób mniej doświadczonych do pracy z osobami doświadczonymi. Podejście mistrz-uczeń może być korzystne, gdyż w sposób naturalny budowane są w takiej sytuacji zasoby wiedzy, jak również kształtują się kompetencje miękkie. Do tego, by tak się faktycznie zadziało, konieczne jest zrozumienie, że aby zbudować dobry, merytoryczny i kompetentny zespół trzeba dać mu czas i zasoby do rozwoju, w szczególności pozwolić na swobodną pracę w modelu mentoringowym.
Grupa była prowadzona przez:
Grupa VII: Badanie efektywności narzędzi threat intelligence – jak to robić, kiedy i czego oczekiwać?
Spotkanie rozpoczęliśmy od weryfikacji, czym zainteresowani są słuchacze i w jakim stopniu realizowane są usługi CTI w poszczególnych organizacjach. W składzie grupy roboczej reprezentowana była zarówno opcja outsourcingu usług CTI jak i budowania ich od podstaw w firmie.
Dzięki temu możliwym było dwojakie ujęcie tematu:
- w wąskiej postaci jako klasyczna oceny narzędzi, wykorzystywanych przez CTI w trakcie realizowanych zadań;
- w szerszej - jako całościowa ewaluacji efektywności zespołu CTI i jakości dostarczanych produktów.
Weryfikując stanowiska uczestników spotkania wybraliśmy ścieżkę zarządczą CTI. Na wstępie skupiliśmy się na podstawach procesu CTI oraz w jaki sposób skorelowane są one z profilem wymaganych narzędzi. Przedstawiając zarówno fazy cyklu analitycznego, jak i najważniejsze procesy CTI, odwoływaliśmy się do kwestii wskaźników i poziomu efektywności narzędzi.
Fundamentalne znaczenie ma to, że CTI nie może istnieć bez zdefiniowanych celów, produktów i pełnej orientacji na klienta. Dlatego też najważniejsza metodologia oceny wartości CTI to ta, która bezpośrednio porównuje efekty pracy z faktycznym zapotrzebowaniem odbiorcy. Pośrednio wpływa ona na ewaluację wykorzystywanych narzędzi, gdyż, mając świadomość stopnia realizacji zapotrzebowania na informacje, personel CTI jest w stanie oszacować, w jakim stopniu określone narzędzia przyczyniły się do osiągnięcia sukcesu.
Ważne jest, aby rozmowę z naszym wewnętrznym czy zewnętrznym klientem zaczynać od wprowadzenia w świat procesów i działań CTI. Nie wnikając w aspekty techniczne warto przybliżyć istotne zagadnienia i - kluczowe - korzyści wynikające z uruchomienia tego typu działalności w organizacji. Bez zrozumienia roli, możliwości i ograniczeń CTI klienci nie będą w stanie w pełni współpracować w procesie definiowania zapotrzebowania. Jak podkreślali doświadczeni w tej dziedzinie uczestnicy dyskusji, optymalnym rozwiązaniem jest przedstawienie potencjalnym klientom katalogu produktów, którymi już dysponuje CTI wraz z przykładami ich wykorzystania.
Po przejściu od etapu projektowania do etapu dostarczania produktów, badanie ich efektywności może być realizowane w następujących obszarach:
- badanie poziomu zainteresowania raportowaniem odbiorców – wskazano możliwości techniczne (badanie czasu poświęconego na raport, otwarcie raportu, interaktywna analiza raportów, spotkania z odbiorcami),
- specjalizacja w obszarze TI pomaga spełnić potrzeby klienta i podnieść dojrzałość produktów,
- dostosowanie formy i formatu komunikacji do uwarunkowań klienta i charakterystyki narzędzi;
- weryfikacja zasilenia narzędzi,
Osobną kwestią w CTI pozostają posiadane źródła informacji, które do pewnego stopnia mogą być traktowane także jako narzędzia. Tu kluczowa jest weryfikacja ich wykorzystania w dłuższym okresie, a także systematyczna ewaluacja jakości dostarczanych przez nie informacji. Pomocną i powszechnie stosowaną metodologią, jest tzw. „Admirality Code” używana jako standard w społeczności wojskowo–wywiadowczej państw NATO.
Kolejnym działaniem, przed jakim może stanąć zespół CTI, jest kupno gotowego narzędzia. By nie polegać tylko na zewnętrznych opiniach, koniecznym będzie przeprowadzenie własnej ewaluacji tego, w jaki sposób dana technologia może przyczynić się do zwiększenia możliwości wywiadowczych i analitycznych. Aby zrobić to optymalnie, zalecanym jest przygotowanie określonych use-casów rozpatrywanego narzędzia, które umożliwią konkretną ocenę stopnia jego przydatności. Use-casy to sposoby wykorzystania danego narzędzia. Na ich podstawie tworzone są następnie schematy pracy (workflows), które dostawca technologii powinien zaprezentować. Schematy te powinny być szczegółowo wkomponowane w bieżące lub perspektywiczne procesy oraz dostarczane przez CTI produkty. Skąd brać use-casy? Powstają one bezpośrednio na bazie tzw. Wymagań wywiadowczych („Intelligence Requirements”), które zdefiniowane zostały w trakcie rozmów z klientami CTI.
Dodatkowo uczestnicy warsztatów poruszyli kilka kwestii, których zaistnienie może spowodować utratę wiarygodności do CTI:
- realizacja raportowania i komunikacji w sposób nie przynoszący merytorycznej treści,
- wpadnięcie w pułapkę budowy CTI w modelu „horoskopowym”, czyli na zasadzie predykcji, którą zawsze można dopasować do zdarzeń mających miejsce w organizacji,
- brak feedbacku i badania „konsumpcji” produktów CTI,
- dystrybucja produktów w sposób nie pozwalający na skuteczne dotarcie do odbiorcy,
- brak należytej weryfikacji wskaźników IOC, które mogą zostać rozpropagowane w organizacji i zatrzymać procesy biznesowe.
Grupa była prowadzona przez:
GSK
BNP Paribas
Grupa VIII: Po ataku ransomware - rola analizy powłamaniowej jako podstawy do dalszych działań
Początkowo w przypadku incydentów ransomware obserwowaliśmy przede wszystkim naruszenie atrybutu dostępności informacji poprzez ich uszkadzanie (najczęściej szyfrowanie, T1486). Jedną z podstawowych mitygacji na zaszyfrowanie danych przez atakujących (T1486), uszkodzenie lub usunięcie (T1485) są kopie zapasowe (M1053). Wdrożone systemy kopii zapasowych miały również chronić przed koniecznością zapłaty okupów, jednak, jak pokazują badania[1], tylko w 16% przypadków dane były przywracane z backupów. W 80% analizowanych przypadków zapłacono okup, przy czym w ponad 20% spraw zapłacenie okupu nie pomogło w odzyskaniu danych.
Dodatkowo, w ostatnich latach poza atakami ukierunkowanymi na naruszenie atrybutu dostępności obserwujemy również ataki na poufność informacji. Aktualnie w 4 na 5 incydentów ransomware mamy do czynienia z eksfiltracją danych i jest to stały trend, utrzymujący się na tym poziomie od 2021 roku. Pierwsze przypadki eksfiltracji danych przez atakujących obserwowane były w czwartym kwartale 2019 roku. Obecnie ok. 70% ataków ransomware na przedsiębiorstwa zatrudniające ponad 10 tys. pracowników ogranicza się jedynie do eksfiltracji danych, bez ich uprzedniego uszkadzania lub usuwania[2].
Analiza dotycząca eksfiltracji danych wykonywana możliwie jak najwcześniej zwiększa skuteczność podejmowanych działań w zakresie ustalania miejsc, do których dane mogły być wyprowadzone i ograniczania wycieków. Analiza taka powinna ustalić:
- czy i do jakich danych atakujący uzyskał dostęp,
- kiedy i gdzie dane zostały wykradzione,
aby następnie podjąć decyzję:
- czy i jakie instrumenty powinny i mogą zostać wykorzystane, aby ograniczyć skutki wycieku.
W zespołach reagujących na incydent i wykonujących analizę powłamaniową występuje powszechny brak tego rodzaju dojrzałości, która pozwoliłaby możliwie sprawnie ograniczać skutki incydentu, w tym wycieku (eksfiltracji danych). Analizujący atak skupiają się przede wszystkim na ustaleniu sposobu wejścia przez atakującego do infrastruktury (ang. Initial Access, TA0001) zamiast na tym, co atakujący wykradł z organizacji (ang. Exfiltration, TA0010). W związku z tym, działania ograniczające wycieki często mają niską skuteczność, ponieważ np.:
- błędnie oceniono, że atakujący nie wykradł danych lub wykradł dane nieistotne, a dopiero w momencie ich ujawnienia okazuje się, że są to np. dane osobowe lub tajemnice przedsiębiorstwa, które nie powinny być ujawniane;
- nie w porę dokonano ustaleń, w związku z czym dane znajdują się już w wielu miejscach i trudno taki wyciek ograniczyć.
Co więcej, problemem jest brak materiału źródłowego pozwalającego na dokonanie szczegółowej analizy i trudności w jego pozyskiwaniu. Potrzebne są zarówno dane dotyczące sieci (mogą one w ograniczonym zakresie zostać pozyskane od dostawcy usług internetowych bez naruszania tajemnicy telekomunikacyjnej i bez konieczności zwalniania usługodawcy z tej tajemnicy), jak i dane z systemów, z których dane mogły być wykradane (te bywają uszkodzone i niekompletne). Nierzadko potrzebne jest również ustalenie, czy dane zostały wytransferowane dalej niż tylko do pierwszej destynacji. Czasami atakujący przedstawiają „dowód życia” wykradzionych danych – przykładowe pliki lub listy plików, które wykradli. Znacznie trudniej jest uzyskać potwierdzenie, że żadne dane nie zostały wykradzione.
W przypadkach, w których możliwe było ustalenie kiedy, gdzie i jakie dane zostały eksfiltrowane, pozostaje problem ograniczenia ich dalszej proliferacji. Nie dysponujemy uniwersalnym instrumentem prawnym (ang. toolbox), który pozwalałby na ograniczenie możliwości publikacji danych z wycieków, a wśród dostępnych w Polsce można wymienić:
- ustawę antyterrorystyczną,
- ustawę o zwalczaniu nieuczciwej konkurencji,
- wnioski o zabezpieczenie.
Dodatkowo, możliwe jest wysyłanie zawiadomień typu Abuse Report i Cease and Desist, np. z żądaniem zdjęcia treści i uzyskiwanie nakazów typu Website Blocking w innych jurysdykcjach, w których jest to możliwe i uzasadnione (ang. Forum Shopping).
W Polsce, w przypadkach skutecznego ustalenia infrastruktury wykorzystywanej przez atakujących do publikowania danych w jurysdykcjach, z którymi współpraca jest trudna (np. Rosja), zwracano się m.in. do CERT Polska z prośbą o umieszczenie ustalonych domen na Liście ostrzeżeń przez niebezpiecznymi stronami internetowymi. W ocenie jednak CERT Polska dodanie do listy ostrzeżeń domeny wykorzystywanej do proliferacji eksfiltrowanych danych nie ograniczy w żaden sposób skutków wycieku.
W związku z tym, że inne niż płacenie okupów sposoby ograniczania wycieków są nadal mało popularne, ofiary decydują się płacić atakującym okupy w zamian za niepublikowanie wykradzionych danych. W 2022 roku prawie 80% okupów zapłacono z pieniędzy ubezpieczycieli, m.in. z cyberpolis.[3]
Atakujący najczęściej deklarują, że po uiszczeniu żądanego okupu wykradzione dane są usuwane i nie są udostępniane dalej. Można również uzyskać potwierdzenie usunięcia wykradzionych danych – atakujący w ponad 60% przypadków nie przekazują żadnego dowodu, a w pozostałych np. log z usunięcia, materiał video, zdjęcia ekranu lub usuwają dane na żywo, udostępniając ekran ofierze. Pozostaje pytanie o wartość dowodową takich materiałów, np. w postępowaniu o naruszenia RODO.
Podsumowując, wobec coraz większej popularności ataków ransomware z elementem eksfiltracji danych, również w Polsce, konieczne jest wypracowanie standardów postępowania w tego rodzaju sprawach obejmujących obszary techniczne, zgodności (ang. Compliance) i zarządcze.
[1] Veeam Trends Report 2023
[2] Coveware, raporty kwartalne
[3] Veeam Trends Report 2023
Grupa była prowadzona przez:
