Обнаружение угроз 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-года, который, вроде как никто и не отменял официально.

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

Подробнее…

Аутсорсинг. Риски информационной безопасности (презентация и видео)

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

Видео моего выступления:

А также сама презентация:

Аутсорсинг. Управление рисками информационной безопасности from Aleksey Lukatskiy

Подробнее…

Чеклист организации, выстраивающей стратегию безопасного удаленного доступа (презентация и видео)

На прошлой неделе мне посчастливилось поучаствовать в конференции GIS Days 2020, которая проходила целиком онлайн, но по уже становящейся традиции спикеров пригласили выступать в специально оборудованный павильон. Сейчас уже немодно читать из дома или из офиса - организаторы понимают, что слушатели устали от бесконечных вебинаров и онлайн-конференции, которые похожи друг на друга как близнецы. Один из способ выделиться на фоне других - попробовать уйти от набившего оскомину формата Zoom или Webinar.ru и дать слушателям что-то иное - профессиональных ведущих, задающих нужные вопросы спикерам, красивую картинку, возможность задавать вопросы в чате и т.п.

И вот компания Газинформсервис, которая ежегодно проводит свою конференцию GIS Days, в этом году решила попробовать себя в новом формате, и перестроила под себя один из павильонов Ленфильма, в котором снимались такие шедевры отечественного кинематографа как "Особенности национальной охоты", "Гений", "Собачье сердце", "Приключения Шерлока Холмса и Доктора Ватсона", "Трое в лодке, не считая собаки", "Труффальдино из Бергамо" и многие другие.

И вот еще один эксперимент - на этот раз "сериал" про информационную безопасность. Целых 11 часов онлайн-трансляции, 42 актера спикера. Весь "сериал" был посвящен новой реальности; так называют удаленку и вызовы ИБ, которые с ней связаны. Кто-то считает, что эта тема уже набила оскомину и в ней нет ничего нового. Но мне кажется, что это не так. Первую волну пандемии многие пережили в авральном режиме и использовании триальных лицензий, предоставленных вендорами. Сегодня настало время выстраивать полноценную стратегию организации удаленного доступа, какой бы она не была, - с помощью прямого доступа к корпоративным приложениям, с помощью VDI или RDP, с помощью DaaS или иных облачных сервисов.

Вот про чеклист такой стратегии я в рамках GIS Days 2020 и рассказывал. Ниже можно посмотреть видео моего доклада. Я не знаю, откроется ли ссылка ровно на моем докладе, но если что, то смотреть с временной отметки 01:17:15. Моя сцена в этом эпическом фильме заняла всего 20 минут, но если вы хотите посмотреть и другие сюжеты и актеров, то переходите по ссылке выше и вы сможете удовлетворить свое любопытство киномана. 

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

Чеклист организации, выстраивающей стратегию безопасного удаленного доступа from Aleksey Lukatskiy

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

Подробнее…

Презентация ИБ для руководства (видео с CISO Forum)

Продолжим вчерашнюю тему про дашборды для руководства, но выйдем за рамки темы АСУ ТП. Сегодня я выложил видеозапись своего выступления (оно вдвое длиннее, чем на Kaspersky ICS Security Conference) с CISO Forum, прошедшем в этом сентябре, в рамках которого я вновь коснулся темы дашбордов, но уже в более расширенном варианте. 

Презентацию этого выступления я уже выкладывал. 

Подробнее…

Создание дашбордов по ИБ АСУ ТП, понятных руководство (видео)

В начале сентября, первым моим очным мероприятием стала конференция Лаборатории Касперского Kaspersky ICS Security Conference, где я выступил на тему дашбордов по ИБ АСУ ТП. Свою презентацию я выкладывал раньше, а сейчас подошло время и для видеозаписи.

Это мое выступление по сути продолжает прошлогоднее, в котором я рассказывал про измерение эффективности ИБ АСУ ТП. Поэтому я дам ссылку еще и на него, чтобы можно было сложить А и Б, то, что мы измеряем, и то, как мы это визуализируем. Оказалось, что я видео этого выступления в блоге не выкладывал, так что исправляюсь.

ЗЫ. Остальные видеозаписи с Kaspersky ICS Security Conference 2020 можно посмотреть в плейлисте на Youtube (постепенно туда выкладывают обработанные записи докладов).

Подробнее…

5 целей сбора персданных в рамках нового указа мэра столицы

Зарекся писать про тему прав субъектов персональных данных и законодательство про это, так как не только перестал понимать логику его авторов, но и потому что исполнительная власть давно и успешно положила болт на это законодательство и комментировать его действия сложно. Вот про техническую защиту персональных данных пишу и рассказываю - там все чуть проще и понятнее. В мае вот выступал на GDPR Day с рассказом про защитные меры по ФЗ-152 и GDPR. На днях доделал документ по мотивам этой презентации, где в сжатой форме попробовал собрать все ключевые вещи, связанные с технической защитой персональных данных. Но тут Михаил Юрьевич задался сакраментальным вопросом, а зачем мэрия собирает ПДн работников, переведенных на удаленку. И так как он рассмотрел, на мой взгляд, не все возможные причины сбора этих данных, то позволю себе продолжить его заметку и пофантазировать.

Я вижу 5 причин (целей, в терминах ФЗ-152), зачем мэрия это делает. Причина первая - самая очевидная. В мэрии работают недалекие люди, с полностью отсутствующим критическим мышлением, незнанием законодательства; этакие винтики, которые в меру своего понимания делают то, что им устно кто-то приказал, услышав такое же устное распоряжение еще от кого-то сверху и так по цепочке. Чиновники мэрии превратились в собак из опытов Селигмана (я про них писал в контексте ИБ), потеряв всю инициативу и желание сделать что-то по уму.

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

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

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

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

Вот такая конспирология... 

Интерфейс загрузки ПДн удаленщиков... Опять не работает (фото Циникса из телеги)

Подробнее…

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

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

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

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

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

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

Подробнее…

Новое Положение Банка России 719-П. Вопросов больше, чем ответов...

На днях Минюст зарегистрировал новое Положение Банка России 719-П, которое пришло на смену 382-П. У него есть несколько отличий от отменяемого с 1-го января 2022-го года 382-П:

• Расширен перечень лиц, на которых распространяется 719-П. Теперь это не только операторы по переводу денежных средств, операторы услуг платежной инфраструктуры, операторы платежных систем и банковские платежные агенты и субагенты, но и операторы услуг информационного обмена и поставщики платежных приложений, для которых прописаны требования по защите информации.
• Технические требования по защите теперь прописаны в ГОСТ 57580.1, а не в самом Положении как раньше (хотя часть требований остались в самом Положении).
• Операторов по переводу денежных средств обязали выполнять 683-П (как будто они могли отказаться?).
• Оценка соответствия проводится по ГОСТ 57580.2.
• Операторы по переводу денежных средств обязаны провести сертификацию прикладного программного обеспечения автоматизированных систем и приложений (будем считать, что это, что было в устных разъяснениях ДИБ в связи с выходом профиля защиты) по уровню доверия не ниже 5-го, а для значимых и системно значимых кредитных организаций - не ниже 4-го уровня.
• Добавили жесткие требования к банковским платежных агентам и субагентам (ГОСТ 57580.1 и много чего еще, вплоть до сертификации ПО на 6-й уровень доверия).
• Добавили необходимость вычисления значения показателя, характеризующего уровень переводов денежных средств без согласия клиента, формируемого на ежеквартальной основе
• Добавили обязанность подтверждать принадлежность клиентам e-mail, на которые отправляются выписки и подтверждения перевода денежных средств. 

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

Вообще, иногда кажется, что в ЦБ выпуская новые нормативные акты, немного забывают про то, что уже было выпущено ранее. Я тут попробовал оценить сферы применения 382-П, 683-П, 719-П и 672-П и понял, что они очень сильно перекрываются даже по формальным признакам. 

А если брать в расчет практику надзора, когда проверяющий может вытащить операционистку на ресепшн и попросить подключиться к АБС, что по мнению проверяющих означает, что и компьютер на ресепшн попадает в область действия тех же 683-П и 719-П/382-П. А были ведь еще истории, когда таким образом и 672-П/552-П распространяли на весь банк, а не только на сегмент, прямо подключенный к платежной системе Банка России. В общем я вроде и в теме немного, но даже я уже перестал понимать, что делает ЦБ в части регулирования вопросов ИБ и в части соотнесения между собой своих же нормативных актов и почему они не могут синхронизировать их требования между собой, а также четко разнести их сферы действия.

Подробнее…

Кому нужно квантовое шифрование?

За последнее время 8-й Центр ФСБ объявил госзакупок по теме квантового распределения ключей на сумму более 200 миллионов рублей. И уже достаточно активно стали появляться различные новости о том, что то одна, то другая российская компания (преимущественно из финансового сектора) вместе с каким-либо из российских разработчиков СКЗИ, запустили прототип системы квантового шифрования. Если чуть погрузиться в детали, то речь идет не совсем о шифровании, сколько о квантовом распределении ключей, но не суть. Меня во всей этой истории интересует именно практическая сторона дела. И вот с ней все не так просто.

Дело в том, что я никак не могут понять, почему все так носятся с этой концепцией, ведь она абсолютно бесполезная в 95% случаев применения современной криптографии. Дело в том, что расстояние, на котором должны быть установлены узлы, обменивающиеся ключами, составляет всего чуть более 100 км. И это при условии использования оптического волокна достаточно хорошего качества, без спаек. С репитером можно попробовать увеличить расстояние вдвое, достигнув значения около 300 км. И вот спрашивается, кому нужно решение, которое работает на столь малых расстояниях. А ведь это очень небольшое расстояние. То есть даже до Питера "не добьет", не говоря уже о каком-нибудь Владивостоке, Хабаровске, Екатеринбурге или резиденциях Президента в Сочи или Шуе. И в чем тогда смысл всех этих сотен миллионов инвестиций в НИРы, если практической значимости в этом немного? 

Почти все исследователи сходятся в мнении, что применение на практике (если не рассматривать вариант замкнутой системы в пределах одного города и его окрестностей) квантового шифрования вызывает вопросы и с точки зрения длины квантового канала, и с точки зрения скорости передачи данных (единицы мегабит в секунду). В отличие от квантовых компьютеров, которых работающих пока нет, но которые как раз могут иметь более приземленное применение в части ускорения криптоанализа большей части асимметричной криптографии, которая может превратиться в тыкву в случае появления действительно работающих квантовых компьютеров (эксперты называет срок их появления в 2027 году). Поэтому гораздо активнее многие крупные компании развивают направление так называемой постквантовой криптографии, которая будет устойчивой к атакам со стороны квантовых компьютеров. Этой же темой занимается и 8-й Центр ФСБ, который на последнем PKI Forum / CTCrypt, анонсировал направления, в котором они работают. Правда, открытых НИРов в этой области они не анонсируют, но и приведенных на слайде алгоритмов достаточно.    

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

Подробнее…

Про обязательную сертификацию для всех без исключения значимых объектов КИИ

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

Одно из них - расширение запрета на использование элементов значимого объекта КИИ не только 1-й, но уже и 2-й категорией. Прощай Zoom, облака и сервера обновлений, расположенные за пределами Российской Федерации. Ну да и ладно. Зачем значимым объектам КИИ обновление? Не нужно оно. Хотя допускаю, что регулятор не рассматривает сервера обновлений как угрозу для ОКИИ и не включает их в контур контроля. Ну тем лучше.

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

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

Можно ли получить данную методику и требования по доверию посторонним лицам? Согласно требованиям ФСТЭК, они "предназначены для организаций, осуществляющих в соответствии с законодательством Российской Федерации работы по созданию средств, заявителей на осуществление сертификации, а также для испытательных лабораторий и органов по сертификации, выполняющих работы по сертификации средств на соответствие обязательным требованиям по безопасности информации". Учитывая курс ФСТЭК на засекречивание всего и вся, боюсь, что обычный субъект КИИ, владеющий значимыми объектами КИИ, получить их не сможет. И даже если у него есть лицензия ФСТЭК на ТЗКИ или разработку СрЗИ, тоже. А откуда у районной поликлиники или транспортной компании такая лицензия? Вот и получается, что своими силами провести такую оценку будет очень проблематично. Я уже не говорю, про отсутствие у субъектов КИИ специалистов, способных провести такой анализ. Да и вообще, эти требования в принципе не способен выполнить субъект КИИ, как бы он не хотел, так как они рассчитаны либо на разработчиков средств защиты, имеющих весь пакет документации и исходных кодов на свою продукцию, либо на лиц, которым они доверили ее анализ. Субъекты КИИ, до свидания!.. 

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

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

• Значит ли, что уже сейчас нельзя устанавливать на ЗОКИИ средства защиты, прошедшие оценку соответствия в форме испытаний или приемки, но без уровней доверия? Или запрет вступает в силу именно в 2023-м году? 
• Если я сейчас внедрю (или они уже внедрены) такие средства защиты, то 2-го января 2023-го года мне надо от них отказываться или все-таки закон не имеет обратной силы?
• Если закон обратной силы не имеет, то можно ли мне после 1-го января 2023-го года обновлять средства защиты или это уже будет считаться модернизацией ЗОКИИ, а значит, как написано в приказе, надо будет уже проводить оценку по 6-му уровню доверия?
• А если сейчас идет проектирование системы и в ТЗ таких требований не было, то что делать? Будет ли отсрочка?
• Если у меня инвестпрограмма рассчитана на 3 года и в нее уже внесены средства защиты без оценки по 6-му уровню доверия, то что делать в таком случае? Бюджет уже заложен и часто это бюджет государственный.
• Закупка обновлений средств защиты без 6-го уровня доверия не будет ли рассматриваться для госкомпаний или госорганов, как нецелевое расходование средств со всеми вытекающими последствиями? 
• Как будет трактоваться отсутствие 6-го уровня доверия при проведении проверок ФСТЭК (если средство защиты было внедрено до 1-го января 2023-го года)? 

Вопросы, конечно, риторические. Авторы приказа явно не думали о них, когда готовили свой документ. Даже информационного сообщения никакого на сайте не опубликовали с разъяснениями. Видимо, не досуг.

Кстати, еще пример, как ФСТЭК подходит к своим документам. 12-го августа регулятор утвердил список документов, необходимых лицензиатам для выполнения работ по ТЗКИ, включая и тематику КИИ. В этом перечне присутствуют и 17-й, и 21-й приказы, и методичка по защитным мерам, и даже ДСПшная методика моделирования угроз ПДн 2008-го года, на смену которой скоро придет новая методика моделирования угроз ФСТЭК. Чего в этом перечне нет, так это 235-го и 239-го приказов по КИИ. То есть строить защиту субъектам КИИ лицензиат может, а вот документы, устанавливающие требования к этой защите, лицензиату иметь необязательно. В - Внимательность...

Подробнее…

Как ловить кибермафию с помощью анализа DNS (презентация)

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

Презентация выложена на Slideshare и в моем канале в Telegram.

Как ловить кибермафию с помощью DNS from Aleksey Lukatskiy

Подробнее…

Презентация по ИБ для руководства компании (презентация)

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

А пока выкладываю презентацию - на Slideshare и в канал в Telegram.   

Презентация по ИБ для руководства компании from Aleksey Lukatskiy

Подробнее…

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

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

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

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

Подробнее…

От разрозненных фидов к целостной программе Threat intelligence (презентация)

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

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

От разрозненных фидов к целостной программе Threat intelligence from Aleksey Lukatskiy

Подробнее…

Мои выступления в сентябре

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

8 сентября - "Последние тренды при организации безопасного удаленного доступа". Формат - онлайн. Организаторы - Cisco и Step Logic. Это в меньшей степени обычный вебинар, сколько лабораторная работа, перед началом которой я расскажу о 8 сценариях удаленного доступа, один из которых и будет отработан в рамках онлайн-лабы.

8 сентября - "Как DNS помогает разоблачать мафию". Формат - онлайн. Конференция - TLDCON 2020. В секции про использовании DNS для аналитических исследований я буду рассказывать про то, как с помощью DNS можно проводить расследования вредоносных инфраструктуры и выявлять, кто стоит за теми или иными киберпреступлениями.

10 сентября - "Как построить современную стратегию обнаружения угроз или почему IDS сегодня недостаточно?". Формат - онлайн. Серия вебинаров - Cisco Club. Здесь я буду рассказывать, почему за 20 лет в области обнаружения угроз изменилось все и только отношение заказчиков к IDS остается неизменным и почему это плохо.  

10 сентября - "ВЗГЛЯД CISO НА НОВЫЕ ВЫЗОВЫ И ТРЕНДЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ПОСЛЕ ПАНДЕМИИ. ТРЕНДЫ МУЗЫКИ: УКУЛЕЛЕ, БАЛАЛАЙКА ИЛИ ПИПА?" (модерирование пленарной сессии). Формат - вживую. Конференция - CISO Forum. Первое крупное очное мероприятие по ИБ после самоизоляции. У пленарки, конечно, была своя концепция и задумка, но все может поменяться. Все-таки с таким явлением, как самоизоляция, мы сталкиваемся впервые и для многих она стала неожиданностью, как и последствия для ИБ. Про это и поговорим.  

11 сентября - "АФИША ДЛЯ КОНЦЕРТА: ЭКОНОМИЧЕСКАЯ ЭФФЕКТИВНОСТЬ. ПРЕЗЕНТАЦИЯ ИБ ДЛЯ РУКОВОДСТВА". Формат - вживую. Конференция - CISO Forum. А это уже будет не модерируемая мной дискуссия, а полноценный доклад, который будет закрывать CISO Forum и в котором я попробую дать ряд практических советов о подготовке презентаций по ИБ для руководства компании. 

14 сентября - "Как выбрать правильную архитектуру удаленного доступа или что делать, если коронавирус вернется?". Формат - онлайн. Серия вебинаров - Cisco Club. Для многих весенний аврал, связанный с переходом на удаленку, закончился. Но сейчас начинается уже планомерная работа с организацией удаленного доступа не только из дома, но из любой точки с наличием Интернет. О том, как выстроить архитектуру такого доступа я буду говорить вместе с Русланом Ивановым.

17 сентября - "Старый периметр умер. Да здравствует новый периметр. Как защитить размытую картинку?". Формат - онлайн. Серия вебинаров - Cisco Club. Вроде про периметр уже сказано все, что только можно. Но мы попробуем вместе с Михаилом Кадером посмотреть на него немного с другой точки зрения. Как организовать защищенный периметр в условиях удаленной работы, BYOD, доступа к облакам и т.п.?

22 сентября - "Если бы с COVID-19 можно было бороться с помощью сегментации?..". Формат - онлайн. Конференция - Kazan Digital Week. Завершу первый месяц осени рассказом о том, как сегментация могла бы помочь справиться с коронавирусом, если бы ее идеи могли бы быть применены в реальном мире и наоборот, как сегментация может помочь корпоративным сетям, если бы их накрыл коронавирус.

Подробнее…

Дашборды по ИБ АСУ ТП (презентация)

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

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

Скоро коллеги из Лаборатории Касперского выложат видео этого доклада (кто не смог вчера его посмотреть вживую или в онлайн-трансляции), а я пока выкладываю на Slideshare саму презентацию. У кого нет доступа к Slideshare (хотя обойти блокировку РКН сегодня не представляет большого труда) и кто не готов ждать 24-го сентября, когда все презентации Slideshare будут интегрированы в сервис Scribd, могу порекомендовать зайти ко мне в канал Telegram, куда я выложил презентацию в виде pdf. 

Дашборды по ИБ АСУ ТП from Aleksey Lukatskiy

Подробнее…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее…