Zasady Fabryki

{{>toc}}

**Strona nadrzędna:** [[Wiki|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.