Обзор 281-го приказа ФСБ по порядку установки средств ГосСОПКИ

Еще один появившийся на прошлой неделе приказ ФСБ касается правил установки и эксплуатации средств ГосСОПКИ. Эти правила достаточно просты:

• Установка средств ГосСОПКИ согласуется с ФСБ. Ну вроде все понятно, за исключением одного момента. Какое именно подразделение ФСБ согласует установку? Например, в 282-м приказе четко написано, что информировать об инцидентах надо не просто ФСБ, а именно НКЦКИ. По тексту же говорится, что после приемки в эксплуатацию средств ГосСОПКИ необходимо информировать НКЦКИ. Если бы НКЦКИ согласовывал установку, то его не надо было информировать о приемке в эксплуатацию.
• Чтобы согласовать установку с ФСБ вы должна знать, что вы будете устанавливать, где, кто их будет эксплуатировать и какие объекты КИИ будут контролироваться средствами ГосСОПКИ. Любое изменение указанной информации (кроме ФИО администраторов и операторов) требует согласования с ФСБ, на что дается также 45 дней (при изменении админов и операторов надо всего лишь информировать ФСБ об этом).
• За 45 дней ФСБ согласует установку или отказывает в ней (почему-то фраза "мотивированный отказ" в документе отсутствует).
• Субъект КИИ, являющийся финансовой организацией, должен уведомить Банк России (какое подразделение) о том, что ФСБ согласовала установку средств ГосСОПКИ. В случае изменений в согласованных ФСБ условиях, о них также должен быть уведомлен Банк России. В документах ЦБ таких требований нет.

Однако гораздо более интересен вопрос о том, что же такое средства ГосСОПКИ? Например, согласно 196-му приказу об утверждении требований к средствам ГосСОПКИ под это понятие попадают и SIEMы, и сканеры безопасности, и системы обнаружения вторжений, и SOAR/IRP и т.п. Значит ли это, что на установку всех этих решений надо получать согласие ФСБ, без которого их установка будет признана незаконной и за это можно будет "присесть" на срок до десяти лет лишения свободы? В пятницу в одном из чатиков была длинная дискуссия на эту тему, по результатам которой, мы так и не пришли к единому пониманию ибо практика общения с регулятором не бьется с его же требованиями. И вот почему.

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

Отсюда вытекает простой вывод "силы и средства ГосСОПКИ" и "средства защиты и подразделения по ИБ субъекта КИИ", хоть и схожи по смыслу, но являются разными сущностями. При наличии у вас значимых объектов вы обязаны выполнять требования ФСТЭК, описанные в 235-м и 239-м приказах регулятора. Вы должны регистрировать события (SIEM), искать и устранять уязвимости (сканеры), обнаруживать вторжения (СОВ/СОА), управлять инцидентами (IRP/SOAR) и т.п. И это все вы делаете по требованиям ФСТЭК, которая хоть и установила требования к средствам защиты, но достаточно свободные и исполнимые.

А когда же тогда надо устанавливать средства ГосСОПКИ? Согласно закону субъект КИИ это делает по своему желанию (в отличие от ряда госорганов, которые это делают по требованию), если таковое у него возникнет. Я не знаю, в каких случаях такое желание может возникнуть, так как требования ФСБ по этим средствам (196-й и 281-й приказы) загоняют в достаточно жесткие рамки ограничений, которые не так просто и выполнить.

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

Вроде бы на этом, можно было бы и завершить этот обзор 281-го приказа и экскурс в ГосСОПКУ, но в уже упомянутом выше чатике, в процессе дискуссии была озвучена очень интересная мысль о том, что НКЦКИ сегодня согласовывает центрам подключения к ГосСОПКЕ даже если их инструментарий не соответствует требованиям 196-го приказа и, например, может быть модернизирован только только иностранными организациями и имеет гарантийную поддержку от иностранных организаций (а это запрещено 196-м приказом). Я не то, чтобы против такого подхода, даже за. Просто такое вольное прочтение своих же приказов опять приводит к неоднозначностям, что не есть хорошо.

Обзор 282-го приказа ФСБ по порядку информирования ФСБ об инцидентах

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

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

О каких инцидентах надо сообщать в НКЦКИ? В приказе написано, что обо всех, а в различных презентациях сотрудников ФСБ говорится о конкретном списке из 10 категорий и 20 типов инцидентов. Но отсутствие утвержденного перечня приводит к некоторой сумятице в головах. Многие SOC ориентированы не на обнаружение всего, а на вполне конкретные use case, которые могут отличаться от списка ФСБ. Например, мало кто фиксирует публикацию запрещенной законодательством РФ информации (тем более, что это понятие настолько широкое, что приводит к различным ляпам и недоразумениям). А во-вторых, в контексте готовящихся правок в КоАП по части установления штрафов за нарушение порядка уведомления НКЦКИ также возникает вопрос, а что если я не сообщу о чем-то, что для меня мелочь, а ФСБ посчитает важным инцидентом?

Информирование НКЦИ осуществляется в соответствии с утвержденными НКЦКИ форматами представления информации. Утверждены ли эти форматы? Где они опубликованы? Ответов на эти вопросы у меня нет.

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

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

Дальше больше. 7-й пункт порядка говорит о том, что при необходимости в план включаются условия привлечения ФСБ к реагированию на инциденты. Если такие условия попали в план, то он должен быть разработан совместно с НКЦКИ, который в течение 30 дней согласовывает план или возвращает для доработки, после чего план уже согласовывается с ФСБ (с кем конкретно непонятно). Если субъект является финансовой организацией, то план должен также содержать положения о привлечении Банка России к реагированию на инциденты. Это, конечно, странные требования. Во-первых, в нормативных актах ЦБ нигде не говорится о привлечении их к реагированию на инциденты и процедура такого привлечение нигде не описана. А во-вторых, кто определяет необходимость привлечения ФСБ? Если сам субъект (а пока получается именно так), то, думаю, в здравом уме никто не захочет связывать себя такими ограничениями. А если не сам? А если к вам придут и скажут, что вы настолько значимы для страны, что вам необходимо?

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

К сожалению, название приказа не отражает его содержания :-( Никакого порядка информирования или реагирования в нем нет. Есть общие слова и все. Зато есть обязанность информировать НКЦКИ, в том числе и результатах реагирования на каждый инцидент на значимом объекте КИИ. Это тоже одна из тенденций российской регуляторики. Например, ФинЦЕРТ в декабрьском 4926-У также требует не только уведомлять о мошеннических операциях, но и о действиях, предпринятых для устранения причин и последствий атак. Если субъект КИИ является финансовой организацией, то он о мерах по реагированию должен уведомлять еще и ФинЦЕРТ (хотя последний этого и не требует по своим нормативам и не установил такую процедуру).

Модель зрелости SOC от Gartner

На днях попал мне в руки проект по SOC, который делался для одной из российских компаний. И напомнил он мне слайд, который был опубликован в Твиттере одним из участников недавно прошедшего в США Gartner Security & Risk Management Summit. Я не буду приводить не очень качественную фотографию - покажу таблицу, которую я сделал на основе этой фотографии, переведя ее на русский язык. Это упрощенная модель зрелости центров мониторинга безопасности по версии Gartner. Я знаю как многие мои коллеги относятся к Gartner, но в данном случае это и не так важно.

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

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

• мониторинг логов с помощью SIEM
• мониторинг сетевого трафика с помощью NTA
• мониторинг хостов с помощью EDR.

Но многие SOCи упорно строятся только на базе SIEM, упуская из виду события, происходящие на уровне сети или на уровне оконечных устройств. Без этих двух компонентов многие события ИБ остаются незамеченными и злоумышленники месяцами орудуют внутри "защищенной" инфраструктуры не будучи обнаруженными. К ним еще нередко добавляют UEBA для расширенной аналитики поведения пользователей (если use case по скомпрометированным сотрудникам или хакерам, маскирующимся под сотрудников, является актуальными для вас) и CASB для мониторинга облачных платформ. Я могу понять, когда SOC строился на базе только SIEM несколько лет назад. Но сейчас, когда и ландшафт угроз поменялся, и технологии новые появились? Почему сразу не закладывать в проект по SOC мониторинг сети и хостов? Или почему не включить их в план развития SOC на 1, 3, 5 лет (кстати, с ним тоже проблемы - такие планы мало кто готовит, почему-то считая, что создание SOC - это одномоментное событие, которое срабатывает "по щелчку").

В дополнение к средствами мониторинга и аналитики есть есть еще две обязательных платформы, которые должны обязательно быть предусмотрены в современном SOC, - решение по оркестрации (SOAR) и threat intelligence. В итоге получается, что в SOCе, который можно назвать современным (или SOC-NG, или SOC 2.0), должны быть реализованы следующие платформы:

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

Вы готовы к аутсорсинговому SOCу?

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

1. Определитесь сначала, что для вас SOC и какие сервисы вы от него ждете? Готов ли аутсорсер вам их предоставить? Это один из моих любимых вопросов, который возникает даже в случае проектирования SOC, а не только при его аутсорсинге. Дело в том, что у всех совершенно разное представление о том, что входит в это понятие и какие сервисы должны предоставляться SOCом. Не определившись на берегу с тем, что вы готовы отдать сейчас и в перспективе, дальше работать будет сложно и затратно. Например, если вам аутсорсер предлагает мониторинг ваших средств защиты, но не имеет в своем портфолио услуги по реагированию и расследованию, то как вы закроете эти свои потребности? Приглашать еще одного аутсорсера (а то и двух)? 
2. У вас есть четкое понимание термина "инцидент"? Когда ФинЦЕРТ или НКЦКИ требуют присылать данные по каждому спам-сообщению или по каждой уязвимости, это говорит, что они сами не применяли свои же требования к себе. И то, что можно оперативно отработать, когда вы проектируете SOC для себя, не так просто поменять в рамках договорных условий. Если вы неправильно определили понятие инцидента, то вам будут слать или слишком много событий и вы утонете в них, или слишком мало и вы начнете что-то пропускать.
3. Аутсорсинг подразумевает, что между вами и вашим аутсорсером находится пропасть Интернет. А он надежен? У вас нормальные каналы (с резервированием?) до всех ваших площадок, которые вы отдаете на аутсорсинг? А у аутсорсера они нормальные (особенно если он с целью экономии открыл свои центры не в Москве)? 
4. Вы готовы отдать аутсорсинговому SOC мониторинг внутренней инфраструктуры? С периметром все более или менее понятно - это делают многие. А вот как мониторить Netflow в вашей инфраструктуре? А EDR (если он есть) на хостах? А UEBA тоже отдается во внешний SOC? Если вы разделяете мониторинг периметровый и внутренний, то вам придется строить два SOCа, а это непростая задача. Не только в части ресурсов, но и в части интеграции данных из разных SOCов. Кстати, ваш аутсорсер имеет опыт мониторинга внутренней инфраструктуры или все его проекты - это мониторинг МСЭ и СОВ?
5. А кто будет реагировать на обнаруженные инциденты? Большое заблуждение считать, что отдав на аутсорсинг мониторинг ИБ, вы можете теперь спать спокойно и снять с себя головную боль, связанную с ИБ. Она у вас только начинается, так как надо будет более четко прописать все процедуры взаимодействия между вами и аутсорсером, разделить зоны ответственности, договориться со своей службой ИТ и т.п. Это один из самых непростых вопросов в аутсорсинге SOC.
6. Как выстроена система управления заявками у аутсорсера? Процесс общения с внешним поставщиком услуг является достаточно формальным, что требует хорошо регламентированной и автоматизированной процедуры, которая позволит оперативно решать многие вопросы. Например, согласование изменений в настройках СОВ и МСЭ или установка патча для обнаруженной уязвимости. Если за реагирование отвечаете именно вы, а не аутсорсер, то этот вопрос очень важен.
7. Какой SLA будет прописан в договоре? 15 минут на реагирование на инциденты хорошо звучат в маркетинговых презентациях, а под какими цифрами в подписываемом договоре готов подписаться аутсорсер? И это 15 минут на реагирование или все-таки для обнаружения, локализации и закрытия инцидента будут разные SLA? А SLA одинаков для всех инцидентов или для инцидентов разного приоритета и соглашение о качестве сервиса будет разным?
8. С какими use case чаще всего имел дело аутсорсер? Они пересекаются с вами? Не верьте, когда вам говорят, что SIEM/SOC может обнаруживать абсолютно все. Это некоторое лукавство. Есть наборы предопределенных сценариев, которые заложены в SIEM/UEBA/NTA аутсорсера, под которые у него написаны playbook, и с которыми он постоянно имеет дело. Что-то нетипичное для него, но типичное для вас, может вызвать сложности в реализации.
9. Портал для клиента сегодня предоставляют многие аутсорсинговые SOCи (но вы, конечно, уточните). Поинтересуйтесь, что там будет отображаться? Какие dashboard есть у аутсорсера? Насколько они будут полезны вам? И, кстати, реализован ли ролевой доступ к порталу SOC?
10. Какой доступ имеет аутсорсер к вашей инфраструктуре? Если аутсорсер получил право настраивать ваши периметровые средства защиты, то как будет делиться ответственность за их работоспособность между ним и вашей ИТ-службой? Насколько критичные и чувствительные данные сможет видеть аутсорсер, если вы предоставите ему доступ к внутренней инфраструктуре? Какие настройки потребуется сделать у вас на периметре, чтобы пустить аутсорсера внутрь вашей инфраструктуры? И, кстати, как вы убедитесь, что через канал с аутсорсером к вам не залезут плохие парни? Совсем недавно прокатилась волна взломов провайдеров услуг, через которых затем уже ломали самих клиентов.
11. Ударим по больному. Какова ответственность аутсорсера за пропуск инцидента? Ее может не быть вовсе, но вы же должны к этому быть готовы. А если она есть, то какая? Финансовая? Или продление срока контракта на время простоя от пропущеннога инцидента? Или скидка на следующий год? Тут возникает и обратный вопрос. А какова ваша ответственность за неустраненные косяки в инфраструктуре, благодаря которым инцидент стал возможным? Что делать, если аутсорсер вам сообщил о необходимости накатить нужный патч, а вы проигнорировали его уведомление и это стало причиной взлома? Любой контракт - это документ, устанавливающий права и обязанности для обеих сторон, а не только для той, кому вы платите деньги. Вы готовы к тому, чтобы отвечать за что-то по договору, а не только требовать? 
12. Мир безопасности постоянно меняется - новые угрозы, новые требования регулятора, новые технологии (это если рассматривать только внешние драйверы). У вашего аутсорсера запланированы ежеквартальные встречи с вами для обсуждения новых угроз и включения их в use case? Кто является инициатором таких изменений? По уму, это предлагать должен вам аутсорсер - он же ваш доверенный советник по вопросам ИБ.
13. Вроде как очевидный факт, что угрозы актуальны только если у вас есть уязвимости в вашей инфраструктуре. Кто отвечает за их устранение? Ваша ИТ-служба вовлечена в процесс аутсорсинга ИБ? Может случиться так, что процедура управления уязвимостями у ваших айтишников отличается от подходов, принятых аутсорсером. И это тоже надо обсуждать еще на берегу.
14. Где хранятся логи ваших средств защиты? Многие аутсорсеры на Западе переходят на модель оплаты "storage-based" и это понятно - объемы хранения достаточно велики и кто-то должен компенсировать затраты на построение ЦОДа или аренду вычислительных мощностей для хранения большого объема событий безопасности. Например, в стандарте Банка России по менеджменту инцидентов требуется хранить события безопасности от 3-х до 5 лет (оставим в стороне вопрос, зачем так долго). И тут у вас возникает дилемма. Либо хранить у вас, но тогда как проводить расследования в ретроспективе? Как аутсорсер получит доступ к данным, которые хранятся у вас? Примонтирует ваши диски к его SIEM? А если хранить данные у аутсорсера, то это может вылететь в копеечку.  
15. По договору вам будут присылать кучу отчетов по результатам работ (обычно в PDF). В какой-то момент времени вы настроите правило в вашем почтовом клиенте, чтобы все отчеты складывались в отдельную папку, которую вы... никогда уже не откроете :-) Подумайте о том, как вы выстроите процесс ознакомления с отчетами от аутсорсера? Может через портал? Может у него есть вариант с настраиваемыми параметрами для отправки отчетов и их содержимого?
16. Цена аутсорсинга складывается из стоимость контракта + стоимость обработки ложных срабатываний + стоимость обработки инцидентов вашей ИТ/ИБ. Как аутсорсер борется с ложными срабатываниями? 
17. SOC - тема модная и нужная, но и ее не обошла своим вниманием проблема compliance. Как защищаются ваши данные в SOC? Как обеспечивается выполнение GDPR или ФЗ-152 в SOC? А требования по КИИ (там есть свои нюансы)? 
18. Вы не боитесь атрофии вашей службы ИБ, которая становится слишком зависимой от аутсорсера? Аутсорсинг - это не плохо, просто вы должны осознанно прийти к этому решению.

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

А в заключение я бы хотел все-таки привести несколько сценариев, когда применяется аутсорсинговый SOC (с учетом ответов на вышеозвученные вопросы):

• Для первой линии. 2-я и последующие должны реализовываться вами. В данном сценарии вы всю черновую работу перекладываете на плечи аутсорсера.
• Для ночной работы. Если вы не готовы пока переходить на круглосуточный режим работы, то можно поручить ночные смены аутсорсеру. 
• Для базового мониторинга. Какие-нибудь простые use case вы можете отдать аутсорсеру, оставив себе сложные темы, для расследования которых аутсорсеру просто не хватает знаний о вашей инфраструктуре и процессах. 
• Для ДМЗ. Да, периметр можно отдать в руки аутсорсера, особенно, если он еще по совместительству является и поставщиком услуг Managed Security (MSS), а себе оставить мониторинг внутренней инфраструктуры.
• Для помощи в управлении SIEM. Сегодня появляются облачные или аутсорсинговые SIEM, а по прогнозам Gartner в 2020-м году чуть ли не 90% всех SIEM-вендоров (явно не российских) будут предлагать свои продукты из облака, снижая нагрузку на своих заказчиков.
• Помощь в серьезных инцидентах. Не имея возможности содержать квалифицированные кадры для третьей линии, вы можете эту задачу поручать как раз внешнему аутсорсеру.

Тенденции моделирования угроз

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

• Угрозы эволюционируют. Да вы что?! Вот это новость! Но как бы очевидно это не звучало, в моделях угроз этот факт не часто находит свое отражение. Такое впечатление (и что уж греха таить, так оно и бывает), что модель угроз делают только для галочки или для регулятора, а не для реальной работы. Вот возьмем, к примеру, утвержденную ЦБ модель угроз для биометрических ПДн. И вроде бы достаточно свежий документ, но в нем в принципе не рассмотрена угроза, которую для простоты можно именовать DeepFake, то есть создание фальшивых лиц, отпечатков пальцев, голосов и иных биометрических факторов. То есть в реальной жизни использовать такую модель нельзя - ее надо существенно дорабатывать.
• Инструментарий спецслужб утекает. И это тоже не новость. Но это меняет потенциальную модель нарушителя, который теперь по своим возможностям сравним с АНБ. Или не сравним? Или все-таки нарушитель определяется не сиюминутными возможностями, которые в определенный момент времени могут совпадать с обычными киберпреступными группировками, а мотивацией и целеполаганием? Но в любом случае, появление инструментария спецслужб в широком доступе требует пересмотра модели угроз.
• Supply Chain. Spectre, Meltdown... Только две уязвимости в процессорах Intel, которые показали всю слабость современной системы защиты, базирующейся на недоверенных элементах. Да, вы ничего с этим поделать не можете, так как взять и выбросить все свои процессоры вы не в состоянии - заменить их нечем. Но внести это в модель угроз надо, так как реализация угроз на аппаратном уровне сегодня уже не редкость и игнорировать эту проблему, закрывая на нее глаза нельзя. А надо ли эту угрозу включать в модель, если вы не в состоянии с ней ничего делать? 
• Гибкая разработка. Вы внедрили SCRUM или Agile или иную методологию гибкой разработки или проектирования? А вы учли эту методологию с точки зрения методологии угроз? Ведь обычно угрозы моделируются в рамках каскадного проектирования ("Waterfall") - анализ требований, проектирование, реализация... Как моделировать угрозы при длительности спринта (в терминологии SCRUM) в 1-4 недели?  
• Размытость границ. И это тоже не новость, но и она нечастно находит свое отражение при моделировании угроз. Хотя очерчивание границ для объекта защиты - это основа моделирования угроз. Но сегодня у нас активно внедряются технологии виртуализации, Zero Trust, облачные вычисления. Учитываются ли они при определении негативных сценариев развития событий? А если да, то как?
• Искусственный интеллект. 2018-й и 2019-й годы ознаменовались публикацией большого числа исследований про применение машинного обучения для обмана различных защитных технологий - от биометрии до антивирусов, от антифишинговых решений до систем обнаружения атак. И вновь вопрос, который я уже не раз задавал выше. Как учитывает модель угроз такие исследования? Насколько наши технологии безопасности способны выявлять атаки, созданные искусственным интеллектом?
• API. Мир становится все более открытым - продукты интегрируются между собой и разрешают доступ к своим ресурсам извне. Все это делается через API, которые часто становятся самым слабым звеном "защищенной" системы, в которой предусмотрено все, кроме контроля вызовов API.

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

ЗЫ. А чтобы у заметки была картинка, вставлю вот этот список акторов, реализующих угрозы, и атрибутов, с ними связанных.

Тенденции рынка пентестов - от полной автоматизации до краудсорсинга

Наткнулся тут на новый канал в Телеграме - СекьюриСТ, в котором автор недавно коснулся темы пентестов и описал вкратце, что это такое. Я вообще не очень люблю эте тему, но тут так совпало, что при формировании программы сочинского "Код ИБ. Профи", по просьбам участников в нее был включен практический доклад Жени Волошина из BI.ZONE, как раз посвященный пентестам. Поэтому я решил тоже тиснуть небольшую заметку, но скорее о некоторых тенденциях, которые за пределами России существуют в этой области. Понятно, что не все из них дойдут до нас, но учитывая, что регуляторы в лице ФСТЭК и ЦБ начинают активно требовать проведения тестов на проникновение, понимание рыночных трендов будет полезно.

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

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

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

Чтобы уйти от этих проблем сегодня активно рассматривается в качестве альтернативы платформы для краудсорсингового пентеста, в рамках которых, десятки и сотни исследователей начинают "ломать" вас, ища уязвимости в вашей инфраструктуре и в ваших приложениях (преимущественно именно в них). В отличие от обычного пентестера, краудсоринговый исследователь получает деньги только за обнаруженную уязвимость (за это такой анализ еще называют bug bounty program), а сам процесс поиска может быть непрерывным, что позволяет встраивать такой краудсорсинговый пентест в практику DevOps. Примерами таких платформ можно назвать Synack или HackerOne Challenge.

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

Однако не стоит думать, что краудсорсинговые пентесты поглотят классику. Все-таки у крадсорсинговой модели анализа защищенности есть и свои ограничения. В частности, с ее помощью гораздо сложнее проводить тестирование внутренней сети или устройств Интернета вещей. В этом сценарии классический пентест пока подходит лучше. Однако и тут есть свои тренды. Например, активное внедрение автоматизации в процесс проведения тестов на проникновение. И речь идет не только о решениях класса Breach and Attack Simulation (BAS), яркими представителями которых являются компании AttackIQ, Cymulate, SafeBreach, Threatcare, Verodin и другие. Сейчас стал нарождаться новый сегмент рынка ИБ, в котором уже есть такие компании как CyCognito, Pcysys. Randori, SCYTHE, которые предлагают инструментарий для автоматизации пентестов.

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

ЗЫ. У вас еще есть шанс успеть зарегистрироваться на сочинский "Код ИБ. Профи" и послушать доклад Евгения Волошина, посвященный пентестам.

Какой должна быть структура службы ИБ?

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

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

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

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

• следуйте за процессами
• разделяйте реализацию и надзор
• не пытайтесь делать все - делегируйте
• не смотрите, как у других.

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

Обратите внимание на второй справа блок "Business Enablement". Он отвечает за уже набившую оскомину тему привязки ИБ к бизнесу и, в данном случае, за безопасность проектов по цифровой трансформации, которые реализовывались у заказчика. В итоге у вас может родиться вот такая структура службы ИБ.

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

Вот как-то так получается с оргструктурой службы ИБ. Универсального ответа нет, но есть на что ориентироваться.

ИБ для бизнеса на примере HR-подразделения: пять уровней зрелости

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

Итак, классический безопасник, находящийся на первом уровне модели зрелости, обычно не рассматривает бизнес-подразделения в своей организации как нечто самостоятельное и занимающееся какими-то своими процессами и решающее свои собственные задачи. Разницы между HR, АХО, СЭБ, секретариатом, службой АСУ или коммерческим департаментом никакой. Всем надо поставить антивирус, всех надо патчить, у всех надо искать уязвимости. Это и есть ИБ.

Второй уровень уже начинает как-то учитывать особенности подразделения, но в контексте ИБ, а не бизнеса. В случае с HR на этом уровне безопасник начинает задумываться о том, какую информацию обрабатывает HR и как ее защитить? Оказывается, что в отделе кадров есть персональные данные, требующие защиты согласно законодательству. Бинго! Безопасник начинает заниматься защитой ПДн. В отделе АСУ ТП он занимается (пытается) защитой технологических процессов и т.п. Но именно с точки зрения нормативки, а не реальных потребностей бизнеса (может ему нафиг не нужна защита ПДн).

Дальше мы уходим в сторону от compliance и технологического стека и начинаем думать о людях, которые совершают ошибки, которые приводят к ущербу для бизнеса (пока еще неизмеримому, но уже ущербу). И мы начинаем не защищать HR, а вместе с ним работать с людьми, внедряя программу повышения осведомленности. Это уже не защита информации, но это все еще информационная безопасность.

Четвертый уровень зрелости вроде как и не относится к защите информации, потому что мы начинаем думать совершенно иными категориями. Мы не защищаемся от атак на информационные активы. Мы используем информационные активы для защиты бизнеса от широкого спектра угроз. Например, в случае с HR мы начинаем использовать классический ИБшный инструментарий для того, что является одной из ключевых задач HR - удержание кадров. Это странно звучит, но на самом деле, HR должен заниматься именно удержанием персонала, а не его наймом (этим занимается рекрутинг) или увольнением. И чтобы удерживать персонал, среди прочего, надо иметь оперативную информацию о том, когда сотрудники начинает смотреть на сторону и искать работу, размещая резюме, просматривая вакансии или получая job offer по электронной почте. И отслеживать это можно с помощью DLP, прокси, NGFW, SIG (Secure Internet Gateway), E-mail Security и т.п. решений.

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

А что у нас на 5-м уровне? А все тоже самое, только на более высоком уровне. Мы можем вовсе не использовать классический ИБ-инструментарий для того, чтобы обеспечивать интересы бизнеса, но мы обязательно должны задействовать информационную сферу, в которой мы будем искать следы нарушений или аномалии, которые могут нанести ущерб интересам бизнеса. Вот, например, интересный кейс был реализован в "Почте России". С помощью новой автоматизированной системы "1С" удалось выявить "мертвые души" в почтовых отделениях (их число достигало в отдельных отделениях 50%), выявив фальшивые трудовые книжки и выплаты несуществующим людям. Это угроза и угроза в большой и распределенной компании достаточно серьезная. И может быть даже более опасная, чем какая-нибудь DDoS-атака. Чья это епархия? HR? Безусловно. Но они и сами могут быть вовлечены в преступный сговор с целью незаконного обогащения за корпоративный счет. И вот тут вновь нам помогает ИБ, так как она может контролировать информационные потоки, отслеживать события, связанные с тем или иным процессом, анализировать отклонения от эталонного состояния и их допустимость и т.п. Да, это не МСЭ и не антивирус, не контроль Netflow и не разграничение сетевого доступа. Но это все равно информационная безопасность и именно такая ИБ максимально приближена к бизнесу.

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

Презентации с Payment Security по 0day и нормативке ЦБ

На прошлой недел в Питере прошла уже в очередной раз конференция Payment Security, на которой я выступал (точнее, пытался; из-за болезни) с двумя презентациями - про борьбе с 0day-атаками и про нормативку ЦБ по ИБ. Выкладываю.

Один зеродей и тысяча ночей без сна from Aleksey Lukatskiy

Новинки нормотворчества по ИБ от Банка России from Aleksey Lukatskiy

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

Думаю уже все видели новость, что компанию British Airways могут оштрафовать на 183 миллиона фунтов стерлингов за утечку данных платежных карт полумиллиона клиентов во время покупки ими авиабилетов. Я про этот кейс (и Equifax) делал презентацию с их разбором:

История одного взлома. Как решения Cisco могли бы предотвратить его? from Cisco Russia

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

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

Во-вторых, в случае с BA, авиакомпания пострадала дважды. Сначала увели деньги ее клиентов. И тут еще вопрос, кто будет возмещать ущерб. По крайней мере, коллективный иск к BA подан и посмотрим на его результаты. Потом уполномоченный орган по защите ПДн Великобритании запланировал наказать BA на почти 200 миллионов за утечку. Но интересно, что в случае с BA есть версия, что взломали не ее саму, а подрядчика, которому принадлежал скрипт на сайте BA, отвечающий за сбор данных платежных карт. Вторая версия взлома BA говорит, что компрометация произошла не основного сайта BA, а его CDN, размещенного у одного из операторов связи. В обеих версиях, получается, пострадала аутсорсинговая компания, которой была поручена обработка данных авиапассажиров. Получается, что BA отвечает за проблемы других? Да. За недооценку вопросов ИБ у привлеченных компаний, за которые она несет всю полноту ответственности.

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

Вопрос же заключается в том, что в Европе (а в России такие кейсы пока нереальны) акценты в ИБ начинают очень активно меняться. Ведь даже если вы выполнили все требования по ИБ, но вас взломали (а 100%-й защиты не гарантирует никто), то вас могут оштрафовать на достаточно крупную сумму. А это требует в свою очередь внедрение немного иных практик ИБ, к которым ранее обращались далеко не все и не всегда. В частности, речь должна идти об активном расширении практики оценки соответствия как поглощаемых (в рамках due dilligence), так и привлекаемых к выполнению отдельных работ компаний. Причем во втором случае, это будет не разовый процесс, а проводимый на регулярной основе. В случае собственных активов стоит создать и начать активно эксплуатировать команды red team, которые смогут действовать как хакеры и находить то, что может быть использовано "плохими парнями" для компрометации вашей сети. Лучше, если вы сами себя сломаете и потом исправите, чем если это сделают посторонние. Ну и, наконец, так как все равно 100%-й безопасности вы не можете гарантировать, стоить подумать о страховании киберрисков (правда, пока не в России), которое может помочь покрыть возможные претензии органов контроля/надзора.

Вчера на Эхе Москвы была передача с Андреем Мовчаном, экономистом, который высказал очень правильную мысль. Бизнес бессмысленно заставлять делать, что надо, и не делать, что не надо. Бизнес надо мотивировать, чтобы он сам захотел это делать или не делать. Мотивирует ли бизнес 200 миллионов фунтов штрафа? Да нифига. Пополнить казну, опустевшую после Brexit, это помогает. Но это мотивация для регулятора, а не для бизнеса. И 100 миллионов фунтов штрафа тоже не мотивирует. Гораздо разумнее поступил румынский регулятор, который на днях оштрафовал румынский Юникредитбанк за нарушение статьи 25(1) GDPR. Согласно материалам дела банк спроектировал систему так, что раскрыл часть ПДн плательщиков была раскрыта получателям платежа, что нарушает принцип минимизации раскрываемых данных. Косяк архитектора и штраф в наказание. Но штраф не карающий, как в случае с BA или Marriott, а мотивирующий. Да 130 тысяч евро - это немало, но все-таки на 3 порядка меньше, чем у английских коллег румынского "роскомнадзора".

В России многомиллионные или оборотные штрафы за нарушение требований ИБ заменили сроком лишения свободы (по теме КИИ). Да, в России почему-то проще посадить на 10 лет, чем ввести адекватные финансовые меры воздействия. Но будет ли эта статья работать? Думаю, что компании просто будут скрывать факты инцидентов, чтобы случайно не попасть под статью УК. То есть жесткое наказание мотивирует не лучше заниматься ИБ, а скрывать то, как вы ею занимаетесь. И это печально...

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

Асимметрия информации, информационная экономика и рынок ИБ

Я уже обращался к теме экономики безопасности не один раз (последний - пару недель назад), но тема эта безгранична и поэтому я вновь вернуться к ней. Тем более и повод есть. Росс Андерсон пишет третье издание своего классического труда "Security Engineering" и постепенно выкладывает написанные главы на своем сайте. Последнюю главу, посвященную информационной экономике, он выложил 29-го июня. Я позволю себе поделиться некоторыми выводами (тезисно) из этой главы и некоторыми моими добавлениями к ним:

• Люди не меняют своего поведения, если у них нет к этому стимула. Человек, выставляющий в Интернет небезопасную машину, не несет никаких последствий, в то время как человек, который пытается делать все правильно, страдает от побочных эффектов. Тоже самое касается и компаний.
• Асимметричная информация, о которой я впервые написал 10 лет назад (и еще 6 лет назад), управляет рынком ИБ. Если у вас нет полной информации об интересующих вас средствах защиты, их качестве и функционале, то для вас основным критерием покупки будет стоимость. А если транслировать отсутствие информации при покупке в даркнете, то вы будете заложником знакомого вам продавца или площадки и будете торговаться по его ценам и условиям. И так по многим направлениям, в которых тот, кто обладает большей информацией, манипулирует теми, у кого ее нет. В условиях же цифровой симметрии, когда у всех информация одна и та же, наступает конкурентное равновесие. Например, если бы где-то был сайт (или сайты), который, как агрегатор стоимости авиабилетов или отелей, отображал бы стоимость разных МСЭ, соответствующих заданному функционалу, то их цена бы поползла вниз, так как у всех потребителей была бы одинаковая информация и ею нельзя было бы манипулировать. 
• Люди до сих пор покупают антивирусы, хотя это совершенно бессмысленная трата денег. Вирусописатели ведь проверяют свои творения на всех известных средствах защиты до того, как выпустить свой код "в свет". То есть на момент своего победоносного шествия по миру вредоносная программа не детектируется антивирусами. Но об этом производители не говорят, а потребитель просто не задумывается об этом. Еще бы - последние 25 лет на всех углах говорят о важности антивируса и 100% потребителей их использующих (тут вступает в игру одна из предыдущих заметок про страшилки и необходимость демонстрации прогресса и равнения на лучших) поэтому не знает об этом. Налицо цифровая асимметрия.
• Интересно, что асимметричность информации объясняет очень многое в мире ИБ. Многие заинтересованные лица не заинтересованы говорить правду. Спецслужбы и ИБ-компании преувеличивают угрозы; компании электронной коммерции и банки - преуменьшают их. Американские спецслужбы обвиняли в кибератаках на США Россию, не предоставив никаких доказательств. И снова проявление асимметрии информации.
• Ввиду коммерциализации рынка киберпреступности, он также начинает активно жить по экономическим законам. Цена многих услуг падает до нуля и мелкие игроки киберпреступности постепенно уходят с рынка, уступаю место крупняку, который консолидирует усилия и может вышибать нишевых игроков с рынка продавая услуги "в минус", компенсируя потери в других сегментах. Такое происходит на рынке услуг спама, или DDoS. Кстати той же стратегии придерживаются и многие интеграторы, которые торгуют пентестами задешево, выбивая мелкие нишевые конторы с этого рынка. Правда, при этом страдает и качество услуг, но в условиях асимметрии информации потребитель об этом не узнает, а интеграторы не спешат делиться этим откровением.
• Цена информации равна стоимости ее производства, что во многих случаях означает, что она равна стоимость копирования, то есть нулю. Отсюда вытекает отсутствие нормальных аналитических ресурсов, которые не могут жить только за счет информации (ее легко копируют и распространяют) и вынуждены прибегать к рекламе.
• Есть всего два способа получить то, что вам хочется, если вы не можете создать это сами или найти где-то. Вы либо делаете что-то полезное другим и торгуете этим (обмениваетесь или на вырученные деньги покупаете нужное), либо берете то, что вам нужно, силой. Выборе между сотрудничеством и конфликтом ведется каждый день на уровне людей и на уровне компаний. Основным инструментом, который изучает сотрудничество и конфликты, является теория игр.
• Люди, которые занимаются ИБ систем, не являются людьми, которые несут потери от атак на эти системы.
• Иногда механизмы безопасности используются, чтобы свалить вину на других. И если вы один из этих "других", то вам было бы лучше, если бы система была небезопасной.
• Безопасность часть используют для продвижения своих интересов, а не для достижения общего блага.
• Безопасность мешает развитию и рациональным поведением для компании будет пренебрегать ею пока не будет защищена его позиция на рынке. И только после этого можно начать думать о защищенности. Именно поэтому у многих стартапов и начинающих разработчиков ПО проблемы с безопасностью.
• "Сделка - потом грабеж" - так называется ситуация, когда поставщик средств ИБ продает свои решения задешево, но потом начинает "стричь" заказчика на ежегодном продлении, цена которого может составлять 70 и даже 100 процентов от первоначальной стоимости решения. Это тоже объясняется простой экономикой.
• Если вы используете какое-то сложное ПО (Microsoft или  Splunk), то вы начинаете использовать его по максимуму, все его хитрости и трюки. Это существенно осложняет процесс миграции на другое ПО.
• Правоохранительные органы очень мало занимаются киберпреступностью, так как им проще не замечать ее, игнорировать проблему и удерживать жертв от заявлений о преступлениях.
• Обнаружение мошенничества с кликами в рекламных сетях означает, что рекламная сеть не может брать денег с рекламодателей за эти клики. Значит, если владелец рекламной сети очень хорошо борется с мошенничеством, то он меньше зарабатывает. Тоже самое с борьбой с DDoS в условиях, когда оператор связи получает деньги за объем трафика.
• Поиск ошибок и уязвимостей в разработанном вами коде приводит к потере конкурентных преимуществ. Чем больше вы ищете, тем больше вы находите, и тем дальше вы отдаляете срок выхода своего ПО. Менее щепитильные компании или команды в результате выигрывают. Поэтому большого стимула внедрять анализ кода нет, если только об этом не просят клиенты или не введена ответственность за отсутствие анализа.

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

ЗЫ. В книге наткнулся на упоминание интересного кейса. В 2012-м году один из волонтеров внес в открытое ПО (WebKit) уязвимость, чтобы потом через программу bug bounty получить вознаграждение. Деталей в Интернете что-то не смог найти, но на интересные мысли этот кейс наводит. Включены ли ваши разработчики или разработчики ПО, которое пишется для вас, в вашу модель угроз/нарушителя?

ЗЗЫ. Кого интересует тема информационной экономики могу посоветовать материалы ежегодной конференции WEIS (The Workshop on the Economics of Information Security), где эту тему активно обсуждают с 2002-го года. 

Юбилейный "Код ИБ. Профи". Какие сюрпризы ждут участников?

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

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

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

• Наталья Гуляева. Наташа будет рассказывать о цифровых доказательствах и о том, как подготовить их и представить в суде. Дело в том, что сейчас достаточно много разных выступлений про реагирование на инциденты и даже про форензику. Но вот про то, как не просрать все собранные доказательства и сделать так, чтобы суд их принял, почти никто не говорит. Наташа, являясь профессиональным юристом именно в области кибербезопасности, как раз и подскажет, как все сделать так, чтобы никто и придраться не смог к собранным вами доказательствам. А еще Наташу можно будет помучить в свободное время на тему персданных и GDPR :-)
• Рустем Хайретдинов. Руст продолжит тему, начатую на московском "Коде ИБ. Профи", и покажет, как описывать бизнес-процессы с точки зрения ИБ, как составлять план их безопасности, как выделить триггеры и маркеры, характеризующие нарушения, которые наносят ущерб бизнесу. В идеале, если вы сможете захватить с собой ноутбук, чтобы двухчасовой мастер-класс вы смогли не только слушать или рисовать на бумаге, но и выполнять задания на одном или двух реальных бизнес-процессах.
• Дмитрий Мананников. Дима продолжит свою победную серию мастер-классов про экономику ИБ-проектов. В этот раз у Димы будет два часа, за которые участники смогут не просто внимать гуру экономики ИБ, но и самостоятельно просчитать экономику своих проектов по ИБ и своими глазами убедиться, что ИБ рублем посчитать не только можно, но это и не так сложно.
• Илья Борисов. Илья будет делиться опытом, как за 15 минут и 7 слайдов поделиться с топ-менеджментов текущим статусом ИБ в компании, как не допускать типовых ошибок, как правильно расставить акценты при выступлении и какие приемы коммуникаций наиболее эффективны? Как и на московском "Коде ИБ. Профи" у Ильи будет двухчасовой мастер-класс с вовлечением участников, которые смогут попробовать самостоятельно сделать то, что потом поможет им поднять свой статус в организации и увеличить ресурсы на ИБ. Неплохо было бы, если бы вы взяли с собой ноутбук на этот мастер-класс и смогли бы сделать реальную презентацию для руководства.
• Алексей Пятигорский. Алексей будет рассказывать о реальном кейсе, с которым ему пришлось столкнуться в своей нынешней роли. Как организация чуть не проспала атаку, имея мощную систему ИБ, кучу индикаторов компрометации, фидов и вот этого всего? Как отделить ложные срабатывания от реальных и как выжать максимум из результатов форензики? 
• Антон Карпов. Думаю многие видели в новостях историю о том, что иностранные спецслужбы атаковали Яндекс. А у нас по счастливой случайности будет выступать Антон Карпов с докладом о том, как бороться с продвинутыми угрозами. Я бы сказал, что это эксклюзивная возможность узнать, как бороться с тем, что в последнее время все чаще попадает на страницы СМИ и что месяцами и годами находится в корпоративных сетях, не будучи обнаруженным (тот же Regin сидел в Belgacom целых два года).  
• Алексей Качалин. Если ваша компания внедряет систему управления цепочками поставок на блокчейне, то знаете ли вы, какие риски это влечет за собой и как надо защищать блокчейн от хакеров? А вдруг вы подсели на квантовый хайп и решили внедрить систему шифрования на базе квантового распределения криптографических ключей? На что стоит обратить внимание в этом проекте? Алексей попробует поднять участников конференции с земли в небо и расскажет о том, как и с чем есть прорывные технологии (Большие данные, машинное обучение, квантовые вычисления, интернет вещей, блокчейн и т.п.) в контексте ИБ.
• Лев Палей. Сегодня, даже в условиях импортозамещения, когда число возможных альтернатив снижается, все равно на повестке многих компаний стоит вопрос о том, как выбрать именно то решение по ИБ, которое нужно именно вашей компании, и не попасться на удочку маркетологов и "продаванов от ИБ". Лев поделится реально работающей методикой выбора решений по ИБ. Но это будет не монолог Льва, а мастер-класс с вовлечением - участники будут разбиты на три команды, которым будут предложено несколько решений по ИБ и надо будет выбрать и обосновать свой выбор перед лицом строгой комиссией.
• Сергей Волдохин. Фишинг остается самым популярным способом начала многих атак - от банальных до целевых, от инициируемых хакерскими группировками до спонсируемых государством. О том, как выстроить программу защиты от фишинга я рассказывал на последнем московском "Коде ИБ. Профи". А вот о том, как обучать и тренировать своих сотрудников, как разработать сценарий и формат фишинговых симуляций, как измерить поведение сотрудников, расскажет Сергей. В паре с ним будет будет работать профессиональный психолог - Ольга Лимонова. Этот мастер-класс заберет у участников тоже два часа. Если вы возьмете ноутбук, то мастер-класс Сергея будет еще более эффективным.
• Евгений Волошин. На первом "Коде ИБ. Профи", который проходил как раз в Сочи, на заключительной сессии мы спросили участников, чего им не хватало из тем. И прозвучало (и потом в анкетах это повторилось), что людям хотелось бы услышать "про пентесты". Меня это немного удивило, но так как этот запрос повторялся почти на каждом "Коде ИБ. Профи", то на пятый раз мы все-таки решили сделать мастер-класс про пентесты. Но не про абы какие :-) Женя расскажет, почему не стоит пускать YOLO-пентестеров в свою инфраструктуру, а также расскажет о комплексном подходе к тестированию на проникновение: зачем привлекать администраторов в проектную команду, и каким должен быть инфраструктурный пентест здорового человека на примере реальных кейсов. Также Женя объяснит, почему текущий подход к проведению инфраструктурного пентеста не повышает общий уровень защищенности компании.
• Андрей Прозоров. Как говорят англичане "last but not least" и эта характеристика очень хорошо подходит к Андрею, который перебрался на Запад, но не перестает скучать по Родине и регулярно заезжать к нам и делиться своим опытом. В этот раз Андрей поделится опытом по реализации нестареющей классики - ISO 27001. Подводные камни, особенности оценки, непрерывное совершенствование, избежание проблем при внедрении этого международного стандарта управления ИБ. 

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

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

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

ЗЫ. Ааа, про себя-то я забыл написать. У меня будет двухчасовой практический мастер-класс по моделированию угроз, на котором я сначала дам краткую вводную в моделирование, а затем мы, разбившись на группы, попробуем смоделировать угрозы для 3-5 выбранных объектов защиты. Учитывая, как часто в последнее время компании страдают от рук хакеров, понимаешь, что у многих процесс моделирования угроз либо не выстроен вообще, либо сделан для галочки, для соответствия требованиям регуляторов. Мы попробуем поменять эту порочную практику. Будет у меня еще часовое выступление, которое я хотел посвятить проведению стратегических сессии по ИБ, но последние дни я все больше склоняюсь к тому, что я могу сильно пересечься с темой Ильи Борисова. Возможно я поменяю эту тему на что-то иное. Есть задумка рассказать о рынке киберпреступности с точки зрения бизнес-моделирования. Я эту тему на публике почти не читаю (только на закрытых мероприятиях), но тут можно попробовать чуть облегчить ее и уложить в час.

Как "дочкам" иностранных компаний обмениваться инцидентами с штаб-квартирами?

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

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

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

Учитывая, что в НКЦКИ никто так ни разу и не обратился по поводу разрешения на передачу данных зарубеж, регулятор вполне очевидно негодует и грозит карами (до двухсот тысяч рублей за нарушение). И вот тут возникает несколько моментов, на которые я хотел бы обратить внимание:

1. Из пунктов 11-12 не вытекает, что получать разрешение НКЦКИ надо на каждый инцидент и вроде бы можно получить его один раз. Но п.15 говорит о том, что НКЦКИ принимает решение по каждому инциденту отдельно.
2. Про оперативность реагирования можно забыть. НКЦКИ берет 24 часа на принятие решения об отправке данных об инциденте зарубеж и еще 12 часов на то, чтобы переправить вам ответ из-за рубежа. Итого 36 часов. Оперативно, ничего не скажешь :-(
3. Дальше больше. Взаимодействие с иностранными организациями ведется на... иностранном языке. При это взаимодействие с НКЦКИ ведется на русском языке. И возникает вопрос, кто будет осуществлять перевод информации об инциденте? Например, у нас в Cisco (хотя мы и не являемся субъектами КИИ) информирование об инцидентах ведется только на английском языке и во всех системах тикеты заводятся на английском (интересно, в азиатских компаниях на каком языке?).
4. Банк России, активно стоящий на страже интересов вкладчиков, подписал соглашение с рядом Нацбанков СНГ о взаимном обмене информацией об инцидентах, например, с Арменией. Так вот получается, что ФинЦЕРТ является тоже нарушителем требований ФСБ, так как он передает данные своим коллегам в Армении (а также в ряде иных государств) напрямую, минуя НКЦКИ.
5. У международных платежных систем (например, у Visa) существует требование об уведомлении об инцидентах в отношении компрометации данных платежных карт. Насколько я помню, схожее требование есть у SWIFT.
6. Дальше больше. Информация об инциденте от субъекта КИИ его зарубежному "визави" передается не субъектом, а НКЦКИ в формате, установленным НКЦКИ. Пока эти форматы публично нигде не описаны и соответственно на повестке дня возникает простой вопрос. А как зарубежная организация сможет принять данные на русском языке да еще в формате, который нигде не описан и, вероятно, не совпадает с тем, что используется на предприятии за пределами России? Вы пробовали, будучи дочкой иностранной организации, получить документы ФСБ официальным путем? Ооооо, это я вам доложу та еще эпопея.
7. Наконец, представьте себе, что вам от АНБ приходит информация об инциденте у вас внутри? Представили? Отложим в сторону эмоции. Вы вообще готовы к принятию такой информации извне (даже если отбросить в сторону репутацию нашей спецслужбы в мире)? К принятию IOCов да, но к карточкам с описанием инцидентов? Тут тоже есть сомнения, что процессы многих организаций вообще учитывают возможность приема данных об инцидентах извне, по внешним каналам. Да и чисто технически не совсем понятно, как это будет происходит.

Какой же ответ можно дать представительствам иностранных компаний, которым не повезло стать субъектами КИИ? Чего я не буду советовать:

• Скрывать факт передачи инцидентов зарубеж.
• Пытаться уйти от попадания под КИИ.
• Путем "правильного" категорирования прийти к ситуации с отсутствием значимых объектов (на взаимодействие с ГосСОПКОЙ это все равно не влияет - уведомлять надо об инцидентах на любых объектах).

Что же тогда делать? Я бы посоветовал несколько вариантов:

• Через Ассоциацию Европейского бизнеса, американскую торговую палату, российско-германскую внешнеторговую палату, франко-российскую торговую палату делать запросы в НКЦКИ и обсуждать с ним возможные пути решения проблем.
• Создавать в России службу ИБ, которая могла бы взять на себя функции реагирования на инциденты, а в головную структуру, если и передавать что-то, то в одностороннем порядке (тогда это не будет считаться обменом и, формально, не попадет под ограничения в приказе ФСБ).

ЗЫ. У Валерия в заметке приводится интересный кейс с наказанием организации, которая опубликовала на сайте определенный материал, который не должен был распространяться за пределы РФ. Ну дальше можно фантазировать в меру своей испорченности :-(