Как мы моделируем угрозы. Часть 2: негативные последствия, угрозы, техники

“По понятиям”

На время отвлечемся от очевидного для околоайтишной аудитории удаленного доступа и поговорим об угрозах и их последствиях.

Довольно часто мы произносим и пишем повседневные выражения и жаргонизмы, не задумываясь над их смыслом. Например, “обеспечить информационную безопасность” или, как теперь принято писать в нормативке, “обеспечить безопасность информации”. В теории (ГОСТ 50922):

• угроза безопасности информации – это “совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации”;
• безопасность информации – это “состояние защищенности информации [данных], при котором обеспечены ее [их] конфиденциальность, доступность и целостность”.

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

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

Чтобы не путаться в этой каше, приходится разделять понятия:

• То, чего опасается заказчик, мы называем негативными последствиями (или, если у заказчика своя терминология – “рисками”, “ущербами” и т.п., лишь бы самому заказчику это было понятно).
• То, что может непосредственно привести к такому последствию (попадание в АБС фальшивой платежки, прекращение работы веб-сервиса, попадание в долговременную память контроллера битой прошивки) мы называем угрозами.
• Действия, которые могут позволить нарушителю добраться до целевого объекта и нанести coup de grâce реализовать угрозу, мы по аналогии с MITRE называем техниками. Да, став enterprise admin’ом, нарушитель может проделать с нами все, что ему будет угодно. Но само по себе получение таких привилегий к реализации угрозы не приводит – это только одна из техник, которую он применяет на пути к своей цели.
• Мы не привязываем угрозы к нарушениям КДЦ, потому что для моделирования угроз это не нужно. Но если заказчику хочется продемонстрировать буквальное соответствие того, что он делает, нормативным документам ФСТЭК, можем для каждой угрозы указать, что она приводит к полному или частичному нарушению конфиденциальности, доступности и/или целостности.

Определение негативных последствий

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

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

Такой подход хорошо себя зарекомендовал в тестах на проникновение, и с некоторыми изменениями он работает и в моделировании угроз. И тут есть два варианта. Идеальный вариант – это когда в организации уже выстроены процессы менеджмента рисков, есть владельцы продуктов и они в курсе релевантных для этих продуктов рисков. Можно прийти в операционный департамент банка и выяснить, что да, кражи денег из кассет банкоматов возможны, но банку на это наплевать: шесть миллионов остатка в кассетах среднестатистического банкомата - это не та сумма, по которой банк будет горько плакать. Говорите, можно одновременно опустошить сразу несколько банкоматов и даже сразу все? Не знаем, не задумывались – но готовы задуматься, если продемонстрируете, как такое возможно.

Сложнее второй вариант, когда у организации есть только общее понимание своих бизнес-рисков, и эти риски совсем не транслируются на информационные системы. Так, в одном из проектов, связанных с железнодорожной автоматикой, заказчик так и не смог внятно сформулировать, к чему же именно может привести получение нарушителем полного контроля над системой управления объектом. Пришлось рассматривать перечень нарушений безопасности железных дорог, установленный приказом еще Министерства Путей Сообщения в 1994 году – к таким нарушениям относятся “прием поезда на занятый путь”, “перевод стрелки под подвижным составом”, “ложное появление разрешающего показания на напольном светофоре” и т.п. Такие формулировки заказчику оказались понятны, он их подтвердил и даже дополнил своими собственными. Обладая даже минимальными знаниями об устройствах железнодорожной автоматики, уже можно ставить задачу исследователям – понять, что именно нужно проделать с АСУ, чтобы определенное устройство не в то время и не в том месте получило не то управляющее сообщение.

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

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

От опасностей к техникам

Итак, от понятного нашему руководству “получения доступа к переписке” нам нужно перейти к понятным технарям угрозам и техникам. Удаленный доступ – штука очевидная, перечень возможных угроз и целевых для нарушителя объектов я в прошлый раз привел. Но это только в очевидном примере удаленного доступа все легко и просто, а в более сложных случаях приходится потрудиться.

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

Как именно нарушитель может манипулировать лимитом электронного кошелька? Если бы речь шла о готовой системе – можно было бы позвать специалистов и провести ее лабораторные исследования. А как быть, если система еще только создается? Есть несколько источников, которые могут дать нам полезную информацию:

• Микропроцессорная карта – это стандарт EMV. По этому стандарту наработана большая практика технических решений, а для них – описания типовых косяков “вот так делать нельзя ни в коем случае” в статьях, руководствах и учебниках. На этой стадии мы пока не знаем, каких ошибок наделают разработчики системы и какие из них дойдут до релиза – но знаем, что такие ошибки могут быть, и среди них могут быть такие, которые позволят менять лимит кошелька непосредственно в микропроцессоре карты.
• Заказчик хочет, чтобы электронным кошельком можно было расплачиваться даже при отсутствии связи между кассой и процессингом. Это значит, что кассовый терминал имеет легитимную возможность изменять лимит на карте, и ей можно воспользоваться, если получить контроль над терминалом. Терминал – это обычный компьютер под управлением операционной системы X, а способов получить контроль над ней при наличии физического доступа – тьма тьмущая.
• В нормальных условиях кассовый терминал получает управляющие сообщения из процессинга. Например, если держатель карты пополнил баланс переводом средств с банковского счета, карта может узнать об этом только от кассового терминала, а терминал – от процессинга. В протоколе взаимодействия терминала с процессингом возможны ошибки – а значит возможны ошибки, позволяющие нарушителю заставить кассу увеличить лимит на карте, считая, что таково распоряжение процессинга.

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

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

Что по этому поводу говорит методика

П. 3.1 говорит, что нужно определять негативные последствия, от которых придется защищаться. Эти негативные последствия могут быть навязаны законодательством (например, оператор общедоступных персональных данных обязан считать неприемлемым несанкционированное изменение этих данных, даже если самому ему на это глубоко наплевать) или определяться владельцем системы самостоятельно.

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

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

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

Если не заниматься буквоедством, то п. 3.3 говорит о том, что при моделировании угроз нужно очень внимательно посмотреть на инфраструктуру и выделить в ней все элементы, воздействием на которые можно вызвать негативные последствия. Если буквально, то нужно выделить элементы, участвующие в основных технологических процессах организации, и уже для этих объектов определять возможные негативные последствия от вмешательства нарушителя в работу этих объектов. Чтобы увидеть в этой формулировке обязанность применять ко всем элементами инфраструктуры всю матрицу Att&CK, на мой взгляд, нужна очень богатая фантазия и творческая интерпретация текста.

П. 3.4 говорит, что требуется получить в качестве результата определения негативных последствий:

• перечень таких последствий;
• для каждого последствия – перечень объектов, воздействием на которые можно этого последствия добиться;
• для каждого объекта – какими именно воздействиями на него можно этого последствия добиться.

Именно это мы обычно и делаем :)

Как мы моделируем угрозы. Часть 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.

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