Безопасность на полшишечки

За последний месяц я посетил несколько крупных мероприятий по ИБ - московский "Код ИБ. Профи", CISO Forum, питерский Код ИБ, SOC Forum в Казахстане, Cisco Connect и везде меня преследовало ощущение, что все-таки многолетняя ориентация на регуляторов сильно испортила современных безопасников, у которых сформировано неполноценное представление о том, для чего нужна кибербезопасность.

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

Шишки конопли, от которых и пошло выражение "на полшишечки", отражающее дозировку 

В управлении уязвимостями та же проблема. Производители сканеров выпускают решения для поиска уязвимостей, но потребителю нужно другое - устранение дыр. А эту тему никто производители ИБ не копают - слишком она сложна и плохо автоматизируема. Заказчики, кстати, тоже часто подменяют одну задачу другой. Устранение дыр они отдают своим айтишникам. Мол, я сканер запустил, 100500 страниц отчета со списком дыр сгенерил, а дальше пусть уже ИТ разбирается - им за это деньги платят. Опять безопасность на полшишечки.

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

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

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

Выйти же из этого тупика достаточно просто. Называется этот метод "Пять "Зачем" или "Пять "Почему" и заключается он в том, чтобы найти причинно-следственные связи в том или ином явлении. В нашем случае мы при запуске любого проекта/программы/инициативы по ИБ должны задать вопрос "Зачем?" или "Почему?" и делать так пять раз, задавая этот вопрос на предыдущий ответ. В итоге мы должны найти первопричину, то есть понять, зачем мы занимаемся ИБ? Правда, у этого метода есть и недостаток - неспособность задающих вопросы выйти за пределы своих знаний. И если они ограничены только угрозами и compliance, то к бизнесу даже "Пять "Почему" не дадут подобраться - безопасник просто не знает о задачах, стоящих перед бизнесом :-(

ЗЫ. А впереди еще несколько крупных мероприятий по ИБ - PHDays, ITSF, Offzone, ICC и думаю там тоже будет немало безопасности на полшишечки. Кстати, фраза "на полшишечки" пришла из наркоторговли - так определяли дозу марихуаны, приготавливаемой из шишек конопли. А уж потом эта фраза пошла дальше, не сильно изменившись по сути.

Подробнее…

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

Опираясь на опыт службы ИБ Cisco, имеющей SOC с 19-тилетней историей, опираясь на опыт проектирования и построения SOC у сотни заказчиков, и опираясь на опыт аутсорсинга SOC у другой сотни заказчиков, у нас накопился большой опыт в области центром мониторинга ИБ и реагирования на инциденты. И вот для выступления на SOC Forum KZ я выбрал 5 советов, недооценка которых может сделать проект по SOC неудачным. Это не единственные советы, но за 20 отведенных мне минут, больше просто не получилось. Презентацию выкладываю на Slideshare (не у всех покажется).

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

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

А 15-16 апреля я в эту тему смог погрузиться еще глубже - в Алматы и Нур-Султане у меня было от 4 до 7 часов, выделенных только под мой рассказ про SOC. По отзывам получилось неплохо. Но эта презентация была наполнена инсайдами внутренней кухни Cisco и я не планирую ее выкладывать. Однако частично рецептами этой кухни я делился на Cisco Connect в конце марта, где у меня было два доклада - про выстраивание security operations и про некоторые аспекты обеспечения ИБ внутри Cisco. Обе презентации с видеозаписями моих выступлений выложены на сайте конференции (там много выложены и остальные записи с потока по ИБ).

Подробнее…

ФСТЭК катится по наклонной

На днях широко известная в широких кругах сенатор (или сенаторша) Мизулина написала обращение в Генпрокуратуру по поводу занятий йогой в московских СИЗО. По мнению Мизулиной позы йоги вызывают "неконтролируемое сексуальное возбуждение, а это в свою очередь может привести к гомосексуализму в изоляторах"! Хорошее начало, да?! Эта новость иллюстрирует оторванность от жизни тех, кого мы выбрали или считаем, что выбрали. Тоже самое относится и к чиновникам.

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

Решить проблему отсутствия собственной экспертизы можно было бы путем приглашения внешних экспертов и раньше так оно и было. Но в последнее время круг приглашенных лиц сократился (уж не знаю почему - сверху такое распоряжение спустилось или это инициатива самого регулятора) и работают они, как правило, в лицензиатах ФСТЭК. А вот теперь представьте - вы приглашаете 10 разработчиков, ну допустим, систем обнаружения атак, которые свои продукты разработали на базе взятых Snort или Suricata, просто добавив к ним интерфейс управления и интегрировав с другими средствами защиты этого же разработчика (например, с МСЭ). Собрались эти разработчики и их спрашивают: "А вот надо ли нам требовать от IDS использования машинного обучения в дополнение к сигнатурам и обнаружению аномалий?" Ну все, как один, отвечают: "Нет, не надо" и их можно понять. Если такое требование включить, то российские вендоры должны будут у себя развивать экспертизу по ML, что непросто. Поэтому большинством голосов требование не принимается.

Или вот еще пример. Тех же разработчиков IDS (СОВ) спрашивают: "А давайте мы разрешим обновления знаний об угрозах брать не только от вас, но и вообще откуда угодно, чтобы повысить эффективность обнаружения?". Все в один голос отвечают: "Нет, не надо". И снова разработчиков можно понять. Это же надо разрабатывать интерфейсы для поддержки STIX/TAXII, OpenIOC, CyBOX и т.п. стандартов и протоколов. А потребитель сравнит частоту обновления от вендора и от бесплатных источников и начнет задавать вопросы. Зачем это нужно вендору?

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

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

Когда-то, начиная с 2013-го года, я считал, что ФСТЭК стала на путь исправления и теперь станет прогрессивным регулятором, считающимся с мнение отрасли и не только устанавливающим требования по защите, но и толкающим отрасль вперед. Но последние и неоднократные действия регулятора похоже возвращают ФСТЭК во времена СТР-К, "четверокнижия по ПДн" и др., которые "царствовали" в начале 2000-х. Жаль... Похоже скоро я напишу такую же заметку, как когда-то написал про персданные и Роскомнадзор. Вернусь к тому, для чего я изначально затевал блог, - к бизнес-ориентированным заметкам.

Подробнее…

Почему ФСТЭК блокирует использование облачных платформ Threat Intelligence?

Продолжу-ка я тему, начатую позавчера, и разверну вопрос, упомянутый вскользь, - облачная аналитика Threat Intelligence. Я упомянул, что новые сертификационные требования ФСТЭК по требованиям безопасности фактически делают невозможным оперативное получение данных об угрозах из облаков. Причина такого решения ФСТЭК мне понятна - они опасаются нанесения ущерба защищаемым объектам из таких облаков. Рисков два - утечка информации из защищаемой сети в облако и получение из него вместо обновлений вредоносного кода.

Что можно сделать в такой ситуации? Как, например, можно обновлять антивирус или систему обнаружения атак, требующие регулярного получения сигнатур? Флешка - самый простой вариант, который нередко используется сертифицированного решениями. Или создается нечто вроде прокси-шлюза, который отвечает за обновление всех средств защиты внутри защищаемого объекта, а сам он обновляется с помощью той же флешки или через однонаправленный канал. Например, именно такой вариант используют те же решения "Лаборатории Касперского", которые применяют не обычную KSN, а ее приватную версию - KPSN (Kaspersky Private Security Network). Кстати, и при сертификации "Касперского" подавалась именно KPSN, а не KSN. Схожая схема используется в тех же решениях Cisco, которые могут обмениваться данными с облачной песочницей Threat Grid, а могут с локальной, работающей даже в режиме "air-gap". EDR-решение Cisco AMP имеет как управление из публичного облака, так и из частного. Но вариант с флешкой или локальным сервером обновления (или той же "песочницей") работает только в случае, когда источник обновления всего один - от самого вендора средства защиты.

Но сегодня нельзя доверять одному вендору. И дело не в том, что он может прекратить свое существование или неоперативно обновлять свои средства защиты. Он не может "видеть" и знать все и обо всем. Например, он может хорошо разбираться в угрозах для финансовых организаций, но не иметь представления о промышленных атаках. Или он может прекрасно разбираться в атаках, присущих для европейского региона, но не "видеть" азиатских или американских операций хакеров. В любом случае потребитель хочет иметь возможность резервировать источники получения информации об угрозах. Поэтому сегодня многие современные защитные решения поддерживают функцию работы с различными TI-сервисами по стандартизованным протоколам - STIX/TAXI, OpenIOC, CyBOX и т.п. В этом случае вы можете существенно повысить эффективность купленных решений.

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

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

ЗЗЫ. Отдельный вопрос - как проверить облачную площадку на соответствие новым требованиям к доверию? Ведь такое облако является частью сертифицируемого решения и его тоже надо "подавать" на оценку соответствия. И что-то я пока не вижу, как можно новую методику ФСТЭК по поиску НДВ и уязвимостей применить к облачной платформе, неотчуждаемой от вендора (и уж тем более расположенной за пределами РФ)?

Подробнее…

Как устроена безопасность внутри Cisco: зарисовки

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

Учитывая, что про нашу внутреннюю кухню ИБ можно говорить долго (даже на базе публичной информации), а у меня был всего один час, я решил сделать некоторые зарисовки, описывающие как технические, так и организационные аспекты. Про Cisco Security Ninja я уже писал на Хабре. Про мониторинг нашей инфраструктуры тоже; как и про контроль сетевого доступа. В этот раз я погрузился в детали того, что такое Trusted Enterprise в нашей трактовке и из каких четырех столпов оно состоит, а также в то, что такое C-Bridge, решение, которое позволяет нам мониторить удаленные и недоверенные площадки, подключаемые к нашей корпоративной сети. Ну и специально, чтобы показать, что нельзя построить эффективную ИБ только из готовых, купленных на рынке компонентов, я рассказал о системе iCAM, которую мы написали самостоятельно и которая является объединением двух технологий DLP и UEBA. Про наши собственные open source разработки я также уже писал - про GOSINT, про OpenSOC, про OpenGraphiti и про кучу других.

Зарисовки о том, как устроена кибербезопасность в Cisco from Aleksey Lukatskiy

ЗЫ. Возможно скоро на сайте мероприятия выложат видео этой презентации.

Подробнее…

Авторский вечер Алексея Лукацкого "Look At Sky"

Разбавим утренний негатив и чем-нибудь позитивным :-) Спустя 15 лет работы в Cisco дожил до авторского вечера для директоров по ИБ - "Look At Sky Party". Благодаря помощи золотого партнера Cisco, компании Step Logic, вечеринка пройдет в стиле "Звездных войн". Ростовые куклы (в том числе обещана моя кукла :-), настоящий R2D2, рассекающий гостей надвое, голографический бар с реальными напитками и мной, возможно, в роли бармена, игровые автоматы, обучение фехтованию на световых мечах, бизнес-игра и всякое разное другое. Регистрация для директоров по ИБ по адресу - https://ru.surveymonkey.com/r/32S685B

ЗЫ. За регистрацию я не отвечаю. Промо-кодов и контрамарок нет :-)

Подробнее…

Новые требования ФСТЭК по сертификации еще больше сужают рынок средств защиты

Вчера на сайте ФСТЭК было опубликовано информационное сообщение об утверждении требований по безопасности информации, устанавливающие уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий. Данный документ вступает в силу с 1-го июня 2019 года и приходит на смену РД на  НДВ, который по сути прекращает свое действие. Новые требования по доверию, о которых ФСТЭК говорила уже давно, являются обязательными для всех разработчиков средств защиты и заявителей на сертификацию ФСТЭК. Уже становится традицией, что этот документ, а также идущая с ним в паре методика выявления уязвимостей и недекларированных возможностей, носят пометку "для служебного пользования" и широкому кругу лиц недоступны.

Меня в этом информационном сообщении заинтересовал только один пункт, а именно следующий: "Разработчикам и производителям сертифицированных средств защиты информации рекомендуется с привлечением испытательных лабораторий провести оценку соответствия средств защиты информации Требованиям к уровням доверия и представить результаты в ФСТЭК России для переоформления соответствующих сертификатов соответствия. Действие сертификатов соответствия средств защиты информации, в отношении которых указанная оценка соответствия не будет проведена до 1 января 2020 г. на основании пункта 83 Положения о сертификации средств защиты информации, утвержденного приказом ФСТЭК России от 3 апреля 2018 г. N 55, может быть приостановлено" (выделение мое).

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

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

ЗЫ. Но есть и хорошие новости. Но после обеда :-)

Подробнее…

"Код ИБ. Профи": послевкусие

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

Я не буду рассказывать о докладах; тем более, что скоро на сайте https://academy.codeib.ru/  скоро будут выложены и презентации и видеозаписи. Но я хотел бы сказать спасибо коллегам, которые согласились поделиться своим опытом с участниками "Код ИБ. Профи":

• Мона Архипова
• Илья Борисов
• Денис Горчаков
• Антон Карпов
• Александр Леонов
• Дмитрий Мананников
• Лев Палей
• Алексей Плешков
• Рустем Хайретдинов.

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

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

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

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

В целом хочу еще раз сказать спасибо и коллегам-докладчикам, и организаторам в лице компании "Экспо-Линк" и ее руководителю - Ольге Поздняк, и участникам. Думаю, что сейчас, по окончании четвертого мероприятия удалось нащупать баланс в темах, докладчиках, форматах. Близится летний "Код ИБ. Профи", который пройдет в Сочи 25-28 июля и регистрация на который уже открыта. Получено предварительное согласие от ряда спикеров, который вновь поделятся своим опытом (и никаких повторов). Уже есть идеи по новым киберучениям. Ольга Поздняк готовит новую культурную программу, благо горы (а "Код ИБ. Профи" пройдет в "Горки-Город" на Красной Поляне) позволяют замутить много разных вариантов. И такой немаловажный момент - в отличие от московского мероприятия, где спикерам было сложно оторваться от семей и работы и участвовать во всех активностях все дни, в Сочи все будет иначе - деться будет некуда и все открыты будут для общения. Кто был в прошлом году в горах на "Код ИБ. Профи", тот помнит вечерние посиделки в барах и кафе и разговоры до ночи. Присоединяйтесь! 

Подробнее…

ФСТЭК переводит реестр сертифицированных средств защиты на блокчейн

На прошедшей 13-го марта "Нашей игре", посвященной сетевой безопасности, среди прочих я задал следующий вопрос:

Ответом на него был "Google Dorks", то есть набор приемов, который позволяет с помощью специальных операторов Google находить всякие разные штуки, включая уязвимости, пароли, а также конфиденциальные документы, а также файлы, которые сложно найти через систему индексации сайта. Я иногда "прохаживаюсь" по сайтам наших регуляторов и иногда улов бывает очень интересным. Например, как сегодня. На сайте ФСТЭК я наткнулся на презентацию, подготовленную консультантом управления ФСТЭК, в которой говорится о планах перевода реестра сертифицированных средств защиты информации на технологию блокчейн.

Я уже писал о том, каким мог бы быть реестр сертификатов ФСТЭК и на прошедшей в феврале конференции регулятора Виталий Сергеевич Лютиков сказал, что они внимательно изучили мой "сон" и что-то возьмут на реализацию, а что-то сделают уже в самое ближайшее время. И что-то они действительно сделали.

Но я не думал, что будет сделан такой рывок вперед. ФСТЭК решила перевести свой реестр на блокчейн, который в презентации назван "цепной записью". Кстати, именно этот термин используется ФСБ и ТК26, которые даже первый документ на эту тему выпустили.

На конференции РусКрипто я выступал как раз на тему блокчейна и приводил условия, при которых блокчейн не имеет смысла. Например, когда речь идет о централизации, которую пытаются подменить блокчейном. Но в случае с реестром ФСТЭК централизации как раз и нет.

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

В блоке цепной записи ФСТЭК планирует хранить всю сопутствующую средству защиты информацию:

в том числе и контрольные суммы на средство защиты информации:

И судя по составу информации, она может меняться достаточно часто - ФСТЭК приводит несколько таких ситуаций.

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

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

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

Будем ждать новый идей и реализаций от основного регулятора в области информационной безопасности.

Подробнее…

Третий выпуск "Нашей игры" уже в эфире

BIS-TV выложило третий выпуск "Нашей игры", посвященной сетевой безопасности. Когда я готовил вопросы к этому игре, я немного поменял подход, добавив идеи из ЕГЭ и "Как стать миллионером" с набором готовых вариантов, из которых надо выбрать было правильный. Вроде как удалось нащупать баланс между различными типами вопросов и способами их подачи. Но к финалу планирую сделать несколько сюрпризов для участников, чтобы они смогли в полной мере прочувствовать всю феерию чувств от необычных вопросов, связанных с их профессиональной деятельностью :-)

Чтобы я хотел выделить особо. Когда вы будете смотреть выпуск, я настойчиво рекомендую вам лайкнуть его (если, конечно, он вам понравился). Дело в том, что от количества лайков может зависеть результат игры. Один из вопросов случайным образом становится вопросом-сюрпризом и сумма баллов, начисляемых за него, равна числу лайков, умноженных на определенное значение (вроде 50). При большом числе лайков эта сумма может быть значительной и при успешном ответе на вопрос позволит оторваться от конкурентов. Во время третьей игры у нас, как мне показалось, произошел перелом именно в момент озвучивания вопроса-сюрприза - команда, успешно ответившая на него, смогла сразу выбиться в лидеры, получив 1500 баллов. Другие команды как-то сникли после этого вопроса (как мне показалось). Так что у вас есть возможность добавить перчику в 4-ю игру, лайкнув третий выпуск очень много раз.

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

Подробнее…

Криптографический Кракен продолжает опутывать щупальцами бизнес и граждан

Чуть менее трех лет назад я написал заметку про криптографического Кракена, в которой выделил 10 "щупалец", которые захватили определенные направления российской экономики и требуют применения сертифицированной криптографии по требованиям ФСБ. За это время произошло еще ряд важных изменений, которые я решил подсветить в небольшой заметке. А навело меня на мысль написать ее вчерашняя дискуссия в Фейсбуке, где зашла речь о планируемой концепции 5G, которая сейчас разрабатывается и обсуждается в узких кругах.

В заметке написано, что сейчас предлагаются следующие планы по сертификации сетевого оборудования по требованиям ФСБ к средствам криптографической защиты информации (СКЗИ):

• Оборудование центра изготовления ключей - КА
• Отечественные USIM-карты - КСЗ
• Оборудование для изготовления отечественных USIM- карт - КА
• Оборудование для программирования и ввода ключевой информации в отечественные USIM-карты и их персонализации - КА
• Средство криптографической защиты аутентификации абонента - КА
• Средство защиты центра коммутации - КА
• Средство защиты для базовых станций - КСЗ
• Средство защиты для транзитного оборудования - КСЗ
• Средство защиты шлюзового оборудования - КА
• Абонентские устройства - КСЗ

Зачем превращать абонентские устройства в КС3 я не понимаю (это все-таки выбор абонента должен быть, а не регулятора). Еще меньше я понимаю, зачем для внутренней инфраструктуры оператора 5G требовать КА? Я не знаю, можно ли вообще выполнить в современных сетях требования к КА, но если да, то оператор, который сможет/захочет это делать, будет только один и тарифы он для покрытия своих расходов выставит просто конские.

Но это не единственное новое щупальце криптографического Кракена. Вспомним последнюю редакцию 382-П с требованием перейти всем платежным системам на российскую сертифицированную криптографию. И заодно Единую биометрическую систему (ЕБС). В прошлом ЦБ был оплотом криптографического либерализма и он не давал в обиду перед ФСБ банки. Но теперь ситуация иная :-( Это, кстати, не все. На Магнитогорском форуме зампред ЦБ, госпожа Скоробогатова, рассказывала о цифровом профиле гражданина (законопроект был недавно предоставлен для обсуждения ведомствам) и на своем слайде упомянула, что минимальный класс СКЗИ для работы с цифровым профилем будет КС3.

Нерадужная картина получается, если честно. Если сюда еще приплюсовать пакет Яровой, требующий предоставления ключей шифрования организаторов распространения информации, и ряд мероприятий из "Цифровой экономики", то скоро криптографический Кракен окончательно опутает своими щупальцами российский бизнес и граждан. И все мы скоро будем под колпаком защитой!

Подробнее…

О сертификации блокчейна по требованиям безопасности

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

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

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

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

Подробнее…

Применение блокчейна в кибербезопасности (презентация)

Сегодня выступал на РусКрипто с темой "Применение блокчейна в проектах по кибербезопасности. Реализованные проекты". Презентация ниже. Парадоксально, но если не брать тему digital identity, то "чистых" ИБшных проектов с блокчейном почти нет. Там, где он вроде бы мог неплохо применяться, - Threat Intelligence, управление инцидентами, управление уязвимостями, управление патчами, его вообще нет. А там где он применяется, пока сложно говорить о том, что он прижился. Каких-то прорывов не наблюдается и, допускаю, возможно было обойтись и традиционным подходом к решению стоящих задач. Но это именно про блокчейн в кибербезопасности. Про остальные сферы применения блокчейна я не буду столь категоричен, хотя червяк сомнения меня грызет, что пока это не более чем хайп, чем что-то реально полезное (разумеется, кроме тех, кто срывает различные раунды инвестиций, получая миллионы и десятки миллионов долларов на проектах, в названии которых есть слово "блокчейн").

Применение блокчейна в кибербезопасности from Aleksey Lukatskiy

Подробнее…

Майндкарта по 239-му приказу

Решил я тут освежить свои знания по 239-му приказу. Все-таки с категорированием мучаться все скоро закончат и наступит реальная работа по защите своих значимых объектов (ну если они, конечно, будут найдены у субъектов КИИ, которые не захотят загонять себя в прокрустово ложе жестких требований регулятора). Ну а какой самый лучший способ вспомнить и разобраться в хитросплетениях отечественной нормативки? Правильно. Сделать майндкарту. И вот я взял и сделал ее.

PDF с ней выложил в облако - качайте. В карте уже учтены последние правки, выложенные ФСТЭК на прошлой неделе для общественного обсуждения. Если и не примут что-то, то я потом быстро внесу изменения.

Пара замечаний по всему приказу. Обратил внимание, что местами нарушена методологическая составляющая (спустя полтора года обнаружил и только после составления майндкарты). Например, информирование и обучение персонала одновременно включается и в этап обеспечения безопасности в ходе эксплуатации значимого объекта и в список организационных и технических мер. Тоже самое относится и к реагированию на инциденты, и к обеспечению действий в нештатных ситуаций. Например, согласно перечню мер из приложения анализ возникших нештатных ситуаций (ДНС.5) не включен в базовый набор мер ни для одного уровня значимости, а в разделе 13.6 он включен для всех значимых объектов без исключения. Тут либо из перечня мер надо это исключать, либо из раздела 13 приказа. И я не знаю, что лучше. Логичнее вроде бы из перечня приказа, так как эти мероприятия логичны и их закономерно распространять на все ЗОКИИ, но с другой стороны, это нарушить преемственность с другими приказами ФСТЭК, например, с 31-м.

Пункты 15-18 я бы вообще вынес в самое начало приказа, в основные положения. А то получается, что о целях и задачах защиты ЗОКИИ мы узнаем только ближе к концу документа. Мелочь, а при составлении майндкарты за это глаз цепляется (я в итоге это и перенес в общие положения в майндкарте).

ЗЫ. А вообще классно было бы, если бы регулятор сопровождал свою нормативку майндкартами :-)

ЗЗЫ. Та же карта, но через Slideshare.

Майндкарта по 239-му приказу ФСТЭК from Aleksey Lukatskiy

Подробнее…

Киберучения, VR-экскурсия, ИБ-баня и куча эксклюзивных мастер-классов!

Пора-пора... Все оттягивал момент, когда надо сесть за формулирование своих мыслей по поводу грядущего "Кода ИБ. Профи", который пройдет в Москве и который мне посчастливилось вновь курировать. Тут стоило бы вновь спеть песню про Security Dream Team и вот это вот всё, но я подумал, что повторяться смысла нет, а подыскивать новые эпитеты для классной команды спикеров, которые в этом году разведут тучи на серой ИБшной Москвой, я не буду. Просто перечислю тех, кто согласился выступить в этом году и поделиться собственным опытом в непростом деле управления ИБ:

• Архипова Мона
• Борисов Илья
• Горчаков Денис
• Карпов Антон
• Леонов Александр
• Мананников Дмитрий
• Палей Лев
• Плешков Алексей
• Хайретдинов Рустем
• и я :-)

В программе одни насущные темы - управление уязвимостями, психология управления ИБ, работа с Darknet, осведомленность пользователей, бизнес-процессы, машинное обучение, измерение ИБ в контексте бизнеса, гибкое управление проектами и программами ИБ и др. На мой взгляд темы нечасто звучащие на отечественных мероприятиях по ИБ и глубоко рассматриваемые со всех сторон специалистами-практиками. В этот раз я, хотя это получилось и неосознанно, но учел иногда звучащую критику о том, что спикеры, конечно, классные, но что-то много среди них вендоров :-) Вендор - это не приговор, на мой взгляд, но глас народа услышан - в этот раз стан "вендоров" представляю только я и Рустем; остальные участники - работают на другой стороне баррикад и будут делаться наболевшим и способами его лечения.

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

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

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

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

Ну что еще можно добавить? Организатором конференции "Код ИБ. Профи" выступила уже немолодая, но по-прежнему энергичная компания Экспо-Линк, которая подготовила для участников много всяких вкусностей и интересных заманух. Уже по традиции (а "Код ИБ. Профи" проводится уже в 4-й раз) после конференционных двух дней будет двухдневная интересная культурная программа - тут и VR-экскурсия по "Москве, которой не было", и экскурсия на пивоваренный завод (конечно, с дегустацией) и даже, я на сайте увидел, предлагается некое иммерсивное шоу (кто его знает, что это такое) и ИБ-сауна (март в Москве - это вам не в Сочи, будет промозгло, и сауна - хороший способ погреться и расслабить мозг после двухдневного интеллектуального интенсива).

ЗЫ. Каким безопасником вам хочется быть? Тем, который показан наверху справа, или тем, который показан справа, но внизу :-) Выбор за вами. 

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

Подробнее…

Какое главное слово в словосочетании "Threat Intelligence"?

Какое главное слово в словосочетании "Threat Intelligence"? Большинство считает, что threat, угроза. На одном из мероприятий я как-то, не претендуя на социологическую правильность, провел блиц-опрос на тему, что для вас значит Threat Intelligence. 68% участников опроса сказали, что это фиды. Еще 17% сказало, что это информация об угрозах. Оставшиеся 15% затруднились с ответом. Так какое же главное слово в Threat Intelligence? Увы. Не Threat, и даже не Intelligence. Главное - принятие решений.

Именно это - ключевая ошибка большинства проектов по TI, которые реализуются многими компаниями. Cisco достаточно давно занимается аудитом SOCов и одним из популярных слабых мест в них является именно процесс Threat Intelligence, который воспринимается как сбор фидов различных типов и интеграция их в имеющиеся платформы Threat Hunting, SIEM, Incident Response и др. Поэтому частый вопрос во время аудита, который ты слышишь: "А какие источники фидов вы можете посоветовать для нашего TI?" Задаешь встречный вопрос: "А какие решения вы принимаете на основе желаемого TI?", а в ответ тишина и непонимание. Иногда на тебя смотрят как на ребенка, которому надо объяснять вроде бы очевидные вещи. 

Кстати, по поводу фидов и их источников. На Уральском форуме в презентации Владимира Бенгина из Positive Technologies были интересные цифры (я переделал его слайд), в котором он сравнивал C&C-фиды двух российских поставщиков за один и тот же интервал времени. Интересный результат - пересечение на уровне долей процента и это для одного региона и одного типа фидов. Как тут можно что-то советовать, не зная, исходной задачи, а самое главное, предназначения TI?

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

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

А такой показатель, как количество получаемых извне IoC применявшихся в компании? Может оказаться вообще, что индикаторы компрометации вы получаете, но не используете, потому что руки не доходят или не знаете, как автоматизировать процесс интеграции внешних источников с вашими средствами защиты/анализа. Первое говорит о том, что команда TI не очень эффективна, а второе - что возможно имеющиеся средства просто не могут работать с внешними IoCами - такое тоже бывает. О качестве текущих средств защиты и, как следствие, необходимости их обновления или замещения говорит нам и динамика снижения числа ложных срабатываний средств защиты после обогащения сигналов тревоги данными от службы TI, а также соотношение количества обнаруженных угроз средствами защиты организации с данными от службы TI и без них (например, голый IDS в сравнении с IDS + TI или IDS + TI + SIEM). Вот такое применение TI мы в рамках аудита SOCов видим очень и очень редко.

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

Подробнее…

Датасеты по ИБ для машинного обучения

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

• Набор PCAP-файлов с записанным сетевым трафиком от Netresec
• KDD Cup 1999. Это классический набор для проведения тестов IDS (уже размеченный). Да, ему уже 20 лет. Да, его часто используют разработчики вновь создаваемых систем обнаружения атак. И да, часто не достигается значения 100%, что крайне удивительно. 
• 5 датасетов от Stratosphere Lab - для вредоносного ПО, включая самые последние семплы, для нормального трафика, для смешанного трафика (зараженного и вычищенного), для Интернета вещей, а также специальный датасет, основанные на данных из реальной инфраструктуры.
• Еще один датасет NSL KDD для систем обнаружения атак.
• Датасеты от Лаборатории Линкольна MIT, также предназначенный для систем обнаружения атак. Датасеты подготовлены DARPA и описывают несколько сценариев атак. На сайте Лаборатории Линкольна есть несколько версий датасетов - от 1998-го, 99-го и 2000-го годов.
• Лаборатория Лос-Аламоса (занимается ядерным оружием США) также имеет ряд датасетов, гораздо свежее, чем у Лаборатории Линкольна. Один содержит девятимесячные данные по почти 3/4 миллиардам аутентификационных событий. Второй описывает двухмесячные данные (DNS, аутентификация, Netflow и т.п.) из внутренней сети Лос-Аламоса. Третий датасет описывает три месяца работы корпоративной сети Лос-Аламоса с точки зрения хостовых событий и Netflow.
• Датасет АНБ. Да-да, того самого агентства национальной безопасности. Тут и логи Snort, и DNS, и логи Web-серверов.
• Четырехмесячный датасет с 2,5 миллионами вредоносных URL. А тут еще один.
• Датасет ADFA (австралийская академия сил обороны) для проверки хостовых систем обнаружения атак, работающих под Linux и Windows.
• Коллекция Web-атак.
• Тройка датасетов с примерами вредоносного кода - тут, тут и тут (этот с малварью для Андроида).
• Датасеты для спама и фишинга.
• Ember - датасет из 1.1 миллиона вредоносных семплов (PE-файлов), которые "прошли" через VirusTotal в 2017-м году.
• Датасет с DGA-доменами.
• Датасет по даркнету в периоде с 2013 по 2015 годы.
• Топ 1000000 популярных доменов по версии Alexa и Cisco Umbrella.

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

Подробнее…

Уральский форум за 15 минут (видео)

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

ЗЫ. Презентации форума должны быть выложены со дня на день на сайте.

ЗЗЫ. "Уральский форум за 15 минут" - это уже бренд и мы его не меняем. Само выступление заняло вдвое больше времени.

Подробнее…

Уральский форум за 15 минут (презентация)

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

Уральский форум по банковской ИБ за 15 минут from Aleksey Lukatskiy

Все презентации с форума будут выложен на его сайте.

ЗЫ. С моим докладом про машинное обучение в ИБ занял второе почетной место среди всех спикеров форума. Мне ура! Всем спасибо!  

Подробнее…

Искусственный интеллект в ИБ (презентация)

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

Машинное обучение в кибербезопасности from Aleksey Lukatskiy

Подробнее…