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

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

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

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

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

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

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

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

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

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

 

Подробнее…

Обнаружение угроз 20 лет спустя: краткое резюме

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

1. Угрозы постоянно эволюционируют – за ними должны эволюционировать и механизмы их обнаружения.
2. Не существует «серебряной пули» - универсального метода и решения по обнаружению угроз. 
3. Сравнение систем обнаружения вторжений по числу сигнатур сегодня не отражает ни качества продукта, ни его возможностей, так как, во-первых, число угроз бесконечно, во-вторых, способы создания сигнатур могут быть разные (сигнатура для эксплойта vs сигнатура для использования уязвимости), а, в-третьих, существуют не только сигнатурные методы обнаружения угроз.
4. Традиционные системы обнаружения вторжений тоже эволюционируют и могут решать вполне конкретные задачи в рамках определенной области применения.
5. Существует немало способов улучшения сигнатурных методов обнаружения угроз. Для выстраивания современной системы обнаружения угроз необходимо понимать ограничения используемых вами сейчас методов 
6. Необходимо использовать разный контент обнаружения, не ограниченный только сигнатурами атак, а расширенный индикаторами компрометации, триггерами, правилами, графом взаимосвязей, алгоритмами и т.п.
7. Контент обнаружения должен применяться к различным источникам данных – сетевому трафику, файлам, URL, активности процессов, логам, API и т.п.
8. Нельзя полагаться только на один метод обнаружения – необходимо комбинировать различные способы, взаимно дополняющие друг друга.
9. Обнаруживать угрозы можно не только на стороне заказчика, но и своевременно выявлять их, устанавливая решения по обнаружению на уровне операторов связи, провайдеров услуг или государства (примером последнего являются ГосСОПКА или ФинЦЕРТ).
10. Современная система обнаружения угроз – это комбинация разного контента и методов обнаружения, различных источников данных, а также мест установки компонентов системы обнаружения угроз.
11. Помимо процесса обнаружения угроз также должен быть выстроен процесс их поиска (threat hunting), который позволяет подтвердить или опровергнуть сделанные гипотезы о наличие или отсутствии следов компрометации в корпоративной инфраструктуре.
12. Требования российских регуляторов (ФСТЭК, ФСБ, Банка России и др.) ориентированы только на один из классов средств обнаружения угроз – системы обнаружения вторжений/атак.

Подробнее…

От обнаружения атак к обнаружению угроз или что изменилось за последние 20 лет

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

Документы ФСБ по системам обнаружения атак являются закрытыми, а вот отношение ФСТЭК к этой теме вполне публично и ориентируясь на приказ №17, методичку по мерам защиты и РД на СОВ можно сделать следующие выводы. По мнению ФСТЭК

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

В целом, все вышеописанное достаточно неплохо описывало возможности систем обнаружения атак от начала 2000-х годов до начала 2010-х, когда собственно и писались упомянутые документы (2012-2013 гг.). Но с тех пор прошло немало времени и утекло много воды. Поменялось все - от техник и тактик злоумышленников до методов их обнаружения, от мест установки средств обнаружения до правил их эксплуатации. Я бы сейчас не взялся за написание единого руководящего документа, который бы позволил описать все современные возможности по обнаружению угроз, который можно было бы еще и применять при оценке соответствия средств защиты. Отсюда простой вывод - ФСТЭК и ФСБ застряли в прошлом со своими требованиями, которые тянут производителей только назад, не давая им разрабатывать более современные технологии обнаружения угроз. А вот потребители, особенно негосударственные, не скованы такими ограничениями и вполне могли бы пересмотреть свои взгляды на то, как должна быть выстроена современная система обнаружения угроз. Да-да, именно так. Не обнаружение вторжений, не обнаружение атак, а обнаружение угроз, которые могут принимать разные формы и с которыми можно и нужно бороться различными методами на различных участках защищаемой сети или за ее пределами.

Учитывая, что в этом году стукнуло 20 лет, как я написал свою первую книгу, "Обнаружение атак", я подумал, что можно запустить серию публикаций, которые будут направлены на то, чтобы рассказать о том, как отличается обнаружение вторжений конца 90-х и начала 2000-х от того, что происходит в начале 2020-х. И начну я, пожалуй, с чеклиста, который покажет, насколько эффективна ваша система обнаружения угроз.

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

Обратите внимание, что чеклист "бьет" по совершенно различным болевым точкам - от проводной сети до беспроводной, от сетевого уровня до прикладного, от офисной сети до облаков, от IoT/АСУ ТП до контейнеров, от сетевых атак до подброшенных устройств, прослушивающих сетевой трафик, от внутрикорпоративной установки средств обнаружения до установки в Интернет, от обнаружения сигнатур до мониторинга Darknet... Что-то из этого может быть реализовано с помощью приобретенных средств обнаружения, что-то с помощью аутсорсинга, а что-то потребует выстраивания системы обмена информацией с другими организациями. Современная система обнаружения угроз - это гораздо больше, чем все еще необходимая, но явно недостаточная система обнаружения вторжений/атак, которая еще и необязательна по мнению ФСТЭК для информационных систем низкого класса защищенности. Вот об этом мы и будем говорить в следующих заметках, которых, если повезет, наберется на 3-е издание книги "Обнаружение атак" :-)

Подробнее…

Регуляторы, ВСЕГЕИ или что такое MDM из ГОСТ 57580.1?

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

Возьмем, к примеру, ГОСТ 57580.1 имени Банка России, в котором, есть раздел 7.9, посвященный базовому составу мер защиты информации при осуществлении удаленного логического доступа с использованием мобильных (переносных) устройств. По сути, данный раздел, посвящен не только смартфонам и планшетам, а вообще любым переносным устройствам, включая и ноутбуки. И вроде бы все меры в этом разделе вполне понятны и реализуемы, если бы не одно но... А именно использование англоязычных аббревиатур для описания средств защиты, которые могут помочь реализовать ту или иную меру по защите. Например, MDM (Mobile Device Management), которые упомянуты в ЗУД.3 и ЗУД.10.

Эта аббревиатура, а равно и MAM, MCM, MSM, MEM, MIM и EMM, исторически была связана только с мобильными устройствами типа смартфон и планшет. Ни к каким других устройствам она не применялась, так как также исторически сложилось, что управление безопасность мобильных устройств отличается от управления безопасностью оконечных устройств (или, как их называет ЦБ: конечных точек) в виде стационарных компьютеров под управлением Windows, Linux, macOS и т.п. И если перед службой ИБ стояла задача защитить смартфоны и планшеты под управлением iOS или Android, то в голове сразу всплывала аббревиатура MDM. Причем надо отметить, что MDM - это управление мобильным устройством, а не обеспечение его безопасности. В контексте ИБ появились аббревиатуры MSM или MDSM, где буква S и означала безопасность (security).

MDM родила и схожие аббревиатуры - MAM (mobile application management), MCM (mobile content management), MIM (mobile information management) и т.д. В 2014-м году главный любитель новых аббревиатур, компания Gartner, ввела в обиход EMM - Enterprise Mobility Management, то есть класс решений, который включал в себя все аббревиатуры, начинающиеся с "M".

Но время шло, производители стали выпускать то, что было сложно относить к одной из четырех привычных категорий - смартфон, планшет, ноутбук, стационарный ПК. Более того, процесс "мобилизации" предприятий пошел так быстро, что классические мобильные устройства стали обладать всем набором ранее присущих только стационарным ПК свойств. Разве, что операционные системы пока использовались разные. Встал вопрос - может быть унифицировать функции управления всеми устройствами, на которых работают пользователи? Так родилась очередная аббревиатура - UEM (Unified Endpoint Management) и все классические игроки рынка MDM (MobileIron, SAP, Samsung, Blackberry, IBM, Citrix, Microsoft, VMware, Cisco и т.п.) стали относить свои решения к UEM, оснастив соответствующим функционалом. В итоге, найти сейчас на рынке классический MDM почти невозможно :-)

Но от экскурса в историю вернемся к стандарту Банка России, который использует именно аббревиатуру MDM. Лично для меня, это не столь существенно и я прекрасно понимаю, что данные раздел ориентирован не только на смартфоны и планшеты, а касается всех типов мобильных устройств, с которых можно осуществить удаленный доступ. Сейчас, во время пандемии и перехода на удаленку, эти устройства могут быть абсолютно любыми, не ограниченными только возможностью запуска на них ОС iOS, Android, "Авроры" или Sailfish. Поэтому для меня упомянутая в ГОСТ 57580.1 аббревиатура MDM не имеет никакого значения и я спокойно заменяю ее на MDSM, MSM, EMM или UEM, так как понимаю, что ГОСТ требует централизованного управления и мониторинга для переносных устройств, независимо от используемой ОС. Это логично. Но...

Недавно, в одном Telegram-канале возникла тема, в которой автор спрашивал, как реализовать ЗУД.3 и ЗУД.10 применительно к ноутбукам с Windows. На очевидный ответ, что ровно также, как и для обычного компа (СЗИ от НСД, EDR/антивирус, разграничение доступа, DLP и другие меры защиты из ГОСТ), последовал ответ, что вот же есть обязанность использовать MDM-решение. На комментарии, что тут важно соблюсти дух ГОСТа, а не буквоедствовать, топикстартер резонно заметил, что это с проверяющими из ЦБ не работает и они будут тупо требовать наличия именно MDM-решения. Не MSM (Mobile Security Management), не EMM, и даже не UEM, а именно MDM. В результате, вместо обсуждения того, как защитить пользовательские устройства на удаленке, дискуссия ушла в споры о том, что надзор можно ткнуть в то, что эта англоязычная аббревиатура вообще нигде не определена и что скрывается за тремя буквами никто не знает. А надо напирать на то, что используется не MDM, а система централизованного управления и мониторинга, под которую уже попадают и решения класса UEM и все остальные. Хотя гарантии, что это пройдет, никто не дает. Проверяющие бывают излишне въедливыми и прямолинейными - написано MDM, подавай MDM.

И ведь сама по себе проблема не стоит и выеденного яйца. Все всё понимают. Но раз уж речь идет о требованиях регулятора, то хотелось бы однозначности трактовок и либо отказа от использования аббревиатур типов защитных средств (достаточно вспомнить историю с аббревиатурами EDR, STAP им EVC, которые означают одно и тоже, только придумано разными аналитическими агентствами), либо их четкого объяснения в том же самом документе. Но лучше, конечно, не использовать такие аббревиатуры вообще.

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

ЗЫ. Надо было найти картинку для заметки и я сразу вспомнил про одну конференцию по ИБ, в которой я участвовал онлайн во время пандемии. Меня на нее пригласили достаточно заранее и я внес ее в свой календарь, но так как это было сделано впопыхах, то адрес сайта конференции я внести забыл. И вот за день до начала, пытаясь вспомнить, какую тему я назвал для своего выступления, я стал судорожно искать в Интернете сайт конференции, ориентируясь на ее название. И в первой десятке сайтов, услужливо предложенных мне Google, нашелся сайт Всероссийского научно-исследовательского геологического института, аббревиатура которого звучит как ВСЕГЕИ :-)

ЗЗЫ. Используя какие-либо названия и аббревиатуры в нормативных документах стоит помнить про закон письменной речи Майерса: "Все, что может быть понято неправильно, будет понято неправильно". К терминологии этот закон применим как никакой другой.

Подробнее…

Терминологический кризис или полный п...ец

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

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

Возьмем к примеру проект ГОСТа с терминами и определениями по ГосСОПКЕ, который внесли в ТК362 в августе этого года. Я на него писал отзыв и сейчас, спустя два месяца, думаю могу и в блоге повторить свои мысли здесь.

1. Большая часть терминов не соответствует терминам, уже данным в законодательстве, в том же ФЗ-187. Они зачем-то "адаптированы" в предлагаемом ГОСТе. Возможно, это и обосновано (хотя обоснования не приведено), но это будет вводить еще большую путаницу вместо того, чтобы терминологическую путаницу устранять. А часть терминов не "адаптирована", а просто другая. Например, термин "компьютерная атака" из ФЗ-187 вообще не соответствует проекту ГОСТа (при этом пометки "адаптировано" нет). Часть терминов не соответствует не только НПА ФСТЭК, но и НПА ФСБ.
2. Часть терминов, повторяющихся в утвержденном, но еще не принятом проекте ГОСТ по мониторингу, также не совпадают по тексту и "адаптированы". Это выглядит еще более странно, так как автор у двух проектов ГОСТов один и тот же. Но ГОСТ по мониторингу, видимо, "велся" "под эгидой" ФСТЭК, а ГОСТ по ГосСОПКЕ - "под эгидой" ФСБ. Необходимо хотя бы на уровне обоих ГОСТов принять единую терминологию.
3. Часть терминов из п.4.2.2 про источники данных не соответствует терминам из уже принятых профилей защиты ФСТЭК. Например, средство доверенной загрузки. Также по тексту используются термины, которые не используются ФСТЭК, например, "фсбшный" термин "система обнаружения атак" вместо "система обнаружения вторжений".
4. Часть терминов из п.4.2.3 не соответствуют их смыслу. Например, нормализация - это устранение избыточности, приводящей к ошибкам, а не приведение к единому формату. Корреляция - это поиск зависимостей между случайными событиями, а не просто вид анализа данных. Правило регистрации признаков атак и инцидентов не может быть алгоритмом анализа событий и т.п. При этом в п.4.4.9 для правила регистрации компьютерного инцидента уже другое определение.
5. Очень много терминов некорректны. Например, бэкдор - это не столько дефект алгоритма, сколько намеренно оставленная уязвимость ПО (про ПО в определении ни слова). А уязвимость "нулевого дня" не всегда трактуется как уязвимость до выпуска патча (есть известные годами уязвимости без патча и их никто не называть "нулевого дня"). Источником атаки (как написано в проекте методики МУ ФСТЭК) может быть не только лицо (то есть антропогенный источник) или инициируемый им процесс, но и техногенный источник. Факт получения ВПО ресурсом не может рассматриваться как распространение ВПО. Нарушение или замедление работы ресурса трактуется как неспособность ресурса выполнять возложенную функцию, но это не так. При замедлении работы ресурса он свою функцию продолжает выполнять.
6. В терминах используется то "Интернет", то "глобальные компьютерные сети". Также бывает, что подменяются понятия "признак", "критерий" и "индикатор" применительно к атаке и инциденту.
7. Очень много англицизмов и жаргонизмов, которые слишком буквально переведены на русский язык - "дампер", "плагин", "бэкдор", "руткит", "инсайдер" и т.п.

Причем, это не проблема только ФСТЭК или ФСБ. У других регуляторов схожая проблема. Например, последний, утвержденный 23 октября, стандарт Банка России СТО БР ФАПИ.СЕК-1.6-2020. Там есть такие термины, как "нативное приложение" (ну зачем эти англицизмы?", "агент пользователя" (это, на секундочку, user agent, - зачем тут буквально переводить - смысл же другой), "конечная точка" (это, как вы понимаете, "endpoint")... От этой "конечной точкой" и начинаются "конечная точка клиента" (наверное, точка G) и "конечная точка токена". А чего тогда не перевести "UserInfo endpoint" как "конечную точку информации пользователя"? Почему оставили "конечная точка UserInfo"?

В чем смысл буквального перевода английских слов на русский? Ну ладно "токен" или "инсайдер". Они уже прижились и вполне себе самодостаточно. Но "нативное приложение", "дампер", "бэкдор"?.. Это в разговорной речи они приемлемы, но не в стандарте, которым потом будут пользоваться по всей стране.

И почему нельзя при использовании терминов, посмотреть на уже принятые стандарты с разделами по терминам? Почему термин "атака"из нового СТО БР ФАПИ.СЕК-1.6-2020 отличается от определений из документов ФСБ? И это если не вспоминать упомянутую выше проблему с тем, что в проекте ГОСТа по ГосСОПКЕ этот же термин отличается и от ФЗ-187, и от уже принятых НПА ФСБ. Ну ладно... Я могу понять, когда регуляторы конфликтуют между собой и им недосуг читать документы "конкурентов" и синхронизироваться с ними. Но свои-то документы надо знать? Почему в новом СТО термин "аутентификация" отличается от этого термина в ГОСТ 57580.1? Да, понятно, что его взяли из свежего ГОСТа Р 58833-2020 по идентификации и аутентификации (а могли бы и из ГОСТ Р 53632-2009). Но почему-то не привести и ГОСТ 57580.1 к единому терминологическому аппарату (а там и не только терминологию, но и некоторые формулировки бы утрясти)? Кстати, термин "аутентификация" в ГОСТ 57580.1 взят из РД Гостехкомиссии 1992-года, который, вроде как никто и не отменял официально.

И вот таких примеров с терминологией по ИБ у нас в нормативке вагон и маленькая тележка. И что с ней делать, фиг разберешься. Регуляторы, похоже, не особо хотят создать единый глоссарий терминов и использовать его в своих документах. Даже один регулятор внутри себя этого не особо хочет. А это уже кризис. Или не кризис? Или п...ец, как говорится в прекрасном фильма "О чем говорят мужчины"?

Подробнее…