Как мы моделируем угрозы. Часть 3: техники и тактики

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

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

Аннотация угрозы: осуществление несанкционированного ознакомления, модификации и блокировки целевой информации, хранимой и обрабатываемой в ИС.

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

Способы реализации угрозы:

1) осуществление несанкционированного доступа, используя штатные средства ИС;

2) использование бесконтрольно оставленных технических средств;

3) хищение нарушителями и утрата уполномоченными лицами технических средств ИС (в том числе носителей информации);

4) несанкционированный просмотр средств отображения информации и распечатанных документов.

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

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

Чтобы решить эту проблему, ФСТЭК обязала операторов информационных систем руководствоваться формулировками угроз из БДУ:

Угроза заключается в возможности повышения нарушителем своих привилегий в дискредитированной системе (получения привилегии дискредитированных программ) путём использования ошибок в программах и выполнения произвольного кода с их привилегиями.

Данная угроза обусловлена слабостями механизма проверки входных данных и команд, а также мер по разграничению доступа.

Реализация данной угрозы возможна при условиях:

- обладания дискредитируемой программой повышенными привилегиями в системе;

- осуществления дискредитируемой программой приёма входных данных от других программ или от пользователя;

- нарушитель имеет возможность осуществлять передачу данных к дискредитируемой программе

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

Как мы это делаем

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

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

1. Initial Access: "первичное проникновение", возможность хоть как-то дотянуться до элементов атакуемой инфраструктуры. Способы ("техники" в терминах Att&CK) могут быть разными, от использования общедоступного уязвимого внешнего интерфейса до социальной инженерии и подключения к инфраструктуре собственных устройств.
2. Execution: возможность хоть каким-нибудь способом заставить атакуемый элемент инфраструктуры выполнить хоть какие-то из нужных нарушителю действий. Техники, опять же, могут быть очень разными, от использования готового интерфейса командной строки до инфицировани узла вредоносным ПО.
3. Persistence: возможность сохранить присутствие в атакованной инфраструктуре даже после того, как будет перезагружен атакованный узел, будут найдены и уничтожены некоторые внедренные инструменты и т.п. Техники... - ну, вы поняли.
4. Privilege Escalation: если Execution - выполнение хоть каких-то действия, то здесь нарушитель старается "добрать" недостающие ему возможности.
5. Defense Evasion: противодействие противодействию. Жертва может использовать различные приемы обнаружения и блокирования действий нарушителя, и тот старается их обойти.
6. Credential Access, в реальности - одна из ключевых тактик, включает в себя различные способы перехвата, восстановления, подбора или повторного использования паролей, ключей, аутентификационных токенов и т.п. Если нарушителю удается получить контроль хоть над каким-то узлом инфраструктуры, эта тактика всегда заканчивается получением учетки enterprise admin'а - таковы суровые реалии современной ИБ.
7. Discovery: сбор любой возможной информации, которая может быть полезна для успешного начала или развития атаки. Сюда входят и анализ общедоступной информации инструментами OSINT, и вдумчивое изучение "внутренностей" успешно атакованных элементов инфраструктуры.
8. Lateral Movement: "расползание" по атакованной инфраструктуре, расширение своего присутствия. "Захватывай все, до чего можешь дотянуться - потом посмотрим, как это использовать". По применяемым техникам - то же самое, что и Initial Access, но только после успешного преодоления периметра, когда возможностей для "захвата" внутренних элементов инфраструктуры гораздо больше.
9. Command and Control, задача, смежная с Persistence: обеспечить удаленное управление контролируемыми узлами инфраструктуры, а в некоторых случаях - возможность "поработать руками" на узле, к которому у нарушителя не должно было бы быть удаленного доступа.
10. Collection, Exfiltration, Impact, финальные штрихи успешной атаки: сбор интересующей нарушителя информации (и ее выгрузка наружу, что, с учетом ее объемов, может оказаться совсем нетривиальной задачей), а также всевохможные деструктивные действия.

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

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

1. в приложении в какой-то момент может присутствовать уязвимость, которая позволит нарушителю внедрить в CMS собственный модуль;
2. в приложении в какой-то момент может присутствовать уязвимость, которая позволит нарушителю выполнить команду ОС, SQL-запрос или собственный скрипт;
3. в приложении в какой-то момент может присутствовать уязвимость, которая позволит нарушителю выполнить собственный скрипт в браузере пользователя;
4. в приложении в какой-то момент может присутствовать уязвимость, которая позволит нарушителю выгрузить чувствительную информацию, например - хеши паролей пользователей или, не дай Бог, сами пароли открытым текстом;
5. в приложении в какой-то момент может присутствовать учетная запись пользователя со словарным паролем (или с паролем, который был успешно получен в результате атаки на другой элемент инфраструктуры) и т.п.

Так как при моделировании угроз мы не фантазируем, а ограничиваемся известными атакующими приемами, то для каждого элемента инфраструктуры, в зависимости от его роли, есть определенный перечень применимых к нему техник: свой набор техник есть для атак на веб-интерфейсы, на беспроводные сети, на сетевую инфраструктуру, на домен MS AD, на рабочие места пользователей с использованием социальной инженерии и без нее и т.п. Понятие "техника" включает в себя:

1. Определенный, пригодный для этой техники класс уязвимостей, которые могут присутствовать в информационной системе "от рождения" или могут появиться в ходе эксплуатации. Причем формулировка "могут появиться" - скорее дань политкорректности: вероятность появления таких уязвимостей напрямую зависит от уровня пофигизма, присущего IT-индустрии на всех стадиях жизненного цикла информационных систем, и сейчас честнее было бы говорить "неизбежно появятся, рано или поздно".
2. Определенные приемы, применяемые нарушителем. Т.е., когда мы говорим "протокол STP позволяет перенаправлять и перехватывать трафик", речь идет не о теоретической возможности, а о вполне определенной последовательности действий, которую можно продемонстрировать.
3. Определенные последствия, в том числе - получение нарушителем определенных возможностей. Опять же, когда мы говорим "доступность протокола STP АРМам пользователей - это плохо", это означает вполне конкретные последствия: нарушитель может перехватывать трафик (и это дает ему возможность применять "пассивные" техники, основанные на анализе трафика) или, при неосторожном применении техники, капитально "уронить" ядро сети.
4. Определенные следы, которые оставляет применение этой техники и по которым ее применение можно обнаружить - в момент атаки или в ретроспективе. Именно поэтому в нормативных документах ФСБ обнаружением атак называется не применение IDS, а комплекс действий по анализу разнородных событий с привязкой их к определенным техникам.
5. Определенные "точечные" меры противодействия. Не абстрактные "поставьте SIEM", "анализируйте программный код", "управляйте конфигурацией", а "настройте вот такие корреляции", "следите, чтобы в коде не появлялись вот такие конструкции" и "бейте админа по рукам при попытке изменить вот эти параметры".

При моделировании угроз на уровне техник появляется возможность оценивать достаточность применяемых мер защиты уже на стадии разработки ТЗ. Вы написали, что должна обеспечиваться аутентификация пользователей по паролям с вот такими требованиями к минимальной политикой сложности? Этого недостаточно: извольте дописать в ТЗ требования к защите парольной информации в процессе хранения, к защите аутентификационной информации в процессе ее передачи и использования, к мерам обнаружения попыток активного подбора паролей, к защите от задания слабых/словарных паролей пользователями и администраторами и так далее. Иногда коллеги возражают: мол, все эти технические подробности исполнитель должен придумать и сформулировать сам. Такое возражение вызывает только недоумение: если такие технические подробности исполнитель должен определять сам по своему усмотрению, то зачем вы вообще тратили свое и его время на написание и согласование банальностей про необходимость аутентификации или управления доступом? Основное назначение ТЗ - не дать разработчику "сэкономить", отказавшись от реализации действительно нужных вам фич, и чем абстрактнее требования - тем лучше для него и тем хуже для вас.

Как именно мы разрабатываем модели угроз на уровне техник, расскажу в следующий раз, но основные принципы нетрудно понять и без этого. К моменту написания ТЗ на создание системы разработчик, а часто - и заказчик тоже, уже в общих чертах представляют, из каких компонентов система будет состоять, как будут реализованы основные ее функции, какой софт будет использоваться на каждом из компонентов, в какой инфраструктуре все это будет обитать т.п. Уже в этот момент для каждого из будущих компонентов информационной системы и для каждого существующего элемента инфраструктуры можно определить, какие техники потенциально к ним применимы и что нарушитель может получить, атаковав этот объект. Для информационной системы это можно сделать для каждого компонента отдельно, для инфраструктуры - сгруппировав элементы по типам ("виндовые АРМ", "линуксовые АРМ", "коммутаторы Cisco/Huawei", "узлы с веб-интерфейсами" и т.п.). Это, в свою очередь, позволяет определить "до вот таких узлов я могу дотянуться снаружи или со своего рабочего места" (т.е. определить возможные стартовые точки сценария) и "контролируя узел А, я могу дотянуться до узлов Б, В и Г" (т.е. возможные пути продвижения по инфраструктуре, включая компоненты информационной системы, для которой моделируются угрозы). Результатом становится граф атак, который определяет все возможные пути реализации угрозы и, что гораздо важнее, "точечные" меры защиты, которые помешают нарушителю двигаться по любому из этих путей. Основная хитрость - как сделать описание этого графа максимально компактным и максимально полезным, но об этом, опять же, в следующий раз.

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

Да, раздел 6 написан на основе MITRE Att&CK. В нем определены те же тактики, что и в матрице Enterprise ("Credential Access" не выделена в отдельную тактику, а "Collection" и "Exfiltrarion" объединены). Подробное описание техник в документ включать не стали - участники сошлись во мнении, что "прибивать гвоздями" описание техник к нормативному документу, который потом не так-то просто изменить - плохая идея. Гораздо правильнее вместо этого переделать БДУ, включив в нее подробное описание техник и исправив недостатки, свойственные Att&CK. Но так как доработка БДУ - вопрос времени, в документ включили обобщенное перечисление техник, которое уже при моделировании угроз каждый вправе самостоятельно детализировать. При этом можно использовать любые общедоступные ресурсы и собственные знания предметной области - например, мы в своей работе используем довольно много техник, которые в Att&CK даже не упоминаются.

В методике говорится о том, что при моделировании угроз нужно рассмотреть максимально возможное количество сценариев. Почему? Для того, чтобы продемонстрировать актуальность угрозы, достаточно ограничиться очевидными сценариями ее реализации (социалка на пользователей системы, вербовка администратора системы и т.п.). Но дальше-то что? Если мы предлагаем меры защиты, то нужно показать, что этих мер защиты достаточно. "Мы рассмотрели все известные нам возможности реализации угрозы и ни одну из них использовать не получится" - вполне себе демонстрация достаточности, а уровень доверия к этой демонстрации определяется квалификацией исполнителя. Доработка БДУ позволит исключить субъективизм в выборе применимых техник, а пока стоит руководствоваться простым принципом: выбирайте исполнителя, который умеет примерно то же, что умеет ваш потенциальный противник. Не нужно переплачивать, если все, чего вы боитесь - это тупой DDoS LOIC'ом, и стоит трижды задуматься, прежде чем звать неопытного интегратора в моделирование APT-атак.

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

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

Почему не MITRE

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

База знаний MITRE Att&CK в каком-то смысле иллюстрирует "систематическую ошибку выжившего" - она отражает прежде всего те техники, которые используются в реальных ставших известными инцидентах. Подавляющее большинство широко известных инцидентов получают ту самую широкую известность благодаря усилиям антивирусных вендоров, и создается ощущение, что ключевым элементом успешных действий преступных группировок является использование вредоносного ПО. Но так ли это? Мы не можем ответить на этот вопрос, так как инцидентов, не связанных с использованием ВПО, известно крайне мало. Но если наши парни в ходе пентестов умудряются получать полный контроль над инфраструктурой заказчика без единого выстрела применения экмплойтов, то логично предположить, что то же самое умеют делать и криминальные группировки.

В матрице техник Att&CK перекос в сторону ВПО виден невооруженным взглядом - под внедрение кода целиком заточены четыре из двенадцати тактик (Execution, Persistence, Defense Evasion и Command and Control). В то же время, например, техники проникновения в инфраструктуру крупных энтерпрайзов через косяки в настройках беспроводной сети в матрице Enterprise отсутствуют вовсе (приходится объединять матрицы Enterprise и Mobile), а все многообразие техник получения доступа к информационным системам через уязвимости веб-приложений представлено абстракцией "Exploit Public-Facing Application" (куда включены вообще все способы удаленной эксплуатации уязвимостей).

Поэтому приходится использовать полезную информацию и удачные идеи из всех доступных источников, и Att&CK - только один из них.

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

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

Радикальные изменения требований ФСТЭК к значимым объектам КИИ

"Тем временем в замке у Шефа": ФСТЭК опубликовала проект изменений в приказ 239, доработанный по итогам общественного обсуждения. Их немного, но картину мира они меняют капитально.

29.2. Средства защиты информации, оценка соответствия которых проводится в форме испытаний или приемки, должны соответствовать требованиям к функциям безопасности, установленным в соответствии с подпунктом «ж» пункта 10 настоящих Требований.

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

На всякий случай подчеркиваю: сертификация и самостоятельные испытания могут проводиться на соответствие самым разным требованиям. Так, WAF как наложенное средство защиты, обычно сертифицируется на соответствие требованиям профиля защиты "Межсетевые экраны типа Г" (точнее, задания по безопасности, написанного на его основе). Если в реальных условиях эксплуатации ЗОКИИ требуются функции безопасности, не отраженные в таком задании по безопасности, то субъект КИИ должен самостоятельно убедиться, что WAF выполняет необходимые ему функции безопасности. Сертификат в этом случае его не прикрывает.

Идем дальше.

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

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

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

Это - очень суровое требование. Требования к уровням доверия установлены в двух ДСПшных документах ФСТЭК. Подробно останавливаться на них не буду, отмечу только самое основное:

1. Для проведения самостоятельных испытаний субъект КИИ должен получить у разработчика проектную документацию на испытываемую софтину или железку (описание архитектуры, функциональную спецификацию и т.п.)
2. В ходе испытаний необходимо провести анализ 0day-уязвимостей. Как минимум требуется провести фаззинг-тестирование, поиск уязвимостей в архитектуре решения на основе анализа предоставленной документации и протестировать продукт на применимость к нему техник MITRE Att&CK или CAPEC

Говоря проще, самостоятельные испытания средства защиты субъектом КИИ в новой редакции приказа 239 - это практически та же сертификация, но с некоторыми отличиями:

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

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

• требования по безопасной разработке программного обеспечения;
• требования к испытаниям по выявлению уязвимостей в программном обеспечении;
• требования к поддержке безопасности программного обеспечения.

Это - наверное, самое суровое требование. Обратите внимание: оно относится не к средствам защиты, а к прикладному софту ЗОКИИ, даже если в нем не реализованы функции безопасности. Дальше в проекте приказа эти требования раскрываются подробно. Цитировать не буду - их много, желающие могут ознакомиться с точным текстом сами (п. 29.3.1-29.3.3). Остановлюсь на самом важном:

1. Для прикладного софта, который будет применяться на вновь создаваемом или модернизируемом ЗОКИИ необходимо проводить статический анализ исходных кодов (для ЗОКИИ первой категории - еще и динамический. Подчеркиваю: для средств защиты достаточно фаззинга, для прикладного софта нужен еще, как минимум, статанализ. Это логично: информационные системы ломают через уязвимости прикладного софта, а не средств защиты, - но подобное изменение многим порвет шаблон напрочь.
2. В силу п. 1 на ЗОКИИ может внедряться софт только тех вендоров, которые будут готовы предоставлять своим заказчикам исходные коды своих программ.

По сравнению с этим остальные изменения выглядят незначительными:

• Определено, что считается модернизацией ОКИИ
• Расширен перечень лиц, которым разрешено удаленное и бесконтрольное локальное обновление компонентов ЗОКИИ и управление ими. В новой редакции к ним отнесены:

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

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