Доработанный текст проекта Приказа Министерства энергетики РФ "Об утверждении требований в отношении базовых (обязательных) функций и информационной безопасности объектов электроэнергетики при создании и последующей эксплуатации на территории Российской Федерации систем удаленного мониторинга и диагностики энергетического оборудования" (подготовлен Минэнерго России 28.08.2018)

Досье на проект

В соответствии с пунктом 1 подпункта "б" постановления Правительства Российской Федерации от 02.03.2017 N 244 "О совершенствовании требований к обеспечению надежности и безопасности электроэнергетических систем и объектов электроэнергетики и внесении изменений в некоторые акты Правительства Российской Федерации" (Собрание законодательства Российской Федерации, 2017, N 11, ст. 1562) приказываю:

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

Министр

А.В. Новак

УТВЕРЖДЕНЫ
приказом Минэнерго России
от "___" _______ 201_ г. N__

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

I. Общие положения

I.1. Настоящие требования устанавливаются в отношении базовых (обязательных) функций программно-аппаратного комплекса, обеспечивающего процесс удаленного наблюдения, управления и контроля за состоянием основного технологического оборудования объекта электроэнергетики, диагностирование и прогнозирование изменения технического состояния основного технологического оборудования объекта электроэнергетики на основе собранных данных (исторические данные о состоянии оборудования) и технологических данных, получаемых от систем сбора данных, установленных на оборудовании, и не влияющего на штатный режим оборудования/объекта (далее - система удаленного мониторинга и диагностики, СУМиД), и к информационной безопасности СУМиД при ее создании и последующей эксплуатации.

I.2. Требования включают в себя организационные требования к обеспечению информационной безопасности систем удаленного мониторинга и диагностики основного технологического оборудования и требования к обеспечению информационной безопасности систем удаленного мониторинга и диагностики при их создании и последующей эксплуатации.

I.3. Субъекты электроэнергетики должны руководствоваться требованиями в отношении базовых (обязательных) функций обеспечения информационной безопасности систем удаленного мониторинга и диагностики основного технологического оборудования (далее - требования) при создании и последующей эксплуатации на объектах электроэнергетики СУМиД.

I.4. Настоящие требования распространяются на объекты электроэнергетики, на основном технологическом оборудовании (в соответствии с перечнем пункта 1.5 настоящих требований) которых используется СУМиД с базовыми (обязательными) функциями, соответствующими перечню пункта 1.6 настоящих требований.

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

паровые турбины установленной мощностью 5 МВт и более и сопутствующее вспомогательное оборудование;

паровые (энергетические) котлы, обеспечивающие паром паровые турбины установленной мощностью 5 МВт и более, и сопутствующее вспомогательное оборудование;

гидротурбины установленной мощностью 5 МВт и более и сопутствующее вспомогательное оборудование;

газовые турбины единичной мощностью более 25 МВт и сопутствующее вспомогательное оборудование;

силовые трансформаторы напряжением 110 кВ и выше, мощностью более 63 МВА и сопутствующее вспомогательное оборудование.

I.6. Выполняемые СУМиД операции в соответствии с назначением являются базовыми (обязательными) функциями. Базовые функции системы СУМиД включают в себя:

I.6.1. Технологический мониторинг состояния основного технологического оборудования объектов энергетики, включая:

выявление на ранних стадиях изменений в техническом состоянии основного технологического оборудования;

оценку остаточного ресурса элементов основного технологического оборудования;

прогнозирование вероятности наступления аварийных событий;

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

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

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

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

I.7. Для реализации базовых (обязательных) функций СУМиД может состоять из следующих основных компонент:

аппаратного обеспечения верхнего, среднего, и нижнего уровней;

программного обеспечения верхнего, среднего и нижнего уровней.

1.7.1 Аппаратное обеспечение СУМиД верхнего уровня может состоять из:

сервера обработки информации;

маршрутизатора;

межсетевого экрана;

источника бесперебойного питания;

автоматизированных рабочих мест персонала.

1.7.2 Аппаратное обеспечение СУМиД среднего уровня может состоять из:

сервера приложений;

сервера базы данных;

маршрутизатора;

межсетевого экрана;

источника бесперебойного питания;

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

1.7.3. Аппаратное обеспечение СУМиД нижнего уровня может состоять из:

сервера приложений;

сервера базы данных;

маршрутизатора;

межсетевого экрана;

источника бесперебойного питания;

автоматизированных рабочих мест персонала.

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

прикладного программного обеспечения серверов хранения данных;

системного программного обеспечения центрального сервера хранения данных;

интерфейсов автоматизированных рабочих мест персонала;

программного обеспечения для формирования, поддержания в актуальном состоянии и уточнения математических моделей СУМиД;

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

программного обеспечения обработки архивных данных;

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

программного обеспечения для синхронизации данных.

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

прикладного программного обеспечения сервера хранения данных;

системного программного обеспечения сервера хранения данных;

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

программного обеспечения по синхронизации данных между уровнями СУМиД.

1.7.7. Программное обеспечение СУМиД нижнего уровня обеспечивает временное хранение информации, а также последующую передачу необработанных данных на верхние уровни. Программное обеспечение СУМиД нижнего уровня может состоять из:

прикладного программного обеспечения сервера оперативного хранения данных;

системного программного обеспечения сервера оперативного храненния данных.

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

II.1. Организационные требования к обеспечению информационной безопасности СУМиД основного технологического оборудования включают в себя организационные требования к обеспечению информационной безопасности:

компонент программного обеспечения СУМиД;

аппаратной инфраструктуры СУМиД;

встроенных средств защиты информации;

организационные требования к обеспечению контроля информационной безопасности СУМиД.

II.2. Организационные требования к обеспечению информационной безопасности компонент программного обеспечения СУМиД предназначены для формирования правил субъектом электроэнергетики по обеспечению процессов доступа к программному обеспечению СУМиД персонала, организации процессов поддержки функциональных требований СУМиД.

II.2.1. Доступ персонала к программному обеспечению СУМиД реализуется через процедуры идентификации и аутентификация.

Для входа в учетную запись пользователя должна быть преднастроена политика паролей, соответствующая минимальным требованиям, приведенным в таблице N 1:

Таблица N 1

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

Для доступа персонала к программному обеспечению СУМиД должны быть предусмотрены утвержденные субъектом электроэнергетики правила доступа, соответствующие следующим минимальным требованиям:

для персонала системы в отношении СУМиД должны быть созданы учетные записи, соответствующие требованиям политики паролей;

настройки учетных записей персонала в отношении СУМиД должны быть утверждены субъектом электроэнергетики;

встроенные учетные записи (неперсонифицированные учетные записи) должны быть отключены.

2.2.2. Поддержка функциональных требований информационной безопасности к программным компонентам СУМиД должна обеспечиваться субъектом электроэнергетики с учетом следующих требований:

поддержка технологических процессов должна обеспечиваться конечным набором программного обеспечения, утвержденного субъектом электроэнергетики;

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

2.2.3. Субъектом электроэнергетики должен быть организован архив проектной и эксплуатационной документации для СУМиД, доступ к которому должен быть регламентирован.

Проектная и эксплуатационная документация должна актуализироваться по утвержденному субъектом электроэнергетики регламенту.

2.2. Организационные требования к обеспечению информационной безопасности аппаратной инфраструктуры СУМиД предназначены для формирования правил определения и утверждения состава аппаратной инфраструктуры СУМиД и обеспечения процессов контроля за аппаратной инфраструктурой СУМиД субъектом электроэнергетики.

2.3.1. Состав оборудования аппаратной инфраструктуры СУМиД, включающей в себя указанные в пункте 1.7. настоящих требований компоненты, а также программного обеспечения, используемого для аппаратной инфраструктуры, должен утверждаться субъектом электроэнергетики в форме разрешенного перечня оборудования и программного обеспечения.

2.2.2. Для утверждения минимального набора сегментов аппаратной инфраструктуры СУМиД субъектов электроэнергетики должна быть осуществлена процедура определения основных составных частей СУМиД (далее - сегментация).

По результатам сегментации аппаратная инфраструктура СУМиД должна включать в себя минимальный набор сегментов, состоящий из:

сегмента сбора, хранения и передачи данных - программное и аппаратное обеспечение нижнего уровня, осуществляющее сбор данных с датчиков оборудования, межсетевые экраны, системы хранения данных;

сегмента эксплуатации - программное и аппаратное обеспечение среднего уровня, осуществляющее первичную обработку и представление данных, автоматизированные рабочие места персонала;

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

системного программного обеспечения - программное обеспечение, которое обеспечивает управление аппаратными компонентами технических средств и функционирование программного обеспечения.

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

информационно-телекоммуникационной инфраструктурой СУМиД;

комплексом технических средств защиты информации;

программным обеспечением и аппаратными средствами СУМиД.

2.2.4. Физический доступ персонала объекта к сегментам аппаратной инфраструктуры СУМиД должен устанавливаться правилами доступа и утверждаться субъектом электроэнергетики.

Правила доступа персонала объекта к сегментам аппаратной инфраструктуры СУМиД должны содержать минимальный набор положений, устанавливающих порядок доступа персонала в зависимости от функций управления:

информационно-телекоммуникационной инфраструктурой СУМиД;

комплексом технических средств защиты информации;

программным обеспечением и аппаратными средствами СУМиД.

Персоналом, выполняющим функции управления программным обеспечением и аппаратными средствами СУМиД, должен по умолчанию устанавливаться запрет на использование программного обеспечения, не внесенного в списки разрешенного к использованию.

Список разрешенного к использованию программного обеспечения утверждается субъектом электроэнергетики с учетом утвержденных субъектом электроэнергетики правил доступа персонала к программному обеспечению.

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

включены персональные межсетевые экраны, которые должны обеспечивать блокировку сетевого доступа, не предусмотренного функционированием СУМиД;

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

2.2.6. Для предотвращения угроз информационной безопасности в отношении аппаратной инфраструктуктуры СУМиД субъектом электроэнергетики должна обеспечиваться безопасность ее функционирования.

Для обеспечения безопасности функционирования аппаратной инфраструктуры СУМиД должен быть реализован минимальный комплекс мероприятий в соответствии с таблицой N 1 приложения N 1 к настоящим требованиям.

2.3. Организационные требования к обеспечению информационной безопасности встроенных средств защиты информации устанавливаются для предотвращения угроз информационной безопасности в отношении СУМиД.

2.4.1. Для обеспечения безопасности СУМиД должны применяться сертифицированные на соответствие требованиям по безопасности средства защиты информации или средства, прошедшие оценку соответствия в форме испытаний или приёмки согласно пункту 18 Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования, утвержденных приказом ФСТЭК России от 21.12.2017 N 235 "Об утверждении Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования" (зарегистрирован Минюстом России 22.02.2018, регистрационный N 50118) (далее - Требования к созданию систем безопасности).

2.3.2. Для реализации организационных требований к встроенным средствам защиты информации СУМиД устанавливаются следующие цели информационной безопасности объекта электроэнергетики:

аудит событий информационной безопасности;

обеспечение криптографической защиты;

дискретный доступ пользователей системы;

контроль сетевого взаимодействия;

передача атрибутов безопасности;

идентификация и аутентификация;

конфигурация безопасности;

установление доверенных соединений;

доступность.

Описание целей информационной безопасности приведены в таблице N 2 приложения N 1 настоящих требований.

2.3.3. Субъектом электроэнергетики в качестве мер по обеспечению предотвращения угроз информационной безопасности СУМиД должна проводиться проверка соответствия встроенных средств защиты информационной безопасности предусмотренным пунктом 2.4.2 целям информационной безопасности объекта электроэнергетики.

2.4. Организационные требования к обеспечению контроля информационной безопасности СУМиД определяют процессы контроля субъектом электроэнергетики соответствия и исполнения требований информационной безопасности СУМиД.

2.5.1. Субъектом электроэнергетики должен осуществляться контроль соответствия и исполнения требований информационной безопасности СУМиД.

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

по контролю документации и исходного состояния программного обеспечения;

по контролю наличия статистического анализа исходных текстов программ;

по обеспечению формирования и хранения отчетности указанных мероприятий.

2.4.2. По результатам категорирования СУМиД в соответствии с правилами категорирования объектов критической информационной инфраструктуры Российской Федерации, утвержденных постановлением Правительства Российской Федерации от 08.02.2018 N 127 "Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации" (Собрание законодательства Российской Федерации, 2018, N 8, ст. 1204), субъектом электроэнергетики должны реализовываться:

требования к организационно-распорядительным документам по безопасности значимых объектов, в соответствии с главой IV Требований к созданию систем безопасности;

проверка требований к обеспечению безопасности СУМиД, установленных пунктом 11 Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации, утвержденных приказом ФСТЭК России от 25.12.2017 N 239 "Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации" (зарегистрирован Минюстом России 26.03.2018, регистрационный N 50524).

2.4.3. В качестве базового набора средств контроля информационной безопасности субъект электроэнергетики должен:

утвердить политику информационной безопасности;

распределить обязанности внутри организации по обеспечению информационной безопасности;

проводить обучение и подготовку персонала по обеспечению информационной безопасности;

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

организовать процессы уведомления о случаях нарушения защиты;

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

обеспечивать защиту данных и документации;

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

III. Требования к обеспечению информационной безопасности СУМиД при их создании и последующей эксплуатации

3.1. В целях обеспечения информационной безопасности СУМиД при создании и последующей эксплуатации СУМиД функция технологического мониторинга состояния основного технологического оборудования объектов электроэнергетики в части сбора, хранения и передачи данных должна осуществляться посредством инфраструктуры, расположенной на территории Российской Федерации, а программное обеспечение, используемое для осуществления функции удаленного управления основного технологического оборудования объектов электроэнергетики (при ее наличии), должно проходить проверку не ниже, чем по 4 уровню контроля отсутствия недекларированных возможностей.

3.2. Требования к обеспечению информационной безопасности СУМиД включают в себя требования к профилю защиты, функциональные требования и требования доверия.

3.2.1. Требования к профилю защиты включают в себя процедуру моделирования и базовую модель угроз информационной безопасности СУМиД.

В качестве основы для моделирования угроз информационной безопасности СУМиД используются критерии:

ценности (важности) рассматриваемой системы и ее компонентов;

существующих уязвимостей системы и её компонентов;

вероятности их реализации (использования);

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

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

банк данных угроз безопасности информации (bdu.fstec.ru), ведение которого осуществляется ФСТЭК России в соответствии с подпунктом 21 пункта 8 положения о Федеральной службе по техническому и экспортному контролю, утвержденного Указом Президента Российской Федерации от 16.08.2004 N 1085 (Собрание законодательства Российской Федерации, 2004, N 34, ст. 3541; 2017, N 48, ст. 7198), а также иные доступные источники, содержащие сведения об уязвимостях и угрозах безопасности информации СУМиД;

результаты оценки вероятности реализации уязвимостей компонент СУМиД.

На основании входных данных для анализа угроз информационной безопасности формируется перечень актуальных угроз информационной безопасности СУМиД.

Базовая модель угроз информационной безопасности СУМиД должна включать в себя:

описание СУМиД, характеристики функций СУМиД, а также учитывать результаты процедуры сегементации;

описание источников угроз, типовых уязвимостей, объектов воздействия, деструктивных действий в отношении СУМиД;

модели нарушителя информационной безопасности СУМиД.

Основными источниками угроз информационной безопасности СУМиД являются:

конкуренты;

криминальные элементы (структуры);

недобросовестные партнеры;

работники (персонал) организации (субъекта электроэнергетики);

злонамеренные высококвалифицированные специалисты информационных технологий, киберпреступники (хакеры);

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

Типовые уязвимости СУМиД могут быть реализованы на прикладном и канальном уровне базовой модели стека сетевых протоколов.

Анализ уязвимостей должен быть проведен:

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

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

для операционных систем.

При анализе уязвимостей необходимо использовать:

перечень атак, приведенный в таблице N 1 приложения N 2 к настоящим требованиям;

перечень базовых уязвимостей СУМиД, приведенный в таблице N 2 приложения N 2 к настоящим требованиям.

Основными объектами воздействия СУМиД являются:

серверы автоматизированой системы управления и СУМиД среднего и нижнего уровней;

сетевой контур взаимодействия между:

сервером СУМиД нижнего уровня и автоматизированным рабочим местом персонала;

серверами СУМиД нижнего, среднего и верхнего уровней;

сервером СУМиД верхнего уровня и прикладным программным обеспечением (средства обработки данных и разработки математических моделей);

сервером СУМиД и автоматизированным рабочим местом персонала.

Основными деструктивными действиями в отношении безопасности информации СУМиД являются:

несанкционированное копирование информации (деструктивное действие 1 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям);

уничтожение информации (носителя информации) (деструктивное действие 2 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям);

модифицирование информации (изменение исходной информации на ложную) (деструктивное действие 3 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям);

блокирование информации (деструктивное действие 1 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям);

перехват информации при ее передаче по каналам связи (деструктивное действие 5 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям);

разглашение информации персоналом (деструктивное действие 6 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям);

хищение носителя информации (деструктивное действие 7 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям);

нанесение ущерба здоровью персонала и окружающим людям (деструктивное действие 8 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям);

нанесение ущерба окружающей среде (деструктивное действие 9 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям);

физическое повреждение объекта защиты или его компонент (деструктивное действие 10 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям);

блокирование контроля над объектом защиты (деструктивное действие 11 в соответствии с нумерацией, приведенной в приложении N 3 к настоящим требованиям).

Определение возможных деструктивных действий для каждой из угроз информационной безопасности осуществляется субъектом элеткроэнрегетики в соответствии с приложением N 3 к настоящим требованиям.

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

Для установления модели нарушителя информационной безопасности СУМиД проводится его классификация по следующим основным направлениям:

по отношению к СУМиД;

по правам доступа к компонентам СУМиД;

по мотивации нарушения;

по возможностям физического доступа;

по квалификации;

по направлению реализации угроз информационной безопасности.

По итогам процедур классификации субъектом электроэнергетики должны быть утверждены типовые модели нарушителей СУМиД. Классификация для установления модели нарушителей приведена в приложении N 4 к настоящим требованиям.

3.2.2. Функциональные требования к информационной безопасности СУМиД устанавливаются субъектом электроэнергетики для достижения целей информационной безопасности. Взаимосвязь функциональных требований информационной безопасности и целей информационной безопасности представлена в таблице N 1 приложения N 5 к настоящим требованиям.

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

Контроль достаточности функциональных требований осуществляется субъектом электроэнергетики в соответствии с таблицами NN 3-9 приложения N 5 к настоящим требованиям.

3.2.4. Для подтверждения достаточности оснований соответствия СУМиД целям безопасности устанавливаются требования доверия к безопасности.

Требования доверия состоят из классов доверия и компонентов доверия к безопасности (компоненты доверия включены в классы доверия). Описание взаимосвязи классов доверия с компонентами доверия представлены в таблице N 1 приложения N 6 к настоящим требованиям.

Компоненты доверия к безопасности используются при создании и последующей эксплуатации СУМиД для достижения целей информационной безопасности, приведенных в приложении N 1 к настоящим требованиям. Классы доверия к безопасности используются для оценки и установления уровней доверия в отношении СУМиД.

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

Основные требования к проведению оценки соответствия требований доверия к безопасностиуказаны в таблицах NN 2-8 приложения N 6 к настоящим требованиям.

3.3. Для обеспечения системы безопасности СУМиД субъектом электроэнергетики должны устанавливаться требования ко встроенным стредствам защиты.

Субъект электроэнергетики для обеспечения системы безопасности компонент СУМиД, должен выполнять требования, установленные главой III Требований к созданию систем безопасности.

Субъект электроэнергетики при организации работ по обеспечению безопасности СУМиД в рамках функционирования системы безопасности должен выполнять требования, установленные главой V Требований к созданию систем безопасности.

Приложение N 1
к требованиям в отношении базовых (обязательных) функций и информационной безопасности
объектов электроэнергетики при создании и последующей эксплуатации
на территории Российской Федерации систем удаленного мониторинга
и диагностики энергетического оборудования,
утвержденным приказом Минэнерго России
от "__" ________2018 года N "____"

МИНИМАЛЬНЫЙ КОМПЛЕКС МЕРОПРИЯТИЙ
для обеспечения безопасности среды функционирования систем удаленного мониторинга и диагностики энергетического оборудования и описание целей информационной безопасности объекта электроэнергетики

Таблица N 1. Минимальный комплекс мероприятий для обеспечения безопасности среды функционирования систем удаленного мониторинга и диагностики энергетического оборудования(далее - СУМиД) организационных требований к обеспечению информационной безопасности аппаратной инфраструктуры СУМиД

N пп.	Мероприятие	Описание
1	3	4
1.	Контроль физического доступа	В местах размещения аппаратной инфраструктуры СУМиД должен быть обеспечен контроль физического доступа
2.	Безопасная установка	Процесс установки, инсталляции и администрирования аппаратной инфраструктуры, программного обеспечения СУМиД должен соответствовать требованиям политики информационной безопасности, утвержденной собственником или иным законным владельцем объекта электроэнергетики. Контроль соответствия требований информационной безопасности осуществляется субъектом электроэнергетики
3.	Повышение осведомленности	Администраторы СУМиД должны пройти обучение и получить сертификат об окончании обучения способам администрирования программного обеспечения. В составе программы обучения должны входить мероприятия по получению знаний и навыков реализации требований информационной безопасности, действующих в Российской Федерации
4.	Администратор безопасности	В рамках организационной структуры подразделения, эксплуатирующего программное обеспечение, должна быть предусмотрена роль администратора информационной безопасности. Роль администратора информационной безопасности должна быть регламентирована и утверждена субъектом электроэнергетики. В качестве исполнителя роли администратора информационной безопасности может быть только сотрудник объекта в соответствии со штатным расписанием

Таблица N 2. Описание целей информационной безопасности объекта электроэнергетики, организационных требований к обеспечению контроля информационной безопасности СУМиД

N пп.	Цель информационной безопасности	Идентификатор*(1)	Описание
1.	Аудит событий	O.AUDITING	Программное обеспечение должно обеспечивать: генерацию, запись и хранение событий информационной безопасности относящихся к функционированию встроенных средств защиты, при этом генерация, запись и хранение событий информационной безопасности должно осуществляться за счет инфраструктуры, расположенной на территории Российской Федерации; защиту данных журналов (доступ к журналам разрешен пользователям, имеющим право допуска, правило получения, которого устанавливаются субъектом электроэнергетики). Хранимая в журналах информация, должна содержать: дату (день, месяц и год) и время (часы, минуты, секунды) произошедшего события информационной безопасности, идентификационные данные пользователя, от имени которого совершалось действие или был запущен процесс, повлекший наступление события информационной безопасности; подробное описание предпринимаемых действий для последующего их анализа выявления попыток несанкционированного доступа или несанкционированной модификации компонент программного обеспечения
2.	Криптографи-ческая защита	O.CRYPTO	Программное обеспечение должно обеспечивать целостность и конфиденциальность информации. Целостность и конфиденциальность информации обеспечивается средствами криптографической защиты. Удаленное соединение должно обеспечиваться совместно со средствами криптографической защиты, в рамках открытых сессий обмена данными должны использоваться средства криптографической защиты. В случае с распределенной сетью хранения и получения данных должны использоваться средства криптографической защиты
3.	Дискретный доступ	O.DACCESS	Программное обеспечение должно осуществлять контроль доступа субъектов на основе идентификаторов объектов. Доступ к объектам пользователей должен осуществляться на основании правил доступа персонала к объектам, утвержденных субъектом электроэнергетики
4.	Контроль сетевого взаимодействия	O.NFLOW	Программное обеспечение должно осуществлять контроль взаимодействия и передачи информации между сетевыми интерфейсами (в том числе виртуальными), между субъектами, между внутренними функциями на основании настраиваемой политики безопасности в рамках функций СУМиД
5.	Передача атрибутов безопасности	O.SUBJECT	При взаимодействии пользователей программное обеспечение должно обеспечивать передачу атрибутов безопасности в соответствии с настраиваемой политикой безопасности
6.	Идентификация и аутентификация	O.I&A	Программное обеспечение должно обеспечивать идентификацию и аутентификацию пользователей для любых действий на основе сертификата открытого ключа подписи и связанного с ним закрытого ключа подписи, размещенного на отчуждаемом носителе. Доступ к программному обеспечению СУМиД должен предоставляться только авторизованным пользователям. Должна быть обеспечена многофакторная аутентификация с использованием доступных для субъектов электроэнергетики средств
7.	Конфигурация безопасности	O.MANAGE	Программное обеспечение должно содержать необходимые механизмы для управления и настройки всех имеющихся функций безопасности. Доступ к этим механизмам должен быть обеспечен только авторизованным пользователям с выделенной ролью администратора информационной безопасности. Программное обеспечение должно иметь возможность указывать на ошибки персонала при конфигурации, а также должно запрещать возможность снижения уровня безопасности. Применяемые средства защиты информации должны соответствовать пунктам 19-22 Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования, утвержденных приказом ФСТЭК России от 21.12.2017 N 235 "Об утверждении Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования" (зарегистрирован Минюстом России 22.02.2018, регистрационный N 50118)
8.	Установление защищенных соединений	O.TRUSTCHAN	Программное обеспечение должно быть спроектировано и разработано таким образом, чтобы позволять установление защищенного соединения с информационными системами того же класса доверия, гарантируя при этом целостность, доступность и конфиденциальность передаваемых в рамках соединения данных, взаимную авторизацию и возможность обмена атрибутами безопасности
9.	Доступность	O.AVAIL	Функционирование программного обеспечения должно осуществляться на постоянной основе. В случае выходов из строя каналов связи функционирование программного обеспечение должно продолжаться. Должны быть предусмотрены механизмы обеспечения продолжения функционирования при переполнении баз данных. Должен осуществляться контроль целостности компонентов СУМиД в процессе их загрузки и эксплуатации. Должно быть исключено неконтролируемое, несанкционированное вмешательство в процессы перезагрузки или восстановления после сбоев компонентов программного обеспечения СУМиД. В процессе функционирования программного обеспечения СУМиД должны быть предусмотрены на периодической основе проверки на наличие уязвимостей компонентов программного обеспечения СУМиД. Должны быть предусмотрены возможности восстановления данных и/или параметров конфигураций компонентов программного обеспечения СУМиД из резервных копий в случае их компрометации, уничтожения, ошибочного изменения, замены аппаратного обеспечения СУМиД. Должны быть предусмотрены возможности создания резервных копий в случае внесения изменений в конфигурации, с заданной периодичностью или комбинации этих вариантов персоналом субъекта электроэнергетики вручную или автоматически с использованием прикладного программного обеспечения

Приложение N 2
к требованиям в отношении базовых (обязательных) функций
и информационной безопасности объектов электроэнергетики
при создании и последующей эксплуатации на территории Российской Федерации
систем удаленного мониторинга и диагностики энергетического оборудования,
утвержденным приказом Минэнерго России
от "__" ________2018 года N "____"

ПЕРЕЧЕНЬ
атак и базовых уязвимостей систем удаленного мониторинга и диагностики энергетического оборудования

Таблица N 1. Перечень базовых атак, необходимых при анализе уязвимостей системы удаленного мониторинга и диагностики энергетического оборудования (далее - СУМиД)

N пп	Объект атаки	Тип атаки	Результат атаки
1	2	3	4
1.	Атаки вследствие использования стека протокола IPSec, PPTP, L2TP, SSL	Атаки типа "человек в середине" и "отказ в обслуживании"	Возможность получения прав администратора, нарушение конфиденциальности, целостности, доступности защищаемой информации.
2.	Атаки вследствие использования стека протоколов ТСР, UDP	Атаки типа "отказ в обслуживании" и "инъекция данных"	Возможность сканирования портов.
3.	Атаки вследствие использования стека протоколов OPC, TELNET, SSH, VNC, RADMIN, TEAMVIEWER, LYNC	Атаки типа "отказ в обслуживании", атаки через неизвестные или неклассифицированные векторы	Неизвестен.
4.	Атаки вследствие использования стека протоколов FTP, SMB, CIFS, ТАСА, SFTP, Rsync	Атаки, направленные на получение злоумышленниками прав администратора, связанные с выполнением произвольного кода типа "отказ в обслуживании"	Возможность получения прав администратора.
5.	Атаки вследствие использования серверами системы удаленного мониторинга и диагностики программного обеспечения MS Windows, терминального доступа	Атаки, связанные с: выполнением злоумышленникам произвольного кода, повышением злоумышленниками своих привилегий, возможностью обхода процедуры аутентификации, позволяющие нарушителю получить доступ к защищаемой информации, обойти механизмы доверенной загрузки, типа "отказ в обслуживании"	Неизвестен.

Таблица N 2. Перечень базовых уязвимостей СУМиД, необходимых для проведения анализа

N пп	Уязвимость
1	2
1.	Среда и инфраструктура:
1.1.	отсутствие физической защиты зданий, дверей и окон;
1.2.	неправильное или халатное использование физических средств управления доступом в зданиях, помещениях и энергоустановками;
1.3.	нестабильная работа электросети собственных нужд;
1.4.	отсутствие системы обеспечения аварийного электропитания оборудования;
1.5.	отсутствие средств пожарной сигнализации;
1.6.	отсутствие средств пожаротушения;
1.7.	размещение в зонах возможного затопления компонентов систем или энергоустановок.
2.	Линии связи и сетевые подключения:
2.1.	незащищенные линии связи;
2.2.	неудовлетворительная стыковка кабелей, спайка оптоволоконных линий;
2.3.	отсутствие идентификации и/или аутентификации отправителя и получателя в прикладном программном обеспечении;
2.4.	подмена данных.
3.	Отказ в обслуживании:
3.1.	несанкционированный доступ к каналам связи;
3.2.	перехват информации;
3.3.	получение несанкционированного доступа к учётной информации (учетные данные пользователей, конфигурационные файлы и прочее);
3.4.	получение несанкционированного доступа;
3.5.	коммутируемые линии связи и/или использование сотовых сетей передачи информации, использование технология беспроводной локальной сети с устройствами на основе стандартов IEEE 802.11;
3.6.	незащищенные потоки конфиденциальной информации;
3.7.	незащищенные подключения к сетям общего пользования.
4.	Сетевое оборудование:
4.1.	отсутствие средств для маршрутизации в целях безопасного управления сетью;
4.2.	ошибки конфигурации сетевых устройств;
4.3.	отсутствие обновлений и патчей на сетевом оборудовании как от производителя, так и не соответствие установленных версий с официальными версиями производителя;
4.4.	неправильная сетевая топология (например, использование "плоских" локальных сетей);
4.5.	использование паролей с малым набором символов, "паролей по умолчанию" или ненадежных механизмов аутентификации на сетевом оборудовании;
4.6.	отказ системы вследствие отказа одного из ключевых элементов телекоммуникационного оборудования или агрегирующего контроллера (возможна, например, угроза сбоев в функционировании услуг связи).
5.	Аппаратное обеспечение:
5.1.	отсутствие схем периодической замены оборудования СУМиД в связи с его моральным устареванием;
5.2.	подверженность колебаниям напряжения оборудования СУМиД;
5.3.	подверженность температурным колебаниям оборудования СУМиД;
5.4.	подверженность воздействию влаги, пыли, загрязнения оборудования СУМиД;
5.5.	чувствительность к воздействию электромагнитного излучения оборудования СУМиД;
5.6.	недостаточное обслуживание / неправильная инсталляция запоминающих сред (в том числе систем хранения данных) СУМиД;
5.7.	отсутствие контроля за эффективным изменением конфигурации оборудования или телекоммуникационного оборудования сетей связи в СУМиД;
5.8.	отсутствие контроллера версии прошивок firmware (версионирование).
6.	Программное обеспечение:
6.1.	отсутствие технических требований к разработке программного (программно-аппаратного) обеспечения, применяемого в СУМиД;
6.2.	отсутствие тестирования или упрощенное тестирование программного обеспечения (возможна угроза использования программного обеспечения несанкционированными пользователями);
6.3.	сложный пользовательский интерфейс компонентов мониторинга и управления энергосетью (возможна, например, угроза ошибки операторов);
6.4.	отсутствие механизмов идентификации и аутентификации, например аутентификации пользователей;
6.5.	отсутствие внешней аудиторской проверки установленного программного обеспечения;
6.6.	ошибки конфигурации программного обеспечения;
6.7.	неустановленные патчи и обновления программного обеспечения (в том числе системного программного обеспечения);
6.8.	отсутствие системы управление паролями учетных записей операторов, управление паролями оборудования, в том числе программируемых контроллеров (легко определяемые пароли, хранение в незашифрованном виде, недостаточно частая замена паролей);
6.9.	неправильное присвоение прав доступа (возможна угроза использования программного обеспечения несанкционированным способом);
6.10.	неконтролируемая загрузка, установка и использование программного обеспечения (возможна угроза столкновения с вредоносным программным обеспечением);
6.11.	отсутствие регистрации окончания сеанса при выходе с рабочей станции (возможна, например, угроза использования программного обеспечения несанкционированными пользователями);
6.12.	отсутствие эффективного контроля внесения изменений (возможна угроза программных сбоев);
6.13.	отсутствие документации (возможна угроза ошибки операторов в связи с отсутствием алгоритмов действий );
6.14.	отсутствие резервных копий информации, обрабатываемой в системе;
6.15.	списание или повторное использование запоминающих сред без надлежащего стирания записей;
6.16.	наличие недекларированных возможностей (программных и аппаратных закладок) в оборудовании иностранных производителей.
7.	Документация:
7.1.	хранение в незащищенных местах (возможна, например, угроза хищения);
7.2.	недостаточная внимательность при уничтожении (возможна, например, угроза хищения);
7.3.	бесконтрольное копирование (возможна угроза хищения).
8.	Персонал:
8.1.	отсутствие квалифицированного персонала (возможна, например, угроза халатного отношения работников к своим обязанностям);
8.2.	отсутствие надзора за работой лиц, приглашенных со стороны, или за работой обслуживающего персонала (возможна, например, угроза хищения);
8.3.	неправильное использование программно-аппаратного обеспечения (возможна, например, угроза ошибки операторов);
8.4.	отсутствие механизмов отслеживания и мониторинга (возможна, например, угроза использования программного обеспечения несанкционированным способом);
8.5.	отсутствие политики и/или наличие ошибок в политике допустимого использования телекоммуникационных систем для обмена сообщениями (возможна, например, угроза использования сетевых средств несанкционированным способом);
8.6.	несоответствующие процедуры набора кадров (возможна, например, угроза намеренного повреждения или недостаточной квалификации дежурного и оперативного персонала).

Приложение N 3
к требованиям в отношении базовых (обязательных) функций
и информационной безопасности объектов электроэнергетики
при создании и последующей эксплуатации на территории Российской Федерации
систем удаленного мониторинга и диагностики энергетического оборудования,
утвержденным приказом Минэнерго России
от "__" ________2018 года N "____"

ПЕРЕЧЕНЬ
возможных деструктивных действий в отношении безопасности информации систем удаленного мониторинга и диагностики энергетического оборудования

N пп	Код угрозы информационной безопасности*(2)	Угроза информационной безопасности	Деструктивное действие
			1	2	3	4	5	6	7	8	9	10	11
1	2	3	4	5	6	7	8	9	10	11	12	13	14
1.	УФД1	Физическое проникновение на территорию без возможности проникновения в помещения с техническими средствами обработки, носителями информации, энергоустановок		+								+	+
2.	УФД2	Хищение носителя информации, средств обработки информации (процессора, микросхемы, контроллеров, серверов), средств коммуникации (маршрутизатора, коммутатора, сетевой карты, модема), средств ввода вывода информации (клавиатура)	+	+	+	+			+				+
3.	УФД3	Уничтожение носителя информации, средств обработки информации (процессора, микросхемы, контроллеров, серверов), средств коммуникации (маршрутизатора, коммутатора, сетевой карты, модема), средств ввода вывода информации (клавиатура)		+									+
4.	УФД4	Потеря носителя информации	+	+		+							+
5.	УФД5	Чтение информации с устройств отображения						+
6.	УФД6	Повреждение оборудования и/или линий связи				+						+	+
7.	УФД7	Навязывание ложной информации на уровне конечного оборудования или линий связи (при обмене данными между датчиками и контроллерами, между контроллерами и автоматизированной системой управления)			+	+							+
8.	УФД8	Съем информации с конечного оборудования или линий связи (датчиков, контроллеров)	+				+
9.	УФД9	Захват объекта защиты, установление над объектом защиты контроля силой или угрозой применения силы, или путем любой другой формы запугивания								+			+
10.	УФД10	Разрушение объекта защиты или нанесение объекту защиты, здоровью персонала и другим лицам повреждений путем взрыва (обстрела)								+		+	+
11.	УФД11	Размещение и (или) совершение действий в целях размещения каким бы то ни было способом на объекте защиты взрывных устройств (взрывчатых веществ)								+		+	+
12.	УФД12	Загрязнение объекта защиты опасными веществами, угрожающих жизни и здоровью персонала и других лиц								+	+
13.	УНДА1	Подбор пароля BIOS или системного программного обеспечения контроллера путем перебора вручную на основе предварительно собранных данных о пользователе	+		+
14.	УНДА2	Обход заданного пароля BIOS или системного программного обеспечения контроллера (воздействие на аппаратное обеспечение)	+		+
15.	УНДАЗ	Загрузка альтернативной операционной системы с нештатного носителя	+		+	+
16.	УНДБ1	Подбор пароля доступа (администратора) в операционную систему компьютера или к системному программному обеспечению контроллера с использованием заданных по умолчанию значений ("заводских" паролей)	+		+	+
17.	УНДБ1.2	Подбор пароля доступа (администратора) в операционную систему компьютера или к системному программному обеспечению контроллера посредством перебора различных вариантов	+		+
18.	УНДВ	Подбор пароля доступа (администратора) в операционную систему компьютера посредством специализированно-го программного обеспечения	+		+								+
19.	УНДГ1	Выявление пароля BIOS при загруженной операционной системы, посредством использования программ выявления пароля	+		+
20.	УНДГ2	Выявление пароля доступа других пользователей при загруженной операционной системы (декодирование, из оперативной памяти, копирование хранилищ)	+		+
21.	УНДГЗ	Создание новой учетной записи с расширенными привилегиями	+		+								+
22.	УНДГ4	Уничтожение системного реестра, обнуление памяти контроллера				+							+
23.	УНДГ5	Редактирование системного реестра с целью нарушения работоспособности операционной системы и/или прикладного программного обеспечения	+		+	+							+
24.	УНДГ6	Использование стороннего программного обеспечения с целью несанкционированного воздействия на объект защиты	+		+	+							+
25.	УНДГ6.4	Заражение вредоносным программным обеспечением автоматизирован-ных рабочих мест, серверов, контроллеров	+	+	+	+							+
26.	УНДГ7	Перезагрузка операционной системы с целью загрузки альтернативной операционной системы с нештатного носителя для расширения привилегий	+		+	+							+
27.	УНДГ8	Копирование информации на нештатные носители информации	+
28.	УНДГ9	Модификация информации			+
29.	УНДГ10	Уничтожение (стирание) информации		+		+							+
30.	УНДГ11	Уничтожение информации путем форматирования носителей информации		+									+
31.	УУДА1	Сканирование сегмента сети с целью сбора информации	+
32.	УУДБ1	Удаленный подбор пароля (администратора) посредством ввода имени и пароля, заданных по умолчанию для используемой операционной системы	+		+
33.	УУДБ1.2	Удаленный подбор имени и пароля (администратора) посредством перебора	+		+	+							+
34.	УУДБ2	Удаленный подбор пароля (пользователя)	+
35.	УУДБЗ	Получение доступа к программам удаленного администрирования	+		+	+							+
36.	УУДБ4	Внедрение ложного доверенного объекта	+		+	+							+
37.	УУДБ5	Угрозы удаленного перехвата внешнесегментного сетевого трафика	+				+
38.	УУДБ5.3	Удаленный перехват аутентификацион-ной информации, передаваемой в открытом виде	+
39.	УУДВ2	Переполнение буфера с запуском исполняемого кода	+		+	+
40.	УУДВ10	Перенаправление сетевого трафика	+		+		+
41.	УУДГ	Атаки на узлы, подключенные к сети Интернет	+	+	+	+							+
42.	УУДД	Угрозы отказа в обслуживании (DoS)				+							+
43.	УУДЕ1	Обход межсетевого экрана посредством инкапсуляции данных в заголовки пакетов протокола обмена сообщениями	+		+	+							+
44.	УМУ1	Хищение мобильного устройства	+
45.	УМУ2	Потеря мобильного устройства	+
46.	УМУ3	Несанкционирован-ное считывание информации с дисплея мобильного устройства	+
47.	УМУ4	Внедрение вредоносного программного обеспечения на мобильное устройство	+		+
48.	УМУ5	Перехват паролей/хэшей паролей при доступе с мобильного устройства через незащищенные сети, а также использование мобильного устройства в незащищенных сетях	+			+
49.	УМУ6	Выявление хранящихся на мобильном устройстве паролей/хэшей паролей	+			+
50.	УО1	Ошибки при проектировании программного обеспечения	+	+	+	+							+
51.	УО2	Ошибки при проектировании технических средств	+	+	+	+							+
52.	УОЗ	Ошибки при изготовлении программного обеспечения	+	+	+	+
53.	УО4	Ошибки при изготовлении технических средств	+	+	+	+
54.	УО5	Ошибки при эксплуатации технических средств	+	+	+	+							+
55.	УО6	Ошибки при эксплуатации программного обеспечения	+	+	+	+							+
56.	УТХ1	Сбои, отказы технических средств				+							+
57.	УТХ2	Сбои, отказы программного обеспечения				+							+
58.	УБИЛ80	Отказа подсистемы обеспечения температурного режима		+								+	+
59.	УБИЛ82	Физическое устаревание компонентов аппаратного обеспечения											+

Приложение N 4
к требованиям в отношении базовых (обязательных) функций
и информационной безопасности объектов электроэнергетики
при создании и последующей эксплуатации на территории Российской Федерации
систем удаленного мониторинга и диагностики энергетического оборудования,
утвержденным приказом Минэнерго России
от "__" ________2018 года N "____"

КЛАССИФИКАЦИЯ НАРУШИТЕЛЕЙ
для модели нарушителя информационной безопасности систем удаленного мониторинга и диагностики энергетического оборудования

N пп	Основные направления для установления модели нарушителя	Вид нарушителя	Описание нарушителя
1	2	3	4
1.	По отношению к системе удаленного мониторинга и диагностики энергетического оборудования (далее - СУМиД)	Внутренний	Лицо с разрешенным доступом к компонентам системы СУМиД и с разрешенным доступом на территорию объекта электроэнергетики (эксплуатация, постановка, сопровождение, обслуживание и ремонт аппаратного обеспечения).
		Внешний	Постороннее лицо, разрабатывающее/распространяющее вирусы и другие программы, предназначенные для осуществления несанкционированного доступа и (или) воздействия на ресурсы и информацию, хранимую на ресурсах, с целью несанкционированного использования или причинения вреда (нанесения ущерба) владельцу информации, ресурса, путем копирования, искажения, удаления или подмены информации) программы; лицо, организующее атаки на отказ в обслуживании.
		Иной нарушитель	Лицо, осуществляющее попытки несанкционированного доступа к СУМиД.
2.	По правам доступа к компонентам СУМиД	Авторизованный (зарегистрирован-ный) пользователь, системный администратор, администратор безопасности компонент СУМиД	Лицо, имеющее разрешенный доступ к компонентам СУМиД.
		Иной нарушитель	Лицо, не имеющее прав доступа к компонентам СУМиД.
3.	По мотивации нарушения	С немотивирован-ными действиями	Действие или бездействие пользователя без злого умысла, связанное со случайным нарушением свойств информационной безопасности информационных активов.
		Действия в целях самоутверждения	Действия пользователя, приводящие к нарушению свойств безопасности СУМиД, в целях самоутверждения.
		Корыстный интерес и терроризм	Действия пользователя, приводящие к нарушению свойств безопасности информационных активов, направленные на получение выгоды.
4.	По возможностям физического доступа	Без доступа в контролируемую зону	Лицо, без доступа в помещения, в которых расположены компоненты СУМиД.
		С доступом в контролируемую зону	Лицо с доступом к техническим средствам СУМиД (в том числе за пределами контролируемой зоны); с доступом к рабочему месту администратора СУМиД.
5.	По квалификации	С отсутствием знаний	Лицо с отсутствием знаний об устройстве и особенностях функционирования СУМиД.
		Со знанием	Лицо со знанием функциональных особенностей СУМиД, протоколов передачи информации, основных закономерностей формирования в ней массивов данных и потоков запросов к ним, с умением пользоваться штатными средствами операционных систем, систем управления базами данных и прикладным программным обеспечением.
		С высоким уровнем знаний	Лицо со знанием в области программирования и уязвимостей применяемых технологий обеспечения функционирования СУМиД.
		С обладанием возможностями активного воздействия на СУМиД	Разработчики, профильные эксперты и другие лица.
6.	По направлению реализации угроз информационной безопасности	Реализация угроз направлена на физический вектор	Не требуется.
		Реализация угроз направлена на СУМиД из сети Интернет, корпоративной информационной вычислительной системы	Не требуется.
		Реализация угроз осуществляется с использованием вредоносного программного обеспечения и сетевых атак внутри СУМиД	Не требуется.

Приложение N 5
к требованиям в отношении базовых (обязательных) функций
и информационной безопасности объектов электроэнергетики
при создании и последующей эксплуатации на территории Российской Федерации
систем удаленного мониторинга и диагностики энергетического оборудования,
утвержденным приказом Минэнерго России
от "__" ________2018 года N "____"

ПЕРЕЧЕНЬ
функциональных компонент для установления функциональных требований к информационной безопасности и взаимосвязь функциональных требований информационной безопасности и целей информационной безопасности систем удаленного мониторинга и диагностики энергетического оборудования

Таблица N 1. Взаимосвязь функциональных требований информационной безопасности и целей информационной безопасности систем удаленного мониторинга и диагностики энергетического оборудования (далее - СУМиД)

N пп.	Функциональные требования безопасности*(3)	Цели безопасности
1	2	3
1.	FAU_ARP.1	O.AUDITING
2.	FAU_GEN.1	O.AUDITING
3.	FAU_GEN.2	O.AUDITING
4.	FAU_SAA.1	O.AUDITING
5.	FAU_SAR.1	O.AUDITING
6.	FAU_SAR.2	O.AUDITING
7.	FAU_SEL.1	O.AUDITING
8.	FAU_STG.1	O.AUDITING
9.	FAU_STG.3	O.AUDITING
10.	FAU_STG.4	O.AUDITING
11.	FAU_COP.1	O.CRYPTO O.I&A
12.	FDP_ACC.1	O.DACCESS
13.	FDP_ACF.1	O.DACCESS
14.	FDP_IFC.2	O.NFLOW
15.	FDP_IFF.1	O.NFLOW
16.	FDP_ITC.2	O.DACCESS O.SUBJECT O.NFLOW
17.	FDP_ITT.1	O.NFLOW
18.	FDP_RIP.2	O.AUDITING O.CRYPTO O.DACCESS O.SUBJECT O.NFLOW O.I&A
19.	FDP_ROL.2	O.AVAIL
20.	FDP_SDI.1	O.AVAIL
21.	FIA_AFL.1	O.I&A
22.	FIA_ATD.1	O.I&A O.NFLOW
23.	FIA_SOS.1	O.I&A
24.	FIA_UAU.2	O.I&A
25.	FIA_UID.2	O.I&A O.NFLOW
26.	FIA_USB.2	O.I&A
27.	FMT_MSA.1	O.MANAGE
28.	FMT_MSA.3	O.MANAGE
29.	FMT_MTD.1	O.MANAGE
30.	FMT_REV.1	O.MANAGE
31.	FMT_SMF.1	O.MANAGE
32.	FMT_SMR.1	O.MANAGE
33.	FPT_STM.1	O.AUDITING
34.	FPT_TDC.1	O.DACCESS
35.	FPT_ITC.1	O.TRUSTCHAN
36.	FTA_SSL.1	O.I&A
37.	FTA_SSL.2	O.I&A

Таблица N 2 Перечень функциональных компонент для установления функциональных требований к информационной безопасности СУМиД

N пп.	Идентификатор*(4)	Название компоненты
1	2	3
Класс FAU: Аудит информационной безопасности
1.	FAU_ARP.1	Сигналы нарушения безопасности
2.	FAU_GEN.1	Генерация данных аудита
3.	FAU_GEN.2	Ассоциация идентификатора пользователя
4.	FAU_SAA.1	Анализ потенциального нарушения
5.	FAU_SAR.1	Просмотр журналов аудита
6.	FAU_SAR.2	Ограниченный просмотр журналов аудита
7.	FAU_SEL.1	Избирательный аудит
8.	FAU_STG.1	Защищенное хранение журнала аудита
9.	FAU_STG.3	Действия в случае возможной потери данных аудита
10.	FAU_STG.4	Предотвращение потери данных аудита
Класс FCS: Криптографическая защита
11.	FCS_COP.1	Криптографические операции
Класс FDP: Защита данных пользователя
12.	FDP_ACC.1	Ограниченное управление доступом
13.	FDP_ACF.1	Управление доступом, основанное на атрибутах безопасности
14.	FDP_IFC.2	Полное управление информационными потоками
15.	FDP_IFF.1	Простые атрибуты безопасности
16.	FDP_ITC.2	Импорт данных пользователя с атрибутами безопасности
17.	FDP_ITT.1	Базовая защита внутренней передачи
18.	FDP_ROL.2	Расширенный откат к исходному состоянию
19.	FDP_SDI.2	Мониторинг целостности хранимых данных и предпринимаемые действия
Класс FIA: Идентификация и аутентификация
20.	FIA_AFL.1	Обработка отказов аутентификации
21.	FIA_ATD.1	Определение атрибутов пользователя
22.	FIA_SOS.1	Верификация секретов
23.	FIA_UAU.2	Аутентификация до любых действий пользователя
24.	FIA_UID.2	Идентификация до любых действий пользователя
25.	FIA_USB.1	Связывание "пользователь-субъект"
Класс FMT: Управление безопасностью
26.	FMT_MSA.1	Управление атрибутами безопасности
27.	FMT_MSA.3	Инициализация статических атрибутов
28.	FMT_MTD.1	Управление данными функций безопасности объекта энергетики
29.	FMT_REV.1	Отмена атрибутов безопасности
30.	FMT_SMF.1	Спецификация функций управления
31.	FMT_SMR.1	Роли безопасности
Класс FPT: Защита функций безопасности объекта энергетики
32.	FPT_STM.1	Надежные метки времени
33.	FPT_TDC.1	Базовая согласованность данных функций безопасности объекта энергетики между функциями безопасности
Класс FTA: Доступ к программному обеспечению
35.	FTA_SSL.1	Блокирование сеанса, инициированное функциями безопасности
36.	FTA_SSL.2	Блокирование, инициированное пользователем
37	FTP_ITC.1	Конфиденциальность экспортируемых дынных при передаче

Таблица N 3. Перечень функциональных компонент класса FAU: Аудит безопасности

N пп.	Идентификатор*(5)	Описание	Применение	Зависимости
1	2	3	4	5
FAU_ARP.1 Сигналы нарушения безопасности
1.	FAU_ARP.1.1	Функции безопасности программного обеспечения должны информировать администратора при обнаружении возможного нарушения безопасности	Разработчик задания по безопасности для реализации программного обеспечения СУМиД или оборудования, входящего в ее состав, помимо непосредственно информирования администратора может перечислить и другие действия при обнаружении возможного нарушения безопасности	Класс FAU_SAA.1 Анализ потенциально-го нарушения
FAU_GEN.1 Генерация данных аудита
2.	FAU_GEN.1.1	Функции безопасности программного обеспечения должны генерировать запись аудита для следующих событий, потенциально подвергаемых аудиту: запуск и завершение выполнения функций аудита; все события, потенциально подвергаемые аудиту, на базовом уровне аудита; другие специально определенные события, подвергаемые аудиту		Отсутствуют
3.	FAU_GEN.1.2	Функции безопасности программного обеспечения должны регистрировать в каждой записи аудита следующую информацию: дата и время события, тип события, идентификатор субъекта, результат события (успешный или неуспешный); для каждого типа событий, потенциально подвергаемых аудиту, из числа определенных в функциональных компонентах, которые включены в задание по безопасности на конкретное программное обеспечение	Для всех событий, потенциально подвергаемых аудиту, на базовом уровне аудита разработчик задания по безопасности в рамках сертификации должен следовать инструкциям ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденного и введенного в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014 ), по включению в класс FAU_GEN.1 событий согласно выбранному уровню аудита, используя пункты в рубрике "Аудит" для каждого функционального компонента из ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденного и введенного в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014), включенного в задание по безопасности, и каждого компонента функциональных требований безопасности, определенных настоящими требованиями. Разработчик задания по безопасности может дополнительно указать другие события, которые программное обеспечение способно подвергать аудиту	Класс FPT_STM.1 Надежные метки времени
FAU_GEN.2 Ассоциация идентификатора пользователя
4.	FAU_GEN.2.1	Функции безопасности программного обеспечения должны быть способны ассоциировать каждое событие, потенциально подвергаемое аудиту, с идентификатором пользователя, который был инициатором этого события		Классы FAU_GEN.1 Генерация данных аудита; FIA_UID.1 Выбор момента идентификации
FAU_SAA.1 Анализ потенциального нарушения
5.	FAU_SAA.1.1	Функции безопасности программного обеспечения должны быть способны применить набор правил мониторинга событий, подвергающихся аудиту, и указать на возможное нарушение реализации функциональных требований безопасности, основываясь на этих правилах		Классы FAU_GEN.1 Генерация данных аудита; FIA_UID.1 Выбор момента идентификации
6.	FAU_SAA.1.2	Функции безопасности программного обеспечения должны осуществлять следующие правила при мониторинге событий, подвергающихся аудиту: накопление или объединение известных подмножество определенных событий, подвергаемых аудиту, указывающих на возможное нарушение безопасности; другие правила		Отсутствуют
FAU_SAR.1 Просмотр журналов аудита
7.	FAU_SAR.1.1	Функции безопасности программного обеспечения должны предоставлять уполномоченные идентифицирован-ные роли из состава ролей безопасности, возможность читать список информации аудита из записей аудита		Отсутствуют
8.	FAU_SAR.1.2	Функции безопасности программного обеспечения должны предоставлять записи аудита в виде, позволяющем пользователю воспринимать содержащуюся в них информацию		Класс FAU_GEN.1 Генерация данных аудита
FAU_SAR.2 Ограниченный просмотр журналов аудита
9.	FAU_SAR.2.1	Функции безопасности программного обеспечения должны предотвращать доступ к чтению записей аудита всем пользователям за исключением тех, кому явно предоставлен доступ на чтение		Класс FAU_SAR.1 Просмотр журналов аудита
FAU_SEL.1 Избирательный аудит
10.	FAU_SEL.1.1	Функции безопасности программного обеспечения должны обеспечить выбор совокупности событий, подвергающихся аудиту, из совокупности событий, потенциально подверженных аудиту, базируясь на следующих атрибутах: тип события; идентификатор субъекта или пользователя; результат (успех или отказ) операции, подверженной аудиту; список дополнительных атрибутов, определяемых в задании по безопасности на конкретное программное обеспечение		Классы FAU_GEN.1 Генерация данных аудита; FMT_MTD.1 Управление данными функций безопасности
FAU_STG.1 Защищенное хранение журнала аудита
11.	FAU_STG.1.1	Функции безопасности программного обеспечения должны защищать хранимые в журнале аудита записи от несанкционирован-ного удаления	Программное обеспечение может как обеспечивать хранение журналов аудита локально, так и обеспечивать передачу журналов на удаленные серверы централизованной системы журналирования для дальнейшей обработки. В последнем случае в системе реализуется локальный стек для записей аудита перед их отправкой на удаленные серверы, при этом к локальному стеку предъявляются все описанные выше требования	Отсутствуют
12.	FAU_STG.1.2	Функции безопасности программного обеспечения должны обнаруживать и предотвращать несанкционирован-ную модификацию хранимых записей в журналах аудита		Отсутствуют
FAU_STG.3 Действия в случае возможной потери данных аудита
13.	FAU_STG.3.1	Функции безопасности программного обеспечения должны обеспечить резервное копирование на внешние ресурсы журналов аудита, в случае если журналы аудита превышают допустимое ограничение		Класс FAU_STG.1 Защищенное хранение журналов аудита
FAU_STG.4 Предотвращение потери данных аудита
14.	FAU_STG.4.1	Функции безопасности программного обеспечения должны обеспечить удаление самой старой (по временному параметру) записи аудита и запись поверх нее новой при переполнении журнала аудита		Класс FAU_STG.1 Защищенное хранение журналов аудита

Таблица N 4. Перечень функциональных компонент класса FCS: Криптографическая защита

N пп.	Идентификатор*(6)	Описание	Применение	Зависимости
1	2	3	4	5
FСS_COP.1 Криптографические операции
1.	FCS_COP.1.1	Функции безопасности программного обеспечения должны поддерживать шифрование, расшифрование, контроль целостности и аутентификацию сторон в соответствии с одним из перечисленных криптографических алгоритмов: SSH с применением ГОСТ 28147-89. "Государственный стандарт Союза ССР. Системы обработки информации. Защита криптографическая. Алгоритм криптографическо-го преобразования", утвержденного и введенного в действие постановлением Госстандарта СССР от 02.06.1989 N 1409 (ИПК Издательство стандартов, 1996) (далее - ГОСТ 28147-89) c 256-битным ключом и ГОСТ Р 34.10-2012."Националь-ный стандарт Российской Федерации. Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи", утвержденного и введенного в действие приказом Росстандарта от 07.08.2012 N 215-ст (Стандартинформ, 2013) (далее - ГОСТ 34.10-2012) в качестве цифровой подписи; TLS с применением ГОСТ 28147-89 c 256-битным ключом и ГОСТ 34.10-2012 в качестве цифровой подписи; IPSEC с IKE, позволяющем применять ГОСТ 28147-89 c 256-битным ключом и ГОСТ 34.10-2012 в качестве цифровой подписи	Криптографические механизмы защиты реализуются в случае предоставления доступа к программному обеспечению или при обмене информацией по открытым каналам связи (каналам операторов связи сети связи общего пользования), а также в целях взаимной аутентификации с иными информационными системами с отличным от текущей по уровням доверия	Отсутствуют
2.	FCS_COP.1.2	Функции безопасности программного обеспечения должны поддерживать технологическую подпись данных и защиту целостности данных с применением криптографических алгоритмов: ГОСТ 34.10-2012, в качестве цифровой подписи и ГОСТ Р 34.11-2012. "Национальный стандарт Российской Федерации. Информационная технология. Криптографическая защита информации. Функция хэширования", утвержденного и введенного в действие приказом Росстандарта от 07.08.2012 N 216-ст (Стандартинформ, 2013) в качестве выработки хеш-функции		Отсутствуют

Таблица N 5. Перечень функциональных компонент класса FDP: Защита данных пользователя

N пп.	Идентификатор*(7)	Описание	Применение	Зависимости
1	2	3	4	5
FDP_ACC.1 Ограниченное управление доступом
1.	FDP_ACC.1.1	Функции безопасности программного обеспечения должны осуществлять ролевой контроль доступа для субъектов (пользователи системы, процессы), объектов (данные, обрабатываемые программным обеспечением), операций (все реализованные программным обеспечением операции)		Отсутствуют
FDP_ACF.1 Управление доступом, основанное на атрибутах безопасности
2.	FDP_ACF.1.1	Функции безопасности программного обеспечения должны осуществлять ролевой контроль доступа к объектам, основываясь на атрибутах безопасности субъекта: идентификатор пользователя/про-цессса, роль пользователя/про-цесса, атрибутах безопасности объекта: идентификатор объекта, разрешения для объекта		Отсутствуют
3.	FDP_ACF.1.2	Функции безопасности программного обеспечения должны реализовать следующие правила определения: разрешена ли операция управляемого субъекта на управляемом объекте, субъект должен быть связан с правами доступа к объекту в соответствии с назначенной ролью		Отсутствуют
4.	FDP_ACF.1.3	Функции безопасности программного обеспечения должны явно разрешать доступ субъектов к объектам, основываясь на атрибутах безопасности, которые явно разрешают доступ субъектов к объектам. Определение атрибутов безопасности осуществляется в соответствии с ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014)		Отсутствуют
5.	FDP_ACF.1.4	Функции безопасности программного обеспечения должны отказывать в доступе субъектов к объектам, если доступ не разрешён		Классы FDP_ACC.1 Ограниченное управление доступом; FMT_MSA.3 Инициализация статических атрибутов
FDP_IFC.2 Полное управление информационными потоками
6.	FDP_IFC.2.1	Функции безопасности программного обеспечения должны осуществлять контроль информационных потоков для: субъектов - неавторизованные внешние по отношению к программному обеспечению сущности (иные информационные системы), которые получают или передают информацию для обработки рассматриваемым программным обеспечением; информации - перечень обрабатываемой программным обеспечением информации и всеми операциями перемещения управляемой информации к управляемым субъектам, обрабатываемым программным обеспечением, и от них		Отсутствуют
FDP_IFF.1 Простые атрибуты безопасности
7.	FDP_IFF.1.1	Функции безопасности программного обеспечения должны осуществлять контроль информационных потоков, основанный на следующих атрибутах безопасности субъектов и информации: идентификатор пользователя или процесса; логический или физический сетевой интерфейс, по которому данные загружаются в систему; атрибуты безопасности стека протоколов TCP/IP: IP адрес источника и назначения, порт UDP источника и назначения, флаги в заголовках протокола TCP; атрибуты безопасности протокола IEEE 802.1Q VLAN: теги VLAN		Отсутствуют
8.	FDP_IFF.1.2	Функции безопасности программного обеспечения должны разрешать информационный поток для управляемого субъекта и управляемой информации посредством управляемой операции, если заданы правила обмена в следующем формате: перечень операций - список поддерживаемых отношений, основанный на атрибутах безопасности		Классы FDP_IFC.1 Ограниченное управление информационными потоками; FDP_MSA.3 Инициализа-ция статических атрибутов
FDP_ITC.2 Импорт данных пользователя с атрибутами безопасности
9.	FDP_ITC.2.1	Функции безопасности программного обеспечения должны осуществлять контроль информационных потоков и управление доступом при импорте данных пользователя из иного программного обеспечения		Отсутствуют
10.	FDP_ITC.2.2	Функции безопасности программного обеспечения должны использовать атрибуты безопасности, ассоциированные с импортируемыми данными пользователя		Отсутствуют
11.	FDP_ITC.2.3	Функции безопасности программного обеспечения должны обеспечить протокол интеграции, который предусматривает однозначную ассоциацию между атрибутами безопасности и полученными данными пользователя		Отсутствуют
12.	FDP_ITC.2.4	Функции безопасности программного обеспечения должны обеспечить интерпретацию атрибутов безопасности пользователя, как предусмотрено источником данных пользователя		Отсутствуют
FDP_ITT.1 Базовая защита внутренней передачи
13.	FDP_ITT.1.1	Функции безопасности программного обеспечения должны осуществлять контроль информационных потоков и управление доступом, чтобы предотвратить модификацию и недоступность данных при их передаче между физически разделенными компонентами аппаратной платформы, на которой функционирует программное обеспечение		Отсутствуют
FDP_ROL.2 Расширенный откат к исходному состоянию
14.	FDP_ROL.2.1	Функции безопасности программного обеспечения должны осуществлять управление доступом для разрешения возврата (отката) всех операций к определенному начальному состоянию		Отсутствуют
FDP_SDI.2 Мониторинг целостности хранимых данных и предпринимаемые действия
15.	FDP_SDI.2.1	Функции безопасности программного обеспечения должны контролировать данные, хранимые в местах хранения, контролируемых программным обеспечением, на наличие ошибок контрольных сумм для всех объектов		Отсутствуют
16.	FDP_SDI.2.2	При обнаружении ошибки целостности данных функции безопасности программного обеспечения должны обеспечить загрузку данных по умолчанию (эталонных)		Отсутствуют

Таблица N 6. Перечень функциональных компонент класса FIA: Идентификация и аутентификация

N пп.	Идентификатор*(8)	Описание	Применение	Зависимости
1	2	3	4	5
FIA_AFL.1 Обработка отказов аутентификации
1.	FIA_AFL.1.1	Функции безопасности программного обеспечения должны обнаруживать, когда произойдет три неуспешных попытки аутентификации, относящихся к вводу пароля пользователя		Отсутствуют
2.	FIA_AFL.1.2	При достижении определенного числа неуспешных попыток аутентификации функции безопасности программного обеспечения должны выполнить блокировку доступа пользователям на 30 минут		Класс FIA_UAU.1 Выбор момента аутентификации
FIA_ATD.1 Определение атрибутов пользователя
3.	FIA_ATD.1.1	Функции безопасности программного обеспечения должны поддерживать для каждого пользователя следующий список атрибутов безопасности: роль пользователя; сертификат пользователя, выданный доверенной стороной; иные атрибуты, определенные в рамках задания по безопасности на программное обеспечение		Отсутствуют
FIA_SOS.1 Верификация секретов
4.	FIA_SOS.1.1	Функции безопасности должны предоставить механизм для верификации, соответствующий следующей метрике: вероятность того, что секретная информация может быть обнаружена нарушителем в течение существования секрета должна быть меньше чем 20 процентов		Отсутствуют
FIA_UAU.2 Аутентификация до любых действий пользователя
5.	FIA_UAU.2.1	Функции безопасности должны требовать, чтобы каждый пользователь был успешно аутентифицирован до разрешения любого действия, выполняемого при посредничестве функций безопасности от имени этого пользователя		Класс FIA_UID.1 Выбор момента идентификации
FIA_UID.2 Идентификация до любых действий пользователя
6.	FIA_UID.2.1	Функции безопасности программного обеспечения должны требовать, чтобы каждый пользователь был успешно идентифицирован до разрешения любого действия, выполняемого при посредничестве функций безопасности от имени этого пользователя		Отсутствуют
FIA_USB.1 Связывание "пользователь-субъект"
7.	FIA_USB.1.1	Функции безопасности программного обеспечения должны ассоциировать атрибуты безопасности пользователя с субъектами, действующими от имени этого пользователя		Отсутствуют

Таблица N 7. Перечень функциональных компонент класса FMT: Управление безопасностью

N пп.	Идентификатор*(9)	Описание	Применение	Зависимости
1	2	3	4	5
FMT_MSA.1 Управление атрибутами безопасности
1.	FMT_MSA.1.1	Функции безопасности программного обеспечения должны осуществлять управление доступом, основанное на ролях, чтобы ограничить возможность модификации, изменения значений по умолчанию атрибутов безопасности объектов программного обеспечения, только владельцам объектов		Классы FDP_ACC.1 Ограниченное управление доступом или FDP_IFC.1 Ограниченное управление информационными потоками; FMT_SMR.1 Роли безопасности
FMT_MSA.3 Инициализация статических атрибутов
2.	FMT_MSA.3.1	Функции безопасности должны осуществлять управление доступом, основанное на ролях, чтобы обеспечить ограничительные значения по умолчанию для атрибутов безопасности, которые используются для реализации требований безопасности		Отсутствуют
3.	FMT_MSA.3.2	Функции безопасности должны предоставлять возможность уполномоченному пользователю в соответствии с его ролью определять альтернативные начальные значения для отмены значений по умолчанию при создании объекта или информации		Классы FMT_MSA.1 Управление атрибутами безопасности; FMT_SMR.1 Роли безопасности
FMT_MTD.1 Управление данными функций безопасности
4.	FMT_MTD.1.1	Функции безопасности программного обеспечения должны ограничивать возможность модификации следующих данных: текущее значение времени, показания счетчиков команд, записи журнала аудита информационной безопасности только администраторам информационной безопасности		Класс FMT_SMR.1 Роли безопасности
FMT_REV.1 Отмена атрибутов безопасности
5.	FMT_REV.1.1	Функции безопасности программного обеспечения должны предоставлять возможность отмены атрибутов безопасности, ассоциированных с пользователями, субъектами и объектами программного обеспечения для администратора информационной безопасности		Отсутствуют
FMT_SMF.1 Спецификация функций управления
6.	FMT_SMF.1.1	Функции безопасности программного обеспечения должны быть способны к выполнению следующих функций управления: резервное копирование конфигурации, загрузка резервной копии конфигурации		Отсутствуют
FMT_SMR.1 Роли безопасности
7.	FMT_SMR.1.1	Функции безопасности программного обеспечения должны поддерживать следующие роли по умолчанию: администратор; администратор информационной безопасности; оператор		Класс FIA_UID.1 Выбор момента идентификации

Таблица N 8. Перечень функциональных компонент класса FPT: Защита функций безопасности объекта энергетики

N пп.	Идентификатор*(10)	Описание	Применение	Зависимости
1	2	3	4	5
FPT_STM.1 Надежные метки времени
1.	FPT_STM.1.1	Функции безопасности программного обеспечения должны быть способны предоставлять надежные метки времени для собственного использования		Отсутствуют
FPT_ITC.1 Конфиденциальность экспортируемых данных при передаче
2.	FPT_ITC.1.1	Функции безопасности программного обеспечения должны обеспечить конфиденциальность всех данных, передаваемых от функций безопасности программного обеспечения другому доверенному программному продукту		Отсутствуют
FPT_TDC.1 Базовая согласованность данных функций безопасности объекта между функциями безопасности
3.	FPT_TDC.1.1	Функции безопасности программного обеспечения должны обеспечить способность согласованно интерпретировать типы данных функций безопасности, совместно используемые с другим доверенным программным продуктом		Отсутствуют

Таблица N 9. Перечень функциональных компонент класса FTA: Доступ к программному обеспечению

N пп.	Идентификатор*(11)	Описание	Применение	Зависимости
1	2	3	4	5
FTA_SSL.1 Блокирование сеанса, инициированное функциями безопасности
1.	FTA_SSL.1.1	Функции безопасности программного обеспечения должны блокировать интерактивный сеанс после 30 минут бездействия пользователя, для чего предпринимаются следующие действия: очистка или перезапись устройств отображения, придание их текущему содержанию нечитаемого вида; блокирование любых действий по доступу к данным пользователей/ устройствам отображения кроме необходимых для разблокировки сеанса		Отсутствуют
FTA_SSL.2 Блокирование сеанса, инициированное пользователем
2.	FTA_SSL.2.1	Функции безопасности программного обеспечения должны допускать инициированное пользователем блокирование своего интерактивного сеанса, для чего предпринимаются следующие действия: очистка или перезапись устройств отображения, придание их текущему содержанию нечитаемого вида; блокирование любых действий по доступу к данным пользователей/ устройствам отображения кроме необходимых для разблокировки сеанса		Отсутствуют

Приложение N 6
к требованиям в отношении базовых (обязательных) функций
и информационной безопасности объектов электроэнергетики при создании
и последующей эксплуатации на территории Российской Федерации
систем удаленного мониторинга и диагностики энергетического оборудования,
утвержденным приказом Минэнерго России
от "__" ________2018 года N "____"

ПЕРЕЧЕНЬ
классов и компонент доверия к информационной безопасности систем удаленного мониторинга и диагностики энергетического оборудования

Таблица N 1. Взаимосвязь классов доверия и компонентов доверия к информационной безопасности систем удаленного мониторинга и диагностики энергетического оборудования (далее - СУМиД)

N пп	Класс доверия	Компонент доверия
1	2	3
1.	ADV: Разработка	ADV_ARC.1 Описание архитектуры безопасности
		ADV_FSP.4 Полная функциональная специфика
		ADV_IMP.1 Представление реализации функции безопасности объекта оценки (далее - ФБО)
		ADV_TDS.3 Базовый модульный проект
2.	AGD: Руководства	AGD_OPE.1 Руководство пользователя по эксплуатации
		AGD_PRE.1 Подготовительные процедуры
3.	ALC: Поддержка жизненного цикла	ALC_CMC.4 Поддержка производства, процедуры приемки и автоматизации
		ALC_CMS.4 Охват управления конфигурацией (УК) отслеживания проблем
		ALC_CMC.2 Использование системы УК
		ALC_DEL.1 Процедуры поставки
		ALC_DVS.1 Идентификация мер безопасности
		ALC_LCD.1 Определенная разработчиком модель жизненного цикла
		ALC_TAT.1 Полностью определенные инструментальные средства разработки
4.	ASE: Оценка задания по безопасности (ЗБ)	ASE_CCL.1 Утверждения о соответствии
		ASE_ECD.1 Определение расширенных компонентов
		ASE_INT.1 Введение ЗБ
		ASE_OBJ.2 Цели безопасности
		ASE_REQ.2 Производные требования безопасности
		ASE_SPD.1 Определение проблемы безопасности
		ASE_TSS.1 Краткая спецификация объекта оценки (ОО)
5.	ATE: Тестирование	ATE_COV.2 Анализ покрытия
		ATE_DPT.2 Тестирование: модули обеспечения безопасности
		ATE_FUN.1 Функциональное тестирование
		ATE_IND.2 Выборочное независимое тестирование
6.	AVA: Оценка уязвимостей	AVA_VAN.3 Сосредоточенный анализ уязвимостей

Таблица N 1. Оценка уровня доверия класса ADV: Разработка

N пп	Компонент доверия	Зависимости	Элементы действий разработчика		Элементы содержания и представления свидетельств		Элементы действий оценщика
			Идентификатор*(12)	Описание	Идентификатор	Описание	Идентификатор	Описание
1	2	3	4	5	6	7	8	9
1.	ADV_ARC.1 Описание архитектуры безопаснос-ти	ADV_FSP.1 Базовая функциональная специфика-ция; ADV_TDS.1 Базовый проект	ADV_ARC.1.1D                                                         ADV_ARC.1.2D                                                                 ADV_ARC.1.3D	Разработчик должен спроектиро-вать ОО и обеспечить реализацию проекта таким образом, чтобы свойства безопасности ФБО невозможно было обойти;     Разработчик должен спроектиро-вать ФБО и обеспечить их реализацию таким образом, чтобы ФБО обеспечивали собственную защиту от вмешательст-ва недоверенных сущностей;     Разработчик должен предоставить "Описание архитектуры безопаснос-ти" ФБО	ADV_ARC.1.1C	Уровень детализации "Описания архитектуры безопасности" должен соответствовать представленному в проектной документации по ОО описанию абстракций (элементов представления ОО), осуществляющих выполнение функциональные требования безопасности (далее - ФТБ)	ADV_ARC.1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ADV_ARC.1.2C	В "Описание архитектуры безопасности" должно быть включено описание доменов безопасности, обеспеченных согласованностью ФБО с ФТБ
					ADV_ARC.1.3C	"Описание архитектуры безопасности" должно предоставлять информацию о том, насколько процесс инициализации ФБО является защищенным
					ADV_ARC.1.4C	В "Описании архитектуры безопасности" должно быть продемонстрировано, что ФБО обеспечивают собственную защиту от вмешательства
					ADV_ARC.1.5C	В "Описании архитектуры безопасности" должно быть продемонстрировано, что ФБО не допускают возможности обхода функциональных возможностей, осуществляющих выполнение ФТБ
2.	ADV_FSP.4 Полная функцио-нальная специфика-ция	ADV_TDS.1 Базовый проект	ADV_FSP.4.1D                             ADV_FSP.4.2D	Разработчик должен представить функциональ-ную специфика-цию;     Разработчик должен представить прослежива-ние функциональ-ной специфика-ции к функциональ-ным требованиям безопасности	ADV_FSP.4.1C	В функциональной спецификации должны быть полностью представлены ФБО	ADV_FSP.4.1E                                     ADV_FSP.4.2E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств;     Оценщик должен сделать независимое заключение, что функциональная спецификация является точным и полным отображением функциональных требований безопасности ОО
					ADV_FSP.4.2C	В функциональной спецификации должны быть описаны назначение и метод использования всех интерфейсов функции безопасности объекта оценки (далее -ИФБО)
					ADV_FSP.4.3C	В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО
					ADV_FSP.4.4C	В функциональной спецификации должны быть описаны все действия, связанные с каждым ИФБО
					ADV_FSP.4.5C	Функциональная спецификация должна содержать описание сообщений обо всех непосредственных ошибках, которые могут возникнуть при вызове каждого ИФБО
					ADV_FSP.4.6C	В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации
3.	ADV_IMP.1 Представле-ние реализации ФБО	ADV_TDS.3 Базовый модульный проект; ALC_TAT.1 Полностью определенные инструмен-тальные средства разработки	ADV_IMP.1.1D                                 ADV_IMP.1.2D	Разработчик должен обеспечить представле-ние реализации для всех ФБО;     Разработчик должен обеспечить прослежива-ние выборки представле-ния реализации к описанию проекта ОО	ADV_IMP.1.1C	Представление реализации должно определить ФБО на таком уровне детализации, что ФБО могут быть созданы без дополнительных проектных решений	ADV_IMP.1.1E	Оценщик должен подтвердить, что для выборки представления реализации представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ADV_IMP.1.2C	Представление реализации должно быть изложено в том виде, какой используется персоналом, занимающимся разработкой
					ADV_IMP.1.3C	В прослеживании между выборкой представления реализации и описанием проекта ОО должно быть продемонстрировано их соответствие
4.	ADV_TDS.3 Базовый модульный проект	ADV_FSP.4 Полная функциональ-ная спецификация	ADV_TDS.3.1D                 ADV_TDS.3.2D	Разработчик должен представить проект ОО;     Разработчик должен обеспечить прослежива-ние ИФБО в функциональ-ной специфика-ции к более низкому уровню декомпози-ции, представлен-ному в проекте ОО	ADV_TDS.3.1C	В проекте должно приводиться описание структуры ОО на уровне подсистем	ADV_TDS.3.1E                                     ADV_TDS.3.2E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств;     Оценщик должен сделать независимое заключение, что проект является точным и полным отображением всех функциональных требований безопасности
					ADV_TDS.3.2C	В проекте должно приводиться описание структуры ОО на уровне модулей
					ADV_TDS.3.3C	В проекте должны быть идентифицированы все подсистемы ФБО
					ADV_TDS.3.4C	В проекте должно приводиться описание каждой из подсистем ФБО
					ADV_TDS.3.5C	В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой
					ADV_TDS.3.6C	В проекте должно быть осуществлено прослеживание подсистем ФБО с модулями ФБО
					ADV_TDS.3.7C	В проекте должен быть описан каждый осуществляющий выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями
					ADV_TDS.3.8C	В проекте должен быть описан каждый осуществляющий выполнение ФТБ модуль с точки зрения его относящихся к ФТБ интерфейсов, значений, предоставляемых этими интерфейсами в ответ на запросы, взаимодействий с другими модулями и вызываемыми интерфейсами этих модулей
					ADV_TDS.3.9C	В проекте должен быть описан каждый поддерживающий и не влияющий на выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями
					ADV_TDS.3.10C	В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО

Таблица N 2. Оценка уровня доверия класса AGD: Руководства

N пп	Компонент доверия	Зависимости	Элементы действий разработчика		Элементы содержания и представления свидетельств		Элементы действий оценщика
			Идентификатор*(13)	Описание	Идентификатор	Описание	Идентификатор	Описание
1	2	3	4	5	6	7	8	9
1.	AGD_OPE.1 Руководство пользовате-ля по эксплуа-тации	ADV_FSP.1 Базовая функциональ-ная спецификация	AGD_OPE.1.1D	Разработчик должен представить руководство пользователя по эксплуатации	AGD_OPE.1.1C	В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть представлено описание доступных пользователям функций, возможных прав и обязанностей, которыми следует управлять в защищенной среде функционирования, а также уместных предупреждений	AGD_OPE1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					AGD_OPE.1.2C	В руководстве пользователя по эксплуатации в рамках каждой пользовательской роли должно быть представлено описание принципов безопасной работы с предоставленными в ОО интерфейсами
					AGD_OPE.1.3C	В руководстве пользователя по эксплуатации должно быть представлено описание доступных для каждой пользовательской роли функций и интерфейсов, особенно всех параметров безопасности под управлением пользователя, с указанием безопасных значений, если это уместно
					AGD_OPE.1.4C	В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть представлено четкое представление каждого типа имеющих значение для безопасности событий, связанных с доступными пользователю обязательными для выполнения функциями, включая изменение характеристик безопасности сущностей, находящихся под управлением ФБО
					AGD_OPE.1.5C	В руководстве пользователя по эксплуатации должны быть идентифицированы все возможные режимы работы ОО (включая операции после сбоев и ошибок эксплуатации), их последствия и участие в обеспечении безопасного функционирования
					AGD_OPE.1.6C	В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть описание всех мер безопасности, предназначенных для выполнения целей безопасности для среды функционирования согласно описанию в ЗБ
					AGD_OPE.1.7C	Руководство пользователя по эксплуатации должно быть четким и обоснованным
2.	AGD_PRE.1 Подготови-тельные процедуры	Отсутствуют	AGD_PRE.1.1D	Разработчик должен предоставить ОО вместе с подготови-тельными процедурами	AGD_PRE.1.1C	В подготовительных процедурах должны описываться все шаги, необходимые для безопасной приемки поставленного ОО в соответствии с процедурами поставки разработчика	AGD_PRE.1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					AGD_PRE.1.2C	В подготовительных процедурах должны описываться все необходимые шаги для безопасной установки ОО и безопасной подготовки среды функционирования в соответствии с целями безопасности для среды функционирования, описанными в ЗБ	AGD_PRE.1.2E	Оценщик должен использовать подготовительные процедуры для подтверждения того, что ОО может быть безопасно подготовлен к работе

Таблица N 3. Оценка уровня доверия класса ALC: Поддержка жизненного цикла

N пп	Компонент доверия	Зависимости	Элементы действий разработчика		Элементы содержания и представления свидетельств		Элементы действий оценщика
			Идентификатор*(14)	Описание	Идентификатор	Описание	Идентификатор	Описание
1	2	3	4	5	6	7	8	9
1.	ALC_DVS.1 Идентифи-кация мер безопаснос-ти	Отсутствуют	ALC_DVS.1.1D	Разработчик должен представить документа-цию по безопасности разработки	ALC_DVS.1.1C	Документация по безопасности разработки должна содержать описание всех физических, процедурных, организационных и других мер безопасности, которые необходимы для защиты конфиденциальности и целостности проекта ОО и его реализации в среде разработки	ALC_DVS.1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
							ALC_DVS.1.2E	Оценщик должен подтвердить, что меры безопасности применяются
2.	ALC_LCD.1 Определен-ная разработчи-ком модель жизненного цикла	Отсутствуют	ALC_LCD.1.1D	Разработчик должен установить модель жизненного цикла, используе-мую при разработке и сопровожде-нии ОО	ALC_LCD.1.1C	Документация по определению жизненного цикла должна содержать описание модели, применяемой при разработке и сопровождении ОО	ALC_LCD.1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
			ALC_LCD.1.2D	Разработчик должен представить документа-цию по определению жизненного цикла	ALC_LCD.1.2C	Модель жизненного цикла должна обеспечить необходимый контроль над разработкой и сопровождением ОО
3.	ALC_TAT.1 Полностью определен-ные инструмен-тальные средства разработки	ADV_IMP.1 Подмножест-во реализации ФБО	ALC_TAT.1.1D                                         ALC_TAT.1.2D	Разработчик должен идентифицировать каждое инструментальное средство, используемое для разработки ОО;     Разработчик должен задокументи-ровать выбранные опции инструмен-тальных средств разработки, обусловлен-ные реализацией	ALC_TAT.1.1C	Все инструментальные средства разработки, используемые для реализации, должны быть полностью определены	ALC_TAT.1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ALC_TAT.1.2C	В документации по инструментальным средствам разработки должны быть однозначно определены значения всех языковых конструкций, используемых в реализации
					ALC_TAT.1.3C	В документации по инструментальным средствам разработки должны быть однозначно определены значения всех опций, обусловленных реализацией
4.	ALC_CMC.4 Поддержка генерации, процедуры приемки и автоматиза-ция	ALC_CMS.1 Охват УК ОО;     ALC_DVS.1 Идентифика-ция мер безопасности;     ALC_LCD.1 Определенная разработчи-ком модель жизненного цикла	ALC_CMC.4.1D                         ALC_CMC.4.2D                     ALC_CMC.4.3D	Разработчик должен предоставить ОО и маркировку для ОО;     Разработчик должен предоставить документа-цию УК;     Разработчик должен использовать систему УК	ALC_CMC.4.1C	ОО должен быть помечен уникальной маркировкой	ALC_CMC.4.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ALC_CMC.4.2C	В документации УК должно содержаться описание метода, используемого для уникальной идентификации элементов конфигурации
					ALC_CMC.4.3C	В системе УК должны быть уникальным образом идентифицированы все элементы конфигурации
					ALC_CMC.4.4C	В системе УК должны быть предусмотрены такие автоматизированные меры, при применении которых в элементы конфигурации могут быть внесены только санкционированные изменения
					ALC_CMC.4.5C	Система УК должна поддерживать производство ОО автоматизированными средствами
					ALC_CMC.4.6C	Документация УК должна включать в себя план УК
					ALC_CMC.4.7C	В плане УК должно быть описание того, каким образом система УК используется для разработки ОО
					ALC_CMC.4.8C	План УК должен содержать описание процедур, используемых для приемки модифицированных или вновь созданных элементов конфигурации как части ОО
					ALC_CMC.4.9C	В свидетельствах должно быть продемонстрирова-но, что все элементы конфигурации сопровождаются системой УК
					ALC_CMC.4.10C	В свидетельствах должно быть продемонстрирова-но, что система УК функционирует в соответствии с планом УК
5.	ALC_CMS.4 Охват УК отслежива-ния проблем	Отсутствуют	ALC_CMS.4.1D	Разработчик должен представить список элементов конфигурации для ОО	ALC_CMS.4.1C	Список элементов конфигурации должен включать следующее: сам ОО; свидетельства оценки, необходимые по требованиям доверия к безопасности; представление реализации; сведения о недостатках безопасности и стадии их устранения	ALC_CMS.4.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ALC_CMS.4.2C	Элементы конфигурации должны быть уникально идентифицированы в списке элементов конфигурации
					ALC_CMS.4.3C	Для каждого значимого для ФБО элемента конфигурации в списке элементов конфигурации должен быть указан разработчик
6.	ALC_DEL.1 Процедуры поставки	Отсутствуют	ALC_DEL.1.1D	Разработчик должен задокументи-ровать процедуры поставки ОО или его частей потребителю	ALC_DEL.1.1C	Документация поставки должна содержать описание всех процедур, необходимых для поддержания безопасности при распространении версий ОО потребителю	ALC_DEL.1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
			ALC_DEL.1.2D	Разработчик должен использовать процедуры поставки

Таблица N 4. Оценка уровня доверия класса ASE: Оценка задания по безопасности

N пп	Компонент доверия	Зависимости	Элементы действий разработчика		Элементы содержания и представления свидетельств		Элементы действий оценщика
			Идентификатор*(15)	Описание	Идентификатор	Описание	Идентификатор	Описание
1	2	3	4	5	6	7	8	9
1.	ASE_CCL.1 Утвержде-ния о соответст-вии	ASE_INT.1 Введение ЗБ;     ASE_ECD.1 Определение расширенных компонентов;     ASE_REQ.1 Установлен-ные требования безопасности	ASE_CCL.1.1D                             ASE_CCL.1.2D	Разработчик должен представить "Утвержде-ния о соответст-вии";     Разработчик должен представить "Обоснование утверждений о соответствии"	ASE_CCL.1.1C	В "Утверждения о соответствии" должно быть включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой части ГОСТ Р ИСО/МЭК 15408 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий", утвержденного и введенного в действие приказами Росстандарта от 08.11.2013 N 1339-ст, 08.11.2013 N 1340-ст (Стандартинформ 2014) (далее - ИСО/МЭК 15408) утверждается соответствие ЗБ и ОО	ASE_CCL.1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ASE_CCL.1.2C	В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ЗБ ГОСТ Р ИСО/МЭК 15408-2 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденный и введенный в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014) (далее - ИСО/МЭК 15408-2); ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-2, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-2 требования
					ASE_CCL.1.3C	В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия профилю защиты (ПЗ) ГОСТ Р ИСО/МЭК 15408-3 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1340-ст (Стандартинформ, 2014) (далее - ИСО/МЭК 15408-3); ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-3, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-3 требования
					ASE_CCL.1.4C	"Утверждение о соответствии ИСО/МЭК 15408" должно согласовываться с "Определением расширенных компонентов"
					ASE_CCL.1.5C	В "Утверждении о соответствии" должны быть идентифицированы все ПЗ и пакеты требований безопасности, о соответствии которым утверждается в ЗБ
					ASE_CCL.1.6C	В "Утверждении о соответствии ЗБ пакету требований" должно приводиться описание любого соответствия ЗБ некоторому пакету требований; ЗБ либо описывается как соответствующее пакету требований, либо как содержащее расширенные по отношению к пакету требования
					ASE_CCL.1.7C	В "Обосновании утверждений о соответствии" должно быть продемонстрирова-но, что тип ОО согласуется с типом ОО в тех ПЗ, о соответствии которым утверждается
					ASE_CCL.1.8C	В "Обосновании утверждений о соответствии" должно быть продемонстрирова-но, что изложение "Определения проблемы безопасности" согласуется с изложением "Определения проблемы безопасности" в тех ПЗ, о соответствии которым утверждается
					ASE_CCL.1.9C	В "Обосновании утверждений о соответствии" должно быть продемонстрирова-но, что изложение "Целей безопасности" согласуется с изложением "Целей безопасности" в тех ПЗ, о соответствии которым утверждается
					ASE_CCL.1.10C	В "Обосновании утверждений о соответствии" должно быть продемонстрирова-но, что изложение "Требований безопасности" согласуется с изложением "Требований безопасности" в тех ПЗ, о соответствии которым утверждается
2.	ASE_ECD.1 Определе-ние расширен-ных компонентов	Отсутствуют	ASE_ECD.1.1D                             ASE_ECD.1.2D	Разработчик должен представить изложение "Требований безопаснос-ти";     Разработчик должен представить "Определение расширенных компонентов"	ASE_ECD.1.1C	В изложении "Требований безопасности" должны быть идентифицированы все расширенные требования безопасности	ASE_ECD.1.1E                                     ASE_ECD.1.2E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств;     Оценщик должен подтвердить, что ни один из расширенных компонентов не может быть четко выражен с использованием существующих компонентов
					ASE_ECD.1.2C	В "Определении расширенных компонентов" должен определяться расширенный компонент для каждого расширенного требования безопасности
					ASE_ECD.1.3C	В "Определении расширенных компонентов" должно указываться, как каждый расширенный компонент связан с существующими компонентами, семействами и классами ИСО/МЭК 15408
					ASE_ECD.1.4C	В "Определении расширенных компонентов" должны использоваться в качестве модели представления компоненты, семейства, классы и методология ИСО/МЭК 15408
					ASE_ECD.1.5C	Расширенные компоненты должны состоять из измеримых объективных элементов, чтобы была возможность продемонстрировать соответствие или несоответствие этим элементам
3.	ASE_INT.1 Введение ЗБ	Отсутствуют	ASE_INT.1.1D	Разработчик ЗБ должен представить "Введение ЗБ"	ASE_INT.1.1C	"Введение ЗБ" должно содержать "Ссылку на ЗБ", "Ссылку на ОО", "Аннотацию ОО" и "Описание ОО"	ASE_INT.1.1E                                     ASE_INT.1.2E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств;     Оценщик должен подтвердить, что "Ссылка на ОО", "Аннотация ОО" и "Описание ОО" не противоречат друг другу
					ASE_INT.1.2C	"Ссылка на ЗБ" должна однозначно идентифицировать ЗБ
					ASE_INT.1.3C	"Ссылка на ОО" должна однозначно идентифицировать ОО
					ASE_INT.1.4C	В "Аннотации ОО" должна быть представлена краткая информация о его использовании и основных функциональных возможностях безопасности ОО
					ASE_INT.1.5C	В "Аннотации ОО" должен быть идентифицирован тип ОО
					ASE_INT.1.6C	В "Аннотации ОО" должны быть идентифицированы любые не входящие в ОО аппаратные, программные, а также программно-аппаратные средства, требуемые ОО
					ASE_INT.1.7C	"Описание ОО" должно включать описание физических границ ОО
					ASE_INT.1.8C	"Описание ОО" должно включать описание логических границ ОО
4.	ASE_OBJ.2 Цели безопаснос-ти	ASE_SPD.1 Определение проблемы безопасности	ASE_OBJ.2.1D                             ASE_OBJ.2.2D	Разработчик должен предоставить "Определение целей безопаснос-ти";     Разработчик должен предоставить "Обоснование целей безопаснос-ти"	ASE_OBJ.2.1C	Изложение "Целей безопасности" должно включать в себя описание целей безопасности для ОО и для среды функционирования ОО	ASE_OBJ.2.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ASE_OBJ.2.2C	В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, и к политике безопасности организации (далее - ПБОр), на осуществление которых направлена эта цель безопасности
					ASE_OBJ.2.3C	В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, к ПБОр, на осуществление которых направлена эта цель безопасности, а также к предположениям, поддерживаемым данной целью безопасности
					ASE_OBJ.2.4C	В "Обосновании целей безопасности" должно быть продемонстрирова-но, что цели безопасности направлены на противостояние всем идентифицирован-ным угрозам
					ASE_OBJ.2.5C	В "Обосновании целей безопасности" должно быть продемонстрирова-но, что цели безопасности направлены на осуществление всех ПБОр
					ASE_OBJ.2.6C	В "Обосновании целей безопасности" должно быть продемонстрирова-но, что цели безопасности для среды функционирования поддерживают все предположения
5.	ASE_REQ.2 Производ-ные требования безопаснос-ти	ASE_OBJ.2 Цели безопасности;     ASE_ECD.1 Определение расширенных компонентов	ASE_REQ.2.1D                             ASE_REQ.2.2D	Разработчик должен представить "Определение требований безопаснос-ти";     Разработчик должен представить "Обоснование требований безопаснос-ти"	ASE_REQ.2.1C	Изложение "Требований безопасности" должно содержать описание ФТБ и требований доверия к безопасности объекта оценки (далее - ТДБ)	ASE_REQ.2.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ASE_REQ.2.2C	Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, использующиеся в ФТБ и ТБД, должны быть определены
					ASE_REQ.2.3C	В изложении "Требований безопасности" должны быть идентифицированы все выполненные над требованиями безопасности операции
					ASE_REQ.2.4C	Все операции должны выполняться правильно
					ASE_REQ.2.5C	Каждая зависимость от "Требований безопасности" должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения зависимости
					ASE_REQ.2.6C	В "Обосновании требований безопасности" должно быть представлено прослеживание каждого ФТБ к целям безопасности для ОО
					ASE_REQ.2.7C	"Обосновании требований безопасности" должно быть продемонстриро-вано, что ФТБ обеспечивают выполнение всех целей безопасности для ОО
					ASE_REQ.2.8C	В "Обосновании требований безопасности" должно приводиться пояснение того, почему выбраны определенные ТДБ
					ASE_REQ.2.9C	Изложение "Требований безопасности" должно быть внутренне непротиворечивым
6.	ASE_SPD.1 Определе-ние проблемы безопаснос-ти	Отсутствуют	ASE_SPD.1.1D	Разработчик должен представить "Определе-ние проблемы безопаснос-ти"	ASE_SPD.1.1C	"Определение проблемы безопасности" должно включать в себя описание угроз	ASE_SPD.1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ASE_SPD.1.2C	Описание всех угроз должно проводиться в терминах источника угрозы, активов и негативного действия
					ASE_SPD.1.3C	В "Определение проблемы безопасности" должно быть включено описание ПБОр
					ASE_SPD.1.4C	"Определение проблемы безопасности" должно содержать описание предположений относительно среды функционирования ОО
7.	ASE_TSS.1 Краткая специфика-ция ОО	ASE_INT.1 Введение ЗБ;     ASE_REQ.1 Установлен-ные требования безопасности	ASE_TSS.1.1D	Разработчик должен представить краткую специфика-цию ОО	ASE_TSS.1.1C	Краткая спецификация ОО должна описывать, каким образом ОО выполняет каждое ФТБ	ASE_TSS.1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
							ASE_TSS.1.2E	Оценщик должен подтвердить, что краткая спецификация ОО не противоречит "Аннотации ОО" и "Описанию ОО"

Таблица N 5. Оценка уровня доверия класса ATE: Тестирование

N пп	Компонент доверия	Зависимости	Элементы действий разработчика		Элементы содержания и представления свидетельств		Элементы действий оценщика
			Идентификатор*(16)	Описание	Идентификатор	Описание	Идентификатор	Описание
1	2	3	4	5	6	7	8	9
1.	ATE_COV.2 Анализ покрытия	ADV_FSP.2 Детализация вопросов безопасности в функциональ-ной специфика-ции;     ATE_FUN.1 Функциональ-ное тестирование	ATE_COV.2.1D	Разработчик должен представить анализ покрытия тестами	ATE_COV.2.1C	Анализ покрытия тестами должен демонстрировать соответствие между тестами из тестовой документации и ИФБО из функциональной спецификации	ATE_COV.2.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ATE_COV.2.2C	Анализ покрытия тестами должен демонстрировать, что все ИФБО из функциональной спецификации были подвергнуты тестированию
					ATE_DPT.1.1C	Анализ глубины должен показать достаточность тестов, идентифицирован-ных в тестовой документации, для демонстрации, что функции безопасности выполняются в соответствии с проектом верхнего уровня
2.	ATE_FUN.1 Функцио-нальное тестирова-ние	ATE_COV.1 Свидетельст-во покрытия	ATE_FUN.1.1D                             ATE_FUN.1.2D	Разработчик должен протестиро-вать ФБО и задокументи-ровать результаты;     Разработчик должен представить тестовую документа-цию	ATE_FUN.1.1C	Тестовая документация должна состоять из планов тестирования, а также ожидаемых и фактических результатов тестирования	ATE_FUN.1.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ATE_FUN.1.2C	В планах тестирования должны быть идентифицированы тесты, которые необходимо выполнить, а также должны содержаться описания сценариев проведения каждого теста. В эти сценарии должны быть включены также любые зависимости последовательности выполнения тестов от результатов других тестов
					ATE_FUN.1.3C	Ожидаемые результаты тестирования должны продемонстрировать прогнозируемые данные на выходе успешного выполнения тестов
					ATE_FUN.1.4C	Фактические результаты тестирования должны соответствовать ожидаемым
3.	ATE_IND.2 Выборочное независимое тестирова-ние	ADV_FSP.2 Детализация вопросов безопасности в функцио-нальной специфика-ции;     ATE_FUN.1 Функцио-нальное тестирование;     AGD_OPE.1 Руководство пользователя по эксплуатации;     AGD_PRE.1 Подготови-тельные процедуры	ATE_IND.2.1D	Разработчик должен представить ОО для тестирования	ATE_IND.2.1C             ATE_IND.2.2C	ОО должен быть пригоден для тестирования;     Разработчик должен представить набор ресурсов, эквивалентных использованным им при функциональном тестировании ФБО	ATE_IND.2.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
							ATE_IND.2.2E	Оценщик должен выполнить выборку тестов из тестовой документации, чтобы верифицировать результаты тестирования, полученные разработчиком
							ATE_IND.2.3E	Оценщик должен протестировать подмножество ФБО так, чтобы подтвердить, что ФБО функционируют в соответствии со спецификациями
4.	ATE_DPT.2 Тестирова-ние: модули, осуществ-ляющие безопас-ность	ADV_ARC.1 Описание архитектуры безопасности;     ADV_TDS.3 Базовый модульный проект;     ATE_FUN.1 Функциональ-ное тестирование;     ATE_COV.1 Свидетельст-во покрытия	ATE_DPT.2.1D	Разработчик должен представить анализ глубины тестирования	ATE_DPT.2.1C	Анализ глубины тестирования должен демонстрировать соответствие между тестами в тестовой документации и подсистемами ФБО, а также осуществляющими выполнение ФТБ модулями из проекта ОО	ATE_DPT.2.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
					ATE_DPT.2.2C	Анализ глубины тестирования должен демонстрировать, что все подсистемы ФБО из проекта ОО были подвергнуты тестированию
					ATE_DPT.2.3C	Анализ глубины тестирования должен демонстрировать, что осуществляющие выполнение ФТБ модули из проекта ОО были подвергнуты тестированию

Таблица N 6. Оценка уровня доверия класса AVA: Оценка уязвимостей

N пп	Компонент доверия	Зависимости	Элементы действий разработчика		Элементы содержания и представления свидетельств		Элементы действий оценщика
			Идентификатор*(17)	Описание	Идентификатор	Описание	Идентификатор	Описание
1	2	3	4	5	6	7	8	9
1.	AVA_VAN.3 Фокусиро-ванный анализ уязвимостей	ADV_ARC.1 Описание архитектуры безопасности;     ADV_FSR.2 Детализация вопросов безопасности в функцио-нальной специфика-ции;     ADV_TDS.3 Базовый модульный проект;     ADV_IMP.1 Представле-ние реализации ФБО;     AGD_OPE.1 Руководство пользователя по эксплуатации AGD_PRE.1 Подготови-тельные процедуры	AVA_VAN.3.1D	Разработчик должен представить ОО для тестирования	AVA_VAN.3.1C	ОО должен быть пригоден для тестирования	AVA_VAN.3.1E	Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств
							AVA_VAN.3.2E	Оценщик должен выполнить поиск информации в общедоступных источниках, чтобы идентифициро-вать потенциальные уязвимости в ОО
							AVA_VAN.3.3E	Оценщик должен провести независимый анализ уязвимостей ОО с использованием документации руководств, функциональной спецификации, проекта ОО, описания архитектуры безопасности и представления реализации, чтобы идентифициро-вать потенциальные уязвимости в ОО
							AVA_VAN.3.4E	Оценщик должен провести тестирование проникновения, основанное на идентифициро-ванных уязвимостях, чтобы сделать заключение, что ОО является стойким к нападениям, выполняемым нарушителем, обладающим Усиленным базовым потенциалом нападения

-------------------------------------------

*(1) Идентификаторы приведены в соответствии с пунктом 10 ГОСТ Р 57628-2017. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности", утвержденного и введенного в действие приказом Росстандарта от 25.08.2017 N 967-ст (Стандартинформ, 2017)

*(2) Код указан в соответствии с пунктом 10 ГОСТ Р 57628-2017. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Руководство по разработке профилей защиты и заданий по безопасности", утвержденного и введенного в действие приказом Росстандарта от 25.08.2017 N 967-ст (Стандартинформ, 2017)

*(3) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014)

*(4) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014)

*(5) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014)

*(6) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014)

*(7) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014)

*(8) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014)

*(9) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014)

*(10) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014)

*(11) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-2-2013. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1339-ст (Стандартинформ, 2014)

*(12) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2008. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1340-ст (Стандартинформ, 2014)

*(13) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2008. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1340-ст (Стандартинформ, 2014)

*(14) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2008. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1340-ст (Стандартинформ, 2014)

*(15) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2008. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1340-ст (Стандартинформ, 2014)

*(16) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2008. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1340-ст (Стандартинформ, 2014)

*(17) Перечень идентификаторов приведен в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2008. "Национальный стандарт Российской Федерации. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности", утвержденным и введенным в действие приказом Росстандарта от 08.11.2013 N 1340-ст (Стандартинформ, 2014)