Strumienie czerwieni, fioletu i błękitu zebrane w jeden znak — ofensywne bezpieczeństwo, audyty i reagowanie na incydenty, wsparte tworzeniem oprogramowania, które wzmacnia to, co łamiemy.
Symulacja rzeczywistych ataków na infrastrukturę, aplikacje webowe, API i środowiska chmurowe. Pełny raport z czytelną biznesowo ścieżką remediacji. Metodyki OWASP i PTES.
Kompleksowa reakcja na incydenty — oprogramowanie ransomware, ataki typu BEC (Business Email Compromise), kradzież danych i przejęcie kontroli nad kontami. Ograniczanie skutków, odzyskiwanie danych metodami kryminalistycznymi, badania nad narzędziami deszyfrującymi oraz raportowanie dostosowane do wymagań ubezpieczycieli.
Systemy Rust i Python tworzone dla środowisk krytycznych dla bezpieczeństwa. Backendy secure-by-design, integracja AI i wysokowydajna automatyzacja dla zespołów produkcyjnych.
Budowanie bezpieczeństwa od podstaw albo wzmacnianie istniejącej infrastruktury. Właściwe decyzje bez stronniczości dostawców. Gotowość na GDPR, przegląd architektury, ocena ryzyka i szkolenie zespołu.
Chcesz porozmawiać o naszych usługach?
Naciśnij Enter, aby zapytać — pasująca odpowiedź pojawi się powyżej. Brak dopasowania? Skorzystaj z metod kontaktu poniżej.
Aby zadać pytanie, wymagany jest JavaScript — pełne FAQ znajdziesz poniżej ↓
PWN-ALL prowadzi cztery powiązane ze sobą obszary działalności: testy penetracyjne i symulację ataków; reagowanie na incydenty i informatykę śledczą; bezpieczną inżynierię oprogramowania w Rust i Python; oraz niezależne od dostawców doradztwo w zakresie bezpieczeństwa. Każde zlecenie ma pisemnie określony zakres, konkretne rezultaty i uzgodnione kryteria odbioru.
Tak. PWN-ALL Auditing, Reviewing & Testing Cyber Risks CO. L.L.C to firma z Dubaju w Zjednoczonych Emiratach Arabskich, założona w 2024 roku i działająca na podstawie licencji Dubai DET No. 1324553. Firma posiada również numer D-U-N-S 571235572 oraz kod NCAGE 10G8W.
Współpracujemy przede wszystkim z przedsiębiorstwami, instytucjami rządowymi i platformami o wysokiej wartości na całym świecie. Zlecenia mogą być realizowane zdalnie w różnych jurysdykcjach, a komunikacja jest dostępna w ponad 20 językach; wszelkie specyficzne dla danej lokalizacji wymogi prawne, dowodowe czy dotyczące przetwarzania danych ustalamy na etapie określania zakresu.
Tak. Możemy podpisać NDA, zanim przekażecie poufne informacje, i korzystać z Signala, poczty e-mail szyfrowanej PGP lub innego zaakceptowanego przez klienta kanału. Dostęp do informacji klienta odbywa się zgodnie z zasadą wiedzy koniecznej, przy zastosowaniu środków kontroli uzgodnionych dla danego zlecenia.
Zacznijcie od opisania oczekiwanego rezultatu, usługi lub zasobów, których dotyczy sprawa, pilności, terminów oraz wszelkich ograniczeń operacyjnych lub regulacyjnych; nie przesyłajcie poufnych danych, zanim nie zostaną ustalone NDA i bezpieczny kanał. Następnie potwierdzamy na piśmie zakres, wyłączenia, autoryzację, zasady zaangażowania, rezultaty prac, kryteria odbioru, osoby kontaktowe i harmonogram.
Planowane testy penetracyjne zwykle mogą rozpocząć się w ciągu 3–5 dni roboczych od ustalenia zakresu i uzyskania pisemnej autoryzacji, w zależności od bieżącej dostępności. Aktywne incydenty obsługiwane są w ramach odrębnego procesu reagowania 24/7, dlatego sytuację awaryjną należy zgłosić natychmiast telefonicznie lub przez bezpieczny kanał komunikacji.
Wycena zależy od zasobów, głębokości prac, terminów, ryzyka, wymogów dowodowych i rezultatów. Po ustaleniu zakresu otrzymujecie pisemną ofertę; dla jasno zdefiniowanych prac dostępne są opcje ze stałą ceną, warunki płatności określa umowa, a przy większych projektach można omówić gwarancje bankowe.
Autoryzowany zakres może obejmować aplikacje webowe, API, sieci zewnętrzne i wewnętrzne, Active Directory, środowiska chmurowe oraz aplikacje mobilne. Szersze zlecenia typu red team mogą również testować mechanizmy tożsamości, ludzi i zabezpieczenia fizyczne, o ile działania te są wyraźnie autoryzowane.
Nie. Narzędzia automatyczne mogą wspierać zakres prac, ale zlecenie prowadzą praktycy, którzy mapują ścieżki ataku, testują logikę biznesową, weryfikują możliwość wykorzystania podatności i oceniają realny wpływ. Rezultatem są dowody i uszeregowana według priorytetów remediacja, a nie niezweryfikowany eksport ze skanera.
Testy prowadzimy zgodnie z praktykami opartymi na OWASP i PTES, w pięciu fazach: ustalenie zakresu i zasad zaangażowania, rozpoznanie i mapowanie powierzchni ataku, bezpieczna eksploatacja, dwupoziomowe raportowanie oraz retesty. Konkretne przypadki testowe dostosowujemy do uzgodnionych zasobów i modelu zagrożeń.
Testujemy wyłącznie zasoby objęte pisemną autoryzacją i uzgodnionymi zasadami zaangażowania. Klient musi być właścicielem systemów lub posiadać zgodę odpowiedniego właściciela albo dostawcy; zasoby stron trzecich, socjotechnika, dostęp fizyczny oraz działania destrukcyjne pozostają poza zakresem, o ile nie zostaną wyraźnie zatwierdzone.
Prace projektujemy tak, aby maksymalnie ograniczyć zakłócenia, jednak testowanie nigdy nie jest całkowicie wolne od ryzyka. Okna ataków, limity zapytań, wyłączenia systemów krytycznych, kontakty eskalacyjne, warunki zatrzymania oraz plany wycofania ustalamy z wyprzedzeniem, a testy destrukcyjne nie są uruchamiane bez wyraźnej zgody.
Czas trwania zależy od zakresu, dostępu, złożoności i potrzeb w zakresie retestów. Strona usługi podaje orientacyjne punkty wyjścia: około dwóch tygodni dla testów aplikacji webowych i API, trzech tygodni dla testów sieciowych oraz sześciu tygodni dla ćwiczenia typu red team; rzeczywisty harmonogram określa oferta.
Otrzymujecie streszczenie zarządcze dla kadry kierowniczej oraz ustalenia techniczne dla inżynierów, obejmujące dowody, zasoby, których dotyczą problemy, realny wpływ, poziom istotności i uszeregowane według priorytetów wskazówki dotyczące remediacji. Ostateczny zakres może również obejmować omówienia wyników, warsztaty naprawcze lub formaty dowodów wymagane przez wewnętrznych interesariuszy.
Tak, retest uzgodnionych, naprawionych ustaleń jest wliczony w standardowy proces testów penetracyjnych. Oferta określa okno retestu, kwalifikujące się ustalenia, wymagany dostęp oraz sposób, w jaki zweryfikowane poprawki zostaną odzwierciedlone w raporcie końcowym.
Nie. Test penetracyjny to ograniczona w czasie ocena autoryzowanego zakresu i nie może dowieść, że nie istnieje żadna podatność. Zmniejsza niepewność i daje Wam oparte na dowodach priorytety, ale bezpieczeństwo nadal zależy od remediacji, działań operacyjnych, monitorowania i przyszłych zmian.
Tak. Usługa reagowania na incydenty 24/7 obejmuje powstrzymanie ataku, zabezpieczenie dowodów, śledcze ustalenie zakresu, usunięcie zagrożenia, odzyskiwanie oraz wzmacnianie zabezpieczeń po incydencie. W przypadku aktywnego incydentu zadzwońcie lub skorzystajcie z Signala natychmiast i nie przesyłajcie poufnych dowodów niezaakceptowanym kanałem.
Nie. Zespół DFIR zajmuje się również kradzieżą danych i wymuszeniami bez szyfrowania, przejęciem firmowej poczty e-mail i oszustwami płatniczymi, przejęciem kont, kompromitacją Microsoft 365 lub Google Workspace i chmury, sprawami związanymi z zagrożeniem wewnętrznym oraz naruszonymi aplikacjami webowymi lub serwerami.
Odizolujcie zaatakowane hosty od sieci, nie wyłączając ich, zabezpieczcie ulotne dowody, chrońcie kopie zapasowe przed dalszym dostępem, rejestrujcie podejmowane działania i uruchomcie mostek reagowania. Nie należy masowo restartować, czyścić, przywracać, deszyfrować ani negocjować, zanim kierownik incydentu oraz Wasi interesariusze prawni lub ubezpieczeniowi nie uzgodnią planu.
Usługa reagowania na incydenty działa w trybie mostka 24/7. Deklarowany poziom obsługi to poniżej 60 minut od pierwszego telefonu do dołączenia analityka do wspólnego mostka, przy czym wstępne wskazówki dotyczące powstrzymania ataku pojawiają się już na etapie triażu; rzeczywisty czas powstrzymania zależy od dostępu, zakresu incydentu i możliwości wykonania działań po stronie klienta.
Zazwyczaj tak, choć wyłączenie może zniszczyć ulotne dowody, takie jak klucze przechowywane w pamięci, wstrzyknięte procesy i aktywne połączenia. Nie włączajcie systemów ponownie; zachowajcie ich obecny stan i skontaktujcie się z zespołem reagowania, aby można było zaplanować triaż na zimno oraz inne źródła dowodów.
Nie. Odzyskiwanie zależy od rodziny ransomware, dostępnych kluczy lub deszyfratorów, jakości dowodów, integralności kopii zapasowych, stanu systemu, ograniczeń prawnych oraz zakresu aktywności, jaka miała miejsce po kompromitacji. Oceniamy czyste kopie zapasowe, odbudowę systemów, badania deszyfratorów i opcje odzyskania kluczy, a następnie określamy, co da się odzyskać, a czego nie.
Zapłata nie powinna być pierwszą reakcją i nie gwarantuje odzyskania ani usunięcia skradzionych danych. Najpierw należy ocenić opcje odzyskiwania i dowody; wszelka komunikacja z operatorem oraz decyzja o płatności muszą obejmować klienta, doradcę prawnego, ubezpieczyciela (jeśli dotyczy) oraz weryfikację pod kątem sankcji.
W zależności od zakresu, produkty mogą obejmować rejestr dowodów i łańcucha dowodowego, oś czasu reagowania, ustalenia dotyczące przyczyny źródłowej i początkowego dostępu, analizę ruchu bocznego i eksfiltracji, wskaźniki kompromitacji, priorytety odzyskiwania oraz raport gotowy dla ubezpieczyciela lub regulatora wraz z planem wzmacniania zabezpieczeń. Wnioski pozostają ograniczone przez zabezpieczone dowody i zachowany łańcuch dowodowy.
Tworzymy bezpieczne backendy w Rust i Python, API, systemy danych, automatyzację, integracje AI, migracje oraz krytyczne dla bezpieczeństwa usługi produkcyjne. Ten sam zespół inżynierski tworzy też dedykowane do incydentów kolektory śledcze, parsery, narzędzia do budowy osi czasu, skanery IOC lub YARA oraz narzędzia badawcze do deszyfratorów i odzyskiwania kluczy.
Rust stosujemy tam, gdzie liczą się bezpieczeństwo pamięci, współbieżność, przewidywalna wydajność i kontrola na niskim poziomie; Python tam, gdzie liczą się szybkość dostarczania, dane, uczenie maszynowe, orkiestracja i integracje. Prace architektoniczne przypisują język do poszczególnych komponentów, zamiast wciskać cały system w jeden stos technologiczny.
Model realizacji przebiega przez fazy: analizę potrzeb, architekturę, wdrożenie, wzmacnianie zabezpieczeń i przekazanie, z testami odbiorczymi i wydajnościowymi uzgodnionymi dla projektu. Przekazanie może obejmować kod źródłowy, zasoby wdrożeniowe, kontrakty API, decyzje architektoniczne, runbooki, diagramy, transfer wiedzy oraz 30-dniowe wsparcie powdrożeniowe, jeśli zostało zakontraktowane.
Doradztwo obejmuje architekturę bezpieczeństwa, ocenę ryzyka ukierunkowaną na biznes, przygotowanie do zgodności z GDPR, przygotowanie do audytu, polityki i procesy reagowania na incydenty, integrację bezpiecznego wytwarzania oprogramowania oraz szkolenia dostosowane do ról. Typowe rezultaty to uszeregowane według priorytetów ustalenia, rejestr ryzyk z przypisanymi właścicielami, mapa drogowa wzmacniania zabezpieczeń, runbooki oraz gotowy do audytu pakiet dowodowy.
Nie. Przygotowanie do zgodności to wsparcie techniczne i operacyjne, a nie porada prawna czy gwarancja certyfikacji; ustalenia śledcze zależą od zabezpieczonych dowodów; odzyskiwanie zależy od warunków incydentu; a testy bezpieczeństwa nie mogą dowieść braku podatności. Każda oferta definiuje mierzalny zakres prac i kryteria odbioru, bez obiecywania rezultatów pozostających poza kontrolą PWN-ALL.
PWN-ALL oferuje jako osobne produkty monitor dark webu i wycieków (Dark-Web and Leak Monitor), wykrywanie botów BotGuard oraz centrum skanowania podatności (Vulnerability Scan Hub). Udostępnia również ponad 20 darmowych narzędzi działających w przeglądarce do zadań takich jak haszowanie, generowanie kluczy, steganografia, identyfikacja ransomware oraz podgląd plików czy materiału śledczego; narzędzia oznaczone jako działające po stronie klienta uruchamiają się lokalnie w przeglądarce bez przesyłania przetwarzanych danych.
Zresetujcie hasło do zaatakowanego konta z urządzenia, o którym wiadomo, że jest bezpieczne, a nie z tego, które zostało przejęte; wylogujcie się i unieważnijcie wszystkie aktywne sesje; usuńcie wszelkie hasła aplikacji oraz dostęp połączonych aplikacji i włączcie uwierzytelnianie wieloskładnikowe. Zachowajcie skrzynkę pocztową wraz z logami logowania i audytu oraz sprawdźcie, czy nie ma ukrytych reguł przekierowania lub reguł skrzynki odbiorczej, ale nie usuwajcie wiadomości, reguł ani konta, ponieważ stanowią one dowody. Jeśli naruszenie nadal trwa lub wiąże się z jakimkolwiek przepływem środków, zadzwońcie lub skorzystajcie z Signala, aby skontaktować się z całodobową infolinią, zamiast czekać na odpowiedź na czacie. Zespół DFIR zajmuje się kompleksowo przypadkami dotyczącymi Microsoft 365, Google Workspace oraz przejęcia kontroli nad kontami — od powstrzymania ataku, przez ustalenie przyczyny źródłowej, aż po wzmocnienie zabezpieczeń.
Mamy do czynienia z aktywnym przypadkiem przejęcia firmowej poczty elektronicznej i oszustwa płatniczego, więc liczy się szybkość — natychmiast skontaktujcie się ze swoim bankiem oraz bankiem odbiorcy, aby podjąć próbę cofnięcia lub zablokowania przelewu, i zgłoście sprawę odpowiednim organom. Zgłoście to nam przez całodobową infolinię, zamiast czekać na odpowiedź na czacie, zwłaszcza gdy środki mogą być nadal w ruchu. Następnie nasz zespół DFIR zbada, w jaki sposób uzyskano dostęp do skrzynki pocztowej lub konta, czy zmieniono dane faktury lub dane bankowe oraz co jeszcze zostało naruszone, jednocześnie zabezpieczając dowody dla waszego banku, ubezpieczyciela i ewentualnego organu regulacyjnego. Zachowajcie wiadomości e-mail i logi konta w nienaruszonym stanie i nie usuwajcie niczego, aby obraz śledczy pozostał kompletny.
To kradzież danych i wymuszenie bez szyfrowania, co w pełni mieści się w zakresie prac zespołu DFIR, mimo że nie wdrożono żadnego oprogramowania ransomware. Priorytetem jest zabezpieczenie dowodów, ustalenie, do czego faktycznie uzyskano dostęp i co zostało wykradzione, ograniczenie ścieżki dostępu oraz zrozumienie żądania, zanim ktokolwiek zareaguje na sprawcę. Nie płaćcie, nie negocjujcie ani nie odpowiadajcie na żądanie, dopóki osoba kierująca reakcją na incydent oraz wasz dział prawny i ubezpieczyciel nie uzgodnią wspólnego podejścia. Zgłoście sprawę przez całodobową infolinię, a wiadomości od sprawcy przekażcie bezpiecznym kanałem, a nie publicznym lub niezatwierdzonym.
Gdy macie przesłanki lub podejrzenia, ale nie ma potwierdzonego incydentu, zespół DFIR może przeanalizować wasze logi, urządzenia końcowe oraz dane w chmurze i dane tożsamości, aby ustalić, czy istnieją dowody bieżącego lub przeszłego włamania, utrzymywania dostępu lub nieuprawnionego dostępu do danych. Następnie przedstawia, czy występują oznaki naruszenia i co zrobić dalej, a jeśli wykryje wyraźną złośliwą aktywność, przechodzi do pełnego reagowania na incydent obejmującego powstrzymanie ataku i analizę śledczą. Dopóki trwa to ustalanie zakresu, zachowajcie istniejące logi i nie przeinstalowujcie ani nie czyśćcie systemów, ponieważ może to usunąć dowody potrzebne do udzielenia odpowiedzi. Jeśli obserwujecie aktywnie rozwijający się atak, zadzwońcie na naszą całodobową infolinię lub skontaktujcie się z nami przez Signala natychmiast, zamiast czekać na odpowiedź na czacie.
Każda reakcja na incydent obejmuje wzmocnienie zabezpieczeń po jego opanowaniu, gdy bezpośrednie zagrożenie zostanie już usunięte. Na podstawie ustaleń dotyczących przyczyny źródłowej i dostępu początkowego zespół przekazuje wam uszeregowany według priorytetów plan wzmocnienia zabezpieczeń, który zamyka konkretne luki wykorzystane przez atakującego i ogranicza możliwości powtórzenia ataku. W ramach głębszych, długoterminowych działań dział konsultingowy może przekształcić to w rejestr ryzyka z wyznaczonymi osobami odpowiedzialnymi, zaktualizowane polityki i procedury reagowania na incydenty oraz szkolenia dostosowane do poszczególnych ról, a zespół inżynierski może zbudować wszelkie narzędzia wymagane przez te poprawki. Wzmocnienie zabezpieczeń zmniejsza ryzyko i poprawia odporność, jednak żaden dostawca nie może obiecać, że przyszły incydent będzie niemożliwy.
Przywrócenie działania usług jest ważne, ale nie mówi wam, w jaki sposób atakujący uzyskał dostęp, czy nadal jest obecny ani do jakich danych uzyskano dostęp, a samo przywracanie może nadpisać dowody wszystkich trzech. Jeśli ścieżka dostępu początkowego i ewentualne utrzymywanie dostępu nie zostaną znalezione i zamknięte, to samo włamanie może się powtórzyć po odzyskaniu danych. Warto, aby zespół DFIR ustalił przyczynę źródłową, sprawdził, czy nie pozostał ukryty dostęp, i potwierdził, co zostało wykradzione, a następnie zastosował ukierunkowane wzmocnienie zabezpieczeń — i zachowajcie wszelkie pozostałe logi, obrazy dysków lub nośniki, których dotyczył incydent, zamiast je usuwać. Jeśli nie macie pewności, czy zagrożenie zostało całkowicie usunięte, potraktujcie je jako aktywne i zgłoście przez całodobową infolinię.
Istniejące systemy w pełni mieszczą się w zakresie prac; zespół inżynierski regularnie podejmuje się migracji, wzmacniania zabezpieczeń oraz krytycznych dla bezpieczeństwa usług produkcyjnych, a nie tylko projektów tworzonych od podstaw. Zlecenie zaczyna się od fazy analizy, która ustala, jak faktycznie działają obecny kod, dane i granice zaufania, zanim cokolwiek zostanie zmienione, a następnie obejmuje projektowanie architektury, implementację i dedykowany etap wzmacniania zabezpieczeń. Gdy główną potrzebą jest ocena bezpieczeństwa istniejącego kodu aplikacji, jest ona realizowana poprzez testy penetracyjne aplikacji oraz integrację bezpiecznego programowania prowadzoną przez dział konsultingowy, a właściwy zakres jest ustalany podczas wstępnej rozmowy.
Odziedziczone, częściowo zbudowane lub wstrzymane systemy można podjąć, jednak praca i tak zaczyna się od fazy analizy, która ustala rzeczywisty stan obecny — co istnieje, co działa oraz gdzie są zagrożenia i luki — zanim zostanie przyjęte jakiekolwiek podejście. Dalej obowiązuje standardowy model: projektowanie architektury, implementacja, wzmocnienie zabezpieczeń i przekazanie, a każdy etap reguluje pisemny zakres prac (Statement of Work) z uzgodnionymi kryteriami odbioru, a nie otwarta obietnica naprawienia wszystkiego. To, co jest realistycznie osiągalne i w jakiej kolejności, określa się po zrozumieniu stanu obecnego.
Integracja AI i LLM to wyraźny element prac zespołu inżynierskiego w Rust i Python, budowany bezpiecznie już na etapie projektowania, w tym samym przepływie analizy, projektowania architektury, implementacji i wzmacniania zabezpieczeń, z uzgodnionymi testami bezpieczeństwa i testami odbiorowymi. Ryzyka specyficzne dla funkcji opartych na LLM — takie jak przedostawanie się niezaufanych danych wejściowych do modelu, ujawnienie danych wrażliwych, to, do czego model ma dostęp, oraz mechanizmy kontroli nadużyć i niekontrolowanych kosztów — są definiowane w zakresie prac i uwzględniane w ich ramach, a nie doczepiane później. Jak przy każdej pracy związanej z bezpieczeństwem, zlecenie definiuje mierzalne środki kontroli i kryteria odbioru, a nie gwarantuje, że systemu nie da się wykorzystać niezgodnie z przeznaczeniem.
Nie zostajecie z samym kodem — przekazanie jest przygotowane do wdrożenia i eksploatacji w waszym środowisku i może obejmować zasoby wdrożeniowe, kontrakty API, decyzje architektoniczne, podręczniki operacyjne (runbooki), diagramy oraz transfer wiedzy, a także 30-dniowe wsparcie po uruchomieniu tam, gdzie przewiduje to umowa. Ponieważ prace są ukierunkowane na krytyczne dla bezpieczeństwa zastosowania produkcyjne, przed przekazaniem następuje dedykowany etap wzmacniania zabezpieczeń. To, kto dokładnie wykonuje i obsługuje wdrożenie, jest ustalane dla każdego zlecenia w zakresie prac.
Wbudowanie bezpieczeństwa w sposób, w jaki zespół już tworzy oprogramowanie, realizuje dział konsultingowy w ramach integracji bezpiecznego programowania — ma ona charakter doradczy: przegląd tego, gdzie bezpieczeństwo wpisuje się w wasz obecny przepływ pracy, zdefiniowanie kontroli i zabezpieczeń, które do niego należą, oraz udzielenie programistom wskazówek zależnych od ról. Gdy proces wymaga zbudowania niestandardowej automatyzacji lub narzędzi, na przykład dedykowanych skanerów lub kontroli, zespół inżynierski może to wdrożyć w ramach odrębnego zakresu. Strona doradcza doradza i definiuje proces, a sama nie tworzy oprogramowania, więc wszystko, co trzeba zbudować, jest ujmowane jako produkt prac inżynierskich.
Rust i Python stanowią trzon: Rust tam, gdzie liczą się bezpieczeństwo pamięci, współbieżność i przewidywalna wydajność, a Python tam, gdzie liczą się szybkość dostarczania, dane, uczenie maszynowe i integracje. Prace nad architekturą przypisują język do poszczególnych komponentów, zamiast wciskać cały system w jeden stos, a istniejące systemy i migracje są w zakresie, więc dopasowanie ustala się na podstawie waszych wymagań podczas określania zakresu.
Doradztwo obejmuje przygotowanie do RODO i do audytu: ocenę luk, kontrole i polityki, które je zamkną, oraz gotowy do audytu pakiet dowodowy, dostarczane w sposób niezależny od dostawców. To wsparcie w zakresie gotowości i przygotowania, a nie porada prawna, i samo w sobie nie gwarantuje zgodności ani certyfikacji — te zależą od waszej działalności i od organu przeprowadzającego ocenę. Rezultatami są uszeregowane według priorytetów ustalenia, rejestr ryzyka z wyznaczonymi osobami odpowiedzialnymi oraz plan wzmacniania zabezpieczeń, na podstawie którego możecie działać.
Szkolenia z bezpieczeństwa dostosowane do ról są częścią prac działu konsultingowego, kształtowane wokół waszego stosu technologicznego, waszych ryzyk i ról, które ich potrzebują. Zwykle łączy się je z otaczającymi je pracami doradczymi — integracją bezpiecznego programowania, politykami i procesami reagowania na incydenty — tak aby szkolenia odzwierciedlały to, jak wasze zespoły faktycznie budują i eksploatują systemy. Jak przy całym doradztwie, zakres i efekty są uzgadniane z góry.
Przegląd architektury bezpieczeństwa lub proponowanego projektu systemu przed jego wdrożeniem to podstawowy element praktyki doradczej. Oceniamy projekt względem waszych ryzyk biznesowych i ograniczeń operacyjnych, a następnie zwracamy uszeregowane według priorytetów ustalenia, plan wzmacniania zabezpieczeń oraz — tam, gdzie to przydatne — podręczniki operacyjne i rejestr ryzyka z imiennie wyznaczonymi osobami odpowiedzialnymi. Ponieważ praktyka jest niezależna od dostawców, rekomendacje wynikają z waszego ryzyka, a nie z jakiegokolwiek produktu, który moglibyśmy w innym przypadku sprzedać.
Różnica polega na zakresie: doradztwo to niezależna od dostawców praca doradcza, która ocenia ryzyko, przegląda architekturę i przygotowuje was do audytów, ale nie tworzy oprogramowania i nie prowadzi awaryjnego reagowania na incydenty. Jeśli potrzebujecie napisania kodu lub zbudowania systemu, to praktyka bezpiecznej inżynierii oprogramowania; jeśli atak trwa, to całodobowy proces reagowania na incydenty; a jeśli potrzebujecie znalezienia i bezpiecznego wykorzystania podatności za zgodą, to testy penetracyjne. Wskażemy wam właściwą praktykę lub połączymy kilka z nich, w zależności od potrzebnego wam rezultatu.
Możecie skontaktować się z nami przez e-mail (z obsługą PGP), Signal, Telegram pod adresem t.me/pwn_all, WhatsApp lub telefonicznie pod numerem +971 58 594 6337, a dla aktywnych incydentów dostępna jest całodobowa infolinia. W sprawach poufnych zalecamy Signal lub e-mail szyfrowany PGP i prosimy, aby nie przesyłać sekretów ani danych uwierzytelniających przed zawarciem NDA i ustanowieniem bezpiecznego kanału. Jeśli macie aktywny incydent, zadzwońcie lub skorzystajcie z Signala natychmiast, zamiast czekać na odpowiedź na czacie.
Dostęp do waszych informacji odbywa się zgodnie z zasadą wiedzy koniecznej, przy zastosowaniu środków kontroli uzgodnionych dla danego zlecenia, a przed udostępnieniem jakichkolwiek poufnych szczegółów zawierana jest NDA i ustanawiany bezpieczny kanał. Konkretne warunki przetwarzania, przechowywania i retencji ustala się w ramach tej umowy, a nie jako uniwersalne ustawienie domyślne, i prosimy, aby nie przesyłać sekretów, zanim nie zostaną one ustalone. W sprawach poufnych zalecanymi kanałami są Signal lub e-mail szyfrowany PGP.
Naszym publikowanym dowodem są podpisane listy referencyjne pokazane w sekcji referencji na stronie, z którymi możecie się bezpośrednio zapoznać. Ponieważ poufność jest najważniejsza, poza tym nie opisujemy konkretnych klientów ani incydentów, a wszelkie dalsze szczegóły możemy ujawnić wyłącznie za zgodą danego klienta i na podstawie NDA. Możemy też omówić na rozmowie ilustracyjne, nieprzypisane przykłady tego, jak przebiega typowe zlecenie.
Nie — strona internetowa i ten czat mają charakter informacyjny i nie stanowią umowy. Każde zlecenie reguluje podpisany zakres prac (Statement of Work), który określa zakres, wyłączenia, upoważnienie, zasady prowadzenia działań, produkty prac, kryteria odbioru, osoby kontaktowe i harmonogram, a wycena jest potwierdzana w pisemnej ofercie po ustaleniu zakresu. Nic poufnego nie musi trafiać do drugiej strony, dopóki nie zostanie zawarta NDA i ustanowiony bezpieczny kanał.
Typowe zlecenie dotyczące aplikacji webowej lub API zaczyna się od ustalenia zakresu, zasad prowadzenia testów i pisemnego upoważnienia, a następnie przechodzi przez rozpoznanie i mapowanie powierzchni ataku, bezpieczne wykorzystanie uzgodnionych celów, dwupoziomowe raportowanie oraz ponowny test usuniętych podatności. Specjaliści ręcznie mapują ścieżki ataku i weryfikują możliwość wykorzystania podatności, zamiast zwracać surowy eksport ze skanera, więc otrzymujecie streszczenie dla kierownictwa, ustalenia techniczne z dowodami i oceną istotności oraz uszeregowane według priorytetów wskazówki dotyczące usuwania podatności. Strona usługi podaje orientacyjny punkt wyjścia około dwóch tygodni dla prac nad aplikacjami webowymi i API, przy czym rzeczywisty harmonogram i zakres kwalifikujący się do ponownego testu ustala się w ofercie. To ilustracyjny zarys; dokładne przypadki testowe są dostosowywane do autoryzowanych zasobów i modelu zagrożeń.
Typowa sprawa zaczyna się na całodobowej infolinii od powstrzymania ataku i zabezpieczenia dowodów, a następnie od śledczego ustalenia zakresu w celu określenia przyczyny źródłowej, dostępu początkowego, ruchu bocznego oraz tego, jakie dane zostały wykradzione. Odzyskiwanie planuje się na podstawie tego, co potwierdzają dowody — czyste kopie zapasowe, odbudowa systemów oraz, gdy to zasadne, badania nad deszyfratorami i opcje odzyskania kluczy — z udziałem klienta, radcy prawnego i ubezpieczyciela w każdej decyzji dotyczącej płatności lub negocjacji. Otrzymujecie dokumentację łańcucha dowodowego, oś czasu reakcji, wskaźniki naruszenia (IOC), priorytety odzyskiwania oraz raport gotowy dla ubezpieczyciela lub organu regulacyjnego wraz z planem wzmocnienia zabezpieczeń. To ilustracyjny zarys; to, co da się odzyskać, zależy od rodziny ransomware, kluczy, kopii zapasowych i dowodów, a nic nie jest gwarantowane.
Typowa realizacja przechodzi przez analizę, projektowanie architektury, implementację, wzmocnienie zabezpieczeń i przekazanie, z testami odbiorowymi i wydajnościowymi uzgodnionymi dla projektu z góry. Język dobiera się dla poszczególnych komponentów — Rust tam, gdzie liczą się bezpieczeństwo i wydajność, Python tam, gdzie liczą się szybkość, dane i integracje — a bezpieczeństwo jest projektowane od początku, a nie dodawane na końcu. Przekazanie może obejmować kod źródłowy, zasoby wdrożeniowe, kontrakty API, decyzje architektoniczne, podręczniki operacyjne, diagramy oraz transfer wiedzy, a także 30-dniowe wsparcie po uruchomieniu tam, gdzie przewiduje to umowa. To ilustracyjny zarys; dokładny zakres i kryteria odbioru są określone w zakresie prac.