Как часто бывает, сначала ты ищешь решение на рынке и, не найдя его, делаешь самостоятельно и под себя. А потом получается настолько хорошо, что ты отдаешь это другим. Так было и с OpenSOC, open source решением для управления большими объемами данных в области кибербезопасности, которое было разработано в Cisco для своих собственных нужд, а потом было выложено на GitHub для всеобщего доступа.
Если вспомнить одну из наших предыдущих заметок про то, как выстроен процесс управления доступом внутри Cisco, то можно обратить внимание на количество устройств, которые нам приходится контролировать. А теперь давайте посмотрим, сколько данных, важных для безопасности, эти устройства генерят/пропускают через себя ежедневно:
Всего же мы собираем и храним для целей анализа 4 ТБ данных ежедневно. Это огромный объем информации, для эффективного управления которой нашей службе кибербезопасности был просто необходим специализированный инструментарий. Первое, что приходит в голову, когда возникает тема управления событиями безопасности, — это SIEM (Security Information Event Management), и мы, как и многие другие компании в мире, тоже пытались использовать такие решения. Но к сожалению, ни одно решение SIEM не смогло решить наши задачи и причин тому было несколько:
В качестве альтернативы существующим SIEM-решениям мы стали использовать Splunk, который позволил решить многие перечисленные выше проблемы, да еще и стоил дешевле. Но… Splunk, несмотря ни на что, все-таки не смог решить все наши задачи; только 95% из них. Он собирал данные от наших антивирусов, МСЭ, IDS/IPS, систем контентной фильтрации и т.п. Но 5% информации, очень важной для нашей группы реагирования на инциденты, оставалась за бортом. Очень важной информации об угрозах, нападающих, их методах и тактике. Не так-то просто было обогатить имеющиеся в Splunk данные от средств защиты этой информацией. Сначала мы создавали различные простые скрипты и утилиты, каждый(ая) из которых решали свои узкие задачи. Потом возникла идея сделать свое решение, превратив его в полноценную платформу для анализа больших данных в области кибербезопасности (Threat Intelligence Platform).
Так как данная система, получившая название OpenSOC, создавалась для собственных нужд, то никаких разработчиков, занимающихся созданием продуктов Cisco, привлекать было нельзя — приходилось использовать только собственные силы службы ИБ. Поэтому вполне логично, что мы не стали писать все с нуля, а задействовали open source решения, среди которых главную роль сыграли:
OpenSOC стал унифицированной платформой анализа данных безопасности в Cisco, которая:
С технической точки зрения в основе лежит кластер из 45 серверов Cisco UCS (1440 процессоров, 12 ТБ памяти), вышеупомянутые технологии Hadoop, Hive, HBase, Elasticsearch и ряд других. Объем хранилища OpenSOC в Cisco составляет 1,2 ПБ. В одной таблице находится свыше 1,3 триллионов строк.
Cisco OpenSOC мы стали создавать в 2013-м году и в сентябре 2013-го появился первый прототип. На половине пути, в декабре 2013-го года к нам присоединилась компания Hortonworks, давшая толчок развитию проекта и привнесшая немало интересных идей по использованию open source компонентов для высокопроизводительной и распределенной платформы, которой должен был стать OpenSOC. В марте 2014 года мы завершили разработку OpenSOC, а в сентябре 2014 мы сделали его публичным и выложили на GitHub.
В базовой комплектации поддерживает функции сбора данных, их хранения и анализа, а также обогащения сведениями об угрозах, жертвах, нападающих. Число адаптеров, которые по сути и выполняют функцию корреляции различных событий, в публичной версии OpenSOC невелико. Как и в случае с большинством SIEM, правила корреляции “из коробки” работают не очень хорошо, и поэтому в OpenSOC их надо писать самостоятельно под каждого потребителя системы. В группе компаний NTT, например, в качестве инструмента для создания триггеров и правил корреляции используется open source движок Esper.
После успеха OpenSOC внутри компании, его было решено развивать в качестве основы для наших аутсорсинговых услуг. Cisco Active Threat Analytics (ATA) по сути представляет собой распределенный Security Operations Center (SOC), который берет на себя функции мониторинга и управления информационной безопасностью наших заказчиков. Развивая OpenSOC и внутри компании и в рамках Cisco ATA, мы столкнулись с тем, что лицензия Apache 2.0 не всегда позволяет нам реализовывать все, что мы хотели. Да и только open source компонентами мы уже не могли ограничиваться для решения всех возникающих у нас задач.
Было принято решение разделить развитие OpenSOC на два направления. Первое оставалось в Cisco, для нужд нашей службы ИБ и сервиса ATA. А вот второе направление оказалось очень интересным. OpenSOC вошел в инкубатор Apache, став полноценным проектом, развиваемым сообществом open source. OpenSOC поменял и имя, став называться Apache Metron. В апреле 2016-го года вышла первая версия Apache Metron 0.1. Идеология при этом осталась неизменной и пользователям OpenSOC будет легко перейти на Apache Metron.
Cisco OpenSOC получил свое развитие и в другом направлении. На его основе компания MapR создала свое решение Security Log Analytics, которое используется и упомянутой выше компанией NTT, и банком Zions Bank, и другими заказчиками. Но, как и в случае с Apache Metron, идеология OpenSOC остается неизменной — анализ больших данных в целях кибербезопасности и возможность работы не только со структурированными, но и с неструктурированными данными. Это позволяет существенно расширить функции мониторинга угроз в компании и «видеть» гораздо больше чем раньше, используя и большее число источников информации. Например, в компании Cisco за последние несколько лет произошел сдвиг от привычных всем статических правил и сигнатур в сторону анализа поведения, аномалий и threat intelligence. Все это было бы невозможно без Cisco OpenSOC.
Если вспомнить одну из наших предыдущих заметок про то, как выстроен процесс управления доступом внутри 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).
Так как данная система, получившая название 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 обработчика, занимающихся обогащением исходных данных.
- Hadoop ([hadoop.apache.org]) — набор утилит и библиотек для разработки выполнения распределенных программ, например, для поисковых и контекстных механизмов. Лежит в основе технологии “Больших данных”. Кластер Hadoop в OpenSOC хранит все данные
- Elasticsearch — система поиска и индексации больших объемов данных в реальном времени.
- HBase — нереляционная распределенная база данных. В OpenSOC обеспечивает долгосрочное хранение сетевых пакетов (PCAP).
- Hive — система управления базами данных на базе Hadoop, в том числе HBase. В OpenSOC обеспечивает долгосрочное хранение событий безопасности.
- MySQL — реляционная система управления базами данных. В OpenSOC хранит метаданные Hive, а также иные данные, например, геолокационные.
- Kibana — система визуализации.
OpenSOC стал унифицированной платформой анализа данных безопасности в Cisco, которая:
- собирает, хранит, обрабатывает и анализирует данные с разных сторон с целью обнаружения аномалий и иных явных и неявных нарушений ИБ
- позволяет использовать различные предиктивные и корреляционные модели для поиска скрытых взаимозавимостей в собранных данных
- учитывает контекст анализируемых данных в реальном времени
- визуализирует события безопасности в нужном среде и генерит отчеты для заинтересованных лиц.
С технической точки зрения в основе лежит кластер из 45 серверов Cisco UCS (1440 процессоров, 12 ТБ памяти), вышеупомянутые технологии Hadoop, Hive, HBase, Elasticsearch и ряд других. Объем хранилища OpenSOC в Cisco составляет 1,2 ПБ. В одной таблице находится свыше 1,3 триллионов строк.
Cisco OpenSOC мы стали создавать в 2013-м году и в сентябре 2013-го появился первый прототип. На половине пути, в декабре 2013-го года к нам присоединилась компания Hortonworks, давшая толчок развитию проекта и привнесшая немало интересных идей по использованию open source компонентов для высокопроизводительной и распределенной платформы, которой должен был стать OpenSOC. В марте 2014 года мы завершили разработку OpenSOC, а в сентябре 2014 мы сделали его публичным и выложили на GitHub.
В базовой комплектации поддерживает функции сбора данных, их хранения и анализа, а также обогащения сведениями об угрозах, жертвах, нападающих. Число адаптеров, которые по сути и выполняют функцию корреляции различных событий, в публичной версии OpenSOC невелико. Как и в случае с большинством SIEM, правила корреляции “из коробки” работают не очень хорошо, и поэтому в OpenSOC их надо писать самостоятельно под каждого потребителя системы. В группе компаний NTT, например, в качестве инструмента для создания триггеров и правил корреляции используется open source движок Esper.
После успеха OpenSOC внутри компании, его было решено развивать в качестве основы для наших аутсорсинговых услуг. Cisco Active Threat Analytics (ATA) по сути представляет собой распределенный Security Operations Center (SOC), который берет на себя функции мониторинга и управления информационной безопасностью наших заказчиков. Развивая OpenSOC и внутри компании и в рамках Cisco ATA, мы столкнулись с тем, что лицензия Apache 2.0 не всегда позволяет нам реализовывать все, что мы хотели. Да и только open source компонентами мы уже не могли ограничиваться для решения всех возникающих у нас задач.
Было принято решение разделить развитие OpenSOC на два направления. Первое оставалось в Cisco, для нужд нашей службы ИБ и сервиса ATA. А вот второе направление оказалось очень интересным. OpenSOC вошел в инкубатор Apache, став полноценным проектом, развиваемым сообществом open source. OpenSOC поменял и имя, став называться Apache Metron. В апреле 2016-го года вышла первая версия Apache Metron 0.1. Идеология при этом осталась неизменной и пользователям OpenSOC будет легко перейти на Apache Metron.
Cisco OpenSOC получил свое развитие и в другом направлении. На его основе компания MapR создала свое решение Security Log Analytics, которое используется и упомянутой выше компанией NTT, и банком Zions Bank, и другими заказчиками. Но, как и в случае с Apache Metron, идеология OpenSOC остается неизменной — анализ больших данных в целях кибербезопасности и возможность работы не только со структурированными, но и с неструктурированными данными. Это позволяет существенно расширить функции мониторинга угроз в компании и «видеть» гораздо больше чем раньше, используя и большее число источников информации. Например, в компании Cisco за последние несколько лет произошел сдвиг от привычных всем статических правил и сигнатур в сторону анализа поведения, аномалий и threat intelligence. Все это было бы невозможно без Cisco OpenSOC.
