Обзор 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. Все скоро будет выложено на сайте конференции после обработки.

Подробнее…

Последствия от онлайна по ИБ - от ибшнего getAbstract до онлайн-ИБ-тамады

UPDATE: Эта заметка изначально писалась в прошлую среду, но я забыл ее запостить, а потом, точно в тот же день, Рустем Хайретдинов в Фейсбуке написал примерно ту же идею, и я даже хотел удалить заметку, чтобы не дублировать Руста. Но потом подумал, что я мысль повторю, но поверну ее немного в иную плоскость. Тем более и повод нашелся для этого. 

Завершившися недавно The Standoff, навел меня на мысль о стартапе, который мог бы быть достаточно востребован у ИБ-аудитории, особенно у людей, занимающих руководящие должности и при этом стремящиеся к постоянному самообучению. Речь идет о аналоге классических getAbstract или Smart Reading (и вроде как эта идея даже уже звучала у Льва Шумского в Фейсбуке). Последние полгода лишний раз показали, что такой сервис как никогда нужен. 

Вот заходите вы на портал The Standoff и видите там 70 досаточно интересных докладов по информационной безопасности, которые вы бы и хотели посмотреть/послушать, но явно не готовы потратить на это 70 часов при обычной скорости просмотра и 50 часов на ускоренной в 1,5 раза перемотке. Что делать? А если сюда приплюсовать сотни часов RSA Conference, Black Hat, Defcon, SOC Forum, Магнитки и множества других не менее интересных мероприятий, на которых часто рассказываются очень интересные вещи, но которые остаются неуслышанными по причине нехватки времени на их прослушивание. Ровно по этой причине столь большой популярностью пользуется моя презентация на Магнитке "Уральский форум за 15 минут", и мои, правда, уже заброшенные обзоры новой нормативки и регулярно читаемые пятичасовые курсы по новинкам законодательства по ИБ для финансовой сферы.

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

С одной стороны, это вроде усложняет задачу. Людей, которые пишут резюме для Smart Reading или getAbstract на порядки больше. Но с другой, это не такая уж и нерешаемая задача. Под нее можно брать "пенсионеров", которые разбираются в теме и у них много времени, чтобы сидеть и слушать/читать все, что необходимо для описываемого сервиса.

Таким "пенсионерам" есть и еще одна сфера применения - поддержка онлайн-мероприятий. Вы замечали же, что многие мероприятия, ушедшие в онлайн, много потеряли, так как нет кулуарного общения? Но проблема еще и в том, что их организаторы часто считают, что можно просто дать красивую картинку во вкладку браузера слушателя и наступит счастье. Увы, не наступит. В онлайне тоже надо активно общаться с участниками в чате/чатах, созданных каналах в Телеграм или группах в Вотсапп, а у продвинутых так и в комнатах Webex Teams/Training, каналах Slack и т.п. Ведь во время скучного доклада слушатель может уйти и уже не вернуться. Его надо удерживать и беседа с умными людьми в чате помогает решить эту задачу. Но другие слушатели не всегда горят желанием "болтать" или отвечать на вопросы - им доклад может быть интересным. Поэтому нужны профессиональные ИБ-тамады, которые будут комментировать выступления, троллить докладчиков (по доброму), вовлекать аудиторию в дискуссию и т.п. Тогда онлайн реально станет онлайном, а не просто просмотром видео, которое можно сделать в свободное время на ускоренной перемотки без потери качества.

Мне такая идея показалось достаточно интересной и сегодня, на SOC Live мы ее обкатаем. Вместе с Алексеем Комаровым мы будем в течении дня комментировать в чате все выступления в обоих потоках виртуального SOC Forum. Не взирая на регалии и спонсорские пакеты - все, что мы посчитаем нужным, мы выплеснем на платформе для мероприятия и с нами можно будет даже вступить в перепалку и виртуально набить нам морду :-) Это интересный формат, которого раньше не было у нас на мероприятиях. И если он получится, то так ругаемый всеми онлайн-формат (он же "вебинар на стероидах", как его называет Денис Горчаков) может получить новуюжизнь. А ИБ-пенсионеры смогут найти себя. Если, конечно, их найдут организаторы мероприятий и посчитают возможным для себя потратить на их услуги немного спонсорских денег :-)

ЗЫ. По итогам формата с онлайн-ИБ-тамадой отпишусь в блоге, а вот идея с ИБшным getAbstract остается пока нереализованной. 

Подробнее…

Как выстроить эффективный процесс повышения осведомленности по ИБ (видео)

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

Подробнее…

Обнаружение угроз 20 лет спустя: источники данных и их расположение

 В ряде прошлых заметок я коснулся темы обнаружения угроз и показал отличия этих двух тем сейчас и 20 лет назад. Продолжу. Одним из ключевых отличий является наличие совершенно различных типов контента обнаружения, который не ограничен только сигнатурами атак. Но не только это. На самом деле я бы выделил еще 3 ключевых направления, в которых произошли кардинальные изменения:

• источники данных
• методы анализа
• сценарии обнаружения (use case).

Задайте себе простой вопрос - что вы сейчас анализируете на предмет вредоносной активности и в чем вы ищете ранее обсуждаемый контент обнаружения? Сетевой трафик? Логи? Телеметрию? Файлы? URL? Почтовый трафик? Активность пользователей и процессов? А анонсы BGP? А API? А DNS-трафик?

20 лет назад основным источником данных для обнаружения угроз служили сырой сетевой трафик (для сетевых систем обнаружения вторжений/атак) и журналы регистрации (для хостовых систем обнаружения вторжений). Но постепенно спектр источников данных стал расширяться и помимо сырого трафика сетевые угрозы стали обнаруживаться по телеметрии и логам, собираемым с сетевого оборудования, а журналы регистрации на узлах дополнились анализом запускаемых процессов. 

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

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

Указанные источники данных для обнаружения угроз необходимо анализировать не только на границе Интернета и корпоративной сети и не только на границах сегментов и контуров внутренней сети, где обычно ставят сенсоры систем обнаружения атак. Мониторинг угроз должен проводиться во всех местах, которые хранят или обрабатывают корпоративные данные и приложения, в том числе и за пределами корпоративного периметра – в облаках, на стороне аутсорсинговых партнеров и т.п. 

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

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

Обратили внимание на последний пункт в последнем чек-листе? "На стороне хакеров". Что это значит? Сегодня существует возможность и технологии, которые позволяют мониторить Darknet или инфраструктуру злоумышленников. Например есть решения, которые позволяют анализировать площадки, которые хостят фишинговые сайты и командные сервера киберпреступников. С помощью различных методов анализа и контента обнаружения можно даже предсказывать некоторые угрозы, еще нереализуемые злоумышленниками.

Вот такая картина сегодня вырисовывается, когда мы говорим об эффективном обнаружении угроз. За прошедшие 20 лет технологии и подходы сменились и ограничиться только обычными СОВами, описываемыми регуляторами, сегодня уже явно невозможно.

Подробнее…

Актуальные требования регуляторов к средствам защиты (видео)

В январе выступал на конференции Oracle Security Day с рассказом об актуальных на тот момент требованиях регуляторов к средствам защиты информации. Оказывается видео этого выступления было официально выложено на Youtube:

ЗЫ. Понятно, что с января много воды утекло, но многие аспекты остаются пока еще актуальными.

Подробнее…

Требуется консультант по безопасности личного профиля (навеяно Дзюбой)

Не так часто пишу про персональную кибербезопасность, но история с интимным видео Дзюбы навеяла ряд мыслей, которые показались мне достаточно важными, чтобы сохранить их для потомков. Итак, дистанцируясь от конкретной истории, мы имеем дело с публикацией интимного видео человека в Интернет явно без его согласия. Что стоит за такой ситуацией? Я бы выделил 5 причины:

1. Месть "бывшей". Вполне возможный вариант, повлиять на который мы не в состоянии никак. По крайней мере информационная безопасность тут ни причем. 
2. Случайность. Всякое бывает. Я тут в Whatsapp хотел отправить картинку в сообщении и случайно вместо одной кликнул на соседнюю. Размер экрана смартфона и толстые пальцы - это вообще сложносовместимые вещи, а уж если в фотопотоке рядом соседствуют обычные и интимные фото и видео, то тем более. К ИБ это тоже отношения не имеет, по крайней мере пока смартфоны не научились распознавать содержимое видео и фото и не задавать вопросов "Вы уверены, что хотите разместить в публичном доступе этот контент?" Ну либо соцсети должны оперативно выявлять и блокировать такой контент (правда, если он попал туда случайно).
3. Смартфон был взломан и злоумышленники вытащили все самое ценное, что было в нем. Вспоминая уязвимости Bluesnarfing/Bluebugging/Bluejacking/Bluesnipping в Bluetooth, понимаешь, что такое возможно; особенно, если смартфон давно не обновляли. Тут даже физический доступ к смартфону получать было необязательно.
4. Было взломано облачное хранилище, в котором хранились фотографии, видео и, возможно, резервные копии смартфона. При отсутствии многофакторной аутентификации или затроянивании домашнего компа с доступом к облаку такой сценарий тоже вполне возможен.
5. Ну и, наконец, дипфейк. В истории, послужившей причиной для данной заметки, вроде как это не так, но в теории такое вполне может быть. В Интернете публикуется видео или фото с подменой лица и потом иди и доказывай, что ты не верблюд. Может быть ты это и докажешь, но "осадочек остался".

В 2014-м году Сколково и АСИ выпустило атлас новых профессий, в котором говорилось о том, что до 2020-го года должна появиться такая профессия, как консультант по безопасности личного профиля. 4 года назад я уже писал о том, что у меня были идеи замутить бизнес на эту тему. Но пока я благополучно работаю в Cisco, а прогноз Сколково и АСИ не сбылся, временно возьму на себя роль такого консультанта и дам ряд советов по 3-5-м пунктам:

1. Регулярно обновляйте свой смартфон, особенно если он на Андроиде, уязвимость которого изначально выше из-за архитектуры и подхода Google к работе с этой платформой и распространением приложений для нее.
2. Настраивайте права доступа мобильных приложений и не разрешайте им то, что не нужно. Например, зачем приложению с прогнозом погоды доступа к вашей адресной книге и фотографиям?
3. Установите на смартфоне PIN-код длиннее 8 символов (если он символьный).
4. Настройте многофакторную аутентификацию при работе с внешними сервисами, особенно облачными сервисами, хранящими фотопоток (например, iCloud, Google Фото, OneDrive, Яндекс.Диск, Облако Mail.ru, Dropbox и т.п.) и резервную копию.
5. Сыграйте с собой в игру "А что, если?.." Если вы достаточно известный человек, то что вы будете делать, если в Интернете появится ваши нелицеприятные видео или фото? И дело тут не только в дикпиках. Представьте, что вы жрете козявки перед web-камерой? :-) Или чешете себе "Гондурас" регулярно... Неприятно, да. Но это уже не исправить и не удалить, а попытка потребовать удаления каких-то материалов из Интернет приведет только к эффекту Стрейзанд. Неплохо бы подготовить (хотя бы в голове) какое-нибудь заявление по поводу, пытаясь не усугублять негатив, повернув его в более позитивное русло. 
6. В развитие предыдущего совета, подумайте о том, что даже если вы весь белый и пушистый и web-камера у вас заклеена изолентой как у Цукерберга, то существует такое явление как Deep Fake, которое позволяет приделать ваше лицо к чужому телу. И это не игрушки, когда используется Photoshop (как в рекламе для 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. Тогда оценка эффективности будет более эффективной. Уж простите за тавтологию...

Подробнее…

Что такое контент обнаружения или почему сигнатур атак недостаточно?

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

На первом этапе вы должны определиться с тем, что вам позволит обнаруживать угрозы. Обычно в качестве контента обнаружения рассматриваются сигнатуры, которые точно описывают ту или иную угрозу. Например, вот так может выглядеть сигнатура для Zerologon:

alert tcp any any -> [$HTTP_SERVERS,$HOME_NET] any (msg:"ET EXPLOIT Possible Zerologon NetrServerReqChallenge with 0x00 Client Challenge (CVE-2020-1472)"; flow:established,to_server; content:"|00|"; offset:2; content:"|04 00|"; distance:19; within:2; content:"|5c 00 5c 00|"; distance:0; within:50; content:"|00 00 00 00 00 00 00 00|"; isdataat:!1,relative; fast_pattern; threshold: type limit, count 5, seconds 30, track by_src; reference:url,www.secura.com/blog/zero-logon; reference:cve,2020-1472; classtype:attempted-admin; sid:2030870; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Server, created_at 2020_09_14, cve CVE_2020_1472, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, updated_at 2020_09_18;)

Имея низкий уровень ложных срабатываний сигнатуры считались долгое время основным, а иногда и единственным способом обнаружения угроз. Ярким примером системы обнаружения атак на базе сигнатур является бесплатная система Snort, лежащая в основе многих отечественных СОВ/СОА, или Zeek (бывшая Bro), а также коммерческие решения, лидером рынка которых по мнению Gartner является Cisco.

Да, на первое место вы поставили сигнатуры; куда уж без них. Но что еще? Более оперативным и получаемым из множества источников (для снижения зависимости от одного поставщика) является способ, ориентированный на индикаторы компрометации, которые позволяют обогатить существующие события безопасности и сделать обнаружение более точным. Да, до 80% всех прилетающих в фидах индикаторов - это шлак и ничего не стоящая информация. Но часто именно этот способ, особенно если IoC поступают не от производителя вашей же системы обнаружения вторжений, помогает обнаруживать то, что пропущено сигнатурами. К тому же, IoC можно загружать в различные системы аналитики, обогащая ими имеющиеся "сырые" данные и повышающие их точность.

Комбинация IoC

Триггеры позволяют отделять нормальную активность от аномальной. Например, решение по защите e-mail позволяет выявлять компрометацию почтовой учетной записи пользования по числу отправляемых вовне сообщений, а система класса Network Traffic Analytics/Analysis позволяет выявлять утечки данных через разрешенные сетевые протоколы, например, DNS.

18 Гб с терминального сервера по DNS? Не странно ли? 

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

Анализ файла в песочнице

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

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

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

Обнаружение утечки данных в зашифрованном трафике

Разновидностью алгоритмов является машинное обучение, которое позволяет выявлять сложные атаки (например, вредоносный код внутри зашифрованного трафика), а также ранее невстречаемые угрозы (например, атаки с новых вредоносных доменов).

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

 

Подробнее…