Кстати да, в Информационной безопасности SOC - это Центр мониторинга информационной безопасности. Кто-то даже понимает/реализует шире (включая сюда специалисотв по реагированию и расследованию инцидентов) и вообще саму службу ИБ
О, это вообще отдельная тема. Дело даже не в доменах приложения: существует возможноcсть создать Native Code приложение сразу. А значит никакой JIT компилляции (кототрая на самом деле через ETW может многое рассказать вашему EDR/AV о том что готовится к запуску на мониторящемся устройстве). +SingleFile компилляция, которая в теории позволит запустить ваше приложение даже на неподготовленной системе (без среды CLR). Это с одной стороны делает "старшие" версии .NET как-бы даже более привлекательными для разработчиков оффенсив утиллит.
Но как бы то ни было, по прежнему существуют методы, которые позволят искать артефакты от переиспользуемых утиллит в памяти приложений. По прежнему существует как ETW, так и новый способ: пайп событий.
Я выражу сейчас своё личное мнение: чтобы создать команду нужно прежде всего что-то что-то софтскиловое. Если вы хотите команду, то там должны быть процессы, команда должна работать как команда, если 24/7, то тоже надо особенно организоваться...
Если вопрос именно технологического стека, то сейчас разразится холиварищще, но для небольших команд рекомендуют ELK + Filebeat. Собственно я при написании пользовался для демонмтрации SilkETW и данные подавал в облако Elastic. Очень удобно.
Я выскажу непопулярную мысль, но для некоего идеального Threat Intel SOC в вакууме уровень ложных срабатываний (фолсы) должен быть постоянно высоким: есть два процесса и они как-бы в равновесии
SOC строит гипотезы, потребляет всё больше данных, подключает новые источники, улучшает покрытие и как следствие генерирует больше алертов для расследования
SOC изучает процессы и потоки данных в компании, понимает типичные кейсы расследует фолсу и как следствие фильтрует алерты
А вообще я не могу дать никакой оценки не ознакомившись с предметной обастью конкретного заказчика
Кстати да, в Информационной безопасности SOC - это Центр мониторинга информационной безопасности. Кто-то даже понимает/реализует шире (включая сюда специалисотв по реагированию и расследованию инцидентов) и вообще саму службу ИБ
О, это вообще отдельная тема. Дело даже не в доменах приложения: существует возможноcсть создать Native Code приложение сразу. А значит никакой JIT компилляции (кототрая на самом деле через ETW может многое рассказать вашему EDR/AV о том что готовится к запуску на мониторящемся устройстве). +SingleFile компилляция, которая в теории позволит запустить ваше приложение даже на неподготовленной системе (без среды CLR). Это с одной стороны делает "старшие" версии .NET как-бы даже более привлекательными для разработчиков оффенсив утиллит.
Но как бы то ни было, по прежнему существуют методы, которые позволят искать артефакты от переиспользуемых утиллит в памяти приложений. По прежнему существует как ETW, так и новый способ: пайп событий.
Я выражу сейчас своё личное мнение: чтобы создать команду нужно прежде всего что-то что-то софтскиловое. Если вы хотите команду, то там должны быть процессы, команда должна работать как команда, если 24/7, то тоже надо особенно организоваться...
Если вопрос именно технологического стека, то сейчас разразится холиварищще, но для небольших команд рекомендуют ELK + Filebeat. Собственно я при написании пользовался для демонмтрации SilkETW и данные подавал в облако Elastic. Очень удобно.
Я выскажу непопулярную мысль, но для некоего идеального Threat Intel SOC в вакууме уровень ложных срабатываний (фолсы) должен быть постоянно высоким: есть два процесса и они как-бы в равновесии
SOC строит гипотезы, потребляет всё больше данных, подключает новые источники, улучшает покрытие и как следствие генерирует больше алертов для расследования
SOC изучает процессы и потоки данных в компании, понимает типичные кейсы расследует фолсу и как следствие фильтрует алерты
А вообще я не могу дать никакой оценки не ознакомившись с предметной обастью конкретного заказчика