23.9.19

Измерение эффективности ИБ промышленных систем

На прошлой неделе мне довелось выступать на конференции Kaspersky ICS Cybersecurity Conference с докладом, посвященным оценке эффективности ИБ промышленных систем. Оказалось, что я удачно дополнил доклад выступившего передо мной Патрика Миллера из Archer про коммуникации с бизнесом. У меня же доклад был более приземленный с примерами метрик, которые могут быть использованы при оценке своей эффективности и последующей коммуникации с бизнесом.


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

Выкладываю свою презентацию:



9.9.19

Разъяснения Банка России с осенной сессии Уральского форума

На прошлой неделе прошла конференция, организатором которой стал Банк России, и которая стала выездной сессией Уральского форума, проведенной в Москве. На ней регулятор попробовал ответить на животрепещущие вопросы, касающиеся как ЕБС, так и недавно выпущенных, но уже вызвавших немало вопросов нормативных актов (683-П, 684-П и т.п.). Параллельно с этим, как член ПК1 ТК122 я собрал с отрасли около 50 вопросов, которые были направлены в Департамент ИБ Банка России с целью получения ответов на них. И вот часть таких ответов прозвучала на конференции. Позволю себе тезисно озвучить то, что было озвучено.

Единая биометрическая система
  1. Банк России опросил 38 банков, 7 из которых планируют делать свои собственные решения для подключения к ЕБС. Остальные хотят использовать типовое решение, самых распространенных сейчас четыре - от Ростелекома, Инфотекса, ЦФТ и IDSystems.
  2. Стоимость облачного решения Ростелекома - около 3 миллионов рублей в год. Стоимость типового решения - 5 миллионов (включая инфраструктуру построения, HSM, антивирусы и т.п.).
  3. Типовое решение уже включает тематические исследования и финансовым организациям проводить их не требуется.
  4. Покупка типового решения не отменяет выполнения методички Банка России МР-4.
  5. По словам ЦБ, ряд разработчиков типовых решений делают только сбор биометрии, без предоставления функции верификации, что неправильно по мнению регулятора.
  6. Стоимость собственной разработки (в качестве примера был приглашен Тинькофф) обходится примерно в те же 5 миллионов. Но это все без резервирования тех HSM. С резервированием - стоимость увеличивается еще примерно на 3-4 миллиона. Длительность создания собственного решения у Тинькофф составила 4-5 месяцев без тематических исследований.
  7. Обсуждалась тема мобильного сбора биометрии, для которой максимальный возможный класс сертификации СКЗИ озвучивался как КС2. Готовых решений пока нет, но Ростелеком работает над ним. При этом вопрос качества собранной биометрии с помощью планшета или смартфона не обсуждался совсем.
  8. Для удаленного сбора должны применяться только СКЗИ КС3 или КС2 но с соблюдением. требований к СВТ 4-го класса. Пока обойти эти требования или снизить нельзя. 

683-П / 684-П / 672-П
  1. Планируется кардинальное изменение 382-П, из которого уберут упоминание кредитных организаций (операторов по переводу денежных средств). 382-П будет распространяться на участников НПС - некредитные организации, а также на новые сущности, введенные последними правками в 161-ФЗ - платежные агрегаторы, разработчики платежных приложений, операторы информационного обмена (SWIFT, привет!). Защита информации при осуществлении переводов денежных средств уйдут целиком под 683-П, который покрывает все банковские операции. 
  2. ЦБ считает, что анализ уязвимостей можно проводить своими силами, если есть для этого возможности, навыки и квалификация. Но пока непонятно, как отсекать некачественно проведенную оценку. ЦБ думает над этим.  
  3. На вопрос о том, что является доказательством проведения анализа уязвимостей, если это делает производитель платежного ПО или привлекаемый лицензиат, ЦБ подготовит разъяснение. Надо внимательно посмотреть ГОСТ 15408 в части представления результатов оценки.
  4. В августе ЦБ разослал письмо по кредитным организациям, в котором говорится, что с учетом принятия ГОСТ 57580.1/57580.2 и 683-П, направлять оценку по СТО БР ИББС 1.2-2014 больше не требуется. Ее проведение остается на усмотрение кредитной организации. Когда кредитные организации выведут и из под 382-П, то у них останется единственная оценка соответствия - по ГОСТу. Надзор ЦБ больше не будет руководствоваться СТО БР при проведении своих мероприятий.
  5. 202-я форма будет пересмотрена.
  6. Документ по операционным рискам (с резервирование капитала и прочим блэкджеком) будет очень плотно завязан на новый ГОСТ по управлению киберрисками, который сейчас активно пишется и в октябре будет представлен членам ПК1 ТК122. Так что можно ожидать, что до конца года положение по операционным рискам будет все-таки принято.  
  7. На вопрос о том, почему 683-П и 684-П местами так отличаются друг от друга, прозвучало, что хоть они и писались ДИБом, но затем сильно перерабатывались соответствующими - департаментами банковским и НФО.
  8. Несмотря на то, что в 684-П прямо не упомянуты (при установлении уровней защиты) микрофинансовые организации, ломбарды и ряд иных, на них распространяются общие требования, прописанные в 684-П (защита от вредоносного кода, уведомление клиентов о рисках и т.п.).
  9. Если кредитная организация ведет депозитарную и репозитарную деятельность, то применять необходимо и 684-П, даже несмотря на то, что у него сфера деятельности - некредитные финансовые организации. Но, учитывая, что кредитные организации обязаны также выполнять и 683-П, то при пересечении требований выполняться должны те, которые жестче, то есть, по сути, 683-П. 
  10. По поводу SMS и Push ЦБ считает, что не обязательно применять УКЭП. Можно использовать и другие меры подтверждения целостности без УКЭП. Сейчас завершается подготовка информационного письма для этого.
  11. Было озвучено, что есть правовые проблемы с использованием облачным провайдером ЭП банка (ключи нельзя передавать третьим лицам). ЦБ вроде как нашел с ФСБ некое решение, но у них есть сомнение в его правомерности. Если в новую редакцию 63-ФЗ внесут "третью доверенную сторону", то проблема разрешится. Пока этот вопрос в серой зоне и каждая кредитная организация решает его для себя самостоятельно.
  12. ГОСТ допускает применение несертифицированных средств защиты при отсутствии их на рынке (техническая невозможность) или высокой цены (экономическая нецелесообразность). Это и так было понятно, но тут это прозвучало еще раз на прямо заданный вопрос.
  13. Вновь прозвучала мысль, которая звучит последние лет 10, что ЦБ не интересует КАК будут реализовываться защитные меры и какие конкретные технические решения будут применяться. Финансовые организации сами выбирают способ реализации. Для ЦБ важна оценка уровня риска, для чего ЦБ сейчас внедряет новый риск-ориентированный подход, который будет оценивать каждую организацию по набору показателей.

Перспективы и планы

Конференция не была ориентирована на озвучивание планов по новым нормативным актам, но на одном из слайдов были приведены направления деятельности ДИБ, из которых становится понятно, в каком направлении ждать и новых нормативных актов. Как минимум, сейчас пишется нормативка под финансовый маркетплейс, блокчейн, цифровой профиль и Open. API.

4.9.19

Почему ВУЗы не преподают теорию игр специалистам по ИБ?

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

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

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

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

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

Про игру Касперского я повторяться не буду, покажу еще парочку примеров игр по ИБ, которые основаны на теории игр (я постил их скриншоты в своем Twitter, но решил повторить и в блоге). Начну с решения Project Ares компании Circadence, которое позволяет моделировать различные ситуации и учить специалистов по ИБ реагированию на различные ситуации.


За последний год проект существенно обновился и "вырос" - появились различные варианты подписки - для ВУЗов, для корпоративных пользователей и т.п.


Есть различные сценарии проведения игр с разным числом участников и разными заданиями.


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


Есть в Project Ares и развлекательные компоненты, например, "пасьянс "Косынка" на тему ИБ:


или аналог "Своей игры":


или аналог "Змейки":


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


Но стали появляться и компьютерные игры, доступные каждому желающему. Например, на игровой платформе Steam скоро выпустят игру ThreatGEN: Red vs Blue, которая позволит множеству игроков попробовать себя в роли хакеров или защитников, не ломая реальные сети и системы, но оттачивая свои стратегические и тактические навыки, которые можно будет применять в реальной жизни (конечно, с оговорками). 

У этой игры будет несколько версий:
  • Red vs Blue. Игра для всех желающих на платформе Steam.
  • Red vs Blue Corporate. Настраиваемые сценарии игр для корпоративных тренингов.
  • Red vs Blue CTF. Соревнования команд.
  • Red vs Blue Tabletop. Игра для проведения штабных киберучений.
  • Red vs Blue Instructor Led Training.
Несмотря на громкое название заметки, я не ставил перед собой цель написать учебник или пособие по теории игр для кибербезопасника (все-таки я учил эту дисциплину в качестве факультатива, для себя лично, уже после окончания ВУЗа, и не могу сказать, что я в ней специалист). Скорее мне хотелось показать, что сегодня, в условиях непрерывно меняющихся технологий, атак, нормативки, и постоянно устаревающих знаний, подходы к обучению (в том числе и корпоративному) должны меняться. И геймификация, построенная на теории игр, является одним из инструментов решения этой задачи.

3.9.19

Deepfake: обход биометрии, непредусмотренный регуляторами

Все откладывал как-то эту тему, но тут что-то критическая масса накопилась - за вчерашний день попало на глаза несколько новостей/статей про обход биометрических систем. Об этом и будет заметка. Начну, пожалуй, с шуточного видео, за которым при этом скрыта очень большая проблема, название которой deepfake. Если первая версия одноименного приложения накладывала лица на видео очень некачественно, то китайское приложение ZAO делает это на порядок лучше. Посмотрите, как с помощью всего одной фотографии (аватарки с соцсети) смогли поменять лицо Леонардо ДиКаприо в фильмах с его участием.



Меня эта тема интересует последние пару лет, когда только появилось первое приложение DeepFake и когда Банк России стал семимильными шагами внедрять Единую Биометрическую Систему (ЕБС). Когда ЦБ выпустил свое Указание 4859-У, то я надеялся, что там такого рода угрозы найдут отражение, но все, что хоть как-то можно отнести к ним, это расплывчатая формулировка про актуальность угроз нарушения целостности (подмены) биометрических персональных данных. Настолько абстрактное понятие, что даже непонятно, о чем идет речь - о deepfake или о подмене свертки биометрического фактора?

Была надежда, что в 321-м приказе МинЦифры или в МР-4 Банка России включат раздел про нейтрализацию таких угроз, но увы. И эти документы оказались далеки от прикладных атак, концентрируясь либо на применении криптографии, либо на применении сертифицированной ОС, МСЭ и антивируса, напрочь забыв даже про защитные меры из 21-го приказа ФСТЭК по защите ИСПДн. Последний, перекрывая по своему содержанию и МР-4 и приказ №321, тоже ни слова не говорит о том, как. бороться с deepfake.

Самое неприятное, что на различных мероприятиях или в соцсетях, где присутствуют участники процесса, связанного с ЕБС, упорно обходят молчанием эту тему, даже если им задаешь напрямую вопрос о том, как бороться с этой проблемой. Хоть какой-то ответ я нашел в одной презентации "Центра речевых технологий", чьи технологии используются в ЕБС, например, у того же Банка "Открытие" и ряда других (решение VoiceKey.INSPECTOR). Правда, используются они при сборе биометрии, а проблема с deepfake возникает на этапе ее проверки в режиме повседневной эксплуатации.

Если посмотреть на классический жизненный цикл биометрической, то он в обязательном порядке должен содержать этап проверки "живости", без которого биометрия не имеет никакой ценности, несмотря на использование СКЗИ класса КВ или даже КА.


В своих материалах ЦРТ приводит методы проверки живости для изображения лица, как биометрического признака:

и для голоса, как второго биометрического признака:

Но какие из этих методов реализованы в ЕБС не совсем понятно. В описании того же "Ключа" от Ростелоекома говорится о liveness detection, но без каких-либо деталей и уточнений. А судя по презентациям отдельных банков, которые бодро отрапортовали о том, что они не только интегрировались с ЕБС, но и внедряют уже биометрию в свои банковские процессы, далеко не все понимают угрозу deepfake и борются с ней. Например, один из банков предлагает возможность перевода денег без указания номера карты или телефона, "просто сфотографировав получателя". В данной схеме даже liveness detection никакого нет - работа со статическим биометрическим признаком, который подделать ничего не стоит.

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

Если посмотреть на обратную сторону, на то, что можно противопоставить deepfake, то тут исследований не так уж и много. На последних крупных конференциях по ИБ я вспомнил только одно. А вот с готовыми решениями по этой теме, что-то не густо. Что-то встроено в сами биометрические решения, но не во все. В отличие от идентификации фальшивых изображений (OZ Forensics) или собственно самой биометрической идентификации. И тут остается полагаться на здравый смысл безопасников, которые будут следовать не только нормативных актам регуляторов, но и самостоятельно задавать вопросы производителям внедряемых решений о том, как те борятся с deepfake. Ибо цена ошибки достаточно высока, а ответственности за взлом биометрической системы регуляторы не несут; как и сами вендоры, которые продают свою решения по принципу "AS IS". Как минимум, стоит посмотреть в сторону решений по многофакторной аутентификации, которые могут частично. нивелировать проблемы, связанные с низкой защищенностью биометрии.

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

2.9.19

От. 2,5 до 5 часов за смену тратят аналитики SOC на работу с инцидентами

В августе я уже делал обзор двух отчетов, SANS и Exabeam, по центрам мониторинга ИБ (SOCам) и вот в руки попало еще один - от CriticalStart. В нем есть несколько интересных цифр о том, как аналитики SOC занимаются своей ежедневной деятельностью. Например, часто звучащий вопрос о том, сколько в среднем инцидентов ИБ в день, попадает в SOC? Я пару лет назад уже писал об этом, давая ссылки на конкретные организации, которые делились своей статистикой. В отчете CriticalStart, который стал результатом опроса около 50 различных корпоративных и аутсорсинговых SOC и MDR, приводится некая средняя цифра - 70% аналитиков расследует более 10 инцидентов в день на каждого. Достаточно большое число; особенно удивляет, что 7% аналитиков более 50 инцидентов в день отрабатывает, то есть по инциденту за 10 минут (!).


Понятно, что отчет показывает среднюю температуру по больнице, но в целом получается, что 95% инцидентов расследуется максимум за 20 минут. Если немного усреднить первые два параметра, то получается, что аналитики тратят на исследования инцидентов от 2,5 до 5 часов за смену (в прошлом году я писал про другое исследование по распределению времени у аналитиков SOC).


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


А вот дальше интересно. На вопрос, что вы делаете с большим количеством сигналов тревоги, 39% аналитиков... игнорируют некоторые категории алертов! Прекрасное решение :-) 38% отключают регистрацию большого числа событий. Также 38% (данный вопрос подразумевал множественный выбор) просто нанимает большее число аналитиков.


В прошлом году у 70% аналитиков основной целью называлось анализ и снижение числа угроз. В этом году этот показатель хоть и остался на первом месте, но снизился до 41%. А высвободившиеся 30% ушли на "тиранию алертов", то есть снижение времени на борьбу с ними (пятикратный рост по сравнению с прошлым годом) и расследование как можно большего их числа (трехкратный рост).


В эпоху мессенджеров, чатботов и средств унифицированных коммуникаций, самым популярным средством коммуникаций с клиентами/пользователями по-прежнему остается электронная почта и портал. Еще 40% аналитиков используют мобильные приложения.