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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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