Как избежать ошибок в построении SOC. Лайфхаки от Тинькофф Банка
Поддерживаю Алексея Лукацкого! Все советы по делу! Я бы дополнил ещё несколькими идеями.
- Не изобретайте велосипед. Не нужно разрабатывать все правила и сценарии с нуля – в условиях «гитхабизации» огромное количество готовых правил корреляции доступны аналитикам. Умейте использовать чужой опыт – iOc, техники поведения злодеев и т.д. Многое из этого открыто и доступно в интернет, например, в каналах Twitter.
- Переиспользуйте. Выясните, что уже реализовано – в мониторинге ИТ, клиентском антифроде, сверках платежей ОПЕРу. Это не только инфраструктура, это могут и должны быть критичные прикладные системы, DLP, антифрод.
- SOC – это в первую очередь набор процессов и людей, структурированных под вашу организацию. SIEM не всегда главный компонент, а возможно, что он в вашем SOC и не нужен. Не обязательно стараться все затянуть в SIEM – вполне нормальный вариант делать прекорреляцию на sysmon на конечных хостах.
- Интегрируйте проактивные техники threatintelligence/threathunting в процессы SOC.
- Тестируйте каждое правило SOC. Постоянно. Автоматизировано. На практике без этого вы рискуете узнать, что из источника пропали события или уже после инцидента не работает правило. Считаете что закрыли мониторингом какую либо технику хакерской группы? Протестируйте это руками redteam и поставьте на мониторинг. Нет redteam? Найдите способы тестирования и автоматизируйте их. Иначе не считается.
- Внедрение средства защиты не считается, если SOC не принимал в нем участие и не реагирует на него.
- Автоматизируйте все, что можно автоматизировать. Задать вопрос пользователю в мессенджер и обработать его ответ вполне может и робот.
- Профилируйте! Планируйте как развивать направление поиска отклонений от «стандартного» поведения. Думаю, мы все уйдем в machine learning рано или поздно, но уже и сейчас можно на простых выборках выявлять отклонения, а также фильтровать фолс.
.png)