Возможно, вы слышали об идее сдвига влево в сфере безопасности: по мере того, как разработчики все больше переходят в облако, специалисты по безопасности все больше смотрят вверх - или влево - туда, где инициируются процессы разработки. По мере того, как вы переходите от разработки к вопросам / ответам, а затем к производству (двигаясь вправо), возникают более глубокие размышления о сквозной безопасности.
Давайте сделаем еще один шаг вперед и поговорим о чем-то новом - о безопасности «проведите пальцем влево».
На самом высоком уровне индустрия безопасности пытается решить две ключевые проблемы параллельно:
- сбор правильных данных
- быстро оценить
Первая проблема связана с растущей темой вокруг «аналитики безопасности» - хлебных крошек, которые помогают нам понять, есть ли реальные инциденты безопасности, требующие нашего времени и внимания. Поверхность атаки любого предприятия сегодня больше, чем когда-либо. Вы должны смотреть на сетевой трафик на уровне пакетов; вы должны смотреть логи сервера, приложения и пользователя; и вы должны посмотреть на запущенные команды и процессы. Вы также должны охватывать все среды: «голое железо» в локальной среде, виртуализированные, контейнеры и публичное облако.
Вторая проблема заключается в том, что даже если вы видите нужные данные или аналитику безопасности, как быстро оценить ценность оповещения? Большинство команд безопасности сегодня скажут вам, что они перегружены данными, получают слишком много ложных срабатываний и гоняются за слишком большим количеством оповещений низкого уровня. При традиционном подходе SIEMВ таком случае вы можете получать 3,000 оповещений в день, и реагирование на такое количество становится проблемой, требующей человеческого фактора.
Мне нравится думать об аналитике безопасности как о просеивании стога сена, набитого иголками, и, в идеале, вы хотите все лучше и лучше просеивать стог сена. Любой продукт, который позволяет вам каждый день укреплять вашу позицию безопасности, - это то, что вам нужно. Эта возможность возникает не только благодаря машинному обучению или разрекламированному влиянию «искусственного интеллекта», она возникает из-за просмотра всех предупреждений и вопросов «связаны ли какие-либо из них?»
Давайте возьмем простой пример, допустим, Стив входит на сервер в 4 часа утра (а я никогда раньше не входил в систему), и мой IP-адрес из Таиланда, но я живу в Сан-Франциско, и приложение, которое я запустил, не приложение, которое я запускал раньше. Эти отдельные предупреждения могут быть восприняты как шум, но, если рассматривать их вместе, вы увидите закономерность, которая создает веские доказательства того, что происходит нарушение!
Так как же собрать все больше и больше данных, не увеличивая и без того слишком большой объем предупреждений системы безопасности? Чтобы получить представление о каждой среде, о которой я упоминал выше, вам необходимо объединить самый широкий в отрасли механизм сбора данных о безопасности с автоматизированными методами для обогащения сбора данных и сопоставления, казалось бы, шумных низкоуровневых предупреждений и демонстрации их фактической взаимосвязи.
Как вы помогаете аналитикам безопасности масштабироваться за счет автоматизации, чтобы они были выделены простым «красным» или «зеленым» выделением, и они просто смахнули влево, чтобы отклонить предупреждение, или смахнуть вправо, чтобы принять его и глубже изучить проблему? В идеале аналитику безопасности нужно было бы проверять не 3,000 предупреждений в день, а три, чтобы расследование и запуск автоматических ответов можно было запрограммировать как политики.
Такое мышление все больше и больше людей называют службой управляемого обнаружения и реагирования - MDR-as-a-Service. Использование автоматизации, чтобы помочь вашей команде масштабироваться и предлагать вашим клиентам перспективную ценность.
