pxl

Doradztwo

Znalezienie słabych punktów to dopiero początek drogi. Wartość tkwi w wyprowadzaniu podatności oraz przeciwdziałaniu powstawaniu nowych problemów. Pomagamy naszym klientom w osiągnięciu tych celów. Poznaj szczegóły naszej oferty doradczej, a potem umów darmową konsultację →.

W przeszłości pomogliśmy poprawić bezpieczeństwo aplikacji firm takich jak:

Przesuwamy bezpieczeństwo w lewo

Bezpieczeństwo to więcej niż okazyjny test czy audyt. Pomagamy zapewniać bezpieczeństwo na każdym etapie SDLC: od fazy projektowania, przez fazy implementacji i weryfikacji aż do fazy wydania i utrzymania.

Rozumiemy stronę biznesową

Zdajemy sobie sprawę, że bezpieczeństwo w biznesie jest centrum kosztów. Dążymy do tego, żeby zmaksymalizować zwrot z inwestycji w bezpieczeństwo oraz zminimalizować ryzyko związane z IT.

Działamy jako zaufany doradca

Krajobraz cyberbezpieczeństwa jest szeroki i łatwo się w nim zgubić. Nasze zadanie widzimy jako pomoc klientowi w znalezieniu odpowiedniej drogi, wypracowaniu planu oraz dotarciu do celu.

Audyty bezpieczeństwa

Audyt zazwyczaj jest pierwszym krokiem w celu poprawy bezpieczeństwa systemu IT. Przeprowadzenie audytu pomoże odpowiedzieć na pytanie czy odpowiednie kontrole bezpieczeństwa są obecne w systemie.

Audyty bezpieczeństwa

Audyt zazwyczaj jest pierwszym krokiem w celu poprawy bezpieczeństwa systemu IT. Przeprowadzenie audytu pomoże odpowiedzieć na pytanie czy odpowiednie kontrole bezpieczeństwa są obecne w systemie.

Efektem wyjściowym każdego rodzaju audytu bezpieczeństwa jest raport opisujący znalezione problemy oraz sposoby ich rozwiązania.

Audyt architektury rozwiązania

Prześwietlamy architekturę Twojego rozwiązania pod kątem bezpieczeństwa. W zależności od wielkości projektu prace możemy wykonywać etapami, przechodząc od ogółu do szczegółu. Zawsze zaczynamy od tzw. one page architecture, a następnie w miarę potrzeby przechodzimy przez kolejne komponenty.

W ramach audytu architektury raport końcowy uzupełniony jest o rekomendacje dotyczące utwardzania oraz wymagania niefunkcjonalne.

Analizę opieramy o własne know-how oraz branżowe standardy publikowane przez m.in.: NIST, ENISA, NCSC czy CIS.

Audyt infrastruktury chmurowej

Przeprowadzamy audyt Twojego środowiska chmurowego (AWS, Azure) w celu znalezienia błędów w konfiguracji.

Jeżeli wykorzystujesz podejście Infrastructure-as-Code to przeanalizujemy również pliki deklaracyjne (np. ARM, Cloudformation, Kubernetes, Terraform).

Podczas prac opieramy się o własne know-how oraz rynkowe standardy i narzędzia (np. CIS Benchmarks).

Audyt kodu aplikacji

Dokonujemy analizy statycznej kodu źródłowego pod kątem błędów bezpieczeństwa występujących w danej technologii. Wspomagamy się również automatyzacją w postaci narzędzi klasy SAST i SCA.

Do tej pory mieliśmy okazję audytować aplikacje napisane w językach takich jak: Java, C#, C/C++, PHP, Python, Ruby, JavaScript.

Audyt kodu aplikacji często łączony jest z testami bezpieczeństwa. Takie połączenie pozwala na testowanie podejściem white-box.

Testy bezpieczeństwa

Testy bezpieczeństwa mogą być kolejnym krokiem po audycie albo osobną inicjatywą. Wykonanie testów bezpieczeństwa dla aplikacji lub całego systemu IT pomoże znaleźć podatności w implementacji, łańcuchy ataków czy sposoby eskalacji.

Testy bezpieczeństwa

Testy bezpieczeństwa mogą być kolejnym krokiem po audycie albo osobną inicjatywą. Wykonanie testów bezpieczeństwa dla aplikacji lub całego systemu IT pomoże znaleźć podatności w implementacji, łańcuchy ataków czy sposoby eskalacji.

W zależności od potrzeby testujemy podejściem white-box, black-box albo gray-box.

Efektem wyjściowym każdego rodzaju testu bezpieczeństwa jest raport opisujący znalezione problemy oraz sposoby ich rozwiązania.

Testy bezpieczeństwa web aplikacji & API

Testowanie bezpieczeństwa web aplikacji i API to nasz chleb powszedni. Widzieliśmy już wszystko, od starych monolitów klasy enterprise do nowoczesnych aplikacji SPA korzystających z REST API opartych o mikroserwisy.

Podczas testów łączymy pracę manualną z automatyzacją. Chętnie korzystamy z narzędzi do analizy dynamicznej (DAST) oraz przeprowadzamy tzw. Fuzzing.

W działaniach wykorzystujemy branżowe standardy i metodyki, m.in. OWASP Top 10, API Top 10, Application Security Verification Standard (ASVS), Software Component Verification Standard (SCVS) czy Web Security Testing Guide (WSTG).

Testy bezpieczeństwa aplikacji mobilnych

Przeprowadzamy testy bezpieczeństwa aplikacji mobilnych zarówno dla platformy Android jak i iOS. Aplikacje mobilne testujemy pod kątem standardu OWASP Mobile Application Security Verification Standard (MASVS) zgodnie z metodyką OWASP Mobile Security Testing Guide (MSTG). Podczas testowania zwracamy szczególną uwagę na zagrożenia z listy OWASP Mobile Top 10.

Aplikacje mobilne najczęściej są interfejsem do interakcji z backendem (API), który odpowiada za logikę biznesową. Dlatego ten rodzaj testów zwykle jest połączony z testami bezpieczeństwa web aplikacji & API.

Testy bezpieczeństwa produktu

Tego rodzaju testy przeprowadzane są często dla aplikacji typu “gruby klient”, rozwiązań IoT, czy systemów wbudowanych.

Testowanie bezpieczeństwa produktu jako całości wymaga kompleksowego podejścia. Podczas pracy używamy zarówno analizy statycznej jak i dynamicznej. Często stosujemy inżynierię odwrotną (x86, x86-64, ARM) w celu głębszego zrozumienia działania rozwiązania. Chętnie włączamy również tzw. Fuzzing, szczególnie dla komponentów niskopoziomowych napisanych w C/C++. Komunikacja zarówno sieciowa jak i radiowa (np. WiFi czy Bluetooth) także zostaje poddana analizie.

Tam, gdzie ma to zastosowanie korzystamy z branżowych standardów (np. OWASP IoT Top 10 czy OWASP Embedded Application Security).

Testy penetracyjne systemów IT

Testy penetracyjne są najbardziej specjalistycznym rodzajem oceny bezpieczeństwa systemu IT. Podczas pentestów system traktowany jest jako “układ naczyń połączonych” co umożliwia odkrywanie łańcuchów ataków oraz sposobów eskalacji pomiędzy jego poszczególnymi elementami (zarówno aplikacyjnymi jak i infrastrukturalnymi).

Pentesty z założenia mają imitować prawdziwego atakującego, dlatego skupione są na niekonwencjonalnych atakach na system IT oraz aktywnych próbach przełamania jego zabezpieczeń. Chcemy udowodnić i oszacować istniejące ryzyka, a nie wykryć jak największą ilość podatności.

Testy penetracyjne dają najlepszy zwrot z inwestycji dla systemów, które były już wcześniej audytowane i testowane pod kątem bezpieczeństwa (brak w nich tzw. low hanging fruits).

Działania operacyjne opieramy o własne know-how oraz standard Penetration Testing Execution Standard (PTES).

Doradztwo w zakresie bezpieczeństwa

Audyty i testy bezpieczeństwa skupiają się na znalezieniu już istniejących problemów, a więc działają retroaktywnie. Działania zapobiegające powstawaniu nowych problemów zaczynają się od przesuwania bezpieczeństwa “w lewo”, a kończą na pełnej implementacji tzw. Secure SDLC.

Doradztwo w zakresie bezpieczeństwa

Audyty i testy bezpieczeństwa skupiają się na znalezieniu już istniejących problemów, a więc działają retroaktywnie. Działania zapobiegające powstawaniu nowych problemów zaczynają się od przesuwania bezpieczeństwa “w lewo”, a kończą na pełnej implementacji tzw. Secure SDLC.

Analiza profilu zagrożeń i ryzyka

Na podstawie danych rynkowych dokonujemy analizy profilu zagrożeń i ryzyka Twojej organizacji (m.in. listujemy typowe zagrożenia i budujemy profile atakujących).

Efektem wyjściowym jest dokument, który można wykorzystać do podejmowania świadomych decyzji w kwestiach bezpieczeństwa (np. w procesie zarządzania podatnościami, modelowania zagrożeń czy zbierania informacji o zagrożeniach tzw. Threat Intelligence).

Modelowanie zagrożeń

Wspólnie z Twoim zespołem budujemy model zagrożeń dla systemu oparty na m.in. DFD i STRIDE. Modelowanie zagrożeń najlepiej przeprowadzić na etapie projektowania docelowego systemu, tak aby uniknąć podatności na etapie implementacji.

Efektem wyjściowym jest dokument zawierający model zagrożeń, jego szczegółowy opis oraz rekomendacje ochrony przed zidentyfikowanymi zagrożeniami.

Automatyzacja bezpieczeństwa w potoku CICD

Przeprowadzamy analizę potoku CICD od kodu na maszynie dewelopera, przez repozytorium, aż do działającej aplikacji na produkcji. Celem jest wyłapanie brakujących kontroli bezpieczeństwa (m.in. narzędzia klasy SAST i DAST).

Automatyzacja w potoku CICD jest jednym z fundamentów modelu DevSecOps.

Efektem wyjściowym jest raport ze stanu obecnego oraz rekomendacje pasujące do Twojego stosu technologicznego. Tam, gdzie to możliwe podajemy rozwiązania komercyjne oraz ich darmowe odpowiedniki.

Przegląd i implementacja bezpiecznego procesu wytwórczego

Dokonujemy kompleksowej analizy procesu SDLC, w której skupiamy się na wykryciu braków pod kątem bezpieczeństwa. Patrzymy tutaj na całość organizacji, a nie tylko na kwestie techniczne.

Naszą analizę możemy oprzeć o własne autorskie narzędzia lub branżowe standardy takie jak OWASP Software Assurance Maturity Model (SAMM), Synopsys Building Security In Maturity Model (BSIMM), Microsoft Secure Development Lifecycle (MSSDL), czy OWASP DevSecOps Maturity Model (DSOMM).

Efektem wyjściowym jest dokument opisujący stan obecny oraz plan prowadzący do osiągnięcia zadowalającego poziomu dojrzałości.

Jak wygląda typowy projekt?

01

Pierwszy kontakt

Poznajemy się w ramach darmowej konsultacji →. W trakcie spotkania omawiamy Twoje problemy oraz identyfikujemy Twoje potrzeby. Po konsultacji dobieramy rekomendowane rodzaje usług i w przeciągu 2 dni roboczych dostajesz od nas wstępną ofertę dostosowaną do Twojego przypadku.

02

Precyzowanie rodzaju działania

Badamy zapotrzebowanie na rodzaj oceny bezpieczeństwa biorąc pod uwagę czynniki takie jak cel, zakres, czy dostępny czas realizacji projektu. Zbieramy podstawowe wiadomości o systemie takie jak stos technologiczny, rozmiar kodu czy ilość punktów wejścia. Na życzenie klienta przed omówieniem szczegółów podpisujemy NDA. Na końcu tej fazy wiemy co i jak chcemy osiągnąć, ile mamy na to czasu oraz jaki będzie koszt całkowity projektu.

03

Przygotowania do prac

Zamykamy sprawy biznesowe takie jak harmonogram działań czy umowa. Ustalamy sposoby komunikacji oraz punkty kontaktowe po obu stronach. W zależności od rodzaju ćwiczenia prosimy o dokumentację techniczną, potrzebne dostępy czy dodanie naszych IP na białą listę. Wewnętrznie przechodzimy przez proces planowania prac technicznych oraz modelowania zagrożeń Twojego rozwiązania.

04

Prace techniczne

Przystępujemy do prac operacyjnych. Od tego momentu naszą uwagę poświęcamy na przeprowadzanie oceny bezpieczeństwa Twojego rozwiązania zgodnie z najlepszymi praktykami (m.in. standardy i metodyki OWASP czy PTES) oraz własnym know-how. W momencie znalezienia podatności krytycznej zgłaszamy ten fakt w trybie ekspresowym dostarczając Twojemu zespołowi Proof-of-Concept oraz propozycję rozwiązania.

05

Zakończenie projektu

Dostarczamy raport końcowy zawierający m.in. podsumowanie kierownicze, ocenę krytyczności oraz opisy techniczne znalezionych podatności. Każdy problem zawiera również propozycje rozwiązania oparte o najlepsze rynkowe praktyki. Po akceptacji wyników przeprowadzamy spotkanie zamykające, na którym omawiamy raport z Twoim zespołem technicznym. Jeżeli istnieje taka potrzeba przeprowadzamy retesty.

Często zadawane pytania

Czym jest audyt bezpieczeństwa?

Audyt polega na porównaniu stanu zastanego z konkretnym wzorcem np. standardem czy zestawem wytycznych. Audyt powinien być wykonany przez niezależną jednostkę po to, aby ocena była obiektywna. Przykładowo: Infrastrukturę można audytować względem CIS Benchmarks.

Czym są testy bezpieczeństwa?

Testy bezpieczeństwa możemy podzielić na kilka rodzajów: ocena podatności, test penetracyjny oraz ćwiczenie red team. Testować można manualnie lub automatycznie (z pewnymi ograniczeniami). Każdy rodzaj testów bezpieczeństwa można wykonać podejściem white-box, black-box albo gray-box.

Czy testy bezpieczeństwa mogą wpłynąć na działanie systemu?

W zależności od rodzaju, testy bezpieczeństwa mogą wpłynąć na działanie systemu IT w stopniu znaczącym. Należy mieć to na uwadze przy określaniu rodzaju testów.

Co jest efektem audytu lub testu bezpieczeństwa?

Efektem wyjściowym zarówno audytu jak i testów bezpieczeństwa jest raport zawierający opis znalezionych problemów bezpieczeństwa oraz sposoby ich rozwiązania.

Czy audyt lub test wystarczy do zapewnienia bezpieczeństwa?

Zarówno audyt jak i testy bezpieczeństwa same z siebie nie uczynią systemu bezpiecznym (ich celem jest znalezienie i pokazanie problemów). Skuteczna obrona wymaga zmiany systemowej, czyli wbudowania bezpieczeństwa w proces wytwórczy.

W jaki sposób oceniacie i wdrażacie proces bezpiecznego wytwarzania oprogramowania?

W pracy doradczej opieramy się na uznanych modelach dojrzałości takich jak Software Assurance Maturity Model (SAMM), Building Security In Maturity Model (BSIMM) czy DevSecOps Maturity Model (DSOMM). Posiadamy również własne autorskie narzędzia zbudowane na przestrzeni lat.

Czy bezpieczeństwo można wbudować do dowolnego procesu wytwórczego?

Tak, każde podejście do wytwórstwa (Waterfall, Agile, itp.) pozwala wdrożyć odpowiednie kontrole bezpieczeństwa na różnych etapach SDLC.

Andrzej Dyjak
ul. Nowy Świat 33/13, Warszawa

NIP: 6332229233
VAT-UE: PL6332229233

REGON: 243638190
Tel: +48 576 106 313