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

Что ожидать от судебной практики по статье 274.1 УК РФ

Прогнозировать судебную практику - занятие неблагодарное, но иногда это удается с высокой степенью уверенности в результате. Субъекта КИИ в первую очередь интересует, кто и в каком случае может быть привлечен к ответственности по ч. 3-5 статьи 274.1 УК РФ ("Неправомерное воздействие на критическую информационную инфраструктуру Российской Федерации").

Для события преступления по этим составам требуется два фактора: должен быть причинен вред КИИ и причиной этого вреда должно являться невыполнение виновником правил эксплуатации "средств хранения, обработки или передачи охраняемой компьютерной информации, содержащейся в КИИ". КИИ определена в ФЗ-187 как совокупность объектов критической информационной инфраструктуры и сетей электросвязи, используемых для организации взаимодействия таких объектов. Соответственно, причинение вреда любому объекту КИИ будет причинением вреда КИИ в целом.

Рассматриваемую предметную область можно охарактеризовать так:

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

Статистически значимой судебной практики по применению этой статьи нет и в ближайшее время не предвидится. Но есть статья 274 УК РФ ("Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей"), которая на первый взгляд полностью аналогична и по которой судебная практика есть. Вот что говорится о ней в методических рекомендациях Генеральной Прокуратуры РФ:

• "Предметом данного преступления являются средства хранения, обработки или передачи охраняемой компьютерной информации, информационно-телекоммуникационные сети и оконечное оборудование." Тут все понятно: для события преступления требуется, чтобы вред был причинен воздействием на техническую составляющую объекта.
• "Данная норма является бланкетной и отсылает к конкретным инструкциям и правилам, устанавливающим порядок работы со средствами хранения, обработки или передачи охраняемой компьютерной информации, информационно-телекоммуникационными сетями и оконечным оборудованием в ведомстве или организации." Т.е. не существует абстрактных, по умолчанию всем известных правил - нарушить можно только требования конкретных документов.
• "Эти правила должны устанавливаться правомочным лицом." Тут тоже понятно: никто не обязан выполнять предписания лица, которое никто такими полномочиями не наделял. В зачет идут только требования, установленные уполномоченным лицом.
• "Между фактом нарушения и наступившим существенным вредом должна быть установлена причинная связь, а также доказано, что наступившие последствия являются результатом нарушения правил эксплуатации... Правила, о которых идет речь в ст. 274 УК РФ, должны быть направлены только на обеспечение информационной безопасности.". Очевидно.
• "Правила доступа и эксплуатации, относящиеся к обработке информации, содержатся в различных положениях, инструкциях, уставах, приказах, ГОСТах, проектной документации на соответствующую автоматизированную информационную систему, договорах, соглашениях и иных официальных документах." Т.е. нарушением правил эксплуатации считается нарушение вообще любых обязательных к исполнению требований, в каких бы документах и нормативных актах они ни содержались.

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

Пересказывая чужое мнение, люди склонны опускать или искажать незначительные, по их мнению, подробности. Так, в учебных пособиях понятие "правила эксплуатации" пересказывается более простым языком и, к примеру, студентам Университета прокуратуры РФ преподносятся так:

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

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

Второй фактор - ничтожно малое количество случаев применения статьи 274 УК РФ: по данным Судебного департамента при ВС РФ, за 2017-2018 годы всеми судами РФ вынесено 2 (прописью "Два") приговора, причем в обоих случаях эта статья являлась дополнительной к основному деянию. По другим источникам (спасибо Валерию Комарову), в 2010-2017 годах правоохранительными органами было возбуждено всего 21 уголовное дело с квалификацией деяния по этой статье. Поэтому, говоря о судебной практике по нарушениям правил эксплуатации, мы имеем дело со статистически ничтожной выборкой, в которую попали, в основном, уголовные дела по преступлениям против коммерческих компаний, возбужденные по заявлению их владельцев. Для квалификации деяния было достаточно того, что нарушены внутренние правила потерпевших.

В КИИ, применительно к значимым объектам, мы имеем принципиально иную ситуацию: есть ряд правовых норм, которые определяют обязанности субъекта КИИ в ходе эксплуатации значимого объекта КИИ - см. например, раздел 13 приказа ФСТЭК №239. Возникает вопрос: что будет, если причиной резонансного инцидента на значимом объекте КИИ станет игнорирование требований регулятора?

Судебная практика по статье 274 УК РФ нам тут не помощник, но есть другая предметная область, обладающая точно такими же характеристиками - пожарная безопасность:

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

В обзоре судебной практики мы видим, что Пленум ВС РФ трактует понятие "правила пожарной безопасности" точно так же, как Генпрокуратура - понятие "правила эксплуатации":

Как известно, диспозиция этой статьи является бланкетной. Законодатель не раскрывает в ней понятия "правил пожарной безопасности" и отсылает нас к нормам специального законодательства. При этом в Федеральном законе "О пожарной безопасности" один из видов нормативных документов в этой области называется "правилами пожарной безопасности". В то же время этим Федеральным законом отнесены к нормативным документам по пожарной безопасности стандарты, нормы, инструкции и иные документы, нарушение которых при наступлении указанных в диспозиции ст. 219 УК РФ последствий влечет уголовную ответственность.

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

Говоря проще, если п. 13.2 и 13.3 приказа ФСТЭК №239 требуют от субъекта КИИ проводить периодический анализ уязвимостей и выполнять управление обновлениями, то невыполнение этих требований в случае успешной атаки на объект КИИ вируса-шифровальщика станет самостоятельным уголовным преступлением, ответственность за которое лежит на субъекте КИИ. И тут возникает интересный вопрос: кто именно эту ответственность понесет?

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

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

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

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

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

Профиль защиты автоматизированных банковских систем и приложений

Начало тут...

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

Кредитные организации должны обеспечить использование для осуществления банковских операций прикладного программного обеспечения автоматизированных систем и приложений, распространяемых кредитной организацией клиентам для совершения действий в целях осуществления банковских операций, а также программного обеспечения, обрабатывающего защищаемую информацию на участках, используемых для приема электронных сообщений, к исполнению в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети "Интернет" (далее - сеть "Интернет"), сертифицированных в системе сертификации Федеральной службы по техническому и экспортному контролю на соответствие требованиям по безопасности информации, включая требования по анализу уязвимостей и контролю отсутствия недекларированных возможностей, или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия (далее - ОУД) не ниже чем ОУД 4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013

В формулировке этого требования есть, как минимум, два неясных момента:

1. Какие именно автоматизированные системы и приложения имеются в виду?
2. В чем именно должен заключаться анализ их уязвимостей?

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

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

Во вторую категорию однозначно попадают толстые клиенты систем ДБО и мобильные платежные приложения. В третью однозначно попадают интеграционные приложения, непосредственно получающие электронные платежные сообщения от клиентов и контрагентов банка. А вот дальше начинаются неясности:

• Попадают ли в первую категорию все автоматизированные банковские системы, используемые в платежных процессах банка? Некоторые комментаторы считают, что в эту категорию попадают только фронтэнды АБС, непосредственно доступные из сети Интернет, хотя из формулировки это никак не следует.
• Относятся ли куда-нибудь скрипты веб-интерфейса ДБО, исполняемые в браузере клиента?
• Относится ли это требование к программному обеспечению банкоматов?

С анализом уязвимостей по ОУД4 тоже все непросто, так как ГОСТ 15408-3 никакой конкретики по этому поводу не содержит: оценщик должен как-нибудь поискать потенциальные уязвимости и точка.

Частичную ясность вносит проект профиля защиты для прикладного программного обеспечения автоматизированных систем и приложений, который уже дважды рассматривался в техническом комитете №122 и который ЦБ намеревается принять до конца этого года. Профиль защиты - это специализированный документ, разработка которого предусматривается Общими Критериями для тех случаев, когда нужно установить какие-то единые требования для определенного вида информационных систем или средств защиты. Документ объемный (более 150 страниц), его чтение требует навыка работы с Общими Критериями, и, к сожалению, требования таких документов не всегда правильно интерпретируются неспециалистами.

Что подпадает под действие профиля защиты

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

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

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

И, наверное, также стоит подчеркнуть, что определение объекта оценки, данное в профиле, не уточняет область действия положений Банка России. Если в положении Банка России говорится об АБС, используемых в платежном процессе, а в профиле защиты - о фронтэндах этих АБС, то это означает только то, что профиль применим лишь к части области действия положений ЦБ.

Что такое "функциональные требования безопасности" и почему они такие странные

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

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

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

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

ФБО должны обнаруживать, когда произойдет [выбор: [назначение: положительное целое число]; устанавливаемое администратором положительное целое число в пределах [назначение: диапазон допустимых значений] ] неуспешных попыток аутентификации, относящихся к [назначение: список событий аутентификации].

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

После того, как разработчик сделает выбор и назначения, требование может, например, принять вид: "ФБО должны обнаруживать, когда произойдут три неуспешные попытки аутентификации, относящиеся к некорректному вводу имени пользователя или некорректному вводу пароля пользователя", - и уже в таком виде попасть в задание по безопасности.

Анализ уязвимостей в соовтетствии с профилем защиты

Как человека, зарекшегося заниматься сертификацией (спасибо нашей команде сертификаторов, успешно справляющимся с этой задачей), меня больше интересует, как в профиле защиты раскрывается вопрос анализа уязвимостей. Напомню, нормативные документы ЦБ ссылаются на ГОСТ 15408-3, а в этом документе ничего вразумительного по этому поводу нет. Зато есть в профиле защиты - за это отвечают три компонента доверия:

• "ADV_ARC.1 Описание архитектуры безопасности"
• "ADV_IMP.2 Полное отображение представления реализации ФБО"
• "AVA_VAN.5 Усиленный методический анализ"

Причем основная ценность профиля защиты даже не в самих этих компонентах доверия (они, как положено, просто скопированы из ГОСТ 15408-3), а в замечаниях к их применению.

Как я уже писал ранее, компонент доверия ADV_ARC.1 требует, чтобы разработчик продемонстрировал, что объект оценки защищен от вмешательства нарушителя в момент своего запуска (элемент ADV_ARC.1.3C) и в ходе своей работы (элемент ADV_ARC.1.4C), а также что нарушитель не может обойти механизмы защиты (элемент ADV_ARC.1.5C). Для этого разработчик должен самостоятельно провести анализ уязвимостей своего продукта и предоставить его результаты оценщику). В тексте ГОСТ 15408-3 прямого указания на это нет, поэтому в профиле защиты, в замечаниях к применению этого компонента доверия, дана явная ссылка на пункт 10.3.1 ГОСТ 18045, где подробно описывается, что как именно должны быть обоснованы невмешательство и невозможность обхода.

Компонент доверия ADV_IMP в исходном тексте Общих Критериев не определен ("Общее руководство отсутствует; за консультациями по выполнению данного подвида деятельности следует обращаться в конкретную систему оценки." - ГОСТ 18045, п. 10.5.2), поэтому в профиле защиты он определен "с нуля" замечаниями по применению. Если вкратце, от разработчика (именно от разработчика, не от оценщика) требуется:

1. Провести code review
   • Убедиться, что программный код соответствует стандартам качества, установленным разработчиком.
   • Убедиться, что код полностью документирован
   • Убедиться, что отдельные программисты не пытались включать код явные недекларированные возможности и не пытались обфусцировать код там, где обфускация не была санкционирована руководством
2. Провести статический анализ кода с использованием автоматизированных средств
• Убедиться в том, что проводится проверка корректности входных данных
• Убедиться в отсутствии типовых ошибок программирования
• Убедиться в отсутствии захардкоженных логинов и паролей

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

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

• Провести анализ известных уязхвимостей, опираясь на БДУ ФСТЭК, CVE, бюллетени вендоров, уведомления ФинЦЕРТ и т.п.
• Провести анализ типовых уязвимостей веб-интерфейсов методом "черного ящика"
• Провести динамический анализ кода, ориенртируясь на выявление типовых уязвимостей, предусмотренных классификатором CWE
• Провести тестирование на проникновение (при этом определен минимально-необходимый состав проверок, включающий в себя как внешний, так и внутренний пентесты

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

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

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

Во всяком случае, вариант "раз в год звать прентестеров, чтобы проверили наш код" однозначно нерабочий. Во-первых, результаты одиночной проверки протухнут при следующем же релизе, а во-вторых, даже с учетом фрилансеров, даже при такой низкой интенсивности проверок исполнителей на территории РФ не хватит даже на одну только банковскую сферу.

Анализ уязвимостей в ГОСТ 15408

И еще раз (а может, еще и не раз) вернемся к вопросу о том, что такое "анализ уязвимостей в соответствии с требованиями ОУД4 ГОСТ 15408-3". А точнее, о том, что делать банкам с самостоятельно разработанными приложениями.

Прежде всего стоит обратить внимание на то, что сам по себе ГОСТ 15408 никак не определяет, в чем именно должен заключаться анализ уязвимостей. В ОУД4 за него отвечает компонент доверия AVA_VAN.3, который говорит, что должен посмотреть оценщик (документацию, внешние источники на предмет наличия в продукте уже известных уязвимостей и исходный код на предмет зеродеев, но ничего не говорит о том, как что именно и как именно оценщик должен искать. Более полное описание содержится в дополнении к ГОСТ 15408 - в стандарте ГОСТ 18045 "Методология оценки безопасности информационных технологий". Итак, в чем именно заключается анализ уязвимостей по версии "Общих критериев"?

1. Оценщик должен изучить открытые источники и выяснить, нет ли в исследуемом продукте известных потенциальных уязвимостей. Очень часто это воспринимается как "давайте посмотрим в CVE, нет ли там известных уязвимостей для продукта", и это неверно. В методологии четко оговаривается, что речь идет об открытых материалах (книгах, статьях, материалах конференций), в которых описываются потенциально возможные уязвимости информационной технологии, реализованной в продукте. Так, если речь идет о веб-приложении (а к им относятся практически все фронтэнды ДБО и мобильного банкинга), то основным открытым источником для оценщика должен стать OWASP, а потенциальными уязвимостями - SQL-инъекции, XSS и весь прочий зверинец типовых уязвимостей веб-приложений. Т.е. речь на этом шаге оценки идет прежде всего о типовых уязвимостях и типовых ошибках разработки, характерных для технологии, а не только об отдельных идентификаторfх CVE.

2. Оценщик должен изучить весь объем проектной документации, которую ему обязан предоставить разработчик. При этом он должен убедиться, что в этой документации, как минимум - на бумаге, отсутствуют те самые типовые уязвимости и ошибки разработки, характерные для технологии. Уже на этом шаге оценки вполне нормально получить от оценщика замечание: "Парни, вы пишете, что данные передаются по простому HTTP - фу-фу-фу, это бяка, нельзя так делать!"

Кроме того, оценщик должен провести анализ исходного кода продукта (т.н. "представление реализации") в поисках зеродеев.

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

• демонстрацию того, что невозможно прямое несанкционированное вмешательство нарушителя в работу продукта;

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

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

3. Выявленные уязвимости оценщик должен верифицировать (провести т.н. "тестирование проникновения"). Фактически речь идет о проведении эксплойтных проверок, которые подтвердят возможность или невозможность экплуатации выявленных оценщиком уязвимостей.

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

К сожалению, ни ГОСТ 15408, ни ГОСТ 18045 ничего не говорят о том, в чем именно должен заключаться поиск зеродеев в исходных кодах - и это один из основных недостатков Общих Критериев. Отсутствие прямых указаний на эту тему побудило Банк России разработать дополнительные требования к анализу уязвимостей, включив их в проект профиля защиты для автоматизированных банковских систем и приложений. Но об этих требованиях - в следующий раз.