Czym jest standard ISA/IEC 62443 i dlaczego ma znaczenie dla bezpieczeństwa OT/ICS
ISA/IEC 62443 to międzynarodowa seria standardów definiujących wymagania i procesy dla cyberbezpieczeństwa systemów automatyki przemysłowej i sterowania (Industrial Automation and Control Systems, IACS) oraz infrastruktury OT. Standard ten został opracowany przez International Society of Automation (ISA) i przyjęty przez International Electrotechnical Commission (IEC), tworząc wspólne, konsensusowe ramy ochrony dla wszystkich sektorów przemysłu wykorzystujących systemy ICS.
25 października 2025 r. ONZ otworzyła w Hanoi do podpisu pierwszy globalny traktat przeciw cyberprzestępczości („UN Convention against Cybercrime”, nieformalnie: Hanoi Convention). Wydarzenie zgromadziło delegacje dziesiątek państw i ma usprawnić współpracę międzynarodową w sprawach takich jak phishing, ransomware, handel ludźmi online czy mowa nienawiści. Już podczas ceremonii podpisania dokument zyskał szerokie poparcie – choć towarzyszą mu poważne zastrzeżenia dotyczące praw człowieka i wolności badań bezpieczeństwa.
W skrócie
Status: traktat otwarty do podpisu 25 października 2025 r. w Hanoi; 65 państw podpisało w pierwszym dniu. Wejście w życie: po złożeniu 40 dokumentów ratyfikacyjnych. Okno podpisów pozostaje otwarte do 31 grudnia 2026 r.
Cel: ujednolicenie przestępstw, procedur dowodowych i kanałów współpracy transgranicznej w sprawach cyber.
Kto podpisuje: m.in. UE oraz państwa członkowskie (zgoda na podpis wyrażona wcześniej przez Radę UE).
Kontrowersje: branżowe porozumienie Cybersecurity Tech Accord (m.in. Microsoft, Meta) i organizacje praw człowieka ostrzegają przed ryzykiem nadużyć („traktat nadzoru”) i penalizacją etycznych badań.
Kontekst / historia / powiązania
Negocjacje konwencji prowadziło UNODC po latach dyskusji nad potrzebą globalnych, a nie tylko regionalnych (np. europejskich), ram walki z cyberprzestępczością. Sekretarz Generalny ONZ podkreślił koszt cyberprzestępczości liczony w „bilionach dolarów rocznie” i konieczność ułatwienia współpracy między organami ścigania. Strona konwencji prowadzona przez UNODC potwierdza harmonogram: podpis w Hanoi, a następnie możliwość podpisywania w siedzibie ONZ w Nowym Jorku, z wejściem w życie 90 dni po 40. ratyfikacji.
Analiza techniczna / szczegóły traktatu
Choć pełny tekst jest obszerny, trzon instrumentu obejmuje trzy bloki, które mają największe znaczenie dla praktyków cyberbezpieczeństwa i zespołów prawnych:
Katalog przestępstw – od oszustw (phishing), przez ataki z użyciem malware/ransomware, po przestępstwa związane z treścią (np. mowa nienawiści) definiowane według standardów ONZ. To rozszerzenie tradycyjnych ujęć „komputerowych” czynów zabronionych o kategorie, które w wielu jurysdykcjach są nadal rozproszone.
Procedury dowodowe i e-dowody – zharmonizowane zasady zabezpieczania, utrwalania i udostępniania danych elektronicznych (logi, metadane, treści), ułatwiające szybką i zgodną z prawem wymianę materiału dowodowego między państwami. UNODC wskazuje, że konwencja ma promować „legalne badania” i zawiera klauzule ochrony praw człowieka.
Współpraca transgraniczna – kanały pomocy prawnej, tryb „nagłych wniosków” i punkty kontaktowe 24/7, aby skrócić czas reakcji w incydentach transgranicznych. UE potwierdziła zamiar podpisu i wdrażania zgodnie z własnymi standardami praw człowieka.
Praktyczne konsekwencje / ryzyko
Dla firm (CISO, SOC, DPO):
Więcej wezwań międzynarodowych o dane: krótsze terminy na „preservation” i przekazanie logów/treści organom zagranicznym – zwłaszcza dla usług chmurowych i platform o zasięgu globalnym.
Zwiększona interoperacyjność procedur dowodowych – potencjalnie mniej „tarć” prawnych przy przekazywaniu e-dowodów do państw sygnatariuszy.
Ryzyka praw człowieka i R&D – Tech Accord ostrzega, że nieprecyzyjne definicje mogą ułatwić nadmierny nadzór i kryminalizować testy penetracyjne/bezpieczeństwa prowadzone w dobrej wierze, jeśli lokalne prawo implementujące będzie restrykcyjne. Potrzebne będą wyraźne wyjątki i bezpieczne przystanie dla badaczy (np. coordinated vulnerability disclosure).
Dla organów ścigania i CERT/CSIRT:
Szybszy dostęp do danych transgranicznych i łatwiejsze wspólne operacje w sprawach ransomware czy oszustw finansowych.
Rekomendacje operacyjne / co zrobić teraz
Mapa jurysdykcyjna & readiness: zidentyfikuj, które kraje kluczowe dla Twojej działalności podpisały konwencję i śledź proces ratyfikacji (próg 40). Zaktualizuj playbooki SOC/LERT o tryby współpracy transgranicznej.
Retencja i łańcuch dowodowy: ustandaryzuj politykę data preservation (czas, zakres, integralność), aby spełnić oczekiwania nowych kanałów pomocy prawnej.
Legal & privacy by design: oceniaj wnioski o dane pod kątem zgodności z lokalnym prawem, RODO oraz klauzulami praw człowieka przewidzianymi przez konwencję; dokumentuj podstawy prawne i proporcjonalność.
Program CVD/bug bounty: wprowadź/wyraźnie opisz zasady coordinated vulnerability disclosure i zakres „dozwolonych testów” (safe harbor) – to ogranicza ryzyko penalizacji etycznych badań w krajach o ostrzejszej implementacji. (Obawy branży: Cybersecurity Tech Accord).
Ćwiczenia purple team: przetestuj scenariusze żądań danych z państw trzecich (różne formaty, SLA, szyfrowanie end-to-end), uwzględniając eskalacje do DPO/Legal.
Różnice / porównania z innymi przypadkami
Konwencja ONZ ma ambicję globalnego zasięgu i wspólnych, minimalnych standardów. W porównaniu z dotychczasową mozaiką porozumień i instrumentów regionalnych, stawia mocny akcent na ułatwienie dostępu do e-dowodów i mechanizmy 24/7. Jednocześnie zakres kategorii przestępstw i możliwe ingerencje w prywatność są szersze niż w wielu dotychczasowych reżimach – stąd krytyka NGO i sektora technologicznego, by implementacje krajowe nie prowadziły do nadużyć.
Podsumowanie / kluczowe wnioski
To się dzieje teraz: 25 października 2025 r. w Hanoi ruszył proces podpisywania; 65 podpisów na starcie podnosi szansę na szybkie przekroczenie progu 40 ratyfikacji.
Dla biznesu: przygotuj się na więcej i szybsze żądania o dane z zagranicy oraz audyty łańcucha dowodowego.
Dla bezpieczeństwa i prywatności: zadbaj o jasne wyjątki dla badań i procesy oceny proporcjonalności – inaczej istnieje ryzyko „efektu mrożącego” dla społeczności security.
Źródła / bibliografia
Reuters: „UN cybercrime treaty to be signed in Hanoi to tackle global offences” (25 października 2025). (Reuters)
UNODC (press): „UN Convention against Cybercrime opens for signature in Hanoi, Viet Nam” (25 października 2025). (UNODC)
UNODC (status): „United Nations Convention against Cybercrime — status & entry into force”. (UNODC)
Rada UE: „Fighting cybercrime: EU to sign UN Convention on cybercrime” (13 października 2025). (Consilium)
Cybersecurity Tech Accord: „Calls for changes to new UN treaty…” (29 lipca 2024) – stanowisko branży. (Cybersecurity Tech Accord)
NIS2 w skrócie – po co powstała i co zmienia dla organizacji
Dyrektywa NIS2 (Network and Information Systems 2) to unijne prawo dotyczące cyberbezpieczeństwa, będące następcą pierwszej dyrektywy NIS z 2016 roku (tzw. NIS1). Stanowi ona znaczący krok naprzód w wysiłkach UE na rzecz wzmocnienia cyberbezpieczeństwa w kluczowych sektorach gospodarki.
Kompletny przewodnik po dyrektywie NIS2 dla organizacji w Polsce i UE
Dyrektywa NIS2 to największa od lat zmiana w sposobie, w jaki organizacje w Europie muszą zarządzać bezpieczeństwem informacji, ryzykiem i incydentami. Jej celem nie jest biurokracja — lecz wprowadzenie realnych, mierzalnych standardów cyberbezpieczeństwa, które obejmą zarówno duże firmy, jak i kluczowych dostawców technologii, usług krytycznych i infrastruktury cyfrowej.
Grupa ransomware Everest ogłosiła, że to ona stoi za włamaniem do Collins Aerospace (spółka RTX), którego skutki odczuwalne były w całej Europie — od paraliżu odpraw po wielogodzinne opóźnienia. Nowa deklaracja na stronie wycieków grupy pojawiła się 17–18 października 2025 r., kilka tygodni po tym, jak Collins potwierdził incydent ransomware dotyczący oprogramowania do boardingu pasażerów. Wcześniej służby i media nie wskazywały jednoznacznie sprawców ataku.
W skrócie
Co się stało: Collins Aerospace padł ofiarą ataku ransomware, który zakłócił odprawy i nadawanie bagażu na lotniskach m.in. w Londynie (Heathrow), Brukseli, Dublinie i Berlinie. ENISA potwierdziła charakter ataku jako ransomware.
Nowy element: Grupa Everest publicznie przypisała sobie odpowiedzialność i zapowiedziała publikację wykradzionych danych.
Stan formalny: RTX w zgłoszeniu inwestorskim podał, że chodziło o oprogramowanie do boardingu pasażerów; spółka nie spodziewa się istotnego wpływu finansowego. Równolegle w Wielkiej Brytanii zatrzymano (warunkowo zwolniono) mężczyznę w związku ze sprawą, lecz śledztwo trwa.
Kontekst / historia / powiązania
Atak z września 2025 r. wymusił ręczną obsługę pasażerów na wielu lotniskach i spowodował odwołania lotów. W tamtym czasie nie było potwierdzonej identyfikacji grupy. Dopiero teraz Everest przypisuje sobie odpowiedzialność, ujawniając wpis na stronie wycieków i zapowiadając „transze” danych. Media branżowe i regionalne odnotowały ten zwrot, podkreślając związek ze wcześniejszym chaosem na lotniskach.
Analiza techniczna / szczegóły luki
Wektor uderzenia: RTX wskazał na „passenger boarding software” – klasę systemów krytycznych dla procesu odprawy i wejścia na pokład (CUTE/CUPPS), wdrażanych u wielu przewoźników i operatorów. Uderzenie w taką warstwę oprogramowania ma efekt kaskadowy (łańcuch dostaw).
Taktyki sprawców (TTPs) – wnioskowanie na podstawie znanych kampanii ransomware i deklaracji Everest: kradzież danych (double extortion), szyfrowanie zasobów produkcyjnych, groźba publikacji danych w razie braku okupu. Informacje z wpisów monitorujących leak-site Everest wskazują na publikację wpisu dotyczącego Collins/RTX w dniach 17–18 października.
Skala i propagacja zakłóceń: zakłócenia objęły wiele hubów (Heathrow, Bruksela, Berlin, Dublin), co potwierdza wrażliwość sektora lotniczego na jednopunktowe awarie po stronie dostawcy.
Praktyczne konsekwencje / ryzyko
Ryzyko operacyjne: przestoje w odprawach, ręczne procesy, korki w terminalach, utrata slotów, domino w siatce połączeń.
Ryzyko prawne i reputacyjne: potencjalny wyciek danych pasażerów lub partnerów, presja regulacyjna (NIS2, RODO), roszczenia kontraktowe. (Deklaracje publikacji danych przez Everest zwiększają ryzyko wtórnych nadużyć).
Ryzyko finansowe: choć RTX raportował brak „materialnego” wpływu, koszty incydentu po stronie linii i lotnisk (opóźnienia, personel, rekompensaty) mogą być znaczące – zwykle nieujmowane w raporcie dostawcy.
Rekomendacje operacyjne / co zrobić teraz
Dla operatorów lotnisk i linii lotniczych:
Modelowanie ryzyka łańcucha dostaw (CUPPS/CUTE/MUSE i integracje) – klasyfikacja komponentów „single point of failure”, audyty i plany awaryjne z realnym RTO/RPO.
Segmentacja i „blast radius” – oddzielenie sieci operacyjnych (airside/landsid e), kontrola lateral movement, tiered admin, „break-glass” konta offline.
Kontrole tożsamości – phishing-resistant MFA dla kont uprzywilejowanych, rotacja kluczy API integrujących DCS/Departure Control.
Telemetria i EDR/XDR – pełne logowanie na serwerach aplikacyjnych i brokerach integracyjnych (SITA/Amadeus itp.), korelacja zdarzeń z IOC/TTP grup ransomware.
Kopie zapasowe i runbooki manualne – offline immutable backups + ćwiczenia tabletop z przejściem na manual check-in/boarding.
Bezpieczny rozwój i hardening (CISA/ENISA good practices dla oprogramowania krytycznego), izolacja tenantów, kontrola aktualizacji.
Detekcja exfiltracji – DLP na warstwie aplikacyjnej, egress filtering, honeytokens w danych PII.
Plan odpowiedzialnej komunikacji – spójne advisory dla klientów (IOC, TTP, reguły detekcji, kroki naprawcze).
(Praktyki powyżej wynikają z dobrych praktyk dla incydentów ransomware w infrastrukturze krytycznej oraz z charakteru tego ataku potwierdzonego przez RTX/ENISA).
Różnice / porównania z innymi przypadkami
Wobec typowych ataków na linie lotnicze: tu głównym celem był dostawca oprogramowania, a nie pojedynczy przewoźnik. To tłumaczy szeroki, wielolotniskowy efekt.
Na tle „głośnych” kampanii (np. Scattered Spider): motywacja Everest wpisuje się w trend łączenia okupu z „prestiżem” w środowisku przestępczym – co podkreślali eksperci po wrześniowym chaosie.
Podsumowanie / kluczowe wnioski
Deklaracja Everest domyka najważniejszy znak zapytania: kto uderzył w Collins Aerospace. Formalnego potwierdzenia organów na razie brak, ale wpisy na leak-site i relacje branżowe są spójne czasowo.
Rdzeniem incydentu był atak ransomware na oprogramowanie do boardingu, co obnażyło kruchość łańcucha dostaw lotniczych.
Organizacje lotnicze powinny potraktować zdarzenie jako case study i wzmocnić segmentację, planowanie ciągłości działania oraz egzekwowanie wymagań bezpieczeństwa wobec dostawców.
Źródła / bibliografia
Cybersecurity Dive: „RTX confirms hack of passenger boarding software involved ransomware” (26 września 2025). (Cybersecurity Dive)
Reuters: „Airport chaos highlights rise in high-profile ransomware attacks…” (22 września 2025). (Reuters)
Reuters: „UK police arrest man over hack that affected European airports” (24 września 2025). (Reuters)
CyberNews: „Collins Aerospace attack claimed by Everest…” (18 października 2025). (Cybernews)
Security Affairs: „Everest Gang takes credit for Collins Aerospace breach” (18 października 2025). (Security Affairs)
Newsletter – Zero Spamu
Dołącz by otrzymać aktualizacje bloga, akademii oraz ukryte materiały, zniżki i dodatkową wartość.
Dzięki!
Dzięki za dołączenie do newslettera Security Bez Tabu.
Wkrótce otrzymasz aktualizacje z bloga, materiały zza kulis i zniżki na szkolenia.
Jeśli nie widzisz wiadomości – sprawdź folder Spam lub Oferty.
Ekstorcjonistyczna grupa Scattered LAPSUS$ Hunters opublikowała w sieci zestawy danych skradzionych z instancji Salesforce należących do wielu firm. Wyciek nastąpił po nieudanym wymuszeniu okupu – Salesforce publicznie zadeklarował, że nie zapłaci i nie będzie negocjować. Co istotne, sam rdzeń platformy Salesforce nie został naruszony; ataki uderzyły w klientów i ich integracje/aplikacje oraz ludzi (socjotechnika). Na liście ofiar wymieniono m.in. Albertsons, Engie Resources, Fujifilm, GAP, Qantas i Vietnam Airlines. Qantas informował wcześniej o potencjalnie ~5–6 mln dotkniętych klientów, a w przypadku Vietnam Airlines usługę Have I Been Pwned odnotowała ~7,3 mln kont.
Co? Wyciek części danych i groźby ujawnienia kolejnych – łącznie przestępcy chwalili się setkami milionów do ~1 mld rekordów z dziesiątek firm korzystających z Salesforce.
Jak? Dwie równoległe ścieżki:
Vishing/Help Desk → skłonienie pracowników do instalacji spreparowanego Salesforce Data Loader / uzyskania dostępu do kont.
Przejęte tokeny OAuth aplikacji Salesloft Drift → masowy eksport danych z obiektów Salesforce.
Stanowisko Salesforce: brak dowodów na kompromitację platformy; firma nie zapłaci okupu.
Działania organów ścigania: zaburzenie infrastruktury wymuszeniowej grupy przez FBI; mimo to część danych wyciekła.
Kontekst / historia / powiązania
Początek października przyniósł uruchomienie przez grupę własnego serwisu wyciekowego i eskalację gróźb wobec ~39 wskazanych firm-klientów Salesforce. Jednocześnie pojawiły się potwierdzone publikacje danych (m.in. Qantas, Vietnam Airlines). Wcześniejsze ostrzeżenia pochodziły od Google Threat Intelligence/Mandiant oraz FBI, które niezależnie opisały dwie aktywne komórki (UNC6040 i UNC6395) polujące na instancje Salesforce różnymi metodami.
Analiza techniczna / szczegóły luki
Ścieżka A – socjotechnika i Data Loader (UNC6040):
Atakujący używali vishingu (podszywanie się pod IT Service Desk), aby nakłonić pracowników do instalacji zmodyfikowanego Salesforce Data Loader lub udostępnienia danych logowania/MFA.
Po uzyskaniu dostępu następował eksport masowy rekordów (PII, dane programów lojalnościowych, profile użytkowników).
Ścieżka B – tokeny OAuth i integracje (UNC6395):
Kompromitacja tokenów OAuth aplikacji Salesloft Drift; w odpowiedzi 20 sierpnia unieważniono tokeny Drift i wyłączono aplikację w AppExchange.
Napastnicy wykonywali SOQL z kont zaufanych aplikacji, zliczając i pobierając obiekty Account, Opportunity, User, Case, oraz wyszukiwali w danych sekrety (np. AKIA, hasła, tokeny Snowflake).
GTIG/Mandiant opublikowali IOC (m.in. UA „Salesforce-Multi-Org-Fetcher/1.0”, zakres IP – również węzły Tor) i szczegółowe zapytania SOQL pomocne w detekcji.
Dlaczego ofiary są podatne?
Nadmierne uprawnienia Connected Apps („full access”), zbyt liberalne IP Relaxation, brak restrykcji API na profilach, niewłaściwy lifecycle tokenów i zbyt długie sesje.
Ryzyko wtórne (pivot): wyciek tajnych kluczy/API znalezionych w rekordach Salesforce → dalsze włamania do AWS/Snowflake i systemów SaaS.
Chaos informacyjny: część deklaracji grupy jest przesadzona lub niespójna (np. „nie możemy więcej wyciekać”), co utrudnia ocenę pełnej skali, ale potwierdzone wycieki już mogą skutkować incydentami fraudowymi.
Rekomendacje operacyjne / co zrobić teraz
1) Reagowanie i łagodzenie skutków (Salesforce/SecOps)
Przegląd logów: Event Monitoring (zwł. Connected App OAuth Usage, Login, API, UniqueQuery), anomalia w UA i adresach z IOC (Tor/Cloud).
Rotacja sekretów: natychmiast unieważnij i odtwórz tokeny OAuth, API keys, hasła powiązane z integracjami; usuń nadmiarowe refresh tokens.
Ogranicz Connected Apps: minimalne scopes, IP restrictions, wyłącz „API Enabled” poza uprzywilejowanymi Permission Sets; ustaw krótsze sesje i wymuś MFA.
Wyszukiwanie sekretów w danych: przeszukaj obiekty (Case, Attachment, Task, Chatter) pod kątem AKIA, password, Snowflake, URL-i logowania; zastosuj narzędzia typu TruffleHog.
2) Twardnienie procesów i ludzi
Help Desk Playbook: blokada realizacji żądań przez telefon/voice bez out-of-band potwierdzenia i weryfikacji tożsamości; zakaz dyktowania kodów MFA/SSO.
Dystrybucja oprogramowania: instalatory Salesforce Data Loader wyłącznie z oficjalnych źródeł, podpisy cyfrowe, listy dozwolonych hashy, EDR.
3) Komunikacja z klientami i monitoring nadużyć
Powiadomienie osób, których dotyczy sprawa; brand-monitoring pod kątem phish-kampanii podszywających się pod firmę/lojalności.
Dodatkowe kontrole ryzyka transakcji i weryfikacje zmian danych (adresy, telefony) w systemach lojalnościowych.
4) Współpraca z dostawcami i organami
Wykonaj zalecenia Salesforce/Salesloft; zgłoś ślady kompromitacji do FBI/CERT (flash TLP:CLEAR nt. UNC6040/UNC6395).
Różnice / porównania z innymi przypadkami
Nie jest to „klasyczny” ransomware: brak szyfrowania, czysta ekstorsja danych + presja medialna.
Atak na ekosystem SaaS: kruche punkty to integracje i tożsamość, a nie zero-day w samym Salesforce – odmiennie np. od incydentów z lukami w platformach on-prem.
Podsumowanie / kluczowe wnioski
Wyciek ujawnia strukturalną słabość: zaufane aplikacje i tokeny OAuth są „złotym kluczem” do danych CRM.
Wzmocnienie Connected Apps, monitoring SOQL, rotacja sekretów i dyscyplina operacyjna są dziś ważniejsze niż kiedykolwiek.
Organy ścigania potrafią zakłócić infrastrukturę wymuszeniową, ale skutki wycieku (phishing, oszustwa, przejęcia kont) pozostają i wymagają długofalowej obrony.
Źródła / bibliografia
SecurityWeek – przegląd publikacji danych (Albertsons, Engie, Fujifilm, GAP, Qantas, Vietnam Airlines) i kontekst 39 ofiar. (SecurityWeek)
Reuters – potwierdzenia dot. skali („~1 mld rekordów”), technik vishing oraz stanowiska Salesforce. (Reuters)
Google Cloud Threat Intelligence/Mandiant – techniczne szczegóły kampanii UNC6395 (Drift OAuth), SOQL, IOC, zalecenia. (Google Cloud)
Cybersecurity Dive – deklaracja Salesforce o odmowie płatności, rozdzielenie dwóch kampanii (Data Loader vs. Drift). (cybersecuritydive.com)
BankInfoSecurity/GovInfoSecurity – przebieg publikacji po zakłóceniu przez FBI, liczby dla Qantas/Vietnam Airlines. (BankInfoSecurity)
Newsletter – Zero Spamu
Dołącz by otrzymać aktualizacje bloga, akademii oraz ukryte materiały, zniżki i dodatkową wartość.
Dzięki!
Dzięki za dołączenie do newslettera Security Bez Tabu.
Wkrótce otrzymasz aktualizacje z bloga, materiały zza kulis i zniżki na szkolenia.
Jeśli nie widzisz wiadomości – sprawdź folder Spam lub Oferty.
Moralność potrafi usprawiedliwić krzywdę. Etyka stawia granice. To prowokacyjne stwierdzenie każe zastanowić się, czy zawsze to, co uznajemy za moralne, jest naprawdę słuszne. W życiu codziennym, a szczególnie w świecie cyberbezpieczeństwa, granica między tym co można, tym co wolno a tym co warto bywa rozmyta. Specjaliści ds. bezpieczeństwa dysponują ogromnymi możliwościami – potrafią w kilka chwil uzyskać dostęp do poufnych danych lub wyłączyć kluczowe systemy. Dlatego pytanie „czy to zrobić?” nie może kończyć się na „czy potrafię” ani nawet na „czy mam pozwolenie”. Musimy pójść o krok dalej i zapytać: czy warto to zrobić – czy to jest słuszne i odpowiedzialne?.
