09.08.2019

ИБ-фреймворки: какие бывают и зачем нужны?

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

Я бы выделил три набора фреймворков, различающихся по своим задачам и цели применения - контрольные (от английского control, которое по-русски звучи длиннее - "мера защиты"), программные и рисковые. Большинство знакомо с первой категорией, которые представлены не только иностранными примерами - NIST SP800-53, горячая двадцатка CIS (бывший SANS Top20), а также отечественные документы ФСТЭК (приказы 17/21/31/239) и Банка России (ГОСТ 57580.1).


Эти фреймворки нужны для решения важных "технических" задач по ИБ:

  • определение базового набора защитных мер, подходящих конкретной организации
  • оценка текущего состояния уровня технической защиты информации
  • приоритезации защитных мероприятий и составления дорожной карты развития.
Отличительной особенностью хорошего фреймворка являются группирование (тут почти все упомянутые выше примеры на высоте) и приоритезация защитных мер. А вот с последним пунктом в документах ЦБ и ФСТЭК есть сложности. Каталоги защитных мер обширны и насчитывают около двух сотен наименований, но как из них выбрать те, что дают максимальный эффект, особенно в условиях нехватки ресурсов на внедрение, непонятно. У уже не раз мной описанных австралийских требований по ИБ, например, есть такая приоритезация. Есть Топ4, Топ8 и Топ35 защитных мер, которые позволяют достичь 80%, 90% и 98% результата. Аналогичная функция есть и у NIST SP800-53 - против каждой защитной меры в поле "Приоритет" стоит значение от 0 до 3, означающих важность реализуемого мероприятия.


"Программные" фреймворки предназначены для:

  • оценки текущего состояния программы ИБ на предприятии
  • построения всесторонней (хотя это все-таки не совсем так) программы ИБ
  • измерения зрелости программы ИБ и обеспечения возможности бенчмаркинга (сравнения себя с другими по отрасли).
Самым известным в Евразии и популярным фреймворком является ISO 27001, а в Северной Америке - NIST CSF. Первый интересен тем, что у него множество расширений под различные задачи. Например, есть ISO 27019 для энергетики, 27011 для телекома или ISO 27701 (совсем свежий стандарт) для персональных данных. В отличие от технических мер защиты, в ISO 27001 или NIST CSF меры носят более высокоуровневый характер - взаимоотношение с поставщиками, выбор средств защиты, управление активами, работа с персоналом, повышение осведомленности, управление инцидентами и т.п.





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

Если первые два типа фреймворков хорошо дополняют друг друга, то третий имеет смысл применять только в очень зрелых компаниях, которые действительно понимают, что такое риски ИБ и знают как считать вероятность и ущерб (а это то еще приключение). В целом данный тип фреймворка, ярким представителем которого является FAIR или серия NIST, позволяет:
  • идентифицировать и измерять риски ИБ
  • приоритезировать защитные мероприятия
  • определить ключевые этапы управления рисками
  • структурировать программу управления рисками.
Резюмируя, хорошие фреймворки, опираясь на опыт уже множества внедрений и набитых шишек, позволяют сэкономить вам время и нервы, следуя описанному в фреймворке алгоритмы построения системы ИБ. Но не стоит думать, что вам нужен именно один из перечисленных выше фреймворков. По статистике Gartner 20% компаний разрабатывают собственный фреймворк, еще 16% дорабатывают существующие, а 20% - комбинируют компоненты из разных фреймворков. Еще 21% вообще их не используют вовсе, а 23% используют стандартные фреймворки (NIST CSF, ITIL и ISO 27001 входят в тройку самых популярных по версии NIST). 



Поэтому выбирайте то, что лучше подходит именно вам и именно под ваши задачи. Если вы государственный орган, то выбор у вас не богат - документы ФСТЭК и, возможно, ГОСТ Р ИСО/МЭК 27001 (сейчас как раз через ТК 362 проходит новая версия этого стандарта). Для финансовых организаций обойти ГОСТ 57580.1 (и последующие ГОСТы от ТК122) будет непросто. Остальные же имеют свободу выбора и я бы (если бы я выбирал), остановился бы на NIST CSF и NIST SP800-53. А если бы передо мной стояла задача выбора только контрольного фреймворка, то CIS Top20 у меня был бы на первом месте (или австралийский перечень).

ЗЫ. Практические аспекты по этим фреймворкам можно посмотреть в докладах с "Кода ИБ. Профи", которые скоро будут доступны на сайте (по подписке).

08.08.2019

3 новых нормативных акта по ИБ для финансовых организайций

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

Платежных приложения Apple Pay и облачные ДБО должны быть сертифицированы

3-го июля был подписан 173-й ФЗ "О внесении изменений в Федеральный закон "О национальной платежной системе" и отдельные законодательные акты Российской Федерации", который среди прочего определяет ряд новых терминов и среди них "платежное приложение", "поставщик платежного приложения" и "платежный агрегатор".


К двум новым субъектам ФЗ-161 теперь предъявляются новые требования в области кибербезопасности. Платежные приложения, которые используют операторы по переводу денежных средств должны соответствовать требованиям к защите информации при осуществлении переводов денежных средств. Можно было бы предположить, что под термин "платежное поручение" попадут и системы ДБО или "клиент-банк", но в законе и в своих разъяснениях Банк России дает понять, что речь идет только о тех приложениях, которые разработаны организациями, которые привлекаются кредитной организацией для проведения платежей. В пояснительной записке в качестве примера приводятся имена Apple Pay, Samsung Pay и MirPay. Опираясь на определение, я бы еще отнес к такого рода система и облачные ДБО, которые используют некоторые банки сегодня. Вообще это странная формулировка, так как требования 27-й статьи ФЗ-161 применяются к участникам НПС, а не к приложениям. Думаю, что тут речь идет о последних правках в 382-П, которые требуют сертификации платежных приложений на отсутствие НДВ или выполнения в их отношении анализа защищенности в соответствие с ОУД4.

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

Те, кто работает с МПС, обязаны выполнять требования ФСТЭК

2-го августа был принят 264-й ФЗ "Федеральный закон от 02.08.2019 N 264-ФЗ "О внесении изменений в Федеральный закон "О национальной платежной системе" и Федеральный закон "О Центральном банке Российской Федерации (Банке России)". Он направлен "против" иностранных платежных систем, заставляя их соблюдать требования, применяющиеся к российским платежным системам. Среди прочего в законе есть такой пункт: "Информационные системы операторов по переводу денежных средств, с использованием которых осуществляется прием электронных средств платежа и обмен информацией с иностранными поставщиками платежных услуг, информационные системы операторов услуг информационного обмена, с использованием которых осуществляется взаимодействие с иностранными поставщиками платежных услуг, должны соответствовать требованиям по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации." Иными словами, те системы кредитных организаций, которые взаимодействуют с иностранными платежными системами должны выполнять требования 235-го и 239-го приказов ФСТЭК независимо от результатов категорирования. Кстати, до 1-го сентября 2019-го года в ФСТЭК надо отправить перечень объектов КИИ.

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

Кроме того, операторы иностранных платежных систем должны иметь установленные правила защиты информации, а Банк России имеет право установить требования по защите информации при использовании трансграничного перевода денежных средств. Вспоминая, как Банк России "рисовал" себе картинку про НПС, можно увидеть, что последним пунктом ЦБ как раз закрыл последний ранее незакрытый кусок в виде SWIFT (когда выпустит требования).


Профиль защиты для платежных приложений

В 382-П, 683-П, 684-П, а также ГОСТ 57580.1 было требование о том, что платежные приложения должны быть сертифицированы в ФСТЭК по требованиям безопасности или в отношении которых проведен анализ уязвимостей на соответствие ОУД4. Вот собственно требования, по которым должна проходить сертификация, и прописаны в этом почти 150-тистраничном документе, проект которого выложен на сайте ТК122 (доступен только для членов технического комитета по стандартизации). Я не буду раскрывать подробности этого документа, но работа у разработчиков и испытательных лабораторий предстоит непростая и к 1-му января 2020-го года (этот срок прописан, как минимум, в 382-П) они точно не успеют провести сертификацию (там есть и иные препоны, связанные уже с самой системой сертификации ФСТЭК). Поэтому сейчас стоило бы воспользоваться оставшимися пятью месяцами и начал бы проводить анализ уязвимостей по ОУД4 (или требовать этого от разработчиков).

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

07.08.2019

Пять уровней зрелости оценки ущерба от DDoS-атак на сайт организации

Понравилась мне прошлая заметка про ИБ для бизнеса на примере HR-подразделения. Она и дискуссии на прошедшем "Код ИБ. Профи" подтолкнули меня к идее данной заметки. На мастер-классе Рустема Хайретдинова зашел разговор о том, как можно показать влияние ИБ на бизнес, и прозвучал тезис о том, что бороться с угрозами не всегда необходимо, так как они не всегда интересны бизнесу. Этот тезис не нов, но дальше был приведен пример сайта, который подвергается DDoS-атаке, и который нуждается в защите... Или все-таки не нуждается?

Вроде бы любой безопасник должен защищаться от DDoS-атак, которые могут вывести из строя сайт компании. Но... нужно ли это бизнесу? И вот тут пригодится идея с пятью уровнями зрелости, которую я описал в прошлой заметке про ИБ и HR. На самом низшем уровне зрелости безопасник обычно вообще не думает об оценке ущерба от той или иной атаки, следуя принципу д'Артаньяна "я дерусь, потому что я дерусь", то есть "я защищаю, потому что надо защищать (или потому что так сказал регулятор"). К бизнесу это не имеет никакого отношения.

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

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

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

Но можно (а временами и нужно) пойти дальше. Помимо учета множества показателей, связанных с циклом продаж, профилем пользователя, временными спадами и пиками, размер средней сделки, количеством транзакций и т.п., мы должны также оценить финансовые показатели приобретаемого средства защиты от DDoS. Понятно, что эта сумма не должна превышать размер ущерба, но это совсем уж поверхностное суждение. Борьба с DDoS может быть представлена в виде облачного или on-prem решения (то есть продаваться по модели OpEx или CapEx соответственно). Купить такое решение можно поставив его на баланс, а можно воспользоваться лизингом. Оплата может быть произведена как за год использования (типичная схема для большинства средств защиты), так и помесячно или в пиковые интервалы продаж/спроса со стороны клиентов, а также по схеме "on-demand", то есть во время самой атаки. При этом последний вариант тоже может быть реализован по-разному - оплата "за атаку" или оплата "за полосу". И вот собрав воедино все финансовые, маркетинговые и айтишные показатели, можно уже заниматься расчетом ущерба от DDoS-атак и его оценкой применительно к конкретной организации. И только в этом случае можно говорить о том, нужна ли конкретному бизнесу защита от DDoS-атак или можно принять данный риск.

06.08.2019

Обзор отчета SANS по Security Operations Center

Продолжу тему SOCов. Помимо Exabeam, чей отчет я описал вчера, еще один обзор по SOC был выпущен этим летом. На этот раз его автором стал известный институт SANS, который уделяет этой теме большое внимание. Что интересного преподнес этот отчет и что нового в нем есть по сравнению с данными Exabeam?

  • Чаще всего на аутсорсинг отдают пентесты и различные формы проверки защищенности организации (red/purple teaming). В остальном тенденции схожи с тем, что написано у Exabeam; с поправкой на то, что SANS оперирует абсолютными цифрами и практически не сравнивает ситуацию с предыдущим годом.
  • Интересен был вопрос о том, как в SOC выстроен процесс управления знаниями, то есть документирование знаний, связанных с прошедшими инцидентами и операциями для ускорения процесса погружения в деятельность SOC новых его членов. Небольшие SOC используют неформальный процесс "один гигантский документ OneNote" или просто SharePoint. Большие SOCи используют для этих задач связку Jira с Confluence, которые позволяют вести базу тикетов и осуществлять накопление знаний в wiki-формате и обмен ими. SOCи, тесно связанные с ИТ, часто задействуют ServiceNow или BMC Remedy для управления тикетами и SharePoint для обмена знаниями.
  • SOCи преимущественно мониторят ИТ-инфраструктуру и только 10% из них берут на контроль еще и АСУ ТП и Интернет вещей. 
  • Для большинства SOCов остается проблемой наличие актуальной информации по активам, которые требуют мониторинга. Это связано с тем, что даже в зрелых ИТ-организациях CMDB обладает точной информации хорошо если на 80%. Часто именно SOC, которые предоставляют услуги сканирования и мониторинга учетных записей, сообщают в ИТ знания, которых у ИТ не было даже при наличии CMDB. Еще большую проблему в понимании активов представляет собой использование IaaS/PaaS/SaaS.
  • В случае наличия в организации NOC, в большинстве случаев он никак не связан с SOC, и их усилия объединяются только в условиях экстренных ситуаций.
  • Авторы отчета отмечают, что ответа на вопрос "Сколько достаточно сотрудников в SOC?" нет. Все зависит от множества факторов. Треть всех опрошенных имеют от 2 до 5 сотрудников в SOC (а всего опросили 355 SOCа по всему миру). Еще треть имеет от 6 до 25 сотрудников. Интересно, что 6 SOCов из 355 (в том числе и Cisco) имеют от 101 до 1000 аналитиков в своем составе, а 3 - более 1000 аналитиков. Хотелось бы знать имена этих "героев". Если же попробовать увязать число аналитиков SOC с размером организации, то картинка получается следующая:
    • При численности компании менее 10000 человек в SOC обычно от 2 до 5 аналитиков.
    • При численности от 10 до 15 тысяч человек SOC насчитывает обычно от 6 до 10 человек. 
    • В организациях от 15 до 100 тысяч сотрудников в SOC обычно работает от 11 до 25 человек.
    • В монстрах от 100 тысяч сотрудников SOC насчитывает от 26 до 100 аналитиков.
  • Получается, что среднее число айтишников от общей численности компании составляет 3% и еще 3% от службы ИТ составляет ИБ.
  • Большинство SOCов построено по централизованной архитектуре, что немудрено. Однако интересным оказалось, что более 10% опрошенных планируют перейти к облачной модели SOC. Еще 10% не имеют вообще никакой четко определенной архитектуры для своего центра мониторинга.
  • Интересным, но предсказуемым оказался ответ на вопрос об используемых метриках эффективности SOC. Самыми популярными метриками являются число инцидентов и время от обнаружения инцидента до реагирования и восстановления после него. Их измерять проще всего, опираясь на используемые в SOC инструменты. Бизнес-метрики, о которых я писал в прошлом сентябре, измерять достаточно тяжело и поэтому ими мало кто занимается. Стоимость инцидента как метрику для SOC использует не больше шестой части участвовавших в опросе центров мониторинга, также как и соотношение понесенных и предотвращенных от инцидентов потерь. В практике Cisco у нас был интересный проект по созданию SOC в финансовой организации, где заказчик в качестве одной из основных метрик использовал стоимость выписки по клиенту в Darknet. Ее увеличение говорило об эффективности работы ИБ. Только 11% организаций полностью автоматизировали процесс сбора и представления метрик - остальные используют либо целиком ручной, либо смешанный способ работы с показателями оценки эффективности SOC.
  • Список барьеров при построении и эксплуатации SOC более полон, чем у Exabeam, хотя топ этих барьеров почти полностью совпадают:
    • Нехватка квалифицированного персонала
    • Нехватка автоматизации и оркестрации
    • Отсутствие интеграции между инструментами SOC
    • Нехватка поддержки руководства
    • Нехватка процессов или playbook
    • Нехватка видимости на 360 градусов в рамках всего предприятия
    • Нехватка корреляции между всеми сигналами тревоги
    • Отсутствие кооперации между ИБ, реагированием на инциденты и аналитиками
    • Нехватка контекста к событиям безопасности
    • Требования регуляторики.
Вот такие данные, которые можно использовать как некоторый ориентир при построении с нуля или оценке уже построенного центра мониторинга безопасности. В целом могу подтвердить правдивость и отчета SANS и отчета Exabeam - мы, проводя аудиты SOCов по всему миру, включая и территорию бывшего Советского Союза, видим те же сложности и наблюдаем то же, что и в упомянутых отчетах.

05.08.2019

Обзор отчета Exabeam по состоянию Security Operations Center

Попался мне тут в руки отчет Exabeam с различной статистикой и обзором происходящего в области Security Operations Center в 2018 году (80% участников опроса имеют опыт работы в SOCах от 6 лет, а длительность работы 90% опрошенных SOC составляет более 3-х лет). Все перечислять не буду, но несколько интересных моментов оттуда я все-таки вытащу:

  • Почти половина SOCов продолжает аутсорсить функции Threat Intelligence (ежегодный рост 17%) и анализ вредоносного кода (ежегодный рост 15%), а вот аутсорсинг функции мониторинга (одной из основных для SOC) наоборот снижается (на 10% по сравнению с прошлым годом). Вспоминая недавнюю заметку, становится понятно, почему многие организации (если уж они доросли до идеи SOC) предпочитают все-таки строить свой центр мониторинга, отдавая вовне только сложные сервисы. Также возрастает число кейсов (на 6%), в которых на аутсорсинг отдается внеурочная работа (ночные часы и выходные). Сократилось до нуля число организаций, которые целиком отдавали функцию SOC на аутсорсинг. 
  • Менее эффективные SOC имеют больше проблем с нехваткой персонала, чем высоко эффективные центры мониторинга. Трети SOC не хватает 6-10 человек для выполнения своих функций. Интересно, что в России многие службы ИБ насчитывают меньше людей, чем это число.
  • Одним из мотивирующих факторов для аналитиков SOC продолжать работать в SOC являются вызовы, с которыми приходится сталкиваться в работе. Иными словами, в центрах, которые занимаются "ерундой" (мало заказчиков при аутсорсинге, мониторинг только периметра и небольшое количество инцидентов), аналитики должно не удерживаются, что приводит к снижению эффективности SOC (я об этом уже писал год назад). И это обычно не находится на поверхности, если речь идет об аутсорсинговом SOC. На желание покинуть SOC активно влияют плохой график работы (о том, что с этим делать, я говорил на прошлом SOC Forum), возможность фриланса (врядли актуально в России), а также отсутствие возможностей для внутреннего роста.
  • Возрастает роль так называемых soft skills для аналитиков SOC. Особенно важны становятся социальные навыки, умение коммуницировать и умение работать в команде.
  • Из технических навыков возрастает роль threat hunting и поиска утечек информации. А вот важность навыков работы с МСЭ, форензики и анализа вредоносного кода снизилась.
  • Общая эффективность SOC за год не изменилась, а вот возможности по автоматизации существенно упали (на 14%).
  • Три основных проблемы, возникающие у аналитиков SOC, - время, затрачиваемое на отчетность и документацию, ложные срабатывания и усталость от угроз (а тут недалеко и до психологической слепоты). А в целом у SOC проблемы следующие (в порядке приоритета) - успевать реагировать на все события ИБ, координация между ИБ и ИТ, слабая интеграция различными инструментов ИБ, необновленное оборудование. Тут вроде ничего нового
  • В рамках технологического стека у SOCов 4 приоритета - анализ больших данных, EDR (endpoint detection & response), мониторинг сети (NTA) и облаков (но не CASB), а также управление учетными записями. Около 40% SOC используют их в своей работе. Возрастает интерес к машинному обучению, которое может помочь в деятельности SOC, но пока только в крупных центрах мониторинга. 
  • Треть высокоэффективных SOCов проводят тренинги персонала на ежемесячной основе, еще столько же - на ежеквартальной, а пятая часть - на еженедельной основе. Это очень необычно для многих российских SOCов (да и вообще служб ИБ), которые не всегда выполняют требования даже пятилетних циклов повышения квалификации для своих сотрудников. Но не нужно думать, что речь всегда идет только о внешних курсах обучения или повышения квалификации. Нередко SOCи проводят внутренние тренинги или онлайн-курсы. Интересно, что высокоэффективные SOC отдают предпочтение внутреннему обучению, в отличие от низкоэффективных, ориентированных на внешнее обучение.
  • Интересно отличие в части используемых метрик для больших (более 200 человек) или малых (до 24 человек) SOCов. Последние чаще всего используют время простоя ИТ- или бизнес-сервисов, а первые - число эскалированных инцидентов, время простоя ИТ-сервисов и время от обнаружения инцидента до реагирования и восстановления после него. При этом существуют отличия между тем, какие метрики предпочитают руководители ИТ или ИБ и аналитики SOC. Первым интересно число тикетов по инцидентам, а вторым - время простоя. 
  • Только 5% SOCов утверждают, что видят все, что им необходимо. К основным причинам, которые мешают SOCам видеть все, относят - legacy-приложения, которые не отдают события в SIEM, нехватка взаимодействия с владельцами сервисов/приложений, которые должны отдавать события безопасности, нехватка бюджета, а также нестандартизованные технологии (например, в процессе слияний и поглощений или неиспользующие стандарты).
  • В тройку основных направлений инвестиций для улучшения SOC входят - новые технологии, персонал и автоматизация.

23.07.2019

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

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

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

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

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

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


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

22.07.2019

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

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


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

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


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

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

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

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

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

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

19.07.2019

Модель зрелости 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), должны быть реализованы следующие платформы:


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

18.07.2019

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

17.07.2019

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

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

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


16.07.2019

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

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

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

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

15.07.2019

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

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

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


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


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

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

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


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


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


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

12.07.2019

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


11.07.2019

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

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






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

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



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

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

03.07.2019

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

Я уже обращался к теме экономики безопасности не один раз (последний - пару недель назад), но тема эта безгранична и поэтому я вновь вернуться к ней. Тем более и повод есть. Росс Андерсон пишет третье издание своего классического труда "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-го года.