Doradztwo

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.

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).

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.

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).

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.

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 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).

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).

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.

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.

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.