Как мы моделируем угрозы. Часть 1.

Спасибо Алексею Лукацкому за попытку построить модель угроз удаленному доступу в соответствии с проектом методики ФСТЭК. Жалко, конечно, что он так и не сумел эту модель построить, увлекшись вместо этого поиском скрытых смыслов в проекте методики. Ладно, попробую довести заявленную им работу до конца 🙂 Будет много букв, так что основные выводы сформулирую здесь:

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

Но для начала давайте определимся, зачем вообще в парадигме ФСТЭК нужна модель угроз. В нормативных документах ФСТЭК, как и в большинстве современных фреймворков в области безопасности, используется гибридный подход к выбору мер защиты – сочетание baseline approach и risk-based approach. Начиная выстраивать защиту информационной системы, мы вначале по какому-то принципу определяем то, что некоторые комментаторы называют “гигиеническим набором мер защиты” – базовый набор, baseline. Это минимально необходимый набор мер защиты, который в идеале необходим большинству информационных систем.

В реальности базовый набор мер защиты в любом фреймворке определен вообще без учета специфики защищаемой информационной системы, и некоторые базовые меры защиты могут оказаться даже избыточными (нормативные документы ФСТЭК этим особенно грешат, но это – совсем другая история). С точки зрения основной задачи ИБ – защиты информационных систем – это не трагедия: задача защиты все же решается. Проблема в другом – в подавляющем большинстве информационных систем будут угрозы, от которых базовый набор мер защиты не спасает совсем или, что еще хуже, защищает не полностью, создавая лишь иллюзию защищенности. Поэтому базовый набор приходится тюнить — анализировать угрозы, специфичные для конкретной информационной системы, смотреть, защищает ли от них базовый набор мер защиты, и придумывать дополнительные решения, если все же не защищает. Все это описано в нормативных документах ФСТЭК – п. 21 приказа 17, п. 9 приказа 21, п. 23 приказ 239.

Что мы защищаем

OK, приступаем. Разумеется, построить модель угроз абстрактному “удаленному доступу” невозможно – можно защищать только определенные способы удаленного доступа к определенной инфраструктуре. Попробуем проделать это упражнение на предельно упрощенном примере. Есть умозрительная “наша организация”, которая в своей работе преимущественно использует софт от Microsoft. Отправляя коллег на удаленку, мы хотим, чтобы у них по возможности сохранилась привычная им среда обитания, и поэтому удаленный доступ включает в себя:

• доступ к корпоративной почте и телефонии – в нашем примере это будут Exchenge и Skype for Business через OWA;
• терминальный доступ к офисным компам и операционным системам серверов через RDG;
• доступ к внутренним веб-сервисам через VPN.

При такой организации работа из офиса и из дома для пользователя не отличается ничем (разве что при удаленной работе некоторые привычные приложения придется запускать в окошке терминальной сессии).
Для такой инфраструктуры у нас уже есть определенный baseline: сегментирование, фильтрация трафика на границах сегментов, WAFы перед внешними и внутренними веб-сервисами, идентификация, аутентификация и разграничение доступа на базе AD, endpoint-антивирусы на виндовых серверах и ПК, анализ событий по логам и на трафике (SIEM и анализаторы трафика соответственно). Осталось понять, от чего наши базовые меры защиты не защищают “из коробки” и что для этого нужно “докрутить”.

От чего защищаем

Как здравомыслящие люди, мы вполне способны сформулировать, чего именно опасаемся:

1. Для нас неприемлемо получение нарушителем доступа к переписке и телефонным звонкам наших сотрудников. При этом для нас одинаково неприемлемы и нарушение конфиденциальности, и пранк с телефонных номеров и адресов электронной почты нашей организации.
2. Для нас неприемлемо получение внешним нарушителем доступа к офисным ПК и серверам.
3. Для нас неприемлемы прекращение работы офисной инфраструктуры и блокирование удаленного доступа к ней.

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

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

“Лучшие собаководы” рекомендуют провести для указанных выше неприемлемых негативных последствий анализ рисков: сегрегировать пользователей по категориям “VIPы”, “значимые пользователи”, “на этих нам наплевать”, сегрегировать примерно по тому же принципу защищаемые объекты, оценить вероятности наступления негативных последствий для разных категорий объектов и выделить, что нужно защищать капитально, что – так себе, и чем не нужно заморачиваться совсем. Но мы – не собаководы, у нас нет десятка лет на анализ того, с какой информацией на каком защищаемом объекте какой пользователь работает, и мы не верим оценкам вероятностей, сделанным методом “пол-палец-потолок”. Поэтому мы руководствуемся простым принципом: если знаем, как именно нарушитель может причинить неприемлемый ущерб, то мы не будем гадать, захочет ли нарушитель этот ущерб причинить, а будем защищаться от этого “как именно”.

Для того, чтобы «докрутить» наш базовый набор мер защиты, нужно очень хорошо понимать, как именно нарушитель может добиться неприемлемых для нас негативных последствий. Например, получить доступ к переписке он может:

• получив админские права в домене;
• получив админские права на доступ к MS Exchange;
• получив в свое распоряжение логины и пароли какого-то значимого количества пользователей;
• получив контроль над рабочими местами этих пользователей внутри инфраструктуры;
• получив контроль над сервером OWA;
• получив контроль над терминальными сессиями пользователей;
• получив контроль над домашними компами или мобильными устройствами, с которых ведется переписка, и т.п.

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

Что по этому поводу говорится в методике ФСТЭК

Мы действительно защищаемся только от антропогенных угроз. Более того, мы защищаемся в основном только от сознательных действий злоумышленника и не рассматриваем отдельно ошибки пользователей или спонтанные техногенные события. Если человек что-то может сделать непреднамеренно, значит то же самое он может сделать и специально. Если человек может намеренно вывести их строя устройство или нарушить связь и если мы считаем себя достаточно защищенными от такой угрозы, то мы в той же мере защищены и от спонтанного выхода устройства из строя или от случайного обрыва связи. П. 1.3 методики говорит о том же самом и отторжения у нас не вызывает.

П. 2.1 предлагает нам сконцентрироваться на негативных последствиях как на отправной точке моделирования – и да, мы так и делаем.

Методика говорит, что результатом моделирования должен стать перечень угроз безопасности информации, которые могут быть реализованы в нашей инфраструктуре (п. 2.2). Понятие “угроза безопасности информации” определено в нормативке очень расплывчато (“совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации”, т.е. создающих опасность нарушения конфиденциальности, доступности и целостности информации). Такое определение абсолютно непригодно для работы: нам понятна угроза “получить привилегии enterprise admin’а”, но так как сделать это можно кучей разных способов, очень трудно сформулировать эту угрозу в терминах “нарушение КДЦ”. Да и фиг с ним – задача соблюдения буквы ФСТЭКовской методики для нас вторична: мы должны смоделировать угрозы, мы не должны нарушить требования методики, но при этом мы не обязаны слепо этой методике следовать. Значит, мы будем моделировать то, что называем угрозой мы сами (“получение привилегий enterprise admin’а”), а потом сделаем небольшой реверанс в сторону методики, добавив, что этой угрозе соответствует угроза безопасности информации “нарушение конфиденциальности, доступности и(или) целостности всей обрабатываемой информации”). Никакой пользы этот реверанс не принесет, но он несложен и не мешает решению основной задачи.

П. 2.3 определяет порядок моделирования, и да, этот порядок мы считаем совершенно правильным:

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

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

Особняком в п. 2.3 стоит “оценка уровня опасности угрозы” – еще одно, на мой взгляд, бесполезное (об этом в свою очередь), но ненапряжное действие.

П. 2.4 предписывает определить границы области моделирования угроз, и это понятно не всем. В нашем примере объектом защиты является только “узел доступа” – сервер OWA, сервер RDG и сервер VPN. Но, чтобы смоделировать угрозы, приходится охватить моделированием значительно большую часть инфраструктуры (включить в нее объекты удаленного доступа, телекоммуникационное оборудование, обеспечивающие компоненты (например, AD), а также собственные устройства сотрудников, которые для нас объектами защиты тоже не являются). Но при этом нам не обязательно охватывать всю инфраструктуру — на рисунке нет ни изолированных производственных сегментов, ни обособленных структурных подразделений, которые у организации могут быть, но которые для сценариев компрометации удаленного доступа оказались неинтересны.

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

П. 2.7 методики обращает внимание читателя на один важный момент: анализ угроз проводится “поверх” базовых мер защиты, но эти меры защиты не должны считаться априори блокирующими действия нарушителя. Фактически сценарий реализации угрозы – это последовательность действий, с помощью которых нарушитель потенциально способен обойти криво реализованные меры защиты, если, конечно, эти меры защиты вообще есть. Т.е. если у вас настроено временное блокирование учетных записей пользователей при обнаружении попыток подбора пароля — честь вам и хвала, но от активного подбора словарных паролей оно не защищает никак от слова “совсем”.

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

Опыт категорирования субъектами КИИ своих значимых объектов КИИ подтолкнул авторов методики к вопросу: что делать, если часть инфраструктуры, необходимой для функционирования системы, принадлежит ее владельцу, а остальная часть инфраструктуры – кому-то постороннему? Например, если вы арендуете мощности в “облачном» ЦОД, вы можете сколько угодно моделировать угрозы “своим” компонентам системы, но вы ровным счетом ничего не знаете о том, что может помешать нарушителю получить контроль над самим облаком. Опять же, как люди здравомыслящие, мы понимаем, что тут возможны только три варианта:

1. Поставщик может убедить нас, что рассмотрел все возможные сценарии получения нарушителем контроля над его ЦОД, что от всех этих сценариев его инфраструктура защищена и что с этой стороны нам опасаться нечего. Естественно, мы не поверим ему на слово и потребуем доказательств – мы же, все-таки, здравомыслящие люди.
2. Если мы не убеждены в защищенности чужой инфраструктуры, можно попробовать учесть в своих сценариях возможность того, что нарушитель контролирует используемый нами ЦОД, и защищаться от такого нарушителя самостоятельно. Почему бы и нет?
3. Если при этом мы не можем защититься от угроз со стороны ЦОД самостоятельно, значит – сюрприз! — защититься от этих угроз мы не можем. Придется или мириться с тем, что неприемлемые для руководства последствия все равно остаются возможными (и компенсировать это иными способами – страхованием, молитвой, припарками или любыми другими неИБшными способами), или искать доверенного поставщика услуг, или менять архитектуру системы.

Для нас это очевидно, а авторы методики решили прописать это прямым текстом в п. 2.10-2.12.

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