SOC in-house

SOC in-house to własne centrum operacji bezpieczeństwa, które wykrywa i obsługuje incydenty 24/7 (albo w ustalonych godzinach), na Twoich narzędziach i według Twoich procesów. Ma sens, gdy masz realną skalę ryzyka, własne środowisko do ogarnięcia i chcesz kontrolować jakość reakcji, dane oraz priorytety biznesowe. Najczęściej wygrywa model hybrydowy: core in-house (wiedza o firmie) + wsparcie z zewnątrz (noc, piki, specjalizacje).

(Brzmi jak “robimy to sami”, ale w praktyce to bardziej “bierzemy odpowiedzialność”, a nie “kupujemy SIEM i będzie git”.)

Czym właściwie jest SOC in-house?

SOC (Security Operations Center) to zespół ludzi, procesów i narzędzi, których jedynym zadaniem jest wykrywać zagrożenia, analizować je i reagować, zanim problem zrobi się drogi, głośny i bolesny. “In-house” oznacza, że SOC jest po Twojej stronie biurka: Twoi ludzie (lub przynajmniej trzon zespołu), Twoje decyzje, Twoje runbooki, Twoje KPI.

W porównaniu do SOC-a “z pudełka” (outsourcing, MDR, MSSP) różnica jest prosta: kontrola vs wygoda. Zewnętrzny SOC potrafi być świetny, ale działa w ramach umowy i standardów dostawcy. In-house może być świetny, ale tylko jeśli potraktujesz go jak produkt operacyjny, a nie “projekt IT”.

Kiedy SOC in-house ma sens, a kiedy to przerost formy?

Najprostszy test: czy bezpieczeństwo u Ciebie to “compliance i święty spokój”, czy “ciągła walka o dostępność i dane”.

SOC in-house ma sens, gdy:

• masz środowisko, które generuje dużo sygnałów (chmura + on-prem + SaaS + endpointy + sieć),
• jesteś celem (finanse, zdrowie, e-commerce, produkcja, logistyka, software house z dużymi klientami),
• masz wymagania regulacyjne i audytowe, które wymagają dowodów reakcji, logów, retencji, kontroli dostępu,
• incydent oznacza dla Ciebie realne straty (przestój, wyciek, kary, reputacja),
• chcesz budować kompetencje wewnątrz, bo bezpieczeństwo jest strategiczne.

SOC in-house zwykle nie ma sensu, gdy:

• masz mały zespół IT i ledwo wyrabiacie z utrzymaniem,
• nie masz sensownych logów (albo nie wiesz, skąd je brać),
• chcesz “24/7”, ale budżet i headcount są na “8/5 i to z trudem”,
• oczekujesz, że narzędzia zrobią robotę za ludzi.

(To jest ten moment, gdzie SIEM kupiony bez procesu zaczyna przypominać siłownię kupioną w styczniu.)

Z czego składa się SOC in-house?

SOC to nie jest jeden system. To układ naczyń połączonych.

1) Ludzie (role, nie stanowiska)

Na start nie potrzebujesz armii, ale potrzebujesz odpowiedzialności.

• SOC Lead / Incident Response Lead: właściciel procesu, priorytety, jakość, eskalacje.
• Analityk SOC (Tier 1/2): triage alertów, korelacja, podstawowe śledztwa.
• Threat Hunter (opcjonalnie na start): proaktywne polowania, hipotezy, “co nas ominęło”.
• Inżynier detekcji (Detection Engineer): reguły, tuning, telemetria, mapowanie MITRE ATT&CK.
• Forensics / Malware / Cloud Security (często zewnętrznie): specjalizacje “na wezwanie”.

W małej organizacji jedna osoba może nosić kilka czapek, ale czapki muszą istnieć.

2) Procesy (bez nich SOC jest tylko centrum powiadomień)

Najważniejsze minimum:

• Obsługa incydentu: od zgłoszenia do post-mortem.
• Triage: co jest krytyczne, co jest szumem, co jest “do obserwacji”.
• Eskalacje: kiedy budzisz admina, kiedy prawników, kiedy zarząd.
• Runbooki i playbooki: instrukcje na powtarzalne scenariusze (phishing, ransomware, kompromitacja konta, wyciek tokenu w CI/CD).
• Lessons learned: po każdym incydencie poprawiasz detekcje i proces.

3) Narzędzia (telemetria, detekcja, orkiestracja)

Nie musisz mieć wszystkiego naraz, ale musisz wiedzieć, po co to jest.

Podstawa telemetrii:

• logi tożsamości (IdP, MFA, SSO),
• endpointy (EDR),
• poczta (phishing),
• firewall, DNS, proxy,
• chmura (CloudTrail / Azure Activity / GCP audit logs),
• aplikacje krytyczne i systemy biznesowe.

Warstwa detekcji i korelacji:

• SIEM (korelacja, retencja, reguły),
• systemy detekcji na endpointach i w chmurze (EDR/XDR),
• feedy threat intelligence (ale tylko jeśli umiesz je wykorzystać).

Warstwa reakcji:

• SOAR (automatyzacje, ticketing, playbooki),
• integracja z ITSM (np. zgłoszenia, SLA),
• narzędzia do izolacji hosta, blokad, resetów sesji, cofania tokenów.

Najczęstszy błąd: budowanie SOC-a od narzędzi, a nie od pytań

SOC powinien odpowiadać na konkretne pytania, np.:

• Czy ktoś loguje się niestandardowo do kont uprzywilejowanych?
• Czy mamy ruch do podejrzanych domen i C2?
• Czy ktoś masowo eksportuje dane z aplikacji lub chmury?
• Czy wykryjemy lateral movement i eskalację uprawnień?
• Ile czasu mija od pierwszego sygnału do reakcji?

Jeśli nie masz pytań, będziesz mieć alerty. Dużo alertów.

Jak zbudować SOC in-house krok po kroku (plan, który działa w realu)

Etap 1: 0–30 dni, “widoczność i porządek”

Najpierw ustawiasz podstawy, bo bez tego nie ma czego “monitorować”.

• inwentaryzacja kluczowych systemów i danych,
• centralizacja logów (choćby minimalna),
• podstawowe reguły detekcji (MFA fatigue, impossible travel, anomalie w dostępie do poczty i chmury),
• zasady eskalacji i kanały komunikacji (kto, kiedy, jak),
• pierwsze runbooki na top 5 scenariuszy.

Etap 2: 31–60 dni, “detekcja, tuning, mniej szumu”

Tu zaczyna się prawdziwy SOC, bo zaczynasz oddzielać sygnał od hałasu.

• tuning reguł i whitelisty (robione mądrze, nie “wyciszamy wszystko”),
• mapowanie detekcji do MITRE ATT&CK (żeby widzieć luki),
• playbooki reakcji i automatyzacje (np. izolacja endpointu, blokada domeny, reset sesji),
• metryki i raportowanie do biznesu.

Etap 3: 61–90 dni, “reakcja jak zespół, nie jak chaos”

W tym momencie SOC ma działać powtarzalnie.

• ćwiczenia tabletop (symulacje incydentów),
• współpraca z IT, dev, prawnikami (kto podpisuje decyzje),
• przygotowanie “on-call” lub hybrydy z zewnętrznym wsparciem,
• regularne przeglądy: detekcje, incydenty, poprawki.

(Jeśli po 90 dniach nadal nie wiesz, ile masz fałszywych alarmów i ile czasu zajmuje obsługa incydentu, to znaczy, że SOC jest bardziej dekoracją niż funkcją.)

Ile kosztuje SOC in-house?

To zależy, ale warto myśleć w trzech koszykach:

1. Ludzie: największy koszt i jednocześnie największa wartość.
2. Narzędzia: SIEM, EDR, log storage, integracje.
3. Utrzymanie: tuning, zmiany w środowisku, szkolenia, rotacja.

Dla wielu firm “pełne 24/7” in-house jest po prostu nieopłacalne na początku, bo wymaga większego zespołu (urlopy, choroby, zmiany, jakość). Dlatego realnym złotym środkiem jest: in-house 8/5 + zewnętrzne 16/7 lub 24/7 na eskalację.

Jak mierzyć, czy SOC działa (KPI, które nie są teatrem)

Jeśli mierzysz tylko liczbę alertów, przegrywasz. Alerty mogą rosnąć, bo rośnie widoczność, i to jest OK.

Sensowniejsze wskaźniki:

• MTTD (Mean Time To Detect): średni czas wykrycia.
• MTTR (Mean Time To Respond/Remediate): średni czas reakcji i domknięcia.
• odsetek alertów zamkniętych jako false positive (i jak szybko spada),
• pokrycie technik MITRE w kluczowych obszarach,
• czas od incydentu do wdrożenia poprawki (detekcja + prewencja).

SOC in-house vs outsourcing: decyzja, która rzadko jest “albo-albo”

W praktyce większość dojrzałych organizacji kończy w układzie mieszanym:

• in-house trzyma kontekst: co jest krytyczne, jakie są wyjątki, jak działa biznes,
• zewnętrzni dokładają skalę: noc, weekendy, specjalistyczne analizy, forensics, malware.

To jest sensowne, bo bezpieczeństwo ma rytm miasta: czasem nic się nie dzieje, a czasem jest jeden dzień, który kosztuje rok.

Najczęstsze miny przy SOC in-house (żebyś ich nie nadepnął)

Pierwsza mina to brak ownershipu: “to jest temat security, nie IT”. Druga to brak danych: “czemu nie wykryliśmy, skoro nie logujemy”. Trzecia to brak decyzji: SOC widzi problem, ale nikt nie ma mandatu, żeby wyłączyć usługę, zablokować konto prezesa albo zatrzymać deployment.

Czwarta mina jest najbardziej podstępna: SOC jako raportowanie, a nie reagowanie. Jeśli jedyne, co powstaje, to dashboardy, to masz centrum prezentacji, nie operacji.

FAQ: krótkie odpowiedzi na typowe pytania

Czy da się zrobić SOC in-house bez SIEM?

Da się zacząć bez “pełnego SIEM”, ale nie da się bez logów i korelacji. Minimalnie potrzebujesz centralizacji zdarzeń i sensownej analityki, inaczej utkniesz na ręcznym grzebaniu.

Ile osób potrzeba na SOC in-house?

To zależy od godzin działania i skali. Pełne 24/7 to zwykle więcej niż “kilka osób”, bo dochodzą zmiany i utrzymanie jakości. Dlatego hybryda bywa najlepszym startem.

Co jest pierwsze: EDR czy SIEM?

Jeśli masz wybierać, EDR daje szybki efekt na endpointach, a SIEM daje centralny obraz. W idealnym świecie robisz oba, ale w realnym świecie zaczynasz od tego, co zamyka największą lukę w widoczności.

Podsumowanie

SOC in-house to świetny ruch, jeśli traktujesz go jak produkt operacyjny: ma właściciela, proces, dane, narzędzia i cele biznesowe. Najlepszy SOC nie jest “najdroższy” ani “najbardziej skomplikowany”. Jest ten, który wykrywa szybko, reaguje powtarzalnie i uczy się po każdym incydencie, zamiast powtarzać te same błędy z nowym dashboardem.

(A jeśli chcesz jedno zdanie, które warto powiesić nad biurkiem: SOC to nie narzędzie. SOC to nawyk.)