TLP:CLEAR

Opis zespołu CSIRT SprintTech (ST-SOC)

Dokument opracowano według struktury RFC 2350 / BCP 21 „Expectations for Computer Security Incident Response”. 
Dokument określa publiczny profil zespołu, jego społeczność, mandat, zasady współpracy, dostępne usługi oraz sposób zgłaszania incydentów i podatności.

1. Informacje o dokumencie
1.1 Data ostatniej aktualizacji
Wersja: 3.1
Data publikacji i ostatniej aktualizacji: 7 sierpnia 2026 r.
Klasyfikacja udostępniania: TLP:CLEAR.

1.2 Dystrybucja powiadomień o zmianach
ST-SOC nie prowadzi publicznej listy dystrybucyjnej dotyczącej zmian tego dokumentu. 
Aktualna wersja jest publikowana pod adresem kanonicznym wskazanym w sekcji 1.3. 
Istotne zmiany operacyjne są przekazywane klientom objętym usługami ST-SOC za pomocą uzgodnionych kanałów kontraktowych.

1.3 Lokalizacja dokumentu
Kanoniczna wersja dokumentu:https://www.sprinttech.pl/.well-known/RFC2350.txt
Plik security.txt:https://www.sprinttech.pl/.well-known/security.txt
Kopie dokumentu znajdujące się w innych lokalizacjach mogą być nieaktualne. W przypadku rozbieżności wiążąca jest wersja opublikowana pod adresem kanonicznym.

1.4 Autentyczność dokumentu
Autentyczność wersji internetowej należy weryfikować przez adres kanoniczny HTTPS oraz aktualny certyfikat TLS domeny www.sprinttech.pl. 
Jeżeli obok wersji pobieralnej opublikowano podpis OpenPGP, podpis należy zweryfikować pełnym odciskiem klucza podanym w sekcji 2.8. 
Nie należy uznawać samego skróconego Key ID za wystarczające potwierdzenie tożsamości klucza.

2. Informacje kontaktowe
2.1 Nazwa zespołu
Pełna nazwa: CSIRT SprintTech działający w ramach SprintTech Security Operations Center. 
Skrócona nazwa operacyjna: ST-SOC.

2.2 Adres korespondencyjny
Sprinttech Sp. z o.o.
CSIRT SprintTech / Security Operations Center
ul. Budowlanych 64E
80-298 GdańskPolska

2.3 Strefa czasowa
Europe/Warsaw: UTC+1 oraz UTC+2, zależnie od obowiązującego czasu urzędowego.
W zgłoszeniach zaleca się podawanie znaczników czasu w UTC zgodnie z ISO 8601.

2.4 Numery telefonów
Kontakt administracyjny SprintTech: +48 58 340 77 07. Numer ten nie jest publiczną linią alarmową CSIRT.
Klienci objęci usługą całodobową otrzymują właściwy numer alarmowy i zasady eskalacji w dokumentacji usługi lub umowie. 
Incydentów krytycznych dotyczących usług objętych umową nie należy zgłaszać wyłącznie na numer administracyjny.

2.5 Faks
ST-SOC nie udostępnia faksu jako kanału zgłaszania incydentów ani wymiany informacji wrażliwych.

2.6 Inne kanały komunikacji
Klienci mogą korzystać z uwierzytelnionego portalu zgłoszeniowego oraz innych kanałów wskazanych w dokumentacji usługi.
Dane dostępowe i adresy niepublicznych kanałów są przekazywane indywidualnie.
Publiczny formularz lub zwykła poczta elektroniczna nie powinny służyć do przekazywania haseł, tokenów, kluczy prywatnych, 
pełnych zbiorów danych osobowych ani niezanonimizowanych materiałów dowodowych.

2.7 Adresy e-mail
Podstawowy adres do zgłaszania incydentów:zgloszenia@sprinttech.pl
Adres do szyfrowanej komunikacji operacyjnej i kontaktów CSIRT-to-CSIRT:soc@sprinttech.org
Wiadomość można wysłać o dowolnej porze. Całodobowy czas reakcji dotyczy wyłącznie społeczności, 
zakresu usług i kanałów określonych w odpowiedniej umowie lub dokumentacji usługi. 
Zgłoszenia spoza społeczności są obsługiwane bez gwarantowanego publicznie SLA.

2.8 Klucze publiczne i szyfrowanie
ST-SOC obsługuje szyfrowanie OpenPGP.
Key ID: 2A3BD0D2FD797134Pełny fingerprint: 5056 A789 6023 5063 1646 6A71 2A3B D0D2 FD79 7134
Identyfikator użytkownika klucza: soc@sprinttech.org <soc@sprinttech.org>
Źródło klucza:https://keys.openpgp.org/vks/v1/by-fingerprint/5056A7896023506316466A712A3BD0D2FD797134
Przed pierwszym użyciem klucza nadawca powinien:
- pobrać klucz z odnośnika wskazanego w tym dokumencie;
- zweryfikować pełny fingerprint niezależnym kanałem;
- sprawdzić aktualny status, ważność i ewentualne unieważnienie klucza;
- nie wysyłać materiału poufnego, jeżeli weryfikacja nie powiedzie się.

2.9 Członkowie zespołu
Ze względów bezpieczeństwa operacyjnego i ochrony danych osobowych imienna lista członków ST-SOC nie jest publikowana. 
Kontakty z zespołem są realizowane przez adresy funkcyjne i kanały wskazane w niniejszym dokumencie. 
Tożsamość osoby prowadzącej sprawę może zostać przekazana uczestnikom incydentu, jeżeli jest to uzasadnione operacyjnie i zgodne z zasadą need-to-know.

2.10 Inne informacje
ST-SOC realizuje monitoring i obsługę zdarzeń w modelu 24/7/365 w zakresie przewidzianym dla klientów i usług objętych odpowiednią umową. 
Godziny dostępności pozostałych usług, w tym konsultacji, audytów, szkoleń i obsługi podatności, wynikają z umowy lub uzgodnionego planu prac.

2.11 Punkty kontaktu dla klientów
Klienci powinni w pierwszej kolejności używać uwierzytelnionego portalu, numeru alarmowego lub adresu e-mail wskazanego w dokumentacji usługi. 
Przy dalszej komunikacji należy podawać identyfikator sprawy nadany przez ST-SOC.
Osoby i organizacje spoza społeczności mogą zgłaszać incydenty lub podatności za pomocą publicznych adresów e-mail wskazanych w sekcji 2.7. 
ST-SOC może przekazać zgłoszenie do właściwego właściciela zasobu, dostawcy, operatora lub innego CSIRT.

3. Statut
3.1 Misja
Misją ST-SOC jest wspieranie społeczności zespołu w zapobieganiu incydentom cyberbezpieczeństwa, 
ich wykrywaniu, analizie, koordynacji oraz ograniczaniu skutków, z poszanowaniem wymagań prawnych, umownych i zasad ochrony informacji.

3.2 Społeczność
Społeczność ST-SOC obejmuje:
- systemy, sieci, usługi, dane i użytkowników Sprinttech Sp. z o.o. objętych mandatem zespołu;
- systemy, sieci, usługi i zasoby klientów wyłącznie w zakresie określonym w obowiązujących umowach, upoważnieniach i dokumentacji usług;
- inne podmioty lub zasoby wyraźnie włączone do zakresu ST-SOC na podstawie pisemnego uzgodnienia.
- Lista klientów i szczegóły ich zakresów są poufne ze względu na zobowiązania umowne. 
Sam fakt dostarczenia przez SprintTech produktu, usługi konsultingowej lub sprzętu nie oznacza automatycznie objęcia zasobu całodobową obsługą ST-SOC.
Zgłoszenia dotyczące zasobów spoza społeczności mogą zostać przyjęte i przekazane właściwemu podmiotowi w trybie best effort, bez powstania zobowiązania do prowadzenia pełnej obsługi incydentu.

3.3 Organizacja sponsorująca i afiliacja
ST-SOC jest organizowany i utrzymywany przez Sprinttech Sp. z o.o. Zespół działa w ramach struktury organizacyjnej SprintTech i współpracuje z właściwymi jednostkami grupy kapitałowej Sprint S.A., 
klientami, dostawcami, operatorami telekomunikacyjnymi, zespołami CSIRT oraz organami publicznymi — w zakresie niezbędnym do realizacji swoich zadań.

3.4 Uprawnienia
Mandat ST-SOC wynika z decyzji kierownictwa Sprinttech Sp. z o.o., regulacji wewnętrznych oraz umów i upoważnień udzielonych przez klientów.
W odniesieniu do zasobów SprintTech zespół może prowadzić monitoring, pozyskiwać i analizować dane telemetryczne, koordynować reakcję oraz inicjować działania ograniczające skutki incydentu 
w granicach zatwierdzonych procedur.
W odniesieniu do zasobów klientów ST-SOC działa wyłącznie w granicach umowy, udzielonych upoważnień, uzgodnionych runbooków i procedur eskalacyjnych. 
ST-SOC nie przejmuje samodzielnie kontroli nad systemami klienta ani nie wykonuje działań destrukcyjnych bez odpowiedniej podstawy i autoryzacji.
Procedura awaryjna typu break glass może być zastosowana tylko wtedy, gdy została wcześniej zatwierdzona dla danego zakresu. 
Każde jej użycie podlega rejestracji, ograniczeniu do niezbędnego minimum i przeglądowi następczemu.
ST-SOC nie jest organem ścigania. Może zabezpieczać informacje techniczne, wspierać zachowanie materiału dowodowego i współpracować z uprawnionymi organami, 
regulatorami lub właściwymi CSIRT, jeżeli wymaga tego prawo, umowa albo obsługa incydentu.

4. Polityki
4.1 Rodzaje incydentów i poziom wsparcia
ST-SOC przyjmuje w szczególności zgłoszenia dotyczące:
- nieautoryzowanego dostępu, przejęcia kont i eskalacji uprawnień;
- złośliwego oprogramowania, ransomware i trwałości atakującego;
- phishingu, oszustw, podszywania się i innych ataków socjotechnicznych;
- naruszenia poufności, integralności lub dostępności informacji;
- utraty, ujawnienia lub nieuprawnionej modyfikacji danych;
- ataków odmowy usługi i zakłóceń działania usług;
- podatności, błędnej konfiguracji i aktywnego wykorzystania luk;
- incydentów chmurowych, łańcucha dostaw, aplikacji, sieci, stacji końcowych i tożsamości;
- naruszeń polityk bezpieczeństwa i zagrożeń wewnętrznych;
- innych zdarzeń, które mogą mieć negatywny wpływ na cyberbezpieczeństwo społeczności.
Priorytet jest określany na podstawie wpływu i pilności, w szczególności: krytyczności zasobu lub usługi, zasięgu zdarzenia, wpływu na poufność, integralność i dostępność, rodzaju danych, 
aktywności atakującego, możliwości propagacji, skutków prawnych i biznesowych oraz dostępności obejść lub środków ograniczających.
MITRE ATT&CK może być używany do opisu taktyk, technik i procedur przeciwnika, ale nie stanowi samodzielnej metody ustalania priorytetu incydentu.
Stosuje się następujące poziomy priorytetu:
P1 — krytyczny: trwa lub bezpośrednio zagraża incydent o bardzo wysokim wpływie, dotyczący m.in. usługi krytycznej, rozległego naruszenia, aktywnego ransomware albo istotnej utraty kontroli 
nad środowiskiem. Dla objętej umową usługi całodobowej triage i eskalacja rozpoczynają się niezwłocznie, zgodnie z właściwym SLA i runbookiem kryzysowym.
P2 — wysoki: potwierdzony lub wysoce prawdopodobny incydent o znaczącym, lecz ograniczonym wpływie. Cel rozpoczęcia reakcji w ciągu 30 minut obowiązuje wyłącznie wtedy, gdy został przewidziany 
dla danego klienta lub usługi w SLA.
P3 — średni: incydent o ograniczonym wpływie, bez przesłanek natychmiastowej eskalacji kryzysowej. Obsługa odbywa się w uzgodnionym oknie serwisowym.
P4 — niski lub informacyjny: zdarzenie o niskim wpływie, zapytanie, obserwacja albo zgłoszenie wymagające weryfikacji. Obsługa jest planowana zależnie od ryzyka, umowy i dostępności zasobów.

„Czas reakcji” oznacza czas od skutecznego odebrania zgłoszenia przez właściwy, monitorowany kanał oraz otrzymania minimalnych danych umożliwiających identyfikację sprawy do potwierdzenia 
przyjęcia lub rozpoczęcia triage. Nie jest to czas pełnego powstrzymania, usunięcia przyczyny ani zamknięcia incydentu.

W przypadku rozbieżności pomiędzy niniejszym opisem a umową, SLA lub uzgodnionym runbookiem pierwszeństwo mają postanowienia właściwe dla danego klienta i usługi, o ile są zgodne z prawem.

4.2 Współpraca, interakcja i ujawnianie informacji
ST-SOC stosuje zasadę minimalizacji informacji oraz need-to-know. W zakresie koniecznym do obsługi sprawy informacje mogą być udostępniane m.in. właściwym jednostkom SprintTech, klientowi, 
właścicielowi zasobu, dostawcy technologii, operatorowi telekomunikacyjnemu, innemu CSIRT, doradcy prawnemu, ubezpieczycielowi, organowi ścigania, regulatorowi lub innemu uprawnionemu podmiotowi.

Zakres ujawnienia zależy od charakteru incydentu, instrukcji źródła, obowiązków prawnych i umownych oraz potrzeby ochrony osób i systemów. Informacje dla mediów przekazuje wyłącznie osoba lub 
jednostka upoważniona do komunikacji zewnętrznej.

ST-SOC stosuje Traffic Light Protocol w wersji 2.0:
TLP:RED — wyłącznie dla imiennie określonych odbiorców; bez dalszego udostępniania. Przed przekazaniem treści TLP przez e-mail należy uzgodnić imiennych odbiorców i bezpieczny kanał. 
Ogólna skrzynka zespołowa może służyć jedynie do wstępnego, minimalnego powiadomienia.
TLP:AMBER — odbiorcy mogą udostępniać informację na zasadzie need-to-know wewnątrz swojej organizacji oraz jej klientom, jeżeli jest to niezbędne do ochrony tych podmiotów.
TLP:AMBER+STRICT — udostępnianie jest ograniczone do organizacji odbiorcy.
TLP:GREEN — informacja może być udostępniana w zdefiniowanej społeczności cyberbezpieczeństwa, lecz nie w publicznie dostępnych kanałach.
TLP:CLEAR — informacja może być rozpowszechniana bez ograniczeń wynikających z TLP, z zastrzeżeniem praw autorskich i innych obowiązujących przepisów.

TLP określa granice dalszego udostępniania; nie jest formalną klasyfikacją informacji, nie zastępuje szyfrowania i nie uchyla obowiązków prawnych. 
Jeżeli zgłoszenie nie ma oznaczenia TLP, ST-SOC domyślnie ogranicza dostęp do osób zaangażowanych w obsługę sprawy i uzgadnia z nadawcą ewentualne dalsze udostępnienie.

Statystyki mogą być publikowane wyłącznie w formie zagregowanej lub zanonimizowanej, chyba że istnieje odrębna podstawa do publikacji bardziej szczegółowych informacji.

4.3 Komunikacja i uwierzytelnianie
ST-SOC może nadawać zgłoszeniom unikalne identyfikatory. Identyfikator sprawy należy podawać w kolejnej korespondencji, bez umieszczania danych wrażliwych w temacie wiadomości.
W przypadku komunikacji zawierającej informacje wrażliwe preferowany jest uwierzytelniony portal klienta lub szyfrowanie OpenPGP. Pierwsze, nieszyfrowane powiadomienie powinno 
zawierać wyłącznie minimum pozwalające na nawiązanie kontaktu i uzgodnienie bezpiecznego kanału.

Tożsamość klienta lub osoby kontaktowej może być potwierdzana za pomocą uwierzytelnionego portalu, mechanizmu MFA, zwrotnego kontaktu na wcześniej zarejestrowany numer, 
podpisu cyfrowego albo innej metody uzgodnionej w dokumentacji usługi. Samo podanie identyfikatora klienta lub danych osobowych nie jest wystarczającym uwierzytelnieniem.

Nie należy przesyłać hasła do zaszyfrowanego pliku tym samym kanałem co plik. ST-SOC może odrzucić lub poddać dodatkowej kontroli załączniki, odnośniki i wiadomości, 
które są nieoczekiwane, złośliwe, niezgodne z ustalonym formatem albo stanowią zagrożenie dla środowiska analitycznego.

5. Usługi
Zakres usług dostępnych konkretnemu członkowi społeczności wynika z jego relacji ze ST-SOC, umowy i dokumentacji usługi.

5.1 Reagowanie na incydenty
5.1.1 Triage incydentów
Triage może obejmować:
- przyjęcie i rejestrację zgłoszenia;
- ocenę kompletności, wiarygodności i związku zgłoszenia ze społecznością;
- weryfikację wystąpienia zdarzenia i jego wstępnego zasięgu;
- korelację z innymi zdarzeniami, kampaniami i trendami;
- określenie priorytetu, właściciela sprawy i wymaganej ścieżki eskalacji;
- przekazanie zaleceń dotyczących zabezpieczenia danych i materiału dowodowego.

5.1.2 Koordynacja incydentów
Koordynacja może obejmować:
- klasyfikację informacji oraz ustalenie zasad ich udostępniania;
- komunikację z klientem, właścicielem zasobu, dostawcą, operatorem, innym CSIRT lub właściwym organem;
- uzgodnienie działań ograniczających, kolejności czynności i odpowiedzialności;
- utrzymanie chronologii zdarzeń, decyzji i przekazań sprawy;
- wsparcie eskalacji kryzysowej oraz obowiązków notyfikacyjnych, jeżeli przewiduje to zakres usługi.

5.1.3 Rozwiązanie incydentów
W granicach udzielonych uprawnień ST-SOC może wspierać:
- analizę techniczną i ustalenie przyczyny źródłowej;
- ograniczenie zasięgu i powstrzymanie incydentu;
- usunięcie złośliwych artefaktów i przyczyny wykorzystania;
- odtworzenie bezpiecznego działania systemów i usług;
- walidację skuteczności działań naprawczych;
- analizę poincydentową, wnioski i plan działań doskonalących.
Wykonanie zmian w środowisku, izolacja systemu, blokada konta, usunięcie danych lub inne działania ingerujące w działalność klienta wymagają właściwej podstawy i autoryzacji.

5.2 Działania proaktywne
W zależności od zakresu usługi ST-SOC może realizować:
- monitorowanie bezpieczeństwa z użyciem SIEM, XDR/EDR i innych źródeł telemetrycznych;
- threat hunting i analizę zachowań przeciwnika;
- cyber threat intelligence oraz wymianę wskaźników i kontekstu zagrożeń;
- zarządzanie podatnościami i koordynację działań naprawczych;
- przygotowanie ostrzeżeń, rekomendacji i materiałów technicznych;
- ćwiczenia tabletop, purple teaming i testy gotowości;
- szkolenia, security awareness i konsultacje;
- przeglądy bezpieczeństwa, audyty i wsparcie doskonalenia zabezpieczeń.

6. Formularze i zasady zgłaszania
6.1 Zgłoszenie incydentu
Zgłoszenie można przesłać na adres zgloszenia@sprinttech.pl albo przez kanał klienta wskazany w dokumentacji usługi. 
Formularz internetowy, jeżeli jest dostępny na stronie kanonicznej, służy do zebrania informacji wstępnych i nie zastępuje uzgodnionego kanału dla materiału poufnego.

Zgłoszenie powinno zawierać, o ile informacje są dostępne i bezpieczne do przekazania:
- dane kontaktowe zgłaszającego i organizację;
- identyfikator klienta lub umowy — tylko w przypadku klientów;
- informację, czy zgłaszający jest właścicielem zasobu lub działa z jego upoważnienia;
- datę i czas zdarzenia wraz ze strefą czasową, preferencyjnie UTC;
- opis obserwowanych faktów, wpływu i aktualnego statusu;
- identyfikatory dotkniętych zasobów, systemów lub usług;
- wskaźniki techniczne, np. adresy IP, domeny, porty, nazwy hostów, skróty kryptograficzne i identyfikatory alertów;
- wykonane dotychczas działania oraz ich wynik;
- proponowane oznaczenie TLP i ograniczenia dalszego udostępniania;
- bezpieczną metodę przekazania dodatkowych logów lub materiału dowodowego.

Przed wysłaniem należy zminimalizować i zanonimizować dane, jeśli pełna treść nie jest niezbędna. 
Nie należy przekazywać haseł, kodów MFA, tokenów sesyjnych, kluczy prywatnych ani innych sekretów. 
Materiały wrażliwe należy przesyłać przez uzgodniony bezpieczny kanał lub zaszyfrować kluczem wskazanym w sekcji 2.8.

6.2 Zgłaszanie podatności
Podatności dotyczące domen, usług i produktów pozostających pod kontrolą SprintTech można zgłaszać na adres soc@sprinttech.org, najlepiej z użyciem OpenPGP. 
Zgłoszenie powinno zawierać opis podatności, dotknięty zasób i wersję, warunki odtworzenia, wpływ, bezpieczny proof of concept oraz propozycję sposobu dalszej koordynacji.

Należy przestrzegać następujących zasad:
- nie wykonywać testów poza zakresem posiadanego upoważnienia;
- nie prowadzić ataków odmowy usługi, socjotechniki, testów fizycznych ani masowego skanowania zakłócającego działanie usług;
- nie uzyskiwać trwałości, nie rozszerzać dostępu i nie pobierać danych ponad minimum konieczne do wykazania problemu;
- przerwać test i niezwłocznie zgłosić problem po uzyskaniu dostępu do danych nieprzeznaczonych dla testującego;
- nie testować środowisk klientów ani innych podmiotów trzecich bez ich wyraźnej zgody;
- nie publikować szczegółów przed uzgodnieniem zasad odpowiedzialnego ujawnienia ze SprintTech;
- nie przesyłać aktywnego złośliwego kodu, jeżeli nie został wcześniej uzgodniony bezpieczny sposób przekazania.

Publikacja tego dokumentu ani pliku security.txt nie stanowi upoważnienia do prowadzenia testów. Jeżeli SprintTech nie opublikował odrębnego programu bug bounty, 
zgłoszenie nie tworzy prawa do wynagrodzenia, nagrody ani zwrotu kosztów. Warunki ewentualnego ujawnienia podatności są uzgadniane indywidualnie z uwzględnieniem ryzyka, 
postępu działań naprawczych, praw osób trzecich i obowiązków prawnych.

7. Zastrzeżenia
Niniejszy dokument ma charakter informacyjny i nie stanowi umowy, gwarancji ani samodzielnego zobowiązania do świadczenia usług. 
Rzeczywisty zakres, dostępność, czasy reakcji, odpowiedzialność i zasady współpracy z klientem wynikają z obowiązującej umowy, SLA, upoważnień oraz dokumentacji usługi.

ST-SOC działa z należytą starannością, lecz nie gwarantuje wykrycia wszystkich zdarzeń, całkowitego usunięcia ryzyka ani odtworzenia każdego systemu lub danych. 
Skuteczna obsługa incydentu wymaga terminowej współpracy właścicieli zasobów, administratorów, użytkowników i innych zaangażowanych podmiotów.

Poufność informacji jest chroniona w granicach prawa, umów i uzgodnionych zasad udostępniania. Informacje mogą zostać ujawnione, jeżeli wymaga tego bezwzględnie obowiązujące prawo, 
decyzja uprawnionego organu albo konieczność ochrony osób, systemów lub praw podmiotów trzecich.

Publikacja danych kontaktowych nie stanowi zgody na nieautoryzowane testowanie systemów, skanowanie, próby wykorzystania podatności ani inne działania ingerujące w zasoby SprintTech, klientów lub podmiotów trzecich.

Dokument jest publikowany w języku polskim. W przypadku przygotowania tłumaczenia, w razie rozbieżności pierwszeństwo ma aktualna polska wersja opublikowana pod adresem kanonicznym.