Куда движутся SOCи? Взгляд с RSA Conference 2021

Занимаясь проектами по SOC (как проектированием, так и оценкой существующих и разработкой их улучшений) постоянно сталкиваюсь с темой развития центров мониторинга в соответствие с лучшими практиками. Готовя такие планы, обычно включаешь в них только то, что уже проверено и действительно дает эффект. Понятно, что есть различные идеи и технологии, которые вроде и появились на рынке, но пока непонятно, насколько они полезны на практике. Рекомендовать их в рамках консалтинга не совсем правильно, но и скрывать тоже не имеет смысла. Поэтому решил вкратце пройтись по интересным новациям, которые были представлены в рамках прошедшей в конце мая RSA Conference 2021, где одной из популярных тем стал именно мониторинг ИБ. И хотя в условиях провального импортозамещения все это так и останется красивой сказкой, но кому-то может и поможет. Итак, что добавляют различные компании, производители и потребители, в свои SOCи для повышения их эффективности.

Во-первых, это решения класса Security Intelligence Automation, которые обладают следующими отличительными особенностями:

• Библиотека знаний по ИБ. Человек принимает решения, опираясь на достаточно широкий кругозор и имеющийся опыт, который отсутствует у многих средств анализа ИБ. Идея заключается в формализации правил принятия решений и помещении их в систему для того, чтобы и другие аналитики могли воспользоваться этой библиотекой, и сами средства анализа могли в автоматическом режиме обращаться к этой библиотеке при проверке гипотез и поступающих от источников данных событий. По сути речь идет о набившем оскомину тезисе о контекстно-ориентированной аналитике, но с ее формализацией для удобства использования.
• Роботизация экспертизы расследований инцидентов. При проведении расследований инцидентов аналитики опираются не только на плейбуки, но и на свой опыт, позволяющий им сопоставлять разные данные и делать на их основе выводы, облегчающие принятие решений, классификацию и приоритизацию инцидентов. Анализ выполняемых аналитиками ежедневных действий и выявление в них закономерностей, которые потом могут быть автоматизированы, это тоже тренд в SOCостроении. 
• Роботизация человеческой классификации и приоритизации инцидентов. Многие средства анализа ИБ построены по принципу обнаружения "известного плохого" и пасуют перед новыми событиями, в классификации и приоритизации которых задействуется человек. Часто набор производимых при этом действий достаточно стандартный и может быть автоматизирован с помощью инструментов, схожих с RPA. 

Ключевыми тут являются последние две возможности, которые позволяют не ждать, когда занятые аналитики соблаговолят записать свои действия и облегчит себе жизнь, а заставить "робота", наблюдая за действиями аналитика, записать их и потом их будет гораздо проще проверить, "согласовать" и ввести в действие.

Вторым интересным рассмотренным на RSAC направлением стали решения класса Attack Surface Management, которые позволяют в непрерывном режиме оценивать потенциальные точки проникновения в организацию. Делают они это за счет нескольких функций:

• Автоматическая инвентаризация, которая позволяет идентифицировать все ваши активы без указания, как в сканерах, диапазона IP-адресов. При этом решения класса ASM учитывают наличие облачных сред, динамические инфраструктуры и т.п.
• Непрерывный мониторинг позволяет отслеживать все изменения, происходящие в сети.
• Риск-ориентированный анализ, который заключается в приоритизации ресурсов и активов на основе различных данных - уязвимостей, критичности активов, наличие известных эксплойтов, сложности их использования и т.п. На основании этой информации каждому активу присваивается уровень риска.

Да, все эти действия по отдельности уже и сейчас решаются - есть средства инвентаризации, решения CMDB, сканеры безопасности и т.п. Инструменты ASM объединяют в себе все эти функции и, будучи заточенными под ИБ, позволяют решить важнейшую задачу любого предприятия - в любой момент времени иметь возможность ответить на вопрос "что мне надо защищать?".

Другой проблемой, на которой были направлены усилия отрасли, стала снижение числа ложных срабатываний, с которыми сталкиваются почти все организации (число фолсов достигает 50% и выше). Одним из способов борьбы с этим является внедрение риск-ориентированной аналитики в SIEM, в рамках которой происходит не просто обычная корреляция событий ИБ, но к ней добавляется учет TTP по MITRE ATT&CK (увы, ТТУ от ФСТЭК не поддерживается), уровень риска узла или системы или пользователя и ряд других показателей (у Splunk такой механизм называется RBA - Risk Based Alerting).

Пример риск-ориентированной оценки активов в SIEM

И тут вроде ничего нового. Все это можно было делать с помощью SIEM и раньше, но для этого приходилось сильно заморачиваться, делая все руками, прописывая цепочки событий, задавая уровень критичности актива для бизнеса, вычисляя риски по самостоятельно написанным формулам и т.п. Сейчас появляется возможность автоматизации этих процедур и объединения их в единое решение.

Последним в этой заметке я упомяну решения класса no code, которые начали завоевывать рынок (сложно от всех требовать умения программировать), в том числе и в ИБ. В частности сегмент SOAR стал одним из первых, в которых стали появляться решения no code, позволяющие описывать плейбуки и интеграции с другими решениями без написания отдельных коннектов. Причем в этом направлении сейчас идут многие игроки - от стартапов типа Tines, sirp.io, D3 Security:

Пример описания workflow без программирования

до крупных игроков типа Spunk (с Phantom) или Cisco (с бесплатным SecureX):

Пример встроенных коннекторов с разными решениями по ИБ

Вот такая вырисовывается картина. В условиях роста числа событий ИБ, увеличения ложных срабатываний, нехватки кадров и большого разнообразия средств защиты, которые надо объединять в единый комплекс, вполне очевидной становится задача автоматизации различных аспектов работы SOC, что и наблюдается в отрасли и ее мероприятиях, включая и RSA Conference.  

Подробнее…

Обзор SOCstock или что я не услышал на SOC Live. Часть 2.5 :-)

Не успел закончиться SOC Live, презентации и видео с которого выложили вчера в открытый доступ, как через день в США прошло другое онлайн-мероприятие, целиком посвященное теме SOC - SOCstock. По задумке организаторов, компании Siemplify, называющей себя независимым игроком рынка SOAR №1 (просто других некупленных уже не осталось), это должно было дать отсылку к знаковому концерту в Вудстоке, который собрал всех хиппи того времени. SOCstock тоже собрал немало специалистов по SOC - по заявлениям, не менее полутора тысяч человек (в реальности - около 600), которые в течение 9 часов слушали в два потока рассказы разных экспертов о тех или иных аспектах функционирования центров мониторинга ИБ. И, как это не парадоксально, если с точки зрения концепции и формата мероприятия SOCstock и SOC Live оказались очень похожи, то по контенту они практически идеально дополняли друг друга. Если у нас больше говорилось об аутсорсинговых услугах SOC, различных кейсах при расследовании, взаимодействии с ГосСОПКОЙ, работе с заказчиками и т.п., то на супостатном SOC "Forum" больше говорили об автоматизации, персонале, выгорании, threat hunting'е, threat intelligence, зрелости SOCов и т.п. Да, там тоже была реклама, но, как правило, она была завуалирована в очень интересных докладах и докладчики не сильно злоупотребляли рассказом о местах своей работы.

Началось все с музыкальной пазой (ею же все и завершилось), в которой ветеран Вудстока бренчал на гитаре и пел заунывные песни о бренности бытия, настраивая всех на активную работу :-) Кстати, по Москве мероприятие закончилось в 3 утра.

После того, как все участники собрались и расселись по своим виртуальным местам, начался ключевой доклад от Брайна Кребса, известного ИБ-журналиста. Кстати, можно спорить о том, насколько Кребс - специалист по ИБ, но вопросов ему в онлайне задавали немало. И это было гораздо интереснее, чем слушать свадебного генерала из какого-нибудь регулятора или ведомства, с которых любят начинать российские мероприятия по ИБ. 

В последовавшей за ключевым докладом дискуссии руководители нескольких американских SOCов рассказывали о текущем состоянии своей деятельности. Пересказывать ее не имеет смысла - ее надо слушать. Кстати, о том, почему везде висит значок Zoom. В отличие от SOC Live, в котором спикеры участвовали очно из студии, спикеры SOCstock подключались с разных концов США и поэтому собрать их вместе не предстаавлялось возможным. Поэтому видео-поток с Zoom транслировался уже через платформу мероприятия. Было не так живо, как на SOC Live, но иначе и не получилось бы для такой децентрализованной страны как США. 

Затем конференция разделилась на 2 потока, в каждом из которых доклады длились по 30 минут. Кстати, мне кажется, что 30-тиминутные доклады для таких форматов (и 45 минут для дискуссий) лучше заходят, чем 20-тиминутные, как на SOC Live. По крайней мере мне не хватило этих 10 минут в обоих своих выступлениях - и про мониторинг ИБ удаленного доступа, и про две другие альтернативы между своим и аутсорсинговым SOC. Из интересных докладов я бы отметил следующие.

Gert Jan Bruggnik рассказывал про adversary playbook, инструмент, который позволяет описать профиль нарушителя, его техники и тактики, чтобы эффективно и оперативно использовать эти сведения про мониторинге и атрибуции инцидентов, а также, в большей степени, для организации red team'инга. Куча примеров, куча ссылок на различные Интернет-ресурсы, никакой рекламы (кроме своей книги). Отличный был доклад.

Не менее интересным был доклад и от компании Siemplify, которая рассказала как о том, что такое SOAR и зачем нужна автоматизации в SOC, так и привела немало сценариев, в которых автоматизация действительно помогает специалистам по мониторингу ИБ. Причем это были как достаточно стандартные сценарии типа фишинговой атаки или подбора пароля, так и менее распространенные, такие как утечка данных из облака или обработка фидов о киберугрозах во время пандемии COVID-19.      

Как я уже писал выше, некоторые доклады были не очень интересными, так слишком явно продвигали определенные продукты по ИБ. Например, из доклада про Threat Hunting я смог вытащить только этот слайд:

из доклада про EDR только этот:

а из доклада "обманного" вендора вот этот (я вообще скептически отношусь к перспективам этой технологии, помня уж три ее попытки выйти на рынок и все как-то безуспешно): 

А вот Роб ван Ос не обманул ожиданий - рассказал и о том, как оценивать эффективность (про это спрашивали многих докладчиков и участников пленарных сессий) и зрелость центра мониторинга, и какие модели использовать для оценки возможностей SOC и т.д. Кстати, на последний вопрос, как ни странно, ответ оказался не модель SOC-CMM от авторства самого Роба. В списке популярных она занимает 3-е место после MITRE ATT&CK и NIST CSF. DeTT&CT, CIS 20, CREST SOC и другие тоже были упомянуты, но они оказались не столь популярными.

Как я написал выше, одной из популярных тем SOCstock было выгорание персонала, его карьерный рост, формирование заинтересованности в работе аналитика SOC и т.п. Об этом говорили на еще парочке дискуссий, а также в докладе Аманды Феннели, CISO из Relativity. Она делилась опытом, как можно сделать SOC еще лучше, если фокусироваться не на технологиях, а на людях и процессах. 

Представитель Anomali не смог обойтись без рекламы свой платформы по анализу угроз, но очень грамотно вплел ее в рассказ о том, что такое нормальный процесс Threat Intel, чем он отличается от просто сбора фидов и какую пользу можно получить, если оперировать не просто фидами с IOCами от внешних источников (привет ГосСОПКА и ФинЦЕРТ), но и активно добавлять в них свой собственный контекст, которые сообща только и дают возможность на основе TI-процесса принимать адекватные решения, а не просто загружать индикаторы в SIEM и думать, что вот оно, счастье наступило.

Карсон Циммерман, автор руководства MITRE по "10 стратегиям первоклассного SOC", которое сейчас переводится на русский язык компанией R-Vision, рассказывал о том, как вывести обнаружение угроз на новый уровень. Подход "поставил сенсор и забыл" больше не работает и поэтому надо более внимательно относиться к покрытию SOCом различных систем, используемым технологиям мониторинга, их настройке, а не использованию "из коробки", и т.п. Примерно о том же я начал писать в ноябре и продолжу в декабре.

Еще одним хедлайнером SOCstock стал Антон Чувакин, который закрывал программу форума рассказом о том, что изменилось в SOCах за последние годы. Мне этот доклад напомнил выступление Антона в мае 2017-го года в Москве, когда Gartner собирал ограниченный круг заказчиков, для которого Антон рассказывал о SOCах и других технологиях ИБ. А может просто я слишком много материалов по SOC просмотрел "имени Gartner", что у меня уже в глаза двоится. Из интересного запомнилось заключение выступления, в котором подняли классическую тему о том, что <технология ИБ> мертва. Такое говорили о системах предотвращения вторжения, о SIEMах и вот теперь о SOCах. Антон не опроверг, но и не подтвердил этот тезис, уточнив, что если речь идет о SOC, как о помещении с плазмами, то да, такой подход мертв. И тут впору вспомнить требования ФСТЭК к SOCам, которые требуют не только указания в лицензии места совершения преступления оказания лицензируемого вида деятельности, но и аттестации информационной системы SOCа. До свидения виртуальные и мобильные SOC с распределенным персоналом. Кстати, ФСТЭК закрывает глаза на те SOCи, которые для оказания услуг используют облачные SIEM, размещенные зарубежом, а также сотрудников, которые вот уже скоро год как работающих удаленно, из дома, что, разумеется, в лицензии ФСТЭК не указано.

Вот такое было мероприятие. Материалы с него пока недоступны и не факт, что будут (кроме доступа к записи онлайн-трансляции), что не позволяет разместить ссылку на них. Но хочу вновь отметить, что программа оказалась прям дополняющей наш SOC Live, что и позволило мне в заголовке заметки написать про "часть 2.5". За сим откланиваюсь и буду готовить еще одну заметку про SOC Live, завершающую эту серию.

Подробнее…

Обзор выступлений с SOC Live. Часть 2

А я продолжаю обзор презентаций, прозвучавших в рамках второго канала SOC Live. Открыл первый поток "Эффективный SOC: лучшие практики" Алексей Новиков из НКЦКИ, который... который, к сожалению, не сказал ничего нового. Вроде бы ГосСОПКА и НКЦКИ существуют уже не первый год, но доклады по-прежнему строятся вокруг "присылайте данные по инцидентам в НКЦКИ и мы обработаем их в нашей TIP". Ну, блин. Неужели нет ничего более интересного, что НКЦКИ мог бы рассказать для специалистов? Как работает TIP? Какой жизненный цикл и workflow по получаемым и обрабатываемым данным? Каково распределение по типам инцидентов за время, прошедшее с прошлого SOC Forum? Статистика должна была накопиться уже достойная и она явно не секретная, чтобы ее утаивать... Но если не хочется делиться практикой, расскажите про нормативку. Почему на методических рекомендациях по реагированию на инциденты висит "гриф"? Как решать вопрос с передачей данных об инцидентах дочкам иностранных компаний (эта тема уже несколько лет "висит" и НКЦКИ обещал ответить на нее еще в прошлом году)? Когда и какие появятся требования к средствами ГосСОПКА, о которых говорится и в приказах ФСБ и в проектах НПА Правительства и Президента по импортозамещению в КИИ? Да много каких вопросов накопилось к регулятору именно в контексте мониторинга. Но нет... Жаль...

Вторым довелось выступать мне - я заменял внезапно заболевшего Руслана Иванова из Cisco. Удивительно, что несмотря на 9 месяцев самоизоляции, которая поменяла подходы к ИБ в организациях и, соответственно, к мониторингу ИБ, про коронавирус на SOC Live не говорил почти никто. Я в презентации как раз и коснулся этого вопроса, уделив внимание тому, как мониторить удаленные рабочие места, облака, периметр, ЦОД и каналы связи. В заключение своего короткого выступления я коснулся того, как выстраивать работу самого SOC, если его аналитики сами переведены на удаленку.  Но интересующимся последней темой я бы порекомендовал статью на Хабре, где этот вопрос раскрыт более детально, чем в презентации.

Кстати, о статьях. Во вчерашнем обзоре я упомянул про секцию, в которой SOCостроители делились своим опытом ошибок. Я бы тоже хотел поделиться таким опытом, который был описан мной в статье для последнего выпуска журнала "Информационная безопасность банков". Описанные мной 12 ошибок были накоплены в результате проектов по аудиту или проектированию SOC, в которых мне довелось участвовать за последнее время (а Cisco достаточно активно занимается таким консалтингом, не обремененным сопутствующей продажей SIEMов или услуг по аутсорсингу).

Третьим в потоке выступил Иван Мелехин из Информзащиты, который поделился опытом формирования технического задания на оказание услуг по аутсорсингу функции мониторинга ИБ. Парой недель ранее команда Ивана стала победителем The Standoff в категории защитников, лучше других защитивших свои ИТ-активы и проведя расследования инцидентов в отношении их, о чем Иван скромно указал на последнем слайде своей презентации. 

Второй поток второго канала, который комментировал Алексей Комаров (возможно, он напишет об этом у себя в блоге), был посвящен технологиям SOC. Начал его Владимир Дрюков из Ростелеком-Солара, который сделал обзор того, как поменялись подходы злоумышленников и методы мониторинга и реагирования на инциденты ИБ за последние 5 лет, прошедшие со времен первого SOC Forum. 

Кстати, первый SOC Forum, прошедший в 2015-м году, коренным образом отличался от того, что происходило в этом году. Тогда я даже написал, что это был не SOC Forum, а SIEM или даже Arcsight Forum, так как очень уж много говорилось о конкретных технических решениях. Сейчас SOC Forum стал гораздо более зрелым в этом вопросе и голимой рекламы практически не было. Хотя, конечно, исключения попадали. Например, доклад представителя Security Vision, который был посвящен целиком продуктам этой компании (я даже скриншоты слайдов презентации не стал делать). В следующем докладе, Дениса Кораблева из Positive Technologies, тоже было слишком много рекламы, а именно относительно их нового продукта - песочницы, выпущенной в апреле этого года. Видимо, надо было прорекламировать это решение, обернув его в немного экспертный доклад. Вообще доклады от Позитива на SOC Live вызвали в этом году одно сожаление - наверное все усилия были потрачены на прошедший тремя неделями ранее The Standoff и все экспертные доклады остались там, а повторяться коллеги не захотели.

На продолжившемся после развлекательной ИБ-игры "Голосо истины" потоке по технологиям SOC первым выступил Дмитрий Купецкий из Fortinet. Доклад был тоже рекламным и поэтому рассказывать про него не имеет смысла. Вторым был Александр Бондаренко из компании R-Vision, который, как и я, коснулся темы новой реальности и ее влияния на ИБ, а затем, приведя много разных цифр из зарубежных отчетов по Threat Hunting и управлению активами, плавно прорекламировал новый продукт R-Vision в области обманных решений (deception). Тоже оставлю это без комментариев и скриншотов. Как по мне, так это малоперспективное направление, к которому на моей памяти индустрия ИБ обращалась уже три раза за последние лет 20+ и все без особого успеха. То есть массовым я бы это решение не назвал.

Завершавший этот поток Александр Черныхов из Крока, который напомнил слушателям, какие ключевые компоненты должны быть по его мнению в современном SOC. К ним он причислил SIEM, UEBA, SOAR и Big Data. Не знаю, я не очень согласен с такой постановкой вопроса и в этот список, как минимум, добавил бы еще TIP и THP, а к списку систем сбора событий, наряду с UEBA, добавил бы еще EDR, NTA/NDR и CASB. Но, возможно, просто времени не хватило, - все-таки за 20 минут рассказать можно не так уж и много. 

Следующий поток был посвящен людям, процессам и задачам. Открывал его Алексей Павлов из Ростелеком-Солара (кстати, имя "Алексей" было самым популярным среди спикеров SOC Live, - 9 человек носили его; еще было 4 Антона и 4 Александра). Алексей рассказывал свой опыт пресейла аутсорсингового SOCа и те проблемы, с которыми заказчики приходят в Ростелеком-Солар.

За Алексеем выступал другой Алексей, а именно Лукацкий (компания Cisco), то есть я, посвятивший это свое выступление краткому обзору возможных альтернатив построения центра мониторинга ИБ, а точнее ее ключевого компонента - системы сбора, анализа и корреляции событий ИБ (ее еще иногда называют SIEM). Помимо двух очевидных вариантов - собственный и аутсорсинговый центр мониторинга, я рассмотрел еще два, встречающиеся в тех случаях, когда у заказчика есть инструменты, но нет людей, и наоборот, есть люди, но нет инструментов для мониторинга. В этих вариантах можно использовать варианты Managed SIEM (кто-то управляет вашим, когда-то купленным SIEM) и облачные SIEM или SOC-платформа соответственно. Первый из них в России не представлен (хотя на Западе популярен), а вот второй вполне доступен. И хотя большинство игроков облачных SIEM/SOC-платформ тоже зарубежные, в России представлено, как минимум, два из них - Cisco и Microsoft.

Завершал первую часть этого потока Сергей Солдатов из Лаборатории Касперского, который описывал способы снижения ложных срабатываний в SOC за счет технологии машинного обучения, которая, будучи обученной на размеченным аналитиками данных, позволяет не только более оперативно выявлять инциденты, но и снизить число таких показателей как false negatives и false positives. 

 

После физкульт-разминки, которая напомнила многим, что разминаться надо не только виртуальным участникам SOC Live, которые 8 часов без перерыва смотрели эфир, но и аналитикам SOC, которые часто работают по 12 часов, поток продолжился. Его начал Тимур Зиннятуллин из группы компаний Angara. Он рассказывал о замечательной международной инициативе OSCD (Open Security Collaborative Development), в рамках которой осуществляется обмен опытом и подготовка практических рекомендаций и лучших практик в области ИБ. В контексте темы форума Тимур рассказывал о некоторых проектах в рамках OSCD, а именно о совместной разработке правил Sigma для обнаружения угроз, которые можно использовать в рамках тестов Atomic Red Team, обнаружения инцидентов в TheHive и Cortex, в сценариях RE&CT и т.п.    

Упомянутый ранее Алексей Павлов в своем докладе рассказывал, что меньше чем за год нельзя построить SOC. Но выступавший от имени Инфосистемы Джет Алексей Мальнев в своем докладе рассказал о том, как они построили за год целых 5 центров мониторинга на 6 различных SIEMах.

Поток "люди, процессы и задачи" завершал Алексей Лобзин из CyberART (ГК Innostage), который посвятил свое выступление тому, как бороться с усталостью аналитиков SOC и автоматизировать реагирование на инциденты. Я 2 года назад тоже касался этой темы в своем нашумевшем выступлении о том, что аналитики первой линии не нужны :-)

После небольшой минутки юмора, состоящей из выступлений "безопасного стендапа", начался круглый стол по применению SOCов на производстве и мониторинге промышленных площадок. Я на Хабре уже тоже как-то писал о нашем опыте мониторинга таких систем.

Этим круглым столом без докладов завершилась программа второго канала SOC Live. Завершаю обзор выступлений с этого мероприятия и я. Но думаю завтра я посвящу ему еще одну заметку, рассказав о том, что происходило за кулисами SOC Live (глазами стороннего наблюдателя) и какие еще фишки были предложены организаторами SOC Forum из компании Авангард-Медиа виртуальным участникам этого, одного из крупнейших российских онлайн-мероприятий по ИБ (около 10000 уникальных просмотров).  

Подробнее…

Обзор выступлений с SOC Live. Часть 1

Воспев в ФБ хвалебные дифирамбы прошедшему в начале недели SOC Live, я хотел бы воспользоваться случаем и сделать краткий обзор презентаций, прозвучавших на форуме. Тем более, что я был штатным троллем комментатором 1-го канала (читай онлайн-ИБ-тамадой) и слушал их все. Так что пока воспоминания свежи, поделюсь своими впечатлениями от выступлений.

Пленарная дискуссия врядли стоит того, чтобы писать про нее отдельно. Каких-то откровений или имеющих практическую ценность мыслей не прозвучало. Хакеры атакуют... Государство регулирует... Мир во всем мире... Космические корабли бороздят.... Скучно, предсказуемо и ни о чем. Но традиция есть традиция. Жаль, что не было заявленного Виталия Лютикова из ФСТЭК и незаявленного представителя ФСБ. Видимо двум основным регуляторам по ИБ нечего сказать по теме SOC, мониторинга ИБ, реагирования на инциденты и т.п. А жаль... 

Первый поток про тренды и угрозы был по сути первым, на котором началась активная сексуальная жизнь и погружение в тему мониторинга ИБ. Доклад Игоря Залевского из Ростелеком-Солара у меня оставил смешанные ощущения. Вроде и кейсы интересные и разноплановые (инсайдеры, киберхулиганы и китайские кибершпионы), но лично мне не хватило двух вещей - списка поведенческих индикаторов по каждой из историй, а также списка рекомендаций по тому, как это можно мониторить (а в идеале и блокировать) в своей инфраструктуре. Понятно, что Солар показывал свою крутизну экспертизу, но если рассматривать SOC Forum как площадку для обмена опытом, то было бы классно, если бы менее продвинутые слушатели смогли попробовать сделать тоже самое и у себя.

Рассказ Алексея Новикова не из НКЦКИ, а из Positive Technologies, про проведенный месяцем ранее The Standoff не поразил ничем, так как по сути это была победная реляция о проведенном мероприятии без каких-либо практических выводов и рекомендаций, которые можно было бы применить в жизни. Человек слаб... Учения позволяют отработать навыки... Positive крут... Я следил за атаками на The Standoff с помощью Cisco Stealthwatch Cloud и видел многие атаки, которые там происходили, и мне кажется, что можно было бы из опыта этого мероприятия вытянуть чуть больше практических рекомендаций, которыми можно было бы поделить со слушателями SOC Live. 

А вот третье выступления в этом треке мне понравилось. Алексей Зайцев из Лаборатории Касперского делился опытом проведения тестирования защищенности организации, отличия пентестов от киберучений и redteam'инга, источниками лучших практик для них и множеством других лайфхаков. Сугубо практический доклад, по окончании которого можно было брать упомянутые ссылки и идти формировать план проверок своей защищенности или искать подрядчика для проведения внешних проверок.

После этого потока были задействованы другие форматы - викторина "Голос истины" (по примеру "100 к 1") и Анти-Пленарка с неподражаемым Алексеем Качалиным, который, пригласив на сцену ряд известных в сокостроении лиц, заставил отстаивать их определенные позиции. Было динамично, весело и время пролетело очень быстро. В отличие от утренней пленарки лично у меня появилось желание пересмотреть этот эфир и более внимательно послушать доводы каждого из участников дискуссии. Завершившая развлекательный блок "Наша игра" (догадайтесь, кто для нее писал вопросы) также прошла в ожесточенной борьбе. Оно и понятно - на кону были ценнейшие призы в виду часов Apple Watch, наушников Airpods и ТВ-приставки Apple TV. Жаль, что не смог поучаствовать в игре - все призы мне пришлись бы кстати :-) 

Следующим треком стал "Клиентский опыт построения и эксплуатации SOCов", который открыл Сергей Рысин из ГТЛК. Он описал исходную проблему с наличием инструментария мониторинга угроз, но отсутствием достаточного количества квалифицированных кадров для этого. Кто-то идет по пути найма персонала (если есть такая возможность). Кто-то идет по пути покупки услуг Managed SIEM (я про этот кейс рассказывал в своей презентации на форуме, о чем еще напишу). А кто-то переходит в аутсорсинговый SOC. Последний вариант и был выбран ГТЛК. 

 

Вообще тема аутсорсинга красной нитью проходила через форум. Оно и не мудрено - много партнеров мероприятия предоставляет такие услуги и понятно, что они вытаскивали своих заказчиков на мероприятие. Следующий выступающий, Антон Кокин из ТМК, рассказывал об опыте мониторинга ИБ в своей компании, которая выбрала гибридную модель SOC - что-то было развернуто в собственной инфраструктуре, а что-то было отдано на откуп в аутсорсинговый SOC.

Аутсорсинг - конечно, штука, полезная и интересная. И особенно там, где хочется фокусироваться на основных компетенциях, а все непрофильное отдать вовне. Но есть у этой модели (помимо всего прочего) и такой отрицательный момент, как отсутствие роста внутренних компетенций и потеря производительности. Об этой дилемме говорил Александр Лимонов из Леруа Мерлен, рассказывая про их процесс управления инцидентами, использования аутстаффинга для него. Отдельно он рассказал о том, как автоматизирован процесс реагирования на инциденты и как компания выбирала между коммерческой IRP-платформой и решениями класса open source.

Продолжился трек с клиентским опытом рассказом специалистов Банка "Санкт-Петербург", Евгения Алексеева и Дмитрия Бабкова, которые рассказали о том, как они организуют киберучения в своей организации и проверяют возможности SOCа обнаруживать и отражать спланированные атаки. Это выступление также изобиловало богатой практикой и, на мой взгляд, хорошо дополнило ранее упомянутое выступление Лаборатории Касперского про Red Team'инг.

Выступление Артема Кунгурцева из ДИТа Москвы было предельно коротким, что, как мне кажется, было обусловлено тем, что за время пандемии, когда на ДИТ Москвы было обрушено огромное количество критики за то, как работали сервисы выдачи пропусков, приложение "Социальный мониторинг" и т.п., ДИТ стал очень осторожно общаться с внешним миром и дозированно подавать информацию о том, что он делает. Поэтому каких-либо интересных деталей о том, как устроен главный московский SOC, входит ли в его область контроля видеокамеры, доступ к которым продается в Даркнете, или как мониторится блокчейн, на котором построена система выборов, мы не услышали. А жаль...

Завершал секцию клиентского опыта Антон Юдаков из Ростелеком-Солар (не совсем клиент все-таки), который приоткрывал завесу расследования и реагирования в своем SOCе. Взяв за основу схожий с Игорем Залевским, с которого я начал эту заметку, подход к рассказу - на базе кейсов, Антон добавил в презентацию то, чего не хватало Игорю, - выводы и извлеченные уроки.

Завершал этот канал поток с разбором ошибок, которые совершались в процессе построения и эксплуатации различных SOCов. Это стало отличительной особенностью SOC Live от многих других мероприятий по ИБ, на которых компании и люди деляться своими достижениями, умалчивая о своих провалах и факапах. На SOC Live не стали замыливать и эту тему - о своих ошибках рассказывали Владимир Дрюков (Ростелеком-Солар), Андрей Дугин (МТС), Владимир Дмитриев (CyberART), Тимур Зиннятуллин (Angara) и Антон Юдаков (снова Ростелеком-Солар).

 

На этом я завершу рассказ о первом канале SOC Live, который я комментировал и доклады которого я слушал. Завтра попробую описать то, что происходило на втором канале, который комментировал Алексей Комаров, но в программе которого я выступал дважды и успел послушать ряд докладов, которые были до и после моих выступлений.

ЗЫ. Предвосхищая вопрос о презентациях и видео с SOC Live. Все скоро будет выложено на сайте конференции после обработки.

Подробнее…

Что общего между SOCом и онлайн-мероприятием по ИБ? Ложь в цифрах!

Выборы президента США навели меня тут на рассуждения о том, как умело манипулируют цифрами то демократы, то республиканцы и как это похоже на то, что происходит в центрах мониторинга ИБ, а именно при визуализации ключевых показателей эффективности SOC. Аналогичные манипуляции используют и организаторы онлайн-мероприятий по ИБ, которые пытаются их продавать, используя все те уловки, что и при подсчете голосов или числа инцидентов. Ведь иначе свой "продукт" не продашь. А покупают его все хуже и хуже, так как просто пустить говорящую голову в Zoom или Webinar.ru (даже если она моя ;-), - это еще не значит провести достойное мероприятие. Ни особых фишек, ни кулуаров, ни чего-то еще, что могло бы действительно привлечь аудиторию...

Собственно аналогия с мероприятиями у меня возникла не на пустом месте. Попросили тут меня провести для одной компании вебинар по повышению осведомленности сотрудников в области ИБ, пообещав загнать туда около 400 человек, почти весь свой персонал. Для этого они были готовы привлечь HR, который должен быть разослать сообщение по всем сотрудникам, большинство из которых находилось на удаленке. Сказано - сделано. В день мероприятия я подключаюсь к платформе (это был Zoom) и вижу там 36 человек. Мда, - думаю. "Прекрасный" результат, отражающий все отношение сотрудников компании к ИБ. До конца мероприятия осталось 32 человека (достаточно неплохой результат - 89%). Каков эффект от мероприятия мне неизвестно, но в письме, которое служба ИБ направила своему руководству, фигурировало число 400, красиво обернутое фразой "информация о мероприятии была доведена до 400 человек" :-) Но мы же прекрасно понимаем, что это совсем не то, что было в реальности. Аналогичная ситуация и с онлайн-мероприятиями, а я за последние почти 9 месяцев поучаствовал в многих из них.

Их организаторы обычно хвалятся числом регистраций. Это примерно как хвалиться числом событий ИБ, которые фиксируют ваши средства защиты. Например, в инфраструктуре Cisco фиксируется ежедневно 1,2 триллиона событий ИБ. Это, на минуточку, в 3 раза больше чем звезд в нашей галактике "Млечный путь". Круто, не правда ли? Но вот только мы прекрасно понимаем, что из этих событий ИБ многие ложные, а многие вообще малоинтересны. Мы должны все эти события просеять через различные фильтры, убрав ложные срабатывания, проведя анализ и корреляцию, а после из оставшихся реальных инцидентов выбрав только критичные. В итоге, в Cisco остается на отработку нашим SOCом всего 22 инцидента в день. Так вот с онлайн-мероприятиями необходимо использовать ту же саму "воронку продаж", только вместо "клиентов" использовать слушателей.

Не так важно, сколько человек зарегистрировалось, важнее, сколько из них вообще пришло на вебинар. Кто-то из организаторов говорит, что у них офигенная конверсия, если удается заполучить на вебинар больше 50% от числа регистраций. Это еще одно лукавство организаторов онлайн-мероприятий. Считать надо не число пришедших, а число дослушавших до конца. Причем именно дослушавших, а не досидевших. Вы же понимаете разницу, да? Первые держали окно плейера или вкладку браузера поверх всех остальных окон и, скорее всего, слушали вебинар (конечно, есть вероятность, что они просто свалили пожрать в это время, но это отдельная тема). А вот вторые могли просто включить вебинар, отключить звук и заниматься своими делами. Поэтому, говоря об эффективности онлайн-мероприятия хвалиться надо не числом регистраций (хотя эта цифра лучше продается), а числом активно дослушавших до конца.

В SOC ровно тоже самое - показывать надо не число событий безопасности, и даже не число инцидентов, а число тех инцидентов, которые не были закрыты в течение заданного для данного типа инцидента времени. Именно это будет показывать один из срезов реальной работы SOC. Хотя этот показатель может быть и не очень приятным. В идеале он должен быть равен нулю; как и число активных слушателей вебинара должно быть в идеале равно числу регистраций (а лучше числу разосланных приглашений). В реальности он обычно сильно отличается, может быть на порядки, от первоначального числа, которое все и показывают. Кстати, если говорить о платных онлайн-мероприятиях (для вендоров/интеграторов, покупающих их у организаторов), то там для их покупателей гораздо более важным показателем будет считаться число сделок после вебинара; или хотя бы число лидов после него. А иначе зачем платить деньги за вебинар, если он не приносит покупателей? 

Поэтому простой совет покупателям онлайн-мероприятий - не ведитесь на цифры, связанные с числом регистраций на вебинар или числом пришедших на него (это еще не конверсия). Просите статистику активности слушателей и сколько из них досидело до конца. Это будет гораздо лучше отражать реальную эффективность ваших затрат. Кстати, еще один трюк, который так любят организаторы онлайн-мероприятий, - использовать платформы, для этого непредназначенные, или не покупать правильную лицензию для них, пытаясь ограничиться минимальной, не обеспечивающей нужной функциональности именно для онлайн-меропритий. Кстати, ровно тоже самое касается и онлайн-тренингов по повышению осведомленности по ИБ, который сейчас проводят многие компании для своих сотрудников на удаленке.

Вот пример с повышением осведомленности и более глубокая статистика, чем просто число регистраций. Для анализа использовался сервис Cisco Webex Events (не путать с Webex Meetings - разница именно в фишках для организации мероприятий), который по каждому мероприятию позволяет собрать полноценную статистику, из всего объема которой нас в контексте данной заметки интересует всего три показателя. Первый - длительность участия в мероприятия с момента входа до момента выхода. Для одного из Security Awareness тренингов, длившихся чуть более двух часов (почему так долго - это отдельный разговор), статистика выглядит следующим образом. Метрика "среднее время нахождения на мероприятии":

Четверть слушателей только половину тренинга отсидела и свалила. Второй важный показатель - это время, в течение которого Webex находился поверх других окон, то есть иными словами это реальная активность слушателя. Истинная картинка такая:

Иными словами, около половины слушателей не так активно слушали и смотрели тренинг по повышению осведомленности, как того хотелось бы :-( Можно поименно вытащить всех, кто манкировал и с каждым провести работу. Но это при условии, что у вас есть необходимые для оценки цифры. И снова "кстати", - если SOC предоставляет сервис фишинговых симуляций и повышения осведомленности (а многие SOC это делают), то ему неплохо бы измерять данные показатели, чтобы оценивать реальную вовлеченность слушателей в мероприятие, а не просто проводить их для галочки.

В заключение хочу повторить мысль, с которой я начинал заметку. Понятно, что красивые и большие числа всегда интереснее небольших. Именно первые хочется вынести на дашборд SOC или отобразить в отчете службы ИБ; а организаторам онлайн-мероприятий показать покупателям. Но увы, как и в случае с выборами, надо смотреть за пределы этих очевидных KPI. Тогда оценка эффективности будет более эффективной. Уж простите за тавтологию...

Подробнее…

О необходимости регулярного пересмотра метрик в SOC

Расскажу историю. Проводим мы тут аудит одного SOCа и в рамках выполняемых работ есть у нас задача проверки и выработки рекомендаций по улучшению системы показателей эффективности SOC (метрик), дашбордов, отчетности и вот этого вот всего. В процессе воркшопа, в рамках которого мы выясняем детали реализации процесса изменения эффективности, руководитель SOC делится своей болью. Мол, при построении SOCа разработали им каталог метрик, частично автоматизировали их сбор, настроили визуализацию и поначалу все было хорошо. Но потом руководителю SOC стало казаться, что его аналитики стали отлынивать от работы - он все чаще их стал видеть в курилке или небольшими общающимися группками, но точно не на рабочем месте. При этом все показатели выполнялись - дашборды зеленые. То есть вроде все нормально, но что-то не то...

Стали разбираться и выяснилось, что в SOC был полгода назад внедрен SOAR, который автоматизировал многие ранее выполняемые вручную задачи и, соответственно, у аналитиков высвободилось больше времени на решение своих задач. Но при этом метрики пересмотреть забыли и их по-прежнему считали исходя из прежнего технологического стека, ориентированного на преимущественно ручную обработку многих инцидентов. Поэтому дашборд и был все время зеленым - SOAR в разы сократил время разбора инцидентов, реагирования на них, передачи на другие линии SOC, обогащения инцидентов данными TI и т.п.

Сами аналитики SOC, увидев, что систему оценки их деятельности не пересмотрена, не стали сообщать об этом, что и понятно - в рамках имеющейся бонусной системы они стали получать больше, а работать меньше. В итоге в рамках проекта по аудиту SOC мы пересмотрели имеющиеся метрики и учли новые внедренные решения, автоматизировавшие многие задачи аналитиков SOC.

Эта история показывает, что система оценки эффективности SOC не является застывшим на века и выбитым в граните инструментом измерений - он эволюционирует вместе с SOCом и разработанные метрики должны регулярно пересматриваться. В продвинутых SOC этим занимается отдельный человек или отдел, который контролирует качество процессов SOC и предлагает их улучшения. Этакий внутренний аудитор или ревизор, который не дает центру мониторинга покрыться плесенью.   

Схожая история будет проявляться в SOCах, которые не просто автоматизируют свою деятельность, а внедряют, например, системы искусственного интеллекта (машинное обучение) в деятельность по мониторингу инцидентов, работе с TI, анализу уязвимостей, проведению фишинговых симуляций и т.п. Во всех этих процессах, перешедших на машинное обучение, также придется пересматривать показатели оценки эффективности. Например, в SOCе измеряют число созданных аналитиками правил на SIEM или число созданных/обработанных аналитиками IoC. Понятно, что по мере перехода на ML, который автоматизирует эту задачу, число вручную создаваемых правил и индикаторов будет сильно сокращаться. И если есть метрики, которые считают число заходов в интерфейс SIEM, число разработанных правил корреляции, число используемых источников TI, число разосланных аналитиками фишинговых сообщений и т.п., то они начнут давать сбой (при общем повышении эффективности защиты) и их придется пересматривать.

Подробнее…

13 советов, от которых зависит успешность вашего SOC (презентация)

Продолжаю публиковать ранее невыкладываемые материалы с "Кода ИБ". На этот раз это будет презентация "13 советов, от которых зависит успешность вашего SOC", которую я читал в апреле 2019 года, то есть более года назад. Хочу отметить, что вчерашняя презентация про Threat Intelligence читалась мной 2,5 года назад и сегодня на нее смотришь немного иначе, чем тогда. Так и с презентацией по SOCам - что-то уже не так актуально, но что-то продолжает оставаться достаточно важным и полезным.

Презентацию выкладываю на Slideshare и в свой канал в Telegram.

13 советов, от которых зависит успешность вашего SOC from Aleksey Lukatskiy

Подробнее…

Опыт обучения на курсах по SOCам

Упомянул вчера про прохождение курса по SOCам (для тех, кто думает, что SoC - это System-on-Chip, сообщаю, что это Security Operations Center) и хочу поделиться некоторыми впечатлениями. Начну с того, что когда речь заходит об обучении по SOCам, нет ни одного курса, который бы закрыл все потребности в этой части, как нет человека, который в SOC занимается всеми направлениями - от мониторинга до реагирования, от threat hunting до threat intelligence, от проектирования архитектуры до формирования плана обучения аналитиков. Это все разные задачи, которыми занимаются разные роли внутри SOC. Поэтому и обучение тут нужно разное. Одним нужны курсы по Threat Hunting, другим по реагированию на инциденты, третьим по организации Red Team (если это часть сервисной модели SOC), четвертым - по планированию и проектированию SOC. Я про это уже и писал и выступал, но посчитал нелишним упомянуть еще раз. Так вот сейчас я бы хотел поделиться впечатлением о курсе именно про планирование и проектирование SOC, который ориентирован больше не на аналитиков по мониторингу ИБ (типа CompTIA Cybersecurity Analyst, о прохождении которого я уже писал, или Cisco CyberOps Professional), а на руководителей центров мониторинга или их аудиторов и проектантов (проектировщиков). Ну а так как я в последнее время глубоко погружен в эту тему и участвую в разных проектах по аудиту или проектированию SOCов, то я и решил, что надо систематизировать свои знания по этой теме.

Хочу отметить, что курсы по проектированию SOCов я нашел только у SANS. Первоначально это был пятидневный курс SANS MGT517, который разработал и вел Chris Cowley. Позже, причина до сих пор непонятна, MGT517 был закрыт SANS'ом и долгое время никаких специализированных курсов по SOCам не было, пока в прошлом году Крис не анонсировал собственный трехдневный курс по SOCам (его я и проходил недавно), а SANS не запустил двухдневный курс MGT551 имени Джона Хаббарда. MGT551, по словам его автора, является дополнением к его же курсу SEC450 по Blue Team и позволяет дополнить картину уже с высоты птичьего полета, с точки зрения менеджера SOC. Курс Криса по-прежнему ориентирован только на руководителей/аудиторов/проектантов SOC и не является дополнением к чему бы-то ни было. У SANS есть еще шестидневный курс SEC511 по непрерывному мониторингу и SecOps, но он схож с упомянутыми выше курсами CompTIA и Cisco CyberOps, то есть ориентирован именно на специалистов по мониторингу ИБ, чем на лидеров.

Но вернемся к курсу Криса, который первоначально проходил только очно, но ввиду коронавирусной  шумихи был срочно переведен в онлайн-формат. Не могу сказать, что это повлияло на него с положительной точки зрения, так как возросла нагрузка на слушателей, которые должны были гораздо более серьезно относиться к обучению и заданиям, которые давались в рамках курса (но про это я уже написал вчера). С другой стороны, когда ты не связан корпоративными ограничениями (я имею ввиду SANS), можно быть чуть более открытым и давать материал лучше. Да и кучу сопутствующих материалов предоставлять (хотя, может, это больше зависит от инструктора, чем от от того, где курс читается).

Как я уже упомянул, курс не рассчитан на аналитиков, работающих с различными платформами и инструментами, его задача другая. Показать, нужен ли SOC организации и если да, то какой, и по какой модели его строить.

Очень много времени уделяется вопросу выбора и обоснования. Например, как обосновать необходимость SOC руководству компании, какие доводы использовать, каким ролям CxO важны какие задачи SOC и т.п.

С выбором связана и тема смен в SOCах. Крис давал различные модели и описывал их плюсы и минусы. Полезная тема с точки зрения планирования работ персонала и определения численности сотрудников SOC.  

Фанатам технологий тоже было уделено внимание, но не с точки зрения лабораторных работ по конкретным платформам и инструментам, а с точки зрения их выбора. например, какие альтернативы есть для защиты коммуникаций в SOC, для TI, для SOAR, для SIEM и т.п. Причем они сравниваются по разным параметрам (цена, функциональность и т.п.), что дает возможность слушателям потом выбирать то, что лучше подходит под их задачи. Никаких "купите QRadar как SIEM" или "только Webex Teams может быть использован для коммуникаций внутри SOC".

Тема технологий развивается и с точки зрения геополитических рисков. Но не "Русские хакеры! Все пропало!", как это было на курсах SANS по промышленной ИБ, а с точки зрения оценки рисков использования различных технологий и сервисов от разных компаний и стран. Интересно, что Крис не просто показывает всякие прикольные таблички, а потом отдает их и с ними можно играться по своему усмотрению.

Говоря о мониторинге ИБ, нельзя обойти вниманием вопрос процессов. Крис подробно рассматривает достаточно стандартную процессную схему SOC с погружением в отдельные процессы и особенности их выстраивания с точки зрения менеджмента, выбора технологий под них или их аутсорсинга во внешние руки. 

Хороший раздел про разработку use case. Причем не только с точки зрения теории, но и практики.

Например, выдали табличку с кучей готовых use cases с их разбиением по L1-L3, привязкой к матрице MITRE ATT&CK, метриками и оценкой их эффективности. Полезная штука - мы в рамках наших проектов по SOC тоже используем схожую табличку в Excel, куда заносятся все Use Case, которые мы разрабатываем и с которыми потом можно работать, а не просто теоретизировать. 

Ну и конечно вопрос измерения эффективности тоже не был обойден вниманием, хотя он, на мой взгляд, был не очень детально проработан. Метрики описывались больше технологические, чем бизнесовые. Но и среди них были интересные примеры, нечасто встречающиеся в публичных презентациях по оценке эффективности SOC. 

Ну и для тех, кто любит сравнивать себя с другими SOCами, был раздел про оценку зрелости SOC с рассмотрением соответствующей модели зрелости и заданиями по ее использованию. Мы в своих проектах по аудиту уже построенных центров мониторинга тоже сталкиваемся с вопросом "А как мы соотносимся с другими?". Правда, в ответе на него гораздо важнее иметь не саму модель зрелости, а результаты этой оценки по другим SOCам, о чем Крис скромно умолчал :-)

Сложно в короткую заметку включить материал всех трех дней по 8 часов каждый. Поэтому могу в целом отметить, что курс очень полезный именно для тех, кто строит собственный или проводит аудит уже построенного SOCа и хочет получить общую картину под названием "центр мониторинга ИБ". Если вам нужны знания по конкретным направлениям деятельности SOC, то это скорее уже другие курсы, в том числе и вышеупомянутые. 

ЗЫ. Вроде как Крис упоминал, что ему тоже не очень понравилась идея онлайн-курса по SOC и, возможно, больше таких не будет, - останутся только очные мероприятия, что увеличит цену на них, минимум, вдвое (за счет билетов и проживания). И это не считая сложностей с командировкой за пределы страны (сам Крис из США, но иногда проводит курсы в Европе, куда попасть сейчас непросто).

Подробнее…