K0NSULT // Common-Source-of-Truth/effectiveness-proof
k0nsult.cloud / Common-Source-of-Truth / effectiveness-proof

Effectiveness Proof

Szablon i metodologia dowodzenia skuteczności kontroli bezpieczeństwa w programie K0-CST. Skuteczność wykazana mierzalnym wynikiem z retestem — nie deklaracją.

Skuteczność wykazana dowodem, nie deklaracją.

Kontrola nie jest skuteczna dlatego, że istnieje. Jest skuteczna, gdy mierzalny test potwierdza jej działanie, artefakt to dokumentuje i retest zachowuje ciągłość dowodu w czasie.

Ważne. Dowód skuteczności = mierzalny wynik z retestem, nie zapewnienie. Zasada niezmieniona: claim ≤ proof. Twierdzenie o skuteczności kontroli nie może przekraczać tego, co wykazuje konkretny test i konkretny artefakt. Brak retestu = brak dowodu ciągłości.

1. Struktura dowodu

Każdy dowód skuteczności kontroli składa się z siedmiu obowiązkowych pól. Brakujące pole = GAP w dowodzie, nie wyjątek.

Baseline
Stan wyjściowy — jak system / obszar wyglądał przed wdrożeniem kontroli. Musi być obserwowalny lub zrekonstruowalny.
Control
Wdrożona kontrola — co dokładnie zostało zmienione, uruchomione lub skonfigurowane. Opis precyzyjny, bez parafraz.
Test
Jak sprawdzono — procedura testowa, scenariusz, warunki wykonania. Możliwy do odtworzenia przez inny podmiot.
Evidence
Dowód / artefakt — log, zrzut ekranu, hash pliku, wydruk audytu. Musi istnieć i być wersjonowany.
Result
Wynik — co system zrobił w odpowiedzi na test. Konkretny: dostęp zablokowany / zezwolony / alert wygenerowany / itd.
Residual risk
Ryzyko szczątkowe — co pozostaje nieosłonięte po wdrożeniu kontroli. Wymaga jawnego nazwania, nie może być pominięte.
Retest
Kiedy powtórzyć — harmonogram lub warunek wyzwalający ponowny test (np. kwartalnie, po każdej zmianie konfiguracji).

2. Szablon raportu SIMULATION

Poniżej przykład wypełnionego raportu T-014 dla kontroli MFA na panelu administracyjnym. Dane symulowane — wyłącznie do celów demonstracyjnych.

Pole Zawartość
ID kontroli CST-CTRL-0042
Tytuł MFA email-OTP na panelu administracyjnym /kokpit
Owner Operator K0NSULT / rola: Admin
Wersja v1.0 — 2026-07-01
Baseline Brak MFA. Logowanie wymagało wyłącznie hasła statycznego. Każdy podmiot z poprawnym hasłem uzyskiwał pełny dostęp do kokpitu.
Control Wdrożono MFA email-OTP: po podaniu hasła system wysyła jednorazowy kod (ważny 5 min) na zarejestrowany adres e-mail operatora. Dostęp wymaga podania kodu.
Test Próba logowania do /kokpit z poprawnym hasłem, ale bez podania kodu OTP (pominięcie kroku 2FA). Drugi scenariusz: podanie wygasłego kodu OTP (po upływie 5 min).
Evidence Log serwera: auth-2026-07-01T09:14:22Z — OTP_MISSING — access DENIED; zrzut ekranu komunikatu błędu; hash logu SHA-256: a3f7…c291 (symulowany).
Result Dostęp zablokowany w obu scenariuszach. System nie przyznał sesji bez ważnego OTP. Wynik zgodny z oczekiwanym zachowaniem kontroli.
Residual risk Phishing OTP: atakujący może nakłonić operatora do ujawnienia kodu w czasie okna ważności (5 min). Przejęcie konta e-mail = utrata drugiego czynnika. Rekomendacja: monitoring logowań + powiadomienia push o próbach logowania.
Retest Kwartalnie (kolejny: 2026-10-01) oraz po każdej zmianie konfiguracji systemu uwierzytelniania lub dostawcy e-mail.

3. Zasady

Bez retestu brak dowodu ciągłości. Jednorazowy test wykazuje skuteczność w chwili pomiaru. Upływ czasu, zmiany konfiguracji lub aktualizacje środowiska mogą unieważnić wynik. Retest jest obowiązkowym elementem dowodu — nie opcją.
Wynik negatywny też jest dowodem. Jeśli kontrola nie zadziałała zgodnie z oczekiwaniem, wynik negatywny musi być udokumentowany jako GAP, a nie pominięty. Brak dokumentacji negatywnego wyniku jest manipulacją obrazem skuteczności.
Wersjonowanie i owner. Każdy raport T-014 ma przypisaną wersję, datę i właściciela (owner). Zmiana stanu kontroli — np. rekonfiguracja, patch, zmiana dostawcy — wymaga nowej wersji raportu. Cicha edycja bez wersjonowania = naruszenie integralności dowodu.
claim ≤ proof. Twierdzenie o skuteczności nie może wykraczać poza zakres wykonanego testu. Jeśli test obejmował wyłącznie scenariusz „brak OTP", nie można twierdzić, że kontrola jest odporna na phishing OTP — to odrębny scenariusz wymagający odrębnego dowodu.

4. Powiązane

Zastrzeżenie końcowe. Niniejszy materiał ma charakter informacyjno-metodologiczny. not a certification · not a notified body · not a legal conclusion. Szablony i przykłady symulowane służą wyłącznie prezentacji metodologii K0-CST. Skuteczność rzeczywistych kontroli wymaga wykonania testów w środowisku produkcyjnym.