В чатике про SOCи зашла тут дискуссия на тему, может ли, и если да, то зачем, использовать SOC два разных SIEM (именно SIEM, а не SIEM и LM или SIEM и UEBA). Вынесу я эту тему в блог, чтобы не забылась она и не затерялась. Я сталкивался с такими ситуациями не раз и поэтому не могу назвать это изначально неправильной идеей. Есть несколько сценариев, когда такая схема возможна:
- SIEMы для работы и в рамках импортозамещения. На Западе этот сценарий встретить невозможно (разве, что в Китае, но это уже Восток), а вот в России он не редкость. Компания долгое время жила на зарубежном SIEM, но ввиду либо ухода Splunk из России, либо требований по импортозамещению (для госорганов и госкомпаний) вынуждена переходить на отечественные продукты. Да, тут речь идет о переходе, но для таких проектов он обычно длится не один год и поэтому в организации сосуществуют два SIEM. Иногда, правда, переход даже не планируется, так как отечественный SIEM работает, мягко говоря, неидеально. Например, крупная холдинговая структура строит SOC на все часовые пояса по всей России. SOC двухуровневый — региональные мини-SOCи и один главный в центре. На регионы решили поставить отечественный SIEM. Когда его пытались натянуть на центр, оказалось, что по EPS он не тянет от слова совсем и надо либо ставить кластер из SIEM, что дорого, либо ставить другой, более производительный SIEM.
- SIEM для работы и для compliance. Это частный случай предыдущего кейса, но у него немного иная мотивация. Один SIEM, как правило, зарубежный, используется для реальной работы, а второй, как правило, отечественный, для демонстрации регуляторам при проверках или для сопряжения с ГосСОПКОЙ. В последнем случае до сих пор нет ясности, должны ли средства ГосСОПКИ быть только российского происхождения или нет. С одной стороны, нормативные акты ФСБ говорят, что да. С другой стороны, практика утверждает обратное. Возможно, это явление временное, так как ни ФСБ еще не разработала регламента оценки соответствия средств ГосСОПКИ, ни российские вендоры пока еще не подсуетились с выпуском продуктов под них. В любом случае, видел проекты, где используется Arcsight или QRadar для основного мониторинга, а решение от Positive Technologies использовалось для передачи данных в ГосСОПКУ.
- SIEMы от мамы и от поглощенной компании. Ну тут очевидная история. Купленная компания использует один SIEM, а купившая — второй. У первой достаточно большая автономия и менять шило на мыло она не готова (инвестиции сделаны, люди обучены, плейбуки написаны). Вторая может только в свой план развития включить переход на единый SIEM. Но будет это через несколько лет. А пока надо сосуществовать вместе. При этом речь не идет о том, что эти SIEM независимы — головная компания требует передачи данных из подчиненного SIEM в головной, что можно сделать как на уровне отправки данных об инцидентах, так и в виде отправки определенных или всех событий.
- SIEMы для себя и для предоставления услуг. У нас в рамках оказания услуг по проектированию SOC, один из задаваемых заказчику вопросов звучит так: «Вы планируете использовать SOC для себя или будете предоставлять на нем услугу внешним заказчикам?» От ответа на него зависит многое — не в части процессов или компетенций специалистов (хотя и они немного отличаются), а в части именно технологического стека. «Для себя» можно сделать «на коленке», не очень красиво, но так чтобы работало. Для внешней аудитории или для демонстрации руководству «на коленке» уже не работает и могут понадобиться немного иные решения. Да и совмещать внутренние и внешние источники и события безопасности в одном решении не совсем разумно. Поэтому снова возникает тема с 2 SIEM, хотя в данном случае она и вырожденная, — управляют ими разные подразделения, обменивающииеся, разве что, общими данными Threat Intelligence.
- SIEM для корпоративной сети и для АСУ ТП. Нередко АСУ ТП делают изолированными от внешнего мира и даже от корпоративных сетей. Да и за безопасность АСУ ТП может отвечать подразделение, отличное от корпоративной ИБ. Поэтому и SIEM могут быть изначально разные, которые со временем могут начать обмениваться данными между собой для выявления сложных атак, подразумевающих проникновение через корпоративную сеть (как первый этап kill chain).
- SIEM для корпоративной сети и для облачных сред. Кейс, схожий с предыдущим, но отличающийся тем, что для мониторинга облачных сред Azure, GCP или AWS используются встроенные в облачные платформы SIEM, а корпоративная сеть мониторится «по старинке». Я про эту историю писал большой обзор на Хабре (часть 1 и часть 2).
- SIEM для базовой аналитики и а-ля SIEM для глубокого анализа (Big Data Security Analytics). Наверное, это не совсем история про два классических SIEM, так как второй компонент больше относится к инструменту анализа, чем к инструменту визуализации событий безопасности. Но все-таки, учитывая, что SIEM используется для сбора данных и их анализа, могу отнести его к ситуации, когда в организации используется два разных решения. Второй SIEM нередко даже пишут сами на базе open source компонентов, закладывая в него богатый инструментарий для глубокой аналитики событий ИБ на базе машинного обучения. Например, в Cisco именно так родился OpenSOC, про который я писал 3 года назад на Хабре.
- SIEM подороже и подешевле. Учитывая, что SIEM часто лицензируются по EPS и при большом потоке событий цена решения может быть достаточно велика. Поэтому возникает соблазн, когда вы вместо дорогого SIEM берете тот, у которого цена лицензии на EPS обходится дешевле, или тот, у которого вообще схема лицензирования, отличная от EPS.
- SIEM побыстрее и помедленнее. В зависимости от архитектуры SIEM, использования реляционной или нереляционной базы данных, скорость индексации и поиска событий ИБ может стать ключевым фактором при выборе SIEM. Мы в Cisco в свое время, среди прочего, по этой причине отказались от одного из SIEM и стали писать свой OpenSOC. При этом у нас продолжает использоваться Splunk для работы с краткосрочной аналитикой и для визуализации. А OpenSOC работает с долгосрочными данными, ретроспективой и неструктурированной информацией.
Да, у вас будут сложности при объединении двух разных SIEM в единый комплекс, когда одно из решений выступает в качестве источника событий для другого. Особенно учитывая, что они могут иметь разные форматы данных, разные их схемы. Но при желании такой вариант все-таки возможен. В ряде случаев поток событий будет распараллеливаться между двумя SIEMами. В ряде случаев у вас IRP/SOAR может работать с двумя SIEMами. Все эти варианты непросты в реализации, что повышает вероятность ошибки. Но и отбросить этот вариант тоже не совсем правильно — иногда применение двух SIEM вполне оправдано. В любом случае описанные выше сценарии вполне рабочие, чтобы разговор о двух разных средствах мониторинга событий ИБ можно было рассматривать как глупую шутку или вырожденный кейс.
Но при этом, если уж вы идете по пути двух и более (и такое тоже бывает) SIEM, убедитесь, что они обладают продвинутым API, который позволяет не только делать им запросы друг к другу, но и который поддерживается вашей IRP/SOAR. Тогда интеграция SIEM станет возможной.
В 2017-м году для SOC Forum я сваял много демотиваторов и мемасиков, одним из которых был такой:
И ведь как в воду глядел. Спустя год с лишним предсказание сбылось, правда для другого вендора. Поэтому вопрос про 2 SIEM вполне себе насущный 🙂
