24 июля, 2017, BIS Journal №3(26)/2017

К SOCу готов? Подумай!


Лукацкий Алексей

эксперт информационной безопасности

Обмен опытом строительства центров мониторинга ИБ на SOC Forum в Казахстане

В конце апреля в Астане (Казахстан) состоялся SOC Forum – мероприятие, уже дважды прошедшее в Москве, и вот вырвавшееся на просторы СНГ. Я не раз уже высказывался о данном мероприятии в позитивных тонах, считая, что за фокусными мероприятиями будущее, и Медиа группа «Авангард» смогла оседлать одну из самых живых и «горячих» тем, о которой думают многие специалисты по кибербезопасности в России и других странах. На астанинском форуме мне довелось модерировать пленарную секцию и выступать на секции «Опыт построения SOC». Поэтому мне бы хотелось поделиться своим взглядом на происходящее в Казахстане. Тем более, что мне есть с чем сравнивать – Cisco имеет свой собственный внутренний SOC (о нем я и рассказывал), предлагает аутсорсинговый SOC для своих клиентов, а также помогает им строит свои центры мониторинга, если по каким-то причинам они не готовы обращаться к аутсорсингу данных услуг. Именно это дает мне основания для оценки множества докладов и того, насколько они соотносятся с лучшими мировыми практиками (в 2015-2016-м годах у меня было два «турне» по SOCам в разных странах мира, где я мог почерпнуть много интересного).
 
МОЖЕТ ЛИ NOC ПРЕВРАТИТЬСЯ В SOC?
 
В пленарной секции, которую мне довелось модерировать, прозвучала фраза: «У нас уже есть NOC (Network Operations Center – авт.), поэтому мы можем легко на его базе сформировать SOC». Это классическое заблуждение, которое часто можно слышать от операторов связи, давно имеющих у себя центры управления сетью и которые решили выйти на новые для себя рынки. И хотя в обоих центрах занимаются мониторингом, это совершенно разные задачи. Да, эти команды могут и должны работать вместе, но все-таки они занимаются разными вещами: у них разные приоритеты. Задача NOC обеспечить непрерывное функционирование сетевой инфраструктуры и быстро восстанавливать сеть в исходное состояние. Задача SOC – реагировать на инциденты безопасности.
 
Согласно 5 моделям функционирования SOC по версии Gartner объединение SOC и NOC все-таки возможно, но только в небольших и низкорискованных организациях, где функции управления сетью и ИБ уже реализуются одними и теми же людьми. По сути речь идет о классическом малом и, иногда, среднем бизнесе, где функции ИБ возложены на ИТ-департамент. В таких ситуациях «не до жиру». Но у данного подхода есть и проблемы. У SOC/NOC разные политики, процессы, процедуры и зачастую инструменты (хотя сбор событий, управление событиями и инцидентами, оркестрация, анализ Netflow и другие могут реализовываться одним и тем же ПО). Будут ли сотрудники NOC концентрироваться на угрозах? А на проблемах, выходящих за рамки текущей сетевой инфраструктуры? А будут ли они заниматься Threat Hunting и Threat Intelligence? Все это маловероятно, а значит идея возложить на NOC еще и функции SOC обречена на неудачу.
 
ОТ SIEM К ТРИАДЕ SIEM+NTA+EDR
 
Еще одна классическая ошибка, которая явно и неявно звучала на SOC Forum, - построение SOC вокруг какого-либо SIEM. Исторически в России самым популярным SIEM-решением считается ArcSight ESM. Его используют и заказчики, и поставщики аутсорсинговых услуг (например, он применяется компаниям JSOC и ISSP, выступавшими на форуме). Забавно, на прошедшей в июне в США конференции Gartner по информационной безопасности и управлению рисками по опросу среди потребителей призовая тройка была распределена между совсем иными компаниями – LogRhytm, LogPoint и Splunk. Кроме последнего имени, остальные два практически не известны на территории постсоветского пространства. Но дело даже не в том, какой продукт используется в качестве SIEM. Фокус на SIEM, как ядре SOC, – это всего лишь первый уровень зрелости SOC по версии Gartner. В выступлении компании Palo Alto прозвучал тезис, что «миссия SOC – отслеживать, обнаруживать и эскалировать важные события ИБ для гарантии конфиденциальности, целостности и доступности во всей компании». В такой постановке задачи, действительно, средство управления событиями ИБ становится ядром SOC. Но центр мониторинга ИБ не занимается событиями ИБ. Его основное предназначение в ином – обеспечение централизованного и консолидированного предотвращения, обнаружения и реагирования на инциденты ИБ.
 
В Cisco наш SOC построен вокруг трех основных элементов, занимающихся мониторингом логов, сетевых потоков, оконечных устройств и поведения, – SIEM (на базе Splunk), NTA или Network Traffic Analysis (на базе Cisco Stealthwatch), EDR или Endpoint Detection & Response (на базе Cisco AMP for Endpoints). И если до 2010-го года львиная доля инцидентов в Cisco обнаруживалась за счет анализа журналов регистрации с помощью SIEM, то сегодня на SIEM у нас приходится около 20% всех обнаруженных инцидентов ИБ. Еще 20% мы ловим за счет анализа Netflow с помощью технологий NTA (раньше их еще называли NBAD, Network-based Anomaly Detection или Network Behavior Anomaly Detection). Третьи 20% обнаруживаются с помощью анализа поведения и, наконец, оставшиеся 40% являются заслугой сервисов Threat Intelligence.
 
Компания Gartner, активно исследующая тему SOC, также считает, что современный SOC в своем ядре использует тройку технологий – SIEM, NTA (иногда еще добавляя NTF, Network Traffic Forensics) и EDR, позволяющих собирать события безопасности из сетевого трафика, с оконечных устройств и с журналов регистрации. В столице Казахстана про решения EDR и NTA практически никто не упомянул, что отражает ситуацию, когда отечественные SOCи находятся на самом начальном этапе своего развития. Исключением стало выступление компании МТС, рассказавшей о своем опыте построения SOC - анализом Netflow они занялись еще в начале этого десятилетия. Если подождать пару-тройку лет, то многие упомянутые технологии (исключая EDR) войдут в те же SIEMы. Но тут стоит добавить, что до России с ее курсом на изоляционизм и импортозапрещение (а большинство технологий к нам все-таки приходит оттуда) этот прогноз может и не сбыться вовсе.
 
Компании Positive Technologies и JSOC, предоставляющие внешние услуги SOC и для SOC, много говорили о необходимости инвентаризации ИТ-активов. Интересно, что опрос клиентов Gartner показал, что на Западе эта технология как раз не входит в число обязательных для SOC, мотивируя это не самым удачным опытом внедрения такого рода продуктов (сложно и неочевидная эффективность). И действительно, в условиях динамично изменяющейся ИТ-инфраструктуры современного предприятия (и чем оно больше, тем динамичнее картина), поддерживать в актуальном состоянии карту сетевых ресурсов превращается в очень неочевидную задачу. Даже при использовании специализированного инструментария (Positive Technologies использует собственное решение на базе MaxPatrol, JSOC использует Skybox Security, Cisco применяет RedSeal).
 
Последний, пятый уровень зрелости SOC по версии Gartner подразумевает под собой применение не только SIEM, NTA/NFT, EDR, но и UEBA (User Entity Behavior Analytics), средств оркестрации и даже обманных решений. С необходимостью последней технологии для SOC я бы поспорил (хотя в мире за последнее время появилось около десятка стартапов по теме обмана в ИБ), а вот остальные упомянутые решения очень важны. Про оркестрацию на SOC Forum KZ говорила компания R-Vision, но только применительно к автоматизации управления инцидентами. Остальные задачи SOC, которые можно и нужно автоматизировать рассмотрены не были (возможно по причине нехватки времени).
 
THREAT INTELLIGENCE И THREAT HUNTING
 
Одной из обязательных задач современного SOC является Threat Intelligence и Threat Hunting. Первое – это базирующееся на доказательствах знание (включая процесс его получения) о текущих или предполагаемых угрозах и нарушителях, обеспечивающее понимание методов, используемых злоумышленниками для нанесения ущерба, и способов противодействия им, где в качестве доказательств могут быть использованы индикаторы компрометации, контекст, предположения и т.п. Второе – это поиск следов нарушителей, которые остаются незамеченными технологиями предотвращения и обнаружения угроз. В качестве исходных данных для Threat Hunting могут использоваться и данные Threat Intelligence. Тема Threat Hunting была обойдена вниманием выступающих, что было обусловлено нехваткой владения темой и неготовностью к ней многих присутствующих, пока только размышляющих о том, нужен им SOC или нет, а не о том, как выявлять следы нарушителей в множестве внутренних и внешних источников информации.
 
Про Threat Intelligence говорили многие участники SOC Forum, которые используют источники Open Source, репутационные базы вендоров, а также платные подписи, среди которых упоминались российские «Лаборатория Касперского» и Group-IB, а также иностранные Cisco Threat Grid, Payload Security, VirusTotal, Cisco OpenDNS и другие. Для консолидации получаемых извне или созданных самостоятельно индикаторов компрометации применяются различные платформы – от open source MISP (используется ISSP) или CRiTs (используется Cisco) до коммерческих или вообще самописных. Компания МТС пока только планирует внедрять Threat Intelligence в своем SOC, в том числе и в виде взаимодействия с национальной системой обнаружения, предотвращения и ликвидации последствий компьютерных атак ГосСОПКА. В Cisco пошли еще дальше и разработали собственную платформу Cisco TIP (Threat Intelligence Platform), которая предназначена для решения множества внутренних задач службы ИБ и в т.ч. SOC.
 
SOC – ЭТО ЛЮДИ, ПРОЦЕССЫ И ТЕХНОЛОГИИ
 
Взяв за основу классическую триаду «люди, процессы и технологии», почти все выступающие отмечали, что SOC – это прежде всего люди и люди квалифицированные. Как сказал неделей позже на мероприятии Gartner Антон Чувакин «лучше плохой SIEM с хорошей командой, чем офигенный SIEM с плохой командой». И вот в этом вопросе большинство заказчиков столкнется с классической проблемой – людей нет.
 
Представители Solar Security рекомендуют начинать с 2-3 человек первой линии, 1 аналитика и 1 руководителя (то есть 4-5 человек). Именно с таких цифр начинался JSOC, работающий в режиме 5х8. Сейчас, при режиме работы 24х7, в JSOC трудится уже 54 человека. По оценкам Cisco минимальное количество специалистов, которые могли бы обеспечивать круглосуточный режим работы SOC составляет около 20 человек. Например, в Microsoft Cyber Defense Operations Center работает 50 человек, в Cisco CSIRT – 103, в Ростелекоме – 25 и идет еще набор, в Solar JSOC – около 60 и также идет набор, Сбербанк озвучивает цифру в 400 человек, у Лаборатории Касперского – 14 человек. При этом у тех же Microsoft, Cisco, ЛК есть отдельные подразделения Threat Intelligence, которые в озвученные выше цифры не включены (например, Cisco Talos, занимающийся анализом угроз и создающий сигнатуры, описывающие репутации узлов и т.п., насчитывает 250 человек). Готовы ли вы к такому расширению штата или все-таки стоит смотреть на внешние центры мониторинга?
 
Тема процессов была практически обойдена вниманием на SOC Forum, а вот про технологии, говорили много. Оно и понятно – многие выступающие представляли «продуктовые» компании, желающие продать свои решения. И если кто-то пытался увязать свои решения с SOC, то некоторые производители даже не удосуживались сделать хотя бы такую небольшую работу и никак не объясняли место своих NGFW, сканеров кода и других решений в деятельности SOC.
 
Интересная ситуация возникла с анализом защищенности. Некоторые поставщики услуг упоминали про необходимость сканирования уязвимостей, как части SOC. При этом на прошедшем в Москве несколькими днями позже закрытом мероприятии Gartner ее представитель Антон Чувакин рассказывал, что на Западе в последнее время многие компании не то, чтобы совсем отказываются от устранения уязвимостей и выстраивания патч-менеджмента, но и не ставят эти процессы во главу угла. При среднем времени устранения уязвимостей в 30 дней и более (по исследованиям Cisco устранение заказчиками уязвимостей в сетевом оборудовании или серверном ПО может длиться до пяти лет) говорить об оперативности не приходится. Отсюда и исключение этого процесса из списка ключевых для SOC. Нередко клиенты мирятся с наличием дыры и поэтому не имеют выстроенного процесса устранения уязвимостей. Тем интереснее сравнивать этот взгляд с российским, где только совсем недавно регуляторы обратили внимание на анализ защищенности и сделали его обязательной частью любой системы защиты (по требованиям ФСТЭК, ЦБ, ФСБ), а также частью обязательных требований при получении лицензии ФСТЭК на деятельность SOC.
 
В КАЧЕСТВЕ ЗАКЛЮЧЕНИЯ 
 
На форуме было представлено несколько аутсорсинговых SOC, и у многих заказчиков звучал классический вопрос: “Что лучше – свой SOC или аутсорсинговый?” Представители аутсорсинговых центров, разумеется, утверждали, что отдать на аутсорсинг лучше всего. Представители многих заказчиков наоборот считали, что «своя рубаха ближе к телу» и надо постепенно наращивать свои компетенции. Например, у МТС первоначально SOC работал в режиме 8х5 и только сейчас перешел на режим 24х7. Истина, как известно, где-то посередине – часть функций можно попробовать (при наличии людей) реализовать самостоятельно, а часть (те же Threat Intelligence, расследование инцидентов, сканирование защищенности и другие) отдать во внешние руки.
 
Но гораздо интереснее вопроса, должен быть SOC внешним или внутренним, является другой вопрос, которого на форуме почти не коснулись. Кому нужен SOC (именно кому, а не зачем)? Дело в том, что внедрение собственного SOC или переход на аутсорсинговую модель требуют определенного, и немалого, уровня зрелости. Сегодня только ленивый не задумывается о том, чтобы назвать купленный ArcSight или скачанный OSSIM SOCом, но... повторюсь, SOC - это люди, процессы и только потом технологии. Если в компании нет процессов (или они приобретены у крупного консалтера без понимания их сути) - к SOCу компания не готова. Если в компании есть только межсетевой экран на периметре и антивирус на персоналках - к SOCу компания не готова. Нужно дозреть и только наткнувшись на невозможность решить возникающие проблемы текущими средствами, можно задумываться о переходе на новый уровень под названием Security Operations Center. 

 

Смотрите также

Подпишись на новости!
Подписаться