Projekt

Ogólne

Profil

Akcje
Historia

Strona nadrzędna: Zasady Fabryki

Źródło: ZasadyRealizacji\test-styku-domen-system-informacyjny-a-lokalizacja w drzewie FB. Wiki jest kopią do czytania – zmiany nanosimy w pliku źródłowym, nie tutaj.

Ustalone 2026-09-03 przy VTS, przy okazji rozstrzygnięcia, że ochrona
fizyczna i przeciwpożarowa wchodzą do UKSC wprost z ustawy, a nie przez
analogię do normy. Zob. pamiec-asystenta\przestrzenie\ogolna-doradztwo\uksc-dokumentacja-art8-art10.

Problem, który ten test rozwiązuje

Ustalenie z 3.09 brzmi: podmiot z działającą ochroną przeciwpożarową
i fizyczną może mieć już pokryty zakres z art. 10 ust. 3 pkt 2 UKSC,
bo Ministerstwo dopuszcza kilka dokumentów zamiast jednego, a liczy się
zachowanie zakresu.

To ustalenie jest prawdziwe warunkowo i łatwo je przekręcić w wygodne
złudzenie. Analiza ppoż zwykle istnieje, plan ochrony zwykle istnieje,
obie opisują budynek. Pytanie brzmi inaczej: czy którakolwiek z nich
zeszła do poziomu, na którym mieszka system informacyjny.

Bez tego "macie już to pokryte" jest twierdzeniem o okładce, nie
o treści.

Przyczyna leży wyżej: w celu i zakresie analizy

Ustalenie Grega z 3.09, które porządkuje cały ten test: brak śladu jest
skutkiem, nie przyczyną. Przyczyną jest źle postawiony cel szacowania
i oceny.

To dlatego problem wychodzi także w firmach dojrzałych. Tam analiza
jest zrobiona porządnie, metodyka się broni, zespół był kompetentny.
Tylko cel postawiono w granicach jednej domeny, więc wynik nie może
obsłużyć drugiej. To nie jest błąd wykonania, tylko błąd zlecenia.

Cel postawiony jako Zakres, który z niego wynika Co wypada
zapewnienie bezpieczeństwa pożarowego budynku budynek, ludzie, mienie, drogi ewakuacji znaczenie sprzętu dla usługi, bo liczy się jego wartość jako mienia
ochrona osób i mienia na obiekcie strefy, wejścia, dozór, mienie o wysokiej wartości zależność usługi od pomieszczeń technicznych i tras kablowych
zapewnienie ciągłości świadczenia usługi wszystko, od czego usługa zależy, niezależnie od wartości majątkowej nic istotnego

Sedno: wartościowanie do mienia zamiast do wartości procesowej

System informacyjny jest mieniem i domena zwykle go widzi. Serwer stoi
w ewidencji środków trwałych, w wykazie mienia chronionego, czasem
w ocenie zagrożenia. Problem jest subtelniejszy niż nieobecność:
wyceniono go jako rzecz, a nie jako element, od którego zależy usługa.

W ochronie mienia i w ppoż priorytet wyznacza wartość majątkowa, bo taki
jest cel tych reżimów i w ich granicach jest to poprawne. Skutek uboczny
jest jednak dotkliwy:

Aktywo Wartość majątkowa Wartość procesowa Priorytet w ochronie mienia
przełącznik sieciowy za 3 tys. zł, przez który idzie cała produkcja pomijalna krytyczna niski, bo tanie
maszyna produkcyjna za 400 tys. zł z zapasem w magazynie wysoka umiarkowana wysoki, bo drogie

Odwrócenie priorytetów jest pełne. Ochrona zbudowana na wartości
mienia będzie chronić maszynę, a nie szafę z przełącznikiem, choć to
przełącznik zatrzymuje usługę.

Model, który to rozwiązuje, mamy zbudowany w VCN. Wycena aktywów na
trzech równorzędnych osiach: majątkowej, procesowej i informacyjnej,
gdzie wartością aktywa jest najwyższa z trzech. Osie nie zastępują
się nawzajem, bo mierzą co innego. Zasady wyceny VCN podają wprost ten
sam przykład: sprzęt za 3 tys. zł, którego awaria zatrzymuje kontrakt za
400 tys. zł, jest aktywem wysokiej wartości i widać to wyłącznie na osi
procesowej.

To jest właściwe zalecenie dla klienta, ostrzejsze niż "rozszerzcie
zakres": nie chodzi o dopisanie serwerowni do wykazu mienia, tylko
o dołożenie osi procesowej do wyceny, która dziś ma tylko majątkową.
Po tym priorytety ochrony ustawiają się same.

Mechanizm jest ten sam co w BIA. Tam też pierwszą czynnością jest
ustalenie zakresu, a wszystko dalsze jest jego konsekwencją. Zakres
postawiony na procesach biznesowych gubi systemy wspierające. Zakres
postawiony na usłudze objętej wpisem daje właściwy zbiór za pierwszym
razem. Ta sama zasada wraca jako "ocena tylko w zakresie celu".

Pytanie diagnostyczne w audycie brzmi więc inaczej, niż się wydaje.
Nie "czy uwzględniliście serwerownię", tylko:

Jaki był cel tej analizy, kto go postawił i co z niego wynikało dla
zakresu.

Odpowiedź znajduje się zwykle na pierwszej stronie dokumentu albo
w zleceniu. Jeżeli cel mówi o obiekcie, ludziach i mieniu, a nie mówi
o usłudze, to dalej można już nie szukać: system informacyjny wypadł
z zakresu na wejściu i żadna staranność wykonania tego nie naprawi.

Konsekwencja dla zalecenia. Przy ustaleniu negatywnym nie zalecamy
"uzupełnienia analizy o serwerownię", bo to leczy objaw. Zalecamy dwie
rzeczy naraz: przestawienie celu analizy na usługę oraz dołożenie
osi procesowej do wyceny aktywów. Po tym zakres domyka się sam,
a priorytety ochrony przestają być pochodną ceny sprzętu.

Treść testu

Szukamy śladu, że system informacyjny był przedmiotem rozważań jako
obiekt fizyczny w konkretnej lokalizacji. Nie deklaracji, że
"bezpieczeństwo jest zapewnione", tylko zapisu, z którego widać, że ktoś
o tym pomyślał.

Test ma dwa kierunki i oba trzeba przejść:

Kierunek Pytanie Podstawa
domena patrzy na system czy analiza zagrożeń albo szacowanie ryzyka w ppoż lub ochronie fizycznej obejmuje pomieszczenia i urządzenia systemu informacyjnego art. 10 ust. 3 pkt 2 lit. c i e
system patrzy na lokalizację czy analiza ryzyka po stronie bezpieczeństwa informacji uwzględnia zagrożenia miejsca, w którym sprzęt stoi art. 8 ust. 1 pkt 2 lit. c

Jednokierunkowe pokrycie nie wystarcza. Analiza ppoż wymieniająca
serwerownię, przy analizie ryzyka IT milczącej o zalaniu, oznacza, że
domeny się nie spotkały.

Czego szukamy jako śladu

Ślad pozytywny, po stronie domenowej:

  • serwerownia albo pomieszczenie techniczne wymienione jako odrębna
    strefa     w planie ochrony albo w instrukcji bezpieczeństwa pożarowego,
    a nie tylko jako numer pomieszczenia na planie ewakuacji,
  • urządzenia systemu w wykazie mienia chronionego albo w ocenie
    zagrożenia,
  • dobór środka gaśniczego z uwagi na elektronikę (gaz zamiast wody).
    Tryskacz wodny nad szafą serwerową jest sam w sobie ustaleniem
    i pokazuje, że analiza ppoż nie widziała, co gasi,
  • kontrola dostępu opisana do pomieszczeń technicznych z osobna, nie
    zbiorczo do budynku,
  • zasilanie gwarantowane, klimatyzacja precyzyjna i monitoring warunków
    środowiskowych w zabezpieczeniach technicznych.

Ślad pozytywny, po stronie systemu:

  • w analizie ryzyka bezpieczeństwa informacji występują zagrożenia
    miejscowe: pożar, zalanie, awaria zasilania, przegrzanie, dostęp
    fizyczny osoby nieuprawnionej,
  • lokalizacja jest atrybutem w rejestrze aktywów, a nie tylko nazwą
    sprzętu.

Typowe ustalenia negatywne

Cztery wzorce, które powtarzają się na tyle często, że warto ich szukać
wprost:

  1. Analiza zatrzymuje się na budynku. "Hala produkcyjna", "budynek
    biurowy", bez zejścia do pomieszczeń. Wtedy zakres z lit. c nie jest
    pokryty, choć dokument istnieje.
  2. Trasy kablowe i szafy poza strefami. Przełączniki w korytarzu,
    szafa krosownicza w pomieszczeniu socjalnym, okablowanie w części
    ogólnodostępnej. Ochrona fizyczna kończy się na drzwiach serwerowni,
    a system informacyjny wychodzi poza nie.
  3. Serwerownia poniżej poziomu terenu bez oceny ryzyka zalania.
    Klasyk, bo pomieszczenia techniczne trafiają do piwnic.
  4. IT nieobecne przy analizie. Ocenę zagrożenia robił specjalista
    ppoż albo firma ochroniarska, bez udziału osoby znającej system.
    Wtedy nawet poprawny dokument nie mógł zobaczyć systemu.

Jak to prowadzić w audycie

Pytanie do klienta stawiamy przez dokument, nie przez deklarację:
prosimy o analizę zagrożeń albo szacowanie ryzyka prowadzone w domenie
ppoż i w ochronie fizycznej, i szukamy w nich systemu informacyjnego.
Odpowiedź "oczywiście, że to uwzględniamy" nie jest śladem.

Wynik testu zapisujemy w trzech stanach, tak jak przy pokryciu wymagań:

  • pokryte – ślad istnieje w obu kierunkach, dokumentacja domenowa
    zasila zakres z art. 10 ust. 3 pkt 2,
  • pokryte częściowo – ślad istnieje w jednym kierunku, wskazujemy,
    którego brakuje,
  • niepokryte – analiza domenowa nie zeszła do systemu. Wtedy zakres
    trzeba uzupełnić, ale uzupełnienie robi się w istniejącym
    dokumencie    , nie przez pisanie nowego.

Gdzie to wchodzi do produktów ESSA

Test nie jest wyłącznie narzędziem audytowym. Wchodzi do dwóch
szkoleń ze ścieżki i w każdym w innej roli:

Szkolenie Rola testu
Szacowanie i ocena ryzyka warstwa celu i zakresu, dokładnie jak w BIA. Uczestnik uczy się stawiać cel analizy tak, żeby zakres domknął się sam. Przypadek pokazowy: ta sama firma, dwa różne cele, dwa różne wyniki
Audyt bezpieczeństwa test wykonawczy. Ustalenie ma wyjść wprost, przez dokument, a nie przez rozmowę. Tu ćwiczy się pytanie o cel analizy i czytanie pierwszej strony dokumentu

W szkoleniu Pełnomocnik ds. cyberbezpieczeństwa wchodzi wyłącznie
zajawkowo, przy dokumentacji z art. 10, zgodnie z doktryną produktu:
mapa, nie warsztat. Pełne narzędzie jest na ścieżce.

Dlaczego to jest ta sama logika co macierz pięciu domen

To jest pole poza przekątną: praca, którą ochrona fizyczna i ppoż
wykonują na rzecz cyberbezpieczeństwa. Test sprawdza, czy to pole
zostało obsadzone, czy zostało puste, bo każda domena pilnowała swojego.

Stąd wniosek, który wraca w każdym wdrożeniu: jeden wątek ochrony
obiektów, kilka widoków z podstawą w przepisie. Nie prowadzimy
osobnej analizy zagrożeń dla cyberbezpieczeństwa obok istniejącej
analizy ppoż. Rozszerzamy istniejącą o przedmiot, którego nie widziała.

Uaktualnione przez Greg K 4 dni temu · 1 rewizji