Нам сказали отправлять логи в SOC — какой отдел или сотрудник должен этим заниматься в компании нашего размера?

Если попробуете повесить это на системщиков, через месяц обе стороны начнут обвинять друг друга. Системщик логи зальёт и забудет, SOC скажет «этих логов не хватает», клиент останется между ними. Нужен хотя бы один координатор, который шарит в безопасности.

Когда передаёте данные с серверов через syslog или агент, не забудьте посчитать расход трафика и нагрузку на процессор сервера. Системная команда это сделает, но согласованность временных меток и шифрованная передача логов требуют отдельного внимания.

Мы с командой из 40 человек прошли через похожий процесс. Брали внешний консалтинг по безопасности на 20 часов в месяц, стоило около 18.000 TL в месяц. Наш системщик тратил всего 4 часа в неделю, и процесс наладился.

Не отправляйте логи с бухты-барахты только потому что клиент попросил. Большинство SOC-компаний берут доплату за каждый лишний лог. Если не сузите охват того какие системы логировать, в конце месяца получите огромные счета.

Какие именно логи хочет от вас клиент? Только ОС и файрвол, или запросы к базе данных и активность внутри приложения тоже входят в охват?

Сразу подготовьте матрицу эскалации. Кого будить, когда SOC позвонит ночью? 1) Системного администратора, 2) Тимлида разработки, 3) Гендира? Не начинайте интеграцию, пока не зафиксируете это письменно.

у нас тоже всё свалили на системщиков, через два месяца ребята были на грани увольнения. это дело точно надо вести с внешним консультантом.

Кароче, инфраструктура должна остаться на системной команде, код — на разработчиках, но для слежения за алертами и координации по договору точно нужно брать внешнего спеца.

Взял на заметку, спасибо. Автоматический отчет о сканировании и пентест — это не одно и то же.

Попробую.

Сохранил. Первые три месяца все идет хорошо, проблемы всплывают на четвертом.

При принятии решений записывайте и худший сценарий, а не только лучший. Исправьте, если я ошибаюсь.

верно.

Давайте немного раскрою техническую сторону. Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно.

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

Я тоже об этом думал. Забытые тестовые среды становятся входом в систему чаще, чем продакшн.

Абсолютно. Если добавить к этому: Меры, принятые без инвентаризации, оставляют открытыми двери, о которых вы не знаете.

Прежде чем принимать решение, посмотрите, какие данные у вас есть. Надеюсь, это будет полезно.

Именно так. Если делаете впервые начните с малого, масштабирование потом.

Если напишете результат здесь, это поможет и другим.

Именно так. Большинство инцидентов начинается не с уязвимости, а с украденного пароля.

Безопасность не бывает абсолютной; цель — сделать атаку нецелесообразной. Это мое мнение, не утверждаю, что оно единственно верное.