Как часто бывает, сначала ты ищешь решение на рынке и, не найдя его, делаешь самостоятельно и под себя. А потом получается настолько хорошо, что ты отдаешь это другим. Так было и с OpenSOC, open source решением для управления большими объемами данных в области кибербезопасности, которое было разработано в Cisco для своих собственных нужд, а потом было выложено на GitHub для всеобщего доступа.
![Архитектура Cisco OpenSOC](https://habrastorage.org/r/w1560/files/4f8/056/471/4f8056471dae400f9cae1b3cafa029f7.png)
Если вспомнить одну из наших предыдущих заметок про то, как выстроен процесс управления доступом внутри Cisco, то можно обратить внимание на количество устройств, которые нам приходится контролировать. А теперь давайте посмотрим, сколько данных, важных для безопасности, эти устройства генерят/пропускают через себя ежедневно:
Всего же мы собираем и храним для целей анализа 4 ТБ данных ежедневно. Это огромный объем информации, для эффективного управления которой нашей службе кибербезопасности был просто необходим специализированный инструментарий. Первое, что приходит в голову, когда возникает тема управления событиями безопасности, — это SIEM (Security Information Event Management), и мы, как и многие другие компании в мире, тоже пытались использовать такие решения. Но к сожалению, ни одно решение SIEM не смогло решить наши задачи и причин тому было несколько:
В качестве альтернативы существующим SIEM-решениям мы стали использовать Splunk, который позволил решить многие перечисленные выше проблемы, да еще и стоил дешевле. Но… Splunk, несмотря ни на что, все-таки не смог решить все наши задачи; только 95% из них. Он собирал данные от наших антивирусов, МСЭ, IDS/IPS, систем контентной фильтрации и т.п. Но 5% информации, очень важной для нашей группы реагирования на инциденты, оставалась за бортом. Очень важной информации об угрозах, нападающих, их методах и тактике. Не так-то просто было обогатить имеющиеся в Splunk данные от средств защиты этой информацией. Сначала мы создавали различные простые скрипты и утилиты, каждый(ая) из которых решали свои узкие задачи. Потом возникла идея сделать свое решение, превратив его в полноценную платформу для анализа больших данных в области кибербезопасности (Threat Intelligence Platform).
![Уровни и численность специалистов реагирования на инциденты в Cisco](https://habrastorage.org/r/w1560/files/853/4a4/f54/8534a4f54ff54d98a5cbe37fcb7e9f92.png)
Так как данная система, получившая название OpenSOC, создавалась для собственных нужд, то никаких разработчиков, занимающихся созданием продуктов Cisco, привлекать было нельзя — приходилось использовать только собственные силы службы ИБ. Поэтому вполне логично, что мы не стали писать все с нуля, а задействовали open source решения, среди которых главную роль сыграли:
![Архитектура Apache Storm в Cisco OpenSOC](https://habrastorage.org/r/w1560/files/f80/95b/2b9/f8095b2b970d4c52a78df76eeefdd5c9.png)
![Процесс обогащения исходных данных](https://habrastorage.org/r/w1560/files/a53/119/ed5/a53119ed5ee940b6bec2904729626e2c.png)
OpenSOC стал унифицированной платформой анализа данных безопасности в Cisco, которая:
С технической точки зрения в основе лежит кластер из 45 серверов Cisco UCS (1440 процессоров, 12 ТБ памяти), вышеупомянутые технологии Hadoop, Hive, HBase, Elasticsearch и ряд других. Объем хранилища OpenSOC в Cisco составляет 1,2 ПБ. В одной таблице находится свыше 1,3 триллионов строк.
![Хранилище OpenSOC в Cisco](https://habrastorage.org/r/w1560/files/65d/49f/cbb/65d49fcbb9f74a5198566d5c32c90c17.png)
Cisco OpenSOC мы стали создавать в 2013-м году и в сентябре 2013-го появился первый прототип. На половине пути, в декабре 2013-го года к нам присоединилась компания Hortonworks, давшая толчок развитию проекта и привнесшая немало интересных идей по использованию open source компонентов для высокопроизводительной и распределенной платформы, которой должен был стать OpenSOC. В марте 2014 года мы завершили разработку OpenSOC, а в сентябре 2014 мы сделали его публичным и выложили на GitHub.
![image](https://habrastorage.org/r/w1560/files/fe9/61d/55e/fe961d55ecd2434c8c67f1ce48b4b8cd.png)
В базовой комплектации поддерживает функции сбора данных, их хранения и анализа, а также обогащения сведениями об угрозах, жертвах, нападающих. Число адаптеров, которые по сути и выполняют функцию корреляции различных событий, в публичной версии OpenSOC невелико. Как и в случае с большинством SIEM, правила корреляции “из коробки” работают не очень хорошо, и поэтому в OpenSOC их надо писать самостоятельно под каждого потребителя системы. В группе компаний NTT, например, в качестве инструмента для создания триггеров и правил корреляции используется open source движок Esper.
![Пример правила корреляции на базе Esper](https://habrastorage.org/r/w1560/files/5e2/cd7/56d/5e2cd756dd55448f90ac586ccd649ad7.png)
После успеха OpenSOC внутри компании, его было решено развивать в качестве основы для наших аутсорсинговых услуг. Cisco Active Threat Analytics (ATA) по сути представляет собой распределенный Security Operations Center (SOC), который берет на себя функции мониторинга и управления информационной безопасностью наших заказчиков. Развивая OpenSOC и внутри компании и в рамках Cisco ATA, мы столкнулись с тем, что лицензия Apache 2.0 не всегда позволяет нам реализовывать все, что мы хотели. Да и только open source компонентами мы уже не могли ограничиваться для решения всех возникающих у нас задач.
![Графический интерфейс на базе OpenSOC](https://habrastorage.org/r/w1560/files/ec4/1d8/fbd/ec41d8fbd89d4539a63f5f68a8469ded.png)
Было принято решение разделить развитие OpenSOC на два направления. Первое оставалось в Cisco, для нужд нашей службы ИБ и сервиса ATA. А вот второе направление оказалось очень интересным. OpenSOC вошел в инкубатор Apache, став полноценным проектом, развиваемым сообществом open source. OpenSOC поменял и имя, став называться Apache Metron. В апреле 2016-го года вышла первая версия Apache Metron 0.1. Идеология при этом осталась неизменной и пользователям OpenSOC будет легко перейти на Apache Metron.
![Apache Metron](https://habrastorage.org/r/w1560/files/eb3/0c5/ecd/eb30c5ecd1ba40c5b817698d6fa1c262.png)
Cisco OpenSOC получил свое развитие и в другом направлении. На его основе компания MapR создала свое решение Security Log Analytics, которое используется и упомянутой выше компанией NTT, и банком Zions Bank, и другими заказчиками. Но, как и в случае с Apache Metron, идеология OpenSOC остается неизменной — анализ больших данных в целях кибербезопасности и возможность работы не только со структурированными, но и с неструктурированными данными. Это позволяет существенно расширить функции мониторинга угроз в компании и «видеть» гораздо больше чем раньше, используя и большее число источников информации. Например, в компании Cisco за последние несколько лет произошел сдвиг от привычных всем статических правил и сигнатур в сторону анализа поведения, аномалий и threat intelligence. Все это было бы невозможно без Cisco OpenSOC.
![Расширение спектра данных, используемых в Cisco для обнаружения инцидентов ИБ](https://habrastorage.org/r/w1560/files/a09/3c7/b2c/a093c7b2cb0f4ef68cbaca4bbc4b2f32.png)
![Архитектура Cisco OpenSOC](https://habrastorage.org/files/4f8/056/471/4f8056471dae400f9cae1b3cafa029f7.png)
Если вспомнить одну из наших предыдущих заметок про то, как выстроен процесс управления доступом внутри Cisco, то можно обратить внимание на количество устройств, которые нам приходится контролировать. А теперь давайте посмотрим, сколько данных, важных для безопасности, эти устройства генерят/пропускают через себя ежедневно:
- 47 Терабайт данных сетевого трафика
- 1,2 триллиона сетевых событий
- 4,8 миллиарда DNS-запросов для системы Cisco Umbrella
- 4,1 миллиона e-mail сообщений для системы Cisco Email Security Appliance
- 45 миллионов Web-запросов (URL) для системы Cisco Web Security Appliance и Cisco Cloud Web Security
- 15 миллиардов потоков NetFlow для системы Cisco Stealthwatch
- 1,5 миллиона сигналов тревоги от Cisco NGIPS
- 10 тысяч файлов для системы Cisco AMP ThreatGrid.
Всего же мы собираем и храним для целей анализа 4 ТБ данных ежедневно. Это огромный объем информации, для эффективного управления которой нашей службе кибербезопасности был просто необходим специализированный инструментарий. Первое, что приходит в голову, когда возникает тема управления событиями безопасности, — это SIEM (Security Information Event Management), и мы, как и многие другие компании в мире, тоже пытались использовать такие решения. Но к сожалению, ни одно решение SIEM не смогло решить наши задачи и причин тому было несколько:
- сложность индексации данных не от средств защиты информации, включая и поддержку форматов данных от нами разработанных средств ИБ (в данном случае речь идет не о портфолио Cisco, которые мы не только продаем заказчикам, но и используем сами, а собственноручно написанных нашими инженерами по ИБ различных “тулзов” под те или иные задачи)
- серьезные проблемы с масштабированием и скоростью обработки данных (поиск в всего 10 ГБ данных занимал больше 6 минут)
- сложность в кастомизации решения под наши задачи и необходимость переписывать практически с нуля все встроенные правила, которые генерили слишком много ложных срабатываний
- сложность работы со структурированными и неструктурированными данными.
В качестве альтернативы существующим SIEM-решениям мы стали использовать Splunk, который позволил решить многие перечисленные выше проблемы, да еще и стоил дешевле. Но… Splunk, несмотря ни на что, все-таки не смог решить все наши задачи; только 95% из них. Он собирал данные от наших антивирусов, МСЭ, IDS/IPS, систем контентной фильтрации и т.п. Но 5% информации, очень важной для нашей группы реагирования на инциденты, оставалась за бортом. Очень важной информации об угрозах, нападающих, их методах и тактике. Не так-то просто было обогатить имеющиеся в Splunk данные от средств защиты этой информацией. Сначала мы создавали различные простые скрипты и утилиты, каждый(ая) из которых решали свои узкие задачи. Потом возникла идея сделать свое решение, превратив его в полноценную платформу для анализа больших данных в области кибербезопасности (Threat Intelligence Platform).
![Уровни и численность специалистов реагирования на инциденты в Cisco](https://habrastorage.org/files/853/4a4/f54/8534a4f54ff54d98a5cbe37fcb7e9f92.png)
Так как данная система, получившая название OpenSOC, создавалась для собственных нужд, то никаких разработчиков, занимающихся созданием продуктов Cisco, привлекать было нельзя — приходилось использовать только собственные силы службы ИБ. Поэтому вполне логично, что мы не стали писать все с нуля, а задействовали open source решения, среди которых главную роль сыграли:
- Flume (https://flume.apache.org) — распределенный инструмент для сбора и агрегации больших объемов данных из разных источников в разных форматах (Syslog, SNMP, Netflow, JMS, HTTP, файлы, PCAP и т.д.). В OpenSOC Flume собирает телеметрию от различных средств защиты, приложений и оборудования.
- Kafka (http://kafka.apache.org) — распределенный высокопроизводительный брокер сообщений (шина).
- Storm ([http://storm.apache.org]) — распределенный обработчик данных в реальном времени, который получает данные для выполнения вычислений над ними в том числе и от Kafka. Встроенные обработчики позволяют выполнять различные задачи над событиями безопасности — фильтрацию, нормализацию, разбор (парсинг), обогащение сведениями об угрозах. В последнем случае нормализованные данные расширяются контекстом по ИБ — геолокацией, репутацией IP, информацией из Whois и т.п. В публичный вариант OpenSOC по умолчанию входит всего 4 обработчика, занимающихся обогащением исходных данных.
![Архитектура Apache Storm в Cisco OpenSOC](https://habrastorage.org/files/f80/95b/2b9/f8095b2b970d4c52a78df76eeefdd5c9.png)
- Hadoop ([hadoop.apache.org]) — набор утилит и библиотек для разработки выполнения распределенных программ, например, для поисковых и контекстных механизмов. Лежит в основе технологии “Больших данных”. Кластер Hadoop в OpenSOC хранит все данные
- Elasticsearch — система поиска и индексации больших объемов данных в реальном времени.
- HBase — нереляционная распределенная база данных. В OpenSOC обеспечивает долгосрочное хранение сетевых пакетов (PCAP).
- Hive — система управления базами данных на базе Hadoop, в том числе HBase. В OpenSOC обеспечивает долгосрочное хранение событий безопасности.
- MySQL — реляционная система управления базами данных. В OpenSOC хранит метаданные Hive, а также иные данные, например, геолокационные.
- Kibana — система визуализации.
![Процесс обогащения исходных данных](https://habrastorage.org/files/a53/119/ed5/a53119ed5ee940b6bec2904729626e2c.png)
OpenSOC стал унифицированной платформой анализа данных безопасности в Cisco, которая:
- собирает, хранит, обрабатывает и анализирует данные с разных сторон с целью обнаружения аномалий и иных явных и неявных нарушений ИБ
- позволяет использовать различные предиктивные и корреляционные модели для поиска скрытых взаимозавимостей в собранных данных
- учитывает контекст анализируемых данных в реальном времени
- визуализирует события безопасности в нужном среде и генерит отчеты для заинтересованных лиц.
С технической точки зрения в основе лежит кластер из 45 серверов Cisco UCS (1440 процессоров, 12 ТБ памяти), вышеупомянутые технологии Hadoop, Hive, HBase, Elasticsearch и ряд других. Объем хранилища OpenSOC в Cisco составляет 1,2 ПБ. В одной таблице находится свыше 1,3 триллионов строк.
![Хранилище OpenSOC в Cisco](https://habrastorage.org/files/65d/49f/cbb/65d49fcbb9f74a5198566d5c32c90c17.png)
Cisco OpenSOC мы стали создавать в 2013-м году и в сентябре 2013-го появился первый прототип. На половине пути, в декабре 2013-го года к нам присоединилась компания Hortonworks, давшая толчок развитию проекта и привнесшая немало интересных идей по использованию open source компонентов для высокопроизводительной и распределенной платформы, которой должен был стать OpenSOC. В марте 2014 года мы завершили разработку OpenSOC, а в сентябре 2014 мы сделали его публичным и выложили на GitHub.
![image](https://habrastorage.org/files/fe9/61d/55e/fe961d55ecd2434c8c67f1ce48b4b8cd.png)
В базовой комплектации поддерживает функции сбора данных, их хранения и анализа, а также обогащения сведениями об угрозах, жертвах, нападающих. Число адаптеров, которые по сути и выполняют функцию корреляции различных событий, в публичной версии OpenSOC невелико. Как и в случае с большинством SIEM, правила корреляции “из коробки” работают не очень хорошо, и поэтому в OpenSOC их надо писать самостоятельно под каждого потребителя системы. В группе компаний NTT, например, в качестве инструмента для создания триггеров и правил корреляции используется open source движок Esper.
![Пример правила корреляции на базе Esper](https://habrastorage.org/files/5e2/cd7/56d/5e2cd756dd55448f90ac586ccd649ad7.png)
После успеха OpenSOC внутри компании, его было решено развивать в качестве основы для наших аутсорсинговых услуг. Cisco Active Threat Analytics (ATA) по сути представляет собой распределенный Security Operations Center (SOC), который берет на себя функции мониторинга и управления информационной безопасностью наших заказчиков. Развивая OpenSOC и внутри компании и в рамках Cisco ATA, мы столкнулись с тем, что лицензия Apache 2.0 не всегда позволяет нам реализовывать все, что мы хотели. Да и только open source компонентами мы уже не могли ограничиваться для решения всех возникающих у нас задач.
![Графический интерфейс на базе OpenSOC](https://habrastorage.org/files/ec4/1d8/fbd/ec41d8fbd89d4539a63f5f68a8469ded.png)
Было принято решение разделить развитие OpenSOC на два направления. Первое оставалось в Cisco, для нужд нашей службы ИБ и сервиса ATA. А вот второе направление оказалось очень интересным. OpenSOC вошел в инкубатор Apache, став полноценным проектом, развиваемым сообществом open source. OpenSOC поменял и имя, став называться Apache Metron. В апреле 2016-го года вышла первая версия Apache Metron 0.1. Идеология при этом осталась неизменной и пользователям OpenSOC будет легко перейти на Apache Metron.
![Apache Metron](https://habrastorage.org/files/eb3/0c5/ecd/eb30c5ecd1ba40c5b817698d6fa1c262.png)
Cisco OpenSOC получил свое развитие и в другом направлении. На его основе компания MapR создала свое решение Security Log Analytics, которое используется и упомянутой выше компанией NTT, и банком Zions Bank, и другими заказчиками. Но, как и в случае с Apache Metron, идеология OpenSOC остается неизменной — анализ больших данных в целях кибербезопасности и возможность работы не только со структурированными, но и с неструктурированными данными. Это позволяет существенно расширить функции мониторинга угроз в компании и «видеть» гораздо больше чем раньше, используя и большее число источников информации. Например, в компании Cisco за последние несколько лет произошел сдвиг от привычных всем статических правил и сигнатур в сторону анализа поведения, аномалий и threat intelligence. Все это было бы невозможно без Cisco OpenSOC.
![Расширение спектра данных, используемых в Cisco для обнаружения инцидентов ИБ](https://habrastorage.org/files/a09/3c7/b2c/a093c7b2cb0f4ef68cbaca4bbc4b2f32.png)