👋🏻

Коллеги, а кто-то знает, как SACL на процесс можно повесить, или чтобы он его унаследовал? Вот у товарища мониторинг доступа в lsass c помощью мимикатз на базе 4656 и 4663, но как он этого добился - не описывает https://github.com/hunters-forge/ThreatHunter-Playbook/blob/master/playbooks/windows/06_credential_access/T1003_credential_dumping/lsass_access_non_system_account.md

Там табличка есть

В каких журналах они есть я знаю, как такие события получить на доступ к реестру\файлам - тоже в курсе

А вот чтобы к процессам, это впервой...

Среда - маленькая пятница. А отписался, поди, первый отдел Эшелона - побежали ссылку перепрятывать и узнавать, кто слил количество участников.

С дампами вообще-то, но правильная гипотеза была высказана до них.

Хочешь несколько кейсов из нашей, что характерно, российской практики?
1. M&A. Купленная компания использует один SIEM, а купившая - второй. У первой достаточно большая автономия и менять шило на мыло она не готова (инвестиции сделаны, люди обучены, плейбуки написаны). Вторая может только в свой план развития включить переход на единый SIEM. Но будет это через несколько лет.
2. Крупная холдинговая структура строит SOC на все часовые пояса по всей России. SOC двухуровневый - региональные мини-SOCи и один главный в центре. На регионы решили поставить отечественный SIEM. Когда его пытались натянуть на центр, оказалось, что по EPS он не тянет от слова совсем и надо либо ставить кластер из SIEM, что дорого, либо ставить другой, более производительный SIEM.

Первый кейс не очень интересный. Так как ситуация не редкая и чаще всего заканчивается настройки интеграции на уровне (передай наверх мои инциденты) иногда ещё спусти вниз списки плохих IPшников или ещё чего-то такого.

а вот второй кейс интересный.
Правильно ли я понимаю, что в центр был поставлен "хороший" импортный SIEM, и интегрирован на уровне событий с нижестоящими отечественными жигули? и если это вдруг был не спланк. То что в итоге от него получили и как оно работает? нижестоящие прям поток событий льют наверх? и претензий к потоку нет? Нормализован хорошо, агрегирован правильно? все поля из событий есть? и другие вопросы про качество сбора.

Во втором кейсе проект еще идет. Там  только проектирование завершается. Имплементация в 2020 будет. Потом можно будет говорить предметно по твоим вопросам

Володь, ты подталкиваешь к мысли, что во втором кейсе один SIEM - это LM для второго? Я правильно понял, к чему ты клонишь? 😇

хуже. мне кажется весь геморрой (сложности) всё равно будет на нижнем уровне. и большого велью от другого сиема в центре не будет. Кажется что дешевле было бы поставить кластер от того же отечественного решения.  Хотя конечно я не знаю какой там ценник и может есть ещё какие то условия. Но пока выглядит как бантик на палено. красиво конечно. Но всё равно всё в печь.

От реализации зависит. Ты упёрся в то что один сием отдаёт в другой. Иерархическая модель. При этом не рассматриваешь случай параллельной отправки или единой точки сбора логов с расслаиванием по нужным точкам

в обсуждениях такого сценария я участвовал. а вот чтоб хоть кто-то согласился не знаю. Это же как потом перед руковосдтвом и бухам защищать двойные косты?! Но в целом согласен, кейс более рабочий.

Я тут вспомнил) был у меня проект где в один SIEM отправлялись события из 2х разных SIEM...

Вроде до сих пор работает))

С кластером мы тоже сталкивались 😊 30 SIEMов. 5 на макрорегион для сбора данных и один суперSIEM в этом же макрорегионе, чтобы управлять кластером. Про центр умалчиваю. Ахренительный дизайн получается... Но чего не сделаешь для поддержки отечественного производителя

Когда с исходной архитектурой проблемы, то только так и изголяться

непременно вспоминается анекдот про суперлайнер