Jak się pracuje w SOC?

[monthy]

Wlasnie chyba najwiekszym bledem w tym watku to opinia SOC == SIEM. To jest absolutny blad.
Tak DDoS to tez SOC
A co ma SP do DDoSa? Nie wiedziales ze ochrona przed DDoS to nie tylko SP?
Pracowalem dla oddzialow duzych firm z USA w Wawie/KRK

[PatrykW]

Wlasnie chyba najwiekszym bledem w tym watku to opinia SOC == SIEM. To jest absolutny blad.
Tak DDoS to tez SOC
A co ma SP do DDoSa? Nie wiedziales ze ochrona przed DDoS to nie tylko SP?
Pracowalem dla oddzialow duzych firm z USA w Wawie/KRK

SP ma do DDoS tyle ze jak masz slaby backbone to lezysz, (pomijam kwestie blackholingu itp itd)
Cale scrubbing center jest pomiedzy WANem a warstwa sieciowa hosta,

Zgodze sie ze DDoS ma tyle do SOC, ze tutaj moga abouse leciec

Tak sie zastanawiam, SOC to nie SIEM, zatem czym SOC, jak nie monitorowaniem trendow zwiazanych z aspaktami bezpieczenstwa, analiza logow ?
Czy cos mnie pominelo ?

[psztoch]

(...)

Teraz otwierajac kilka biur to czynsz x2/3, do każdego biura trzeba zatrudnić managiera (chyba nie zostawicie tych ludzie bez szefa).
Żeby teraz ogarnąć problemy 1 i 2? Trzeba szukac ludzi do roboty, zmuszać ich do pracy w weekendy, święta, albo o dziwnych godzinach, wyobrażacie sobie to w USA? Ja nie.
Więc 100x łatwiej jest odpalić takie biuro w jednym miejscu, na kilka zmian, zrobić to tanio, dobrze i bez zbednych problemów z ludzmi.

Pzdr
mHuba

mHuba jak zwykle konkretnie i na temat.

[CCIESecWannabe]

SOC SOCowi nie równy. Moje doświadczenia z SOC w managed services dla amerykańskiego corpo są nieco odmienne od wielu wypowiedzi tutaj, więc i ja się dorzucę.

Bardzo zaskoczony jestem że wiele osób uważa SOC = SIEM. Mój SOC to był po prostu NOC z pudełkami czysto pod security - 5 vendorów firewalli, 3 vendorów web proxy, 2 vendorów load balancerów. Żadnego SIEM; od tego (+IDS/IPS) był Threat Management team i była to zupełnie inna ekipa. Praca zmianowa jako regóła też mi jakoś nie pasuje. Ogólnie wiem że wiele ludzi uważa pracę w *OC za kiepską, ja natomiast pracę w SOC wspominam dobrze.

1. U mnie był FTS: Indie -> EU -> USA. Każdy pracował w swoich businness hours, jedynie USA miały early i late shift które mocno się nakładały. Pod względem ilości głów to 50% USA, 30% Indie, 20% EU. Wielu ludzi w USA pracowało z domu.
2. Pracowałem poniedziałek-piątek, bez względu na to czy było to święto czy nie + 1 weekend w miesiącu, ale wtedy czwartek lub piątek przed weekendem i poniedziałek lub wtorek po weekendzie miałem wolny. Oczywiście stawka weekendowa, czy świąteczna doliczana do pensji. On-call miał jedynie L3 engineer w weekend, bo pracował tylko pn-pt. W święta wielu klientów miało change freeze, do tego odddział z Indii przychodził wtedy częściowo później, więc u nas kto chciał to miał wolne.
3. Z mojego doświadczenia można się dużo nauczyć, a jak piszesz osoba z CCNA nawet bardzo dużo. Oczywiście typowy SOC to będą inżynierowie Level 1, 2 i 3. L1 to incydenty typu interface down, device unreachable, itp., prosty troubleshooting i eskalacja do L2 i proste change: dodaj ACL, dodaj static routing, dump configu, dump logów, itp. Ilościowo L1 odwalał u mnie 2/3 wszystkich ticketów. L2 robi bardziej skomplikowane change (np. VPN, policy na load balancerach czy proxy, których L1 przeważnie nie zna wcale), change peer review od L1 i L2, asystuje L1; Z troubleshootingu to potencjalnie sky is the limit. L3 u nas to chyba tylko case-y w TACu otwierał Pracując na L2 w dobrze zorganizowanym zespole można być na prawdę świetnym wymiataczem, bo jesteś non-stop karmiony nie-trywialnymi problemami z różnych środowisk i od różnych klientów. Powtarzam, w manages services, nie SOCu pod jedną firmę, choć tam pewnie też.
4. Nie mam porównania, ale mam wrażenie że bardziej urozmaicona. Niestety, wydaje mi się też że bardziej stresująca, bo czasem mieliśmy straszny zapier... Plus taki że to są tickety, więc o 17 część z nich wywalasz ze swojgo wiaderka i zapominasz o wszystkim.
5. Angielski musisz mieć dobry. Częsty troubleshooting, bardziej skomplikowane konfiguracje, czy nawet migracje z klientem i innymi zespołami przez telefon. Do tego ciężko zrozumiały akcent ludzi z różnych części świata i niekiedy krzyczenie przez słuchawkę do jakiegoś człowieka który nurkuje w jakiejś szafie w DC i z tobą gada

[ormek]

SOC to zazwyczaj cost center, aby zabezpieczyc czas USA, w europie musisz miec zmiane nocna. Nikt nie otworzy SOC w kraju tylko dlatego bo roznica w czasie.

Dokładnie tak jest jak pisze Wojtachinho.
SOC, GNOC, NOC są w jednym miejscu, pracuje się zmianowo, Polska, Indie, Filipiny

Kyniu jak zwykle zabiera głos w temacie o którym NIE MA ZIELONEGO POJĘCIA.

Pzdr
mHuba

To mocno zależy. W mojej firmie (total assets ~500 mld euro, wiec nie mała) czy to SOC czy NOC ludzie są all over the world i jest follow the sun (podzieleni na 3 regiony APAC->EMEA->AMER).
Wygląda więc, że jakieś tam pojęcie ta gimbaza ma.
Fakt, że trend jest w kierunku konsolidacji zamiast rozpraszania zasobów, ale dotyczy to raczej wygaszania malutkich lokalizacji i pracy typowo home office (stałego). Tworzą się jednak huby typowo regionalne, tak więc follow the sun zostaje.

[Phibrizzo]

SOC SOCowi nie równy. Moje doświadczenia z SOC w managed services dla amerykańskiego corpo są nieco odmienne od wielu wypowiedzi tutaj, więc i ja się dorzucę.

Bardzo zaskoczony jestem że wiele osób uważa SOC = SIEM. Mój SOC to był po prostu NOC z pudełkami czysto pod security - 5 vendorów firewalli, 3 vendorów web proxy, 2 vendorów load balancerów. Żadnego SIEM; od tego (+IDS/IPS) był Threat Management team i była to zupełnie inna ekipa. Praca zmianowa jako regóła też mi jakoś nie pasuje. Ogólnie wiem że wiele ludzi uważa pracę w *OC za kiepską, ja natomiast pracę w SOC wspominam dobrze.

1. U mnie był FTS: Indie -> EU -> USA. Każdy pracował w swoich businness hours, jedynie USA miały early i late shift które mocno się nakładały. Pod względem ilości głów to 50% USA, 30% Indie, 20% EU. Wielu ludzi w USA pracowało z domu.
2. Pracowałem poniedziałek-piątek, bez względu na to czy było to święto czy nie + 1 weekend w miesiącu, ale wtedy czwartek lub piątek przed weekendem i poniedziałek lub wtorek po weekendzie miałem wolny. Oczywiście stawka weekendowa, czy świąteczna doliczana do pensji. On-call miał jedynie L3 engineer w weekend, bo pracował tylko pn-pt. W święta wielu klientów miało change freeze, do tego odddział z Indii przychodził wtedy częściowo później, więc u nas kto chciał to miał wolne.
3. Z mojego doświadczenia można się dużo nauczyć, a jak piszesz osoba z CCNA nawet bardzo dużo. Oczywiście typowy SOC to będą inżynierowie Level 1, 2 i 3. L1 to incydenty typu interface down, device unreachable, itp., prosty troubleshooting i eskalacja do L2 i proste change: dodaj ACL, dodaj static routing, dump configu, dump logów, itp. Ilościowo L1 odwalał u mnie 2/3 wszystkich ticketów. L2 robi bardziej skomplikowane change (np. VPN, policy na load balancerach czy proxy, których L1 przeważnie nie zna wcale), change peer review od L1 i L2, asystuje L1; Z troubleshootingu to potencjalnie sky is the limit. L3 u nas to chyba tylko case-y w TACu otwierał Pracując na L2 w dobrze zorganizowanym zespole można być na prawdę świetnym wymiataczem, bo jesteś non-stop karmiony nie-trywialnymi problemami z różnych środowisk i od różnych klientów. Powtarzam, w manages services, nie SOCu pod jedną firmę, choć tam pewnie też.
4. Nie mam porównania, ale mam wrażenie że bardziej urozmaicona. Niestety, wydaje mi się też że bardziej stresująca, bo czasem mieliśmy straszny zapier... Plus taki że to są tickety, więc o 17 część z nich wywalasz ze swojgo wiaderka i zapominasz o wszystkim.
5. Angielski musisz mieć dobry. Częsty troubleshooting, bardziej skomplikowane konfiguracje, czy nawet migracje z klientem i innymi zespołami przez telefon. Do tego ciężko zrozumiały akcent ludzi z różnych części świata i niekiedy krzyczenie przez słuchawkę do jakiegoś człowieka który nurkuje w jakiejś szafie w DC i z tobą gada

No tak, dzwonia pozniej do mnie panie z rekrutacji i chca mnie na pozycje w Network Security bo mam wpisane security w CV
Tak powaznie, twoja firma miala\ma program cybersecurity na przedpotopowym poziomie. W programie cyberbezpieczenstwa zadnej szanujaca sie organizacji nie moze zabraknac produktow z rodziny SIEM. Juz nawet nie chodzi o te przestarzale rule-based SIEM ale takze o najnowsze trendy "Behavioral based" i Security Analytics ktore zgodnie z nowa regulacja KE GDPR (EU) 2016/679 beda wymagane w ramach tzw. State-of-art.
Wiele firm uzywa nazwy SOC raczej propagandowo jesli nie wdroza odpowiednich technologii w ramach swojej struktury

[monthy]

Tak powaznie, twoja firma miala\ma program cybersecurity na przedpotopowym poziomie. W programie cyberbezpieczenstwa zadnej szanujaca sie organizacji nie moze zabraknac produktow z rodziny SIEM. Juz nawet nie chodzi o te przestarzale rule-based SIEM ale takze o najnowsze trendy "Behavioral based" i Security Analytics ktore zgodnie z nowa regulacja KE GDPR (EU) 2016/679 beda wymagane w ramach tzw. State-of-art.
Wiele firm uzywa nazwy SOC raczej propagandowo jesli nie wdroza odpowiednich technologii w ramach swojej struktury

Jeszcze raz - SOC nie równa sie SIEM. Skad wiesz na jakim poziomie jest jakis SOC skoro nie wiesz czym sie zajmuja? Moga zarzadzac firewallami swoich klientow (tak zeby np. kazda placowka sieci restauracji byla zgodna z PCI), moga chronic organizacje przed atakami DDoS albo moga tez dostarczac proxy w chmurze i analizowac ruch/whitelistowac strony. Jeszcze raz, co ma do tego SIEM?

[Phibrizzo]

Tak powaznie, twoja firma miala\ma program cybersecurity na przedpotopowym poziomie. W programie cyberbezpieczenstwa zadnej szanujaca sie organizacji nie moze zabraknac produktow z rodziny SIEM. Juz nawet nie chodzi o te przestarzale rule-based SIEM ale takze o najnowsze trendy "Behavioral based" i Security Analytics ktore zgodnie z nowa regulacja KE GDPR (EU) 2016/679 beda wymagane w ramach tzw. State-of-art.
Wiele firm uzywa nazwy SOC raczej propagandowo jesli nie wdroza odpowiednich technologii w ramach swojej struktury

Jeszcze raz - SOC nie równa sie SIEM. Skad wiesz na jakim poziomie jest jakis SOC skoro nie wiesz czym sie zajmuja? Moga zarzadzac firewallami swoich klientow (tak zeby np. kazda placowka sieci restauracji byla zgodna z PCI), moga chronic organizacje przed atakami DDoS albo moga tez dostarczac proxy w chmurze i analizowac ruch/whitelistowac strony. Jeszcze raz, co ma do tego SIEM?

Wspolczesne Security Operation Center nie moze istniec bez produktu typy SIEM jesli ma uchodzic za zgodne ze State-of-art. Wiem ze wiekszosc z was jako osoby techniczne lub pracujace w firmach nie stosujacych najnowszych rozwiazan moze miec problem ze zrozumieniem tej koncepcji. Co byscie nie powiedzieli. Jesli jako uslugodawca swiadczycie uslugie dla swoich klientow zwiazane z zarzadzaniem infrastruktura security controls (takimi jak proxy, firewalle itp) to nie mozecie nazywac tego SOCiem. Jest to bardziej MSS (Managed Security Service) ktora dostarcza tylko jeden komponent dla calego programu. Z nazywaniem tego SOC to taki sam zabieg marketingowy jak ze slowami "Next Generation". Swego czasu wszyscy zaczeli naduzywac tego zdania chcac zaistniec marketingowo.

[monthy]

Czesciowo sie z Toba zgadzam, ale nawet pracujac w MSS oficjalnie pracujesz w SOCu (taka jest oficjalna nazwa stanowiska). I nie mowie o jakis malych firmach, tylko o liderach w okreslonych uslugach z security. Nie ma znaczenia ze oferuja tylko jeden produkt, a nie zarzadzaja cala infrastruktura klienta od strony security. Ja bym tu podzielil tu SOCi na takie ktore pracuja dla jednej firmy i ogarnia wszystko co zwiazane z security (tam na pewno jest SIEM i przegladanie logow) i na take ktore dostarczaja konkretne uslugi dla klientow (MSS) i tam juz SIEMa moze nie byc.