Co zawiera audyt bezpieczeństwa IT w firmie?

Co zawiera audyt bezpieczeństwa IT w firmie? Trzeba rozróżnić część organizacyjną, która ocenia odpowiedzialność, uprawnienia, kopie zapasowe i reagowanie na incydenty, oraz część techniczną, która bada ustawienia systemów, podatności i kod. Cena zależy od liczby i wielkości badanych systemów oraz szczegółowości prac: nasza automatyczna kontrola bezpieczeństwa kosztuje 89–890 € zależnie od zakresu, a ręczny audyt ekspercki jest dostępny od 3500 €. Najpierw powinni Państwo ustalić, której części potrzebują i jakich dowodów oczekują, ponieważ badanie strony internetowej, ocena zarządzania bezpieczeństwem firmy i certyfikacja to odrębne zamówienia o różnych wynikach.

Proszę sobie wyobrazić, że przed podpisaniem umowy klient przesyła wymaganie przeprowadzenia audytu bezpieczeństwa, a załącznik zawiera pytania zarówno o uprawnienia pracowników, jak i techniczne badanie systemu. Samo przekazanie wymagania programiście nie wystarczy: muszą Państwo ustalić, czy klient oczekuje raportu o witrynie, udokumentowanych procesów firmy czy certyfikatu niezależnej jednostki oraz jaką część systemów lub działalności ma obejmować to potwierdzenie. Zalecamy zachowanie dokładnego brzmienia wymagania i wyjaśnienie jego celu przed wyborem wykonawcy i zaakceptowaniem wyceny.

Co zawiera audyt bezpieczeństwa IT: dwa zadania pod jedną nazwą

Obie części odpowiadają na różne pytania. Część organizacyjna dotyczy tego, jak firma podejmuje i realizuje decyzje dotyczące bezpieczeństwa, a techniczna tego, jak działa konkretny system i czy można obejść jego zabezpieczenia. Dlatego ten sam temat wygląda w każdej z nich zupełnie inaczej: przy ocenie zasad zarządzania uprawnieniami audytor prosi o wskazanie, kto zatwierdza uprawnienia pracownika i jak się je odbiera, natomiast podczas testowania aplikacji próbuje ze zwykłego konta wykonać czynności, na które to konto nie ma uprawnień. Warto czytać oba wyniki łącznie, lecz jeden nie zastępuje drugiego: uporządkowana polityka dostępu nie dowodzi, że aplikacja jej przestrzega, a bezpieczna aplikacja nie dowodzi, że ktoś zamknął konto byłego pracownika.

Dlatego samo słowo "audyt" w zamówieniu mówi niewiele. Zalecamy dodanie dwóch rzeczy: kryteriów oceny prac oraz dowodów oczekiwanych w raporcie. Dla oceny podatności są to ustalenia z priorytetami, dla testów penetracyjnych konkretny mechanizm ochrony lub ograniczenie działania, które wykonawca spróbuje obejść, a dla organizacyjnego audytu zgodności zestaw wymagań, z którym porówna dokumenty i codzienną praktykę.

Jeśli wybierają Państwo jedynie wstępną ocenę braków, należy tak też nazwać jej wynik, zamiast określać go jako certyfikację, i już przy ustalaniu zadania uzgodnić, kto ma przeczytać ten dokument i jaką decyzję podjąć. W przypadku certyfikacji trzeba wiedzieć, kto wystawi potwierdzenie: ISO samo nie certyfikuje firm, a certyfikację wyjaśnia jako pisemne potwierdzenie przez niezależną jednostkę zgodności z określonymi wymaganiami. W tym samym wyjaśnieniu ISO wskazuje, że akredytacja potwierdza kompetencje jednostki certyfikującej, lecz nie jest obowiązkowa; stwierdzenie, że certyfikować może wyłącznie jednostka akredytowana, byłoby więc nieprecyzyjne. Jeśli Państwa klient wymaga certyfikacji akredytowanej, należy wyjaśnić ten warunek przed zawarciem umowy i sprawdzić akredytację wybranej jednostki, aby później nie pozostać z potwierdzeniem, którego klient nie zgodził się przyjąć.

Nasza oferta obejmuje techniczne badanie systemów internetowych, a w części organizacyjnej możemy pomóc w przygotowaniu polityk bezpieczeństwa. Nie certyfikujemy jednak firm ani nie prowadzimy za Państwa systemu zarządzania bezpieczeństwem informacji (SZBI); warto zapisać tę granicę również w zamówieniu. Jeśli zadanie obejmuje zarówno badanie witryny, jak i ocenę zarządzania firmą, należy uzgodnić, kto przygotowuje dowody techniczne, kto porównuje je z wybranymi wymaganiami i kto odpowiada za ocenę końcową. W przeciwnym razie mogą Państwo oczekiwać od nas oceny procesu zarządzania, a od audytora organizacyjnego testu, którego Państwo nie zamówili. Część organizacyjną zwykle wykonuje konsultant zarządzania bezpieczeństwem informacji lub audytor ISO/IEC 27001, a certyfikat wydaje jednostka certyfikująca.

Część organizacyjna: dokumenty trzeba porównać z praktyką

Papier przyjmie wszystko, dlatego w części organizacyjnej warto sprawdzić, czy do zapisów polityki bezpieczeństwa przypisano osoby odpowiedzialne, niezbędne zasoby i dowody realizacji oraz czy dla problemów wskazanych w ocenie ryzyka przewidziano działania; przewodnik ENISA dla małych i średnich przedsiębiorstw obejmuje odpowiedzialność kierownictwa, zaangażowanie i szkolenie pracowników, polityki bezpieczeństwa, zarządzanie dostawcami, ochronę dostępu i plan reagowania na incydenty. Rozmowy z kierownictwem i pracownikami należy uzupełnić badaniem dokumentów oraz konkretnych przykładów z praktyki, aby w ocenie można było oddzielić planowane zasady od ich realizacji, a także wskazać dowody, których audytor nie otrzymał i które trzeba jeszcze przygotować.

W kwestiach dostępu dobry audytor sprawdza nie tylko sposób przydzielania kont, lecz także ich zamykania, stosowanie uwierzytelniania wieloskładnikowego i uprawnienia dostawców. Dlatego w badanych przykładach warto uwzględnić odejście pracownika lub zmianę dostawcy: właśnie wtedy zdarza się zapomnieć o kontach. Podobnie jest z kopiami zapasowymi, ponieważ odpowiedź "robimy kopie" mówi niewiele. Kopia, której przywracania nikt nigdy nie sprawdził, podczas incydentu może okazać się niepełna, a firma dowie się o tym, gdy witryna już nie działa. Ewidencja systemów i urządzeń wymaga wskazania osób odpowiedzialnych, dzienniki zdarzeń zasad ich przeglądania, a plan reagowania na incydenty imiennie wskazanej osoby podejmującej decyzje i kontaktującej się z zaangażowanymi stronami. Inaczej plan pozostaje dokumentem, którego podczas incydentu nikt nie realizuje.

Jako kryteria można wykorzystać ISO/IEC 27001:2022, która określa wymagania dla systemu zarządzania bezpieczeństwem informacji (SZBI); słowo "system" oznacza tu zarządzanie, a nie tylko badaną aplikację. W objaśnieniu normy przez BSI wymieniono 93 zabezpieczenia informacji i cztery obszary: organizacyjny, ludzki, fizyczny i technologiczny. Powinni Państwo uzgodnić, jakie wymagania zostaną ocenione w audycie i na podstawie jakich dowodów, ponieważ odwołanie do normy w wycenie nie mówi jeszcze, czy zamawiają Państwo ocenę systemu zarządzania, czy tylko badanie techniczne, którego wyniki zostaną później wykorzystane w szerszym audycie. Ten wybór należy zapisać przed rozpoczęciem prac.

Inną podstawą są CIS Controls v8.1 z 18 grupami środków zabezpieczających, obejmujące obszary od ewidencji zasobów firmy po testy penetracyjne i zawierające łącznie 153 środki ochrony. CIS opisuje CIS Implementation Group 1 (IG1) jako podstawową cyberhigienę obejmującą 56 środków ochrony. Dlatego w zamówieniu należy wskazać również wybraną grupę, a nie tylko nazwę zestawu zasad. Warto wymagać powiązania w raporcie każdego ocenianego wymagania z otrzymanym dowodem i stwierdzonym brakiem, aby po poprawkach można było sprawdzić dokładnie ten sam warunek, zamiast porównywać dwie ogólne oceny.

Kiedy prawo wymaga audytu bezpieczeństwa IT

Art. 15 ustawy z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa zobowiązuje podmiot kluczowy do przeprowadzania na własny koszt audytu bezpieczeństwa systemu informacyjnego wykorzystywanego do świadczenia usługi co najmniej raz na trzy lata, licząc od sporządzenia i podpisania ostatniego raportu przez audytorów. Elektroniczną kopię raportu należy przekazać właściwemu organowi do spraw cyberbezpieczeństwa w ciągu trzech dni roboczych od otrzymania. Podmiot ważny nie ma w tej ustawie obowiązku audytu okresowego. Właściwy organ może jednak nakazać audyt zewnętrzny podmiotowi kluczowemu w dowolnym momencie, a ważnemu po incydencie poważnym lub innym naruszeniu ustawy (art. 15 ust. 1b–1c). Decyzja podlega natychmiastowemu wykonaniu, wskazuje termin przekazania raportu i rodzaj uprawnionych wykonawców, a także może określić zakres audytu; przepis o tym audycie nie określa, kto ponosi jego koszty. Audyt może przeprowadzić odpowiednio akredytowana jednostka oceniająca zgodność, co najmniej dwóch audytorów spełniających wymagania art. 15 ust. 2 lub CSIRT sektorowy, którego audytorzy spełniają te warunki. Nie może go prowadzić osoba wykonująca w badanym podmiocie zadania z art. 8 oraz 9–13 ani osoba, która wykonywała je w ciągu roku przed rozpoczęciem audytu. Nie ma jednego organu nadzoru dla wszystkich sektorów; właściwość organów określa art. 41. Z uwzględnieniem ustawowych wyjątków są to m.in. minister właściwy do spraw informatyzacji dla infrastruktury cyfrowej poza komunikacją elektroniczną, Prezes Urzędu Komunikacji Elektronicznej dla komunikacji elektronicznej oraz Komisja Nadzoru Finansowego dla bankowości i infrastruktury rynków finansowych. Nadzór nad podmiotami kluczowymi jest prewencyjny i następczy, a nad ważnymi następczy, w szczególności przy uzasadnionym podejrzeniu naruszenia. Organ może kontrolować podmiot, nakazać audyt na zasadach art. 15 ust. 1b, zlecić ocenę bezpieczeństwa systemu CSIRT MON, CSIRT NASK, CSIRT GOV lub CSIRT sektorowemu oraz nakazać wdrożenie zaleceń audytu w określonym terminie (art. 53). CSIRT MON prowadzi Minister Obrony Narodowej, CSIRT NASK prowadzi NASK-PIB, a CSIRT GOV Szef Agencji Bezpieczeństwa Wewnętrznego. Nowelizacja weszła w życie 3 kwietnia 2026 r.; podmioty spełniające wtedy kryteria mają do 3 kwietnia 2027 r. na realizację obowiązków z rozdziału 3, w tym wdrożenie SZBI, a podmioty kluczowe do 3 kwietnia 2028 r. na pierwszy audyt. Podmiot, który później spełni kryteria podmiotu kluczowego, ma na pierwszy audyt 24 miesiące od ich spełnienia. Dawni operatorzy usług kluczowych stali się podmiotami kluczowymi z dniem wejścia nowelizacji w życie. Jeśli już przeprowadzili audyt, nie otrzymują nowego terminu na pierwszy audyt: trzyletni okres liczą od sporządzenia i podpisania ostatniego raportu przez audytorów.

Z kolei art. 8 ustawy o krajowym systemie cyberbezpieczeństwa wymaga od podmiotów kluczowych i ważnych wdrożenia SZBI obejmującego testowanie systemu przy jego nabywaniu, rozwoju, utrzymaniu i eksploatacji. Nie określa częstotliwości testów ani obowiązku testu penetracyjnego przed uruchomieniem systemu. Publiczne podmioty ważne oraz podmioty szkolnictwa wyższego wskazane w art. 8 ust. 3 stosują załącznik nr 4 zamiast art. 8 ust. 1. Publiczny podmiot ważny dokonuje wewnętrznego przeglądu SZBI co najmniej raz w roku, a bezzwłocznie po dotyczącej go rekomendacji Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa lub wystąpieniu okoliczności mogących wpłynąć na ryzyko incydentu poważnego. Testowanie poziomów bezpieczeństwa jest w tym załączniku dodatkowym, fakultatywnym elementem. Nie ma tu ogólnego obowiązku składania okresowej samooceny bezpieczeństwa do centralnego urzędu ani wspólnego terminu jej przekazania. Używana przez Ministerstwo Cyfryzacji „samoocena” oznacza ustalenie, czy podmiot musi złożyć wniosek o wpis do wykazu; dla podmiotów spełniających kryteria 3 kwietnia 2026 r. terminem złożenia wniosku był 3 października 2026 r. Dostawcy wskazani w art. 8b ust. 1, m.in. dostawcy usług DNS, chmurowych i zarządzanych, stosują rozporządzenie wykonawcze Komisji (UE) 2024/2690: potrzebę, zakres, częstotliwość i rodzaj testów ustalają na podstawie oceny ryzyka, a testy penetracyjne są jedną z możliwych metod. Podmiot krytyczny, czyli operator infrastruktury krytycznej wpisany do wykazu podmiotów krytycznych, jest podmiotem kluczowym niezależnie od wielkości, więc podlega także audytowi z art. 15. Dodatkowo art. 6zz ustawy o zarządzaniu kryzysowym, wprowadzony nowelizacją obowiązującą od 4 lipca 2026 r., wymaga, z zastrzeżeniem wyłączeń sektorowych, audytu zintegrowanego systemu zarządzania bezpieczeństwem świadczenia usługi kluczowej co najmniej raz na trzy lata, na własny koszt. Obejmuje on zarządzanie bezpieczeństwem informacji, ciągłość działania usługi kluczowej i bezpieczeństwo fizyczne. Certyfikaty obejmujące ten zakres zastępują audyt, a kopię raportu lub certyfikatu należy przekazać właściwemu organowi do spraw podmiotów krytycznych w ciągu siedmiu dni roboczych od otrzymania. Po incydencie istotnym organ ten może decyzją podlegającą natychmiastowemu wykonaniu nakazać audyt zewnętrzny; przepis ten nie określa, kto ponosi jego koszty. Odrębny obowiązek stanowi ocena ryzyka co najmniej raz na dwa lata (art. 6zt ust. 1 pkt 1). Zgodnie z wyłączeniami w art. 6zzw–6zzx podmioty krytyczne z sektora infrastruktury cyfrowej nie podlegają ani audytowi z art. 6zz, ani tej dwuletniej ocenie ryzyka; podmioty krytyczne z sektora bankowości i infrastruktury rynków finansowych podlegają ocenie ryzyka, lecz nie audytowi z art. 6zz. Ocena bezpieczeństwa prowadzona przez CSIRT MON, CSIRT NASK, CSIRT GOV lub CSIRT sektorowy na podstawie art. 36a–36b ustawy o krajowym systemie cyberbezpieczeństwa służy wykrywaniu podatności i odbywa się za zgodą podmiotu wyrażoną pisemnie lub elektronicznie albo na zlecenie właściwego organu. Nie jest cyklicznym testem penetracyjnym, który podmiot musi zamówić. Wyznaczone podmioty finansowe mają osobny obowiązek testów penetracyjnych opartych na analizie zagrożeń na podstawie rozporządzenia (UE) 2022/2554 i rozporządzenia delegowanego (UE) 2025/1190. Dlatego po otrzymaniu oferty wykonania "obowiązkowego audytu" powinni Państwo poprosić o wskazanie konkretnego obowiązku i Państwa statusu, aby nie traktować audytu okresowego, audytu zewnętrznego nakazanego przez organ nadzorczy i oceny bezpieczeństwa prowadzonej przez CSIRT jako jednego zamówienia.

Część techniczna: od publicznych adresów po kod

W specyfikacji technicznej należy wymienić publiczne adresy, rekordy DNS, otwarte usługi i ustawienia TLS, a także konfigurację serwera lub środowiska chmurowego, aplikacje internetowe i kod źródłowy, które pozwalają Państwo zbadać. Przy każdej części trzeba wskazać, czy wykonawca otrzyma dostęp do ustawień, czy oceni wyłącznie to, co widoczne z zewnątrz, ponieważ są to różne zadania. Podział metod badania bezpieczeństwa według NIST oddziela przegląd dokumentów, dzienników i konfiguracji od identyfikowania i analizowania celów oraz potwierdzania podatności. Mogą Państwo wykorzystać ten podział, aby dokładniej opisać w wycenie wybrane metody i oczekiwany wynik.

Dla aplikacji internetowych OWASP Top 10:2025 stanowi wspólny język: dziesięć kategorii ryzyka, z których dwie pierwsze to błędy kontroli dostępu i niebezpieczna konfiguracja. Sama lista niczego nie sprawdza, dlatego dobry audytor przełoży każdą kategorię na pytanie o Państwa aplikację: w przypadku kontroli dostępu oznacza to próbę wykonania działań jednej roli z konta innej roli, a w kategorii niebezpiecznego projektowania wybór procesu biznesowego, którego zasady ktoś mógłby obejść. Odwołanie do OWASP należy uzupełnić zakresem badania, aby dla obu stron było jasne, które funkcje i role użytkowników rzeczywiście obejmują te prace.

W części dotyczącej poczty elektronicznej należy przewidzieć ocenę ustawień SPF, DKIM i DMARC, powiązaną z systemami, z których firma wysyła wiadomości: wymagania Google'a dla nadawców od 1 lutego 2024 roku przewidują, że każdy nadawca wysyłający wiadomości na konta Gmail konfiguruje SPF lub DKIM, a nadawcy wysyłający ponad 5000 wiadomości dziennie konfigurują SPF, DKIM i DMARC. Polityka DMARC może mieć wartość "none", lecz przy wysyłce bezpośredniej domena wskazana w polu From musi być zgodna z domeną SPF lub DKIM. Dlatego w zadaniu należy wymagać oceny zarówno ustawień, jak i wykorzystywanych przez Państwa dróg wysyłki, zamiast poprzestawać na zaznaczeniu obecności rekordów domeny.

W naszych audytach najczęstszym ustaleniem jest brak zainstalowanych aktualizacji PHP, rdzenia systemu zarządzania treścią i frameworków. Dlatego zalecamy uwzględnienie w specyfikacji technicznej przeglądu używanych wersji, wtyczek i zależności, a w opisie ustalenia wymaganie wskazania konkretnego komponentu i potrzebnego działania. Dzięki temu programista otrzyma zadanie możliwe do wykonania, zamiast ogólnej uwagi o przestarzałej witrynie. Jeśli najważniejsze jest dla Państwa to, co użytkownicy mogą robić w systemie, przegląd wersji nie wystarczy: potrzebne są również testy kontroli dostępu i testy logiki biznesowej. W naszej praktyce zdarzały się błędy krytyczne, przez które każdy użytkownik mógł uzyskać uprawnienia administratora, a ich usunięcie zakończyło się całkowitym przepisaniem rdzenia systemu; przegląd wersji nie wykryłby takiego błędu.

Pytanie o to, co użytkownik może robić, różni się od pytania o zainstalowane wersje i każde wymaga w raporcie własnego dowodu. NIST definiuje skanowanie podatności jako metodę identyfikowania hostów, ich właściwości i związanych z nimi podatności, natomiast w naszej automatycznej kontroli bezpieczeństwa skanowanie jest jednym z etapów prac technicznych. Testy penetracyjne w wyjaśnieniu NIST polegają na odtwarzaniu rzeczywistych ataków w poszukiwaniu możliwości obejścia zabezpieczeń, a często także kombinacji podatności pozwalających uzyskać szerszy dostęp. Wybór samych testów omawiamy dokładniej w artykule o testach penetracyjnych; przy zamawianiu audytu istotne jest tu określenie, których słabości wykonawca będzie tylko szukać, a dla których spróbuje w uzgodnionych granicach dowieść możliwości praktycznego wykorzystania, oraz jakie działania świadomie pozostawi poza pracami.

Jak przebiega audyt od ustalenia zadania po retest

Należy zacząć od pisemnego opisu zakresu auditu, wymieniającego badane systemy, aplikacje, adresy i role użytkowników oraz jasno określającego, czego to zamówienie nie obejmuje. Trzeba dodać cel i granice prac: jakie działania Państwo dopuszczają, w jakim środowisku się odbędą, kto może przerwać badanie i z kim kontaktować się w nieprzewidzianej sytuacji. Na przykład dla systemu zamówień należy osobno uzgodnić sposób sprawdzania działań, które w przeciwnym razie utworzyłyby prawdziwe zamówienie. Ustalenia te powinien przeczytać również Państwa opiekun techniczny, aby dozwolone działania, dostępy i osoby kontaktowe były uzgodnione przed rozpoczęciem prac technicznych.

Przed rozpoczęciem prac należy przygotować dokumenty i osoby do rozmów w zakresie wymaganym przez zadanie: dla części organizacyjnej polityki, przykłady nadawania uprawnień, zapisy przywracania kopii zapasowych i plan reagowania na incydenty, a dla technicznej opis systemu i uzgodnione dostępy, zaznaczając również, czego Państwo jeszcze nie mają. Jeśli badają Państwo kopię, należy zapisać jej różnice względem systemu używanego na co dzień i uzgodnić sposób przedstawienia ich w raporcie. Dzięki temu czytelnik zrozumie później, do którego środowiska odnoszą się wyniki i które pytania pozostały otwarte z powodu braku dokumentów, dostępu lub danej funkcji. Dla prac technicznych należy uzgodnić konkretne godziny testowania i zasady komunikacji, a przy ocenie dokumentów wyznaczyć termin, do którego Państwa współpracownicy mogą przekazywać wyjaśnienia, aby w wyniku wyraźnie oddzielono to, co sprawdzone, od tego, co jeszcze niepotwierdzone.

Jeśli podczas prac wykonawca znajdzie istotny problem, należy wymagać zgłoszenia go w uzgodniony sposób w trakcie pozostałych prac, bez czekania na termin przekazania pełnego raportu. Trzeba również uzgodnić, kto podejmuje decyzję o dalszym testowaniu tego miejsca i jak zapisywać otrzymane zgody lub ograniczenia, ponieważ decyzje te będą potrzebne do wyjaśnienia, w jakim stopniu udało się potwierdzić konkretne ustalenie.

Harmonogram musi uwzględniać także poprawki

Audyt z użyciem naszego systemu zajmuje kilka dni, natomiast same prace przy audycie ręcznym trwają 1–3 tygodnie zależnie od zakresu auditu, a na ich rozpoczęcie można czekać ze względu na obłożenie audytora. Ogólny przedział realizacji podany na stronie usługi to 1–60 dni, dlatego nie należy traktować tych opisów jako jednego gwarantowanego terminu. Przed zamówieniem trzeba uzgodnić datę rozpoczęcia, przekazanie raportu i retest. Jeśli obowiązuje Państwa termin wyznaczony przez klienta lub w postępowaniu zakupowym, należy zaplanować również czas na analizę ustaleń i poprawki oraz odpowiedzi Państwa zespołu na pytania, ponieważ data zakończenia badania i data, do której chcą Państwo usunąć braki, to różne punkty harmonogramu.

Nasza oferta ręcznego audytu eksperckiego obejmuje retest w ciągu 30 dni po poprawkach. Aby wykorzystać go sensownie, przy przekazaniu raportu należy uzgodnić, kto usuwa każdy ze stwierdzonych problemów, kto zgłasza zakończenie prac i jakie dowody wykonawca sprawdzi ponownie. Zakres i rozliczenie samych poprawek trzeba określić oddzielnie, ponieważ cena audytu nie stanowi uzgodnienia wszystkich późniejszych prac programistycznych. Poprawki mogą Państwo wykonać własnym zespołem, a my je potem sprawdzimy, lub powierzyć je nam jako odrębne zadanie, które wycenimy po raporcie. W raporcie z retestu należy wymagać odróżnienia problemu usuniętego od odłożonego lub jeszcze niesprawdzonego oraz wskazania badanego stanu systemu, aby Państwa zespół i odbiorca raportu otrzymali jedną zrozumiałą odpowiedź dotyczącą każdego pierwotnego ustalenia.

Czego wymagać w raporcie z audytu

Na początku raportu warto wymagać zrozumiałego dla kierownictwa podsumowania celu badania, objętych nim systemów i najważniejszych ustaleń, aby decyzję o pracach i zasobach można było podjąć bez czytania całego materiału technicznego. W tym samym miejscu należy poprosić o wskazanie ograniczeń prac. Jeśli kod źródłowy był niedostępny lub pominięto którąś rolę użytkownika, trzeba wymagać powiedzenia tego wprost, zamiast pozostawiać czytelnikowi domysły co do znaczenia krótkiej oceny stanu systemu. Takie podsumowanie warto oceniać według tego, czy Państwa kierownik potrafi na jego podstawie wskazać następną decyzję, osobę odpowiedzialną i pytanie, na które jeszcze nie ma odpowiedzi.

Dla każdego ustalenia technicznego należy wymagać wskazania miejsca w systemie, okoliczności wykrycia, użytej roli użytkownika, opisu odtworzenia działań i dowodu wyniku. Przy niezgodności organizacyjnej obok odwołania do wymagania trzeba poprosić o wskazanie dokumentu lub przykładu z praktyki, na którym opiera się ocena. Zalecenie poprawki musi jasno określać, co należy zmienić, dlatego sformułowanie "uporządkować dostępy" trzeba doprecyzować do konkretnych uprawnień i funkcji, które Państwa programista ma zmienić, oraz wskazać oczekiwane działanie po poprawce. Pozwoli to wykorzystać raport zarówno do przekazania zadania, jak i późniejszego sprawdzenia jego wykonania, bez zmuszania każdego kolejnego czytelnika do ponownego odgadywania intencji audytora.

Jeśli raport wykorzystuje CVSS, należy wymagać również wskazania wersji: FIRST publikuje CVSS, w tym wersję 4.0, której skala oceny dotkliwości obejmuje poziomy "brak" (0,0), "niski" (0,1–3,9), "średni" (4,0–6,9), "wysoki" (7,0–8,9) i "krytyczny" (9,0–10,0); stosowanie tych oznaczeń słownych jest opcjonalne. Obok liczby należy wymagać uzasadnienia i wyjaśnienia dotyczącego działalności Państwa firmy, na przykład jakiej czynności lub zbioru danych dotyczy ustalenie i dlaczego zalecono taką kolejność poprawek. Dzięki temu priorytet można omówić na podstawie opisanych okoliczności, a nie tylko liczby.

Doświadczenie z takimi błędami krytycznymi wykorzystujemy, aby wymagać jasnego opisu skutków, a nie twierdzić, że każda witryna wymaga przebudowy: raport musi pozwalać odróżnić konkretną poprawkę od problemu, którego rozwiązanie wymaga ponownego przemyślenia podstawowego działania systemu. Jeśli raport przewiduje rozległą przebudowę, należy poprosić o pokazanie dowodów uzasadniających to zalecenie, wskazanie, co można poprawić osobno, i jakie pytanie pozostanie nierozstrzygnięte, jeśli firma wybierze tylko część proponowanych prac.

Pliku z nieprzetworzonymi wynikami skanera należy wymagać jako załącznika, jeśli potrzebuje go zespół techniczny. Odbiór raportu trzeba jednak uzależnić od dowodów, priorytetów i wykonalnych zaleceń poprawek, których oczekują Państwo w swoim zamówieniu; liczba wierszy nie powinna być miernikiem jakości. Warto poprosić wykonawcę o wyjaśnienie jednego ustalenia od początku do końca: jak zostało wykryte, czego dowodzi wynik, jak dotyczy Państwa systemu i jak po zmianach zostanie potwierdzone jego usunięcie, a także o wskazanie wszystkiego, co w tym wniosku nadal pozostaje założeniem. Takie omówienie daje konkretną podstawę do odbioru raportu i podziału dalszych prac.

Dlaczego ceny audytów tak bardzo się różnią

Ceny różnią się głównie dlatego, że oferty obejmują różną liczbę systemów i różny poziom szczegółowości prac: automatyczne skanowanie i przegląd wersji kosztują setki euro, natomiast ręczne testy kontroli dostępu i testy logiki biznesowej, audyt bezpieczeństwa kodu źródłowego oraz retest wymagają dni pracy eksperta. W ramach naszej usługi audytu bezpieczeństwa strony internetowej automatyczna kontrola bezpieczeństwa kosztuje 89–890 € zależnie od zakresu i jest przeznaczona dla systemów opartych na WordPressie, Laravelu, Drupalu, Joomli i Moodle. Oferta obejmuje automatyczne skanowanie podatności, sprawdzenie wersji, wtyczek i zależności, ocenę konfiguracji i ustawień serwera oraz raport z ustaleniami i priorytetami. Ten zestaw należy wykorzystać przy porównywaniu ceny z inną ofertą i doprecyzować, które Państwa instalacje zostaną zbadane. Najniższą kwotę w przedziale trzeba odnosić do uzgodnionego zakresu, aby nie przenosić ceny badania jednej witryny na cały zbiór systemów firmy, którego granic wykonawca jeszcze nie ocenił.

Nasz ręczny audyt ekspercki jest dostępny od 3500 € i obejmuje ręczne badanie według OWASP Top 10, testy obchodzenia kontroli dostępu i testy logiki biznesowej, audyt bezpieczeństwa kodu źródłowego oraz dozwolone testy penetracyjne. Audyt bezpieczeństwa kodu źródłowego jest przewidziany dla rozwiązań opartych na Laravelu, WordPressie i tworzonych indywidualnie. W raporcie porządkujemy ustalenia według rzeczywistego ryzyka i do każdego dodajemy zalecenie poprawki; oferta obejmuje również retest po poprawkach. Słowa "od" obowiązują także wtedy, gdy Państwa system ma tylko jeden publiczny adres, ponieważ do wyceny trzeba jeszcze uzgodnić funkcje, role i badany kod.

Pełna kontrola z użyciem naszego systemu kosztuje zwykle 500–800 €. To kwota, którą najczęściej obserwujemy w przedziale cenowym automatycznej kontroli bezpieczeństwa, a nie odrębna cena za łączną ocenę zarządzania firmą, wszystkich systemów i certyfikację. Dlatego słowo „pełna” należy odnosić do konkretnego uzgodnionego zakresu technicznego. Dla większości witryn zalecamy regularną automatyczną kontrolę bezpieczeństwa, którą można często powtarzać, a ręczny audyt ekspercki wtedy, gdy system przetwarza płatności, dane osobowe lub ma krytyczne znaczenie dla firmy, ponieważ błędy uprawnień i obchodzenie logiki biznesowej wykrywa tylko człowiek. W praktyce dobrze sprawdza się regularna automatyczna kontrola bezpieczeństwa i ręczny audyt raz w roku.

To rozróżnienie pomaga również w rozmowie o budżecie: jeśli potrzebują Państwo odpowiedzi dotyczących komponentów i ustawień witryny, należy poprosić o wycenę tego zadania. Jeśli jednak głównym pytaniem jest obchodzenie uprawnień użytkowników lub zasad biznesowych, trzeba uwzględnić odpowiednie testy ręczne i pozwolić wykonawcy osobno wycenić te prace.

Do porównania należy przygotować jednakowy opis systemów, aplikacji, ról użytkowników, a jeśli potrzebna jest również część organizacyjna, także miejsc prowadzenia działalności firmy, a następnie poprosić o osobne wskazanie działań automatycznych i ręcznych. Proszę sobie wyobrazić jedną wycenę wyłącznie publicznej witryny i drugą tej samej witryny wraz z panelem klienta, panelem administracyjnym i kodem źródłowym: przed porównaniem kwot trzeba ustalić granice każdej oferty. Przy każdej części należy zapisać również wymagane dostępy, wybrane kryteria zgodności i odbiorcę raportu. W ten sposób dają Państwo wykonawcy konkretną podstawę wyceny, a sobie możliwość zauważenia pominiętego zadania.

Oddzielnie należy ustalić, czy cena obejmuje wyjaśnienie ustaleń Państwa programiście, powiązanie ich z wymaganiami wybranej normy i retest, a także gdzie kończą się prace audytowe i zaczyna wdrażanie poprawek. Zalecamy, aby przy ustalaniu budżetu audytu podjąć również decyzję dotyczącą usunięcia stwierdzonych braków. Jeśli ceny nadal znacznie różnią się także w ofertach o jednakowym zakresie prac, warto poprosić wykonawców o wyjaśnienie prac i ich granic na przykładzie jednej konkretnej funkcji, takiej jak zmiana uprawnień użytkownika, zamiast za pomocą nazw dodatkowych usług. Pozwoli to Państwu dokonać wyboru według konkretnego wyniku i odpowiedzialności, bez polegania na obietnicy kompleksowego bezpieczeństwa.

Kiedy firma potrzebuje audytu bezpieczeństwa

Zalecamy zamówienie audytu, gdy firma musi podjąć konkretną decyzję dotyczącą bezpieczeństwa lub dostarczyć możliwe do zweryfikowania potwierdzenie, i już na początku określić, czy decyzja dotyczy zarządzania, stanu technicznego czy obu tych kwestii. Jeśli powodem jest NIS2, najpierw należy ustalić Państwa status i mające zastosowanie wymagania, korzystając również z naszego artykułu o NIS2 i jego zakresie stosowania, a następnie sformułować zadanie. Ważna jest tu kolejność: zastosowanie wymagań i potrzebne potwierdzenie trzeba ustalić przed wyborem usługi, aby zamówienie raportu technicznego nie stało się Państwa jedyną odpowiedzią na pytanie, w którym trzeba jeszcze ocenić odpowiedzialność i procesy firmy. Jeśli witryna nie ma kont użytkowników, płatności ani przetwarzania danych osobowych i nikt nie wymaga potwierdzenia, szeroki audyt zwykle nie jest potrzebny: najpierw należy zainstalować aktualizacje, a potem wystarczy automatyczna kontrola bezpieczeństwa.

Jeśli badania wymaga ubezpieczyciel lub klient, należy poprosić o doprecyzowanie oczekiwanego wyniku i przekazać wykonawcy sam tekst wymagania. Na przykład pytanie o szkolenie pracowników lub sprawdzenie przywracania kopii zapasowej trzeba oddzielić od wymagania zbadania uprawnień w aplikacji i przygotować odpowiednie dowody do odpowiedzi. Jeśli w ankiecie dla dostawcy trzeba potwierdzić szerszy proces bezpieczeństwa, niż obejmuje Państwa audyt techniczny, należy uzgodnić z klientem dodatkowe informacje i wyznaczyć w firmie osobę, która je zbierze, zamiast rozszerzać znaczenie raportu technicznego. Jednocześnie trzeba wyjaśnić, czy odbiorca oczekuje samego raportu, odpowiedzi na konkretne pytania czy innej formy potwierdzenia oraz w jakim terminie.

Na potrzeby postępowania zakupowego należy zachować wymagany rodzaj badania i warunki kwalifikacji wykonawcy dokładnie w brzmieniu nadanym przez zamawiającego, a niejasności wyjaśnić przed wystąpieniem o wycenę, aby nie trzeba było przepisywać oferty po rozpoczęciu prac. Wybór omawiamy dokładniej w artykule o badaniu bezpieczeństwa wymaganym w postępowaniu zakupowym, a w celu przygotowania specyfikacji technicznej mogą Państwo skorzystać z kontaktu: Wyślij nam treść wymagania i opis systemu. Należy podać również termin złożenia dokumentów, dostępną dokumentację oraz to, kto po Państwa stronie wykona poprawki, ponieważ rozmowa o realizacji badania musi obejmować nie tylko przygotowanie raportu, lecz także możliwość pracy Państwa zespołu z jego wynikami przed wymaganym terminem.

Po incydencie i między planowanymi badaniami

Po incydencie zalecamy podporządkowanie zadania audytowego konkretnemu pytaniu pozostającemu bez odpowiedzi: czy poprawka usuwa stwierdzony problem, czy podobnego błędu dostępu trzeba szukać w innej funkcji i jak firma będzie w przyszłości sprawdzać przestrzeganie odpowiednich zasad. Wykonawcy należy przekazać opis znanych zdarzeń i oddzielić potwierdzone fakty od założeń. Jeśli chcą Państwo ustalić przebieg zdarzenia, trzeba również nazwać te prace oddzielnie i uzgodnić ich wynik, bez zakładania, że ogólny audyt witryny automatycznie odpowie na wszystkie pytania dotyczące incydentu. Dla badanych poprawek należy natomiast zachować powiązanie z pierwotnymi ustaleniami, aby po zmianach można było wskazać, który dokładnie problem sprawdzono ponownie i w jaki sposób.

Nasi klienci zwykle zamawiają audyt raz lub dwa razy w roku; jest to obserwacja z naszej praktyki, a nie częstotliwość ustalona dla wszystkich firm. Zalecamy, aby w Państwa planie obok następnej daty zapisać także zmiany, po których ponownie ocenią Państwo zakres badania, na przykład nową rolę użytkownika, przepisaną funkcję dostępu lub zmianę dostawcy mającego uprawnienia w systemie. Osobie odpowiedzialnej należy powierzyć porównanie tych zmian z zakresem auditu przeprowadzonego wcześniej i zaproponowanie konkretnej części do zbadania. Nierozwiązane ustalenia z poprzedniego raportu trzeba zachować w zadaniu na kolejne prace wraz z decyzjami o ich odłożeniu, aby nowe badanie zaczynało się od znanej sytuacji.