Файл: В. Б. Кравченко (директор Института информационных наук и технологий безопасности Российского государственного гуманитарного университета).pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 02.02.2024
Просмотров: 699
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
жны быть учтены проектные ограничения, определяемые общи
ми проектными решениями по изделию ИТ». Но ведь на данном этапе еще нет проектных решений! Впрочем, как указано далее, в
ТЗ необходимо указать лишь ссылку на ПЗ, а откуда она появи
лась — это «на совести» заказчика.
Возможны два случая. Если основным назначением изделия
ИТ является обеспечение безопасности информации, то требова
ния к безопасности изделия ИТ составляют основное содержание разделов ТЗ. Если обеспечение безопасности информации — част
ная задача изделия, то требования должны содержаться в отдель
ном разделе ТЗ или в Приложении к нему, либо в частном (спе
циальном) ТЗ.
В ТЗ могут включаться требования соответствия одному или нес
кольким ПЗ, а если изделие предназначено для обработки инфор
мации ограниченного доступа и имеются зарегистрированные ПЗ, то это является обязательным. Если таких ПЗ нет, то в этом случае
ТЗ должно пройти экспертизу в порядке, устанавливаемым ФСТЭК.
Если в ТЗ отсутствует ссылка на ПЗ или ПЗ уточняется, то должны приводиться не только требования, но и цели безопасности.
Таким образом, при наличии соответствующего зарегистриро
ванного ПЗ, все требования по безопасности к изделию ИТ могут состоять в ссылке на этот ПЗ плюс необходимые обоснования, уточнения и дополнения. В Приложении А к Положению приве
дена более подробная характеристика разделов ТЗ. В Положении отмечена целесообразность экспертизы ТЗ в организациях, спе
циализирующихся на разработке или оценке ПЗ, как было отме
чено ранее, нормативных документов ФСТЭК.
Разработка изделия ИТ
В разделе «Разработка изделий ИТ» отмечается важность обес
печения безопасности на всех этапах жизненного цикла. Приво
дится ссылка на документ «Базовая модель обеспечения безопас
ности на этапах жизненного цикла». Отмечено, что «модель жиз
ненного цикла должна быть принята до начала проектирования и разработки изделия ИТ». Требования к этой модели будут предъяв
лены позднее, в документе «Критерии...», и будут ранжированы в зависимости от уровня доверия.
Указано на необходимость разработки документа «Программа обеспечения безопасности при разработке и сопровождении изде
лия ИТ», структура его приведена в Приложении Б Положения.
Центральное место в структуре Программы занимают модель обес
печения безопасности изделия ИТ при разработке и сопровождении и план-график работ по обеспечению безопасности изделия ИТ.
Также в Программе должна быть детализирована система контроля безопасности изделия ИТ при разработке и сопровождении.
ми проектными решениями по изделию ИТ». Но ведь на данном этапе еще нет проектных решений! Впрочем, как указано далее, в
ТЗ необходимо указать лишь ссылку на ПЗ, а откуда она появи
лась — это «на совести» заказчика.
Возможны два случая. Если основным назначением изделия
ИТ является обеспечение безопасности информации, то требова
ния к безопасности изделия ИТ составляют основное содержание разделов ТЗ. Если обеспечение безопасности информации — част
ная задача изделия, то требования должны содержаться в отдель
ном разделе ТЗ или в Приложении к нему, либо в частном (спе
циальном) ТЗ.
В ТЗ могут включаться требования соответствия одному или нес
кольким ПЗ, а если изделие предназначено для обработки инфор
мации ограниченного доступа и имеются зарегистрированные ПЗ, то это является обязательным. Если таких ПЗ нет, то в этом случае
ТЗ должно пройти экспертизу в порядке, устанавливаемым ФСТЭК.
Если в ТЗ отсутствует ссылка на ПЗ или ПЗ уточняется, то должны приводиться не только требования, но и цели безопасности.
Таким образом, при наличии соответствующего зарегистриро
ванного ПЗ, все требования по безопасности к изделию ИТ могут состоять в ссылке на этот ПЗ плюс необходимые обоснования, уточнения и дополнения. В Приложении А к Положению приве
дена более подробная характеристика разделов ТЗ. В Положении отмечена целесообразность экспертизы ТЗ в организациях, спе
циализирующихся на разработке или оценке ПЗ, как было отме
чено ранее, нормативных документов ФСТЭК.
Разработка изделия ИТ
В разделе «Разработка изделий ИТ» отмечается важность обес
печения безопасности на всех этапах жизненного цикла. Приво
дится ссылка на документ «Базовая модель обеспечения безопас
ности на этапах жизненного цикла». Отмечено, что «модель жиз
ненного цикла должна быть принята до начала проектирования и разработки изделия ИТ». Требования к этой модели будут предъяв
лены позднее, в документе «Критерии...», и будут ранжированы в зависимости от уровня доверия.
Указано на необходимость разработки документа «Программа обеспечения безопасности при разработке и сопровождении изде
лия ИТ», структура его приведена в Приложении Б Положения.
Центральное место в структуре Программы занимают модель обес
печения безопасности изделия ИТ при разработке и сопровождении и план-график работ по обеспечению безопасности изделия ИТ.
Также в Программе должна быть детализирована система контроля безопасности изделия ИТ при разработке и сопровождении.
В Положении указано на важность обеспечения безопасности среды разработки изделия ИТ. Указано, что разработчик должен представить документацию по обеспечению этой безопасности.
Конкретные требования будут приведены в «Критериях...» в зави
симости от уровня доверия.
Уделено внимание используемым при разработке инструмен
тальным средствам. Они должны быть лицензионно чистыми, а при необходимости сертифицированными. Средства должны осно
вываться на стандартах (быть полностью определенными) либо быть подробно описаны в документации разработчика. В докумен
тации должны быть зафиксированы все настройки средств. Также приводится ссылка на «Критерии...», где будут предъявлены тре
бования в зависимости от уровня доверия. В указанном докумен
те следует также перечислить требования к устранению недостат
ков изделия в процессе его сопровождения разработчиком.
В Положении отмечено, что конкретные виды разрабатывае
мых проектных документов определяются стандартами. Виды пред
ставления проектных решений следующие:
• функциональная спецификация;
• эскизный проект;
• технический проект;
• рабочий проект.
Требования к уровню представления проектных решений так
же будут установлены в «Критериях...».
Как видно из перечисления, новым видом представления про
ектных решений является функциональная спецификация. В По
ложении не уточняется, на каком этапе она разрабатывается, но из текста видно, что имеется в виду этап аванпроекта (если он предусмотрен), либо эскизного проекта. Функциональная специ
фикация должна содержать описание всех функций безопасности изделия (ФБИ), режимов и выполнения, назначение и способы использования всех внешних интерфейсов ФБИ. Может также раз
рабатываться модель политики безопасности изделия.
Эскизный проект уточняет функциональную спецификацию, преобразуя ее в представление ФБИ на уровне подсистем. Опре
деляются все аппаратные, программные, программно-аппаратные средства, требуемые для реализации ФБИ, взаимосвязи, интер
фейсы всех подсистем.
Технический проект уточняет эскизный проект до уровня де
тализации. Он должен содержать описание внутреннего содержа
ния ФБИ в терминах модулей, их взаимосвязей и зависимостей.
Для высоких уровней доверия к внутренней структуре ФБИ предъявляются требования к модульности проектирования и пред
ставлению описания архитектуры ФБИ.
Важным новым элементом проектирования является необ
ходимость проведения анализа соответствия представлений
(ЗБ
ФС
эп
тп
-» РП). Уровень формализации этого анализа будет зависеть от уровня доверия и он конкретизирован в «Критериях...».
В отличие от других нововведений необходимая документация по управлению конфигурацией (УК) перечислена в тексте Поло
жения. Разработчик должен представить следующую документа
цию:
• список элементов конфигурации изделия ИТ;
• план УК;
• план приемки элементов конфигурации под управление си
стемы УК;
• процедуры компоновки элементов конфигурации в состав изделия ИТ.
Содержание документов кратко поясняется в тексте Положе
ния. Одно из любопытных требований: лицо, ответственное за включение элемента конфигурации под управление системы УК, не должно быть его разработчиком.
Из текста Положения видно, что для управления конфигура
цией необходима разработка инструментальных средств поддерж
ки УК. Конкретные требования по УК будут приведены ФСТЭК в «Критериях...».
Среди эксплутационной документации выделяются руковод
ство пользователя (РП) и руководство администратора (РА). В РП указывается, что делают функции безопасности и какова роль пользователя в ее поддержании. Сюда вносятся все предупрежде
ния пользователю из ПЗ/ЗБ, относящиеся к среде безопасности и целям безопасности изделия.
В Положении приведены требования по функциональному те
стированию. Отмечена необходимость как положительного, так и негативного тестирования. Указано, что разработчик должен со
здавать программу и методики тестирования, глубина проработки которых будет зависеть от уровня доверия и будет обозначена в
«Критериях...».
Разработчик должен проводить оценку уязвимостей, которая включает: анализ уязвимостей; анализ скрытых каналов; оценку стойкости функций безопасности; анализ возможного неправиль
ного применения.
Уязвимости должны быть устранены, минимизированы либо отслежены.
Анализ уязвимостей в зависимости от уровня доверия может выполняться структурированными или частными методами. Все уязвимости должны быть задокументированы.
Анализ скрытых каналов проводится в случае, если изделие имеет функции по управлению информационными потоками и проводится с целью дать заключение о наличии и пропускной способности скрытых каналов. Анализ скрытых каналов в зависи
мости от уровня доверия может выполняться структурированны
ми или частными методами. В документации разработчик должен описать скрытые каналы, их пропускную способность, процеду
ры, применяемые для выявления скрытых каналов и их анализа, наиболее опасный сценарий использования каждого скрытого канала и метод, используемый для оценки пропускной способно
сти.
Обеспечение поддержки доверия к безопасности
изделия ИТ при эксплуатации
Большим недостатком существующей системы сертификации является формальная необходимость «пересертификации» изде
лия при внесении в него изменений. Вместе с тем такие измене
ния могут вноситься достаточно часто, в зависимости от предназ
начения изделия.
В Положении приведена принципиально новая процедура под
тверждения результатов оценки при изменениях в сертифициро
ванной версии изделия. Подтверждение при изменениях может быть осуществлено двумя путями:
• посредством оценки новой версии изделия ИТ;
• посредством реализации процедур поддержки доверия без
опасности к изделию ИТ, определенных в требованиях поддерж
ки доверия в «Критериях...».
Выбор разработчиком стратегии поддержки зависит от него самого. В последнем случае в ЗБ должны быть внесены соответ
ствующие требования поддержки доверия к безопасности из «Кри
териев...».
От разработчика требуется наличие двух документов:
• план поддержки доверия, определяющий процедуры, кото
рые должен выполнять разработчик;
• отчет о категорировании компонентов изделия ИТ по их от
ношению к безопасности.
Содержание этих документов описано в Положении.
В плане указываются контрольные точки, когда разработчик должен выдавать владельцу изделия ИТ свидетельство поддержа
ния доверия. К документации поддержки доверия также относятся:
• список конфигурации изделия ИТ;
• список идентифицированных уязвимостей в изделии ИТ;
• свидетельство следования процедурам поддержки доверия, определенным в плане ПД.
Указывается также график проведения аудита поддержки дове
рия. Этот аудит выполняет испытательная лаборатория, необяза
тельно та же, что проводила сертификацию.
В цикле поддержки доверия должны предусматриваться четы
ре типа процедур:
ми или частными методами. В документации разработчик должен описать скрытые каналы, их пропускную способность, процеду
ры, применяемые для выявления скрытых каналов и их анализа, наиболее опасный сценарий использования каждого скрытого канала и метод, используемый для оценки пропускной способно
сти.
Обеспечение поддержки доверия к безопасности
изделия ИТ при эксплуатации
Большим недостатком существующей системы сертификации является формальная необходимость «пересертификации» изде
лия при внесении в него изменений. Вместе с тем такие измене
ния могут вноситься достаточно часто, в зависимости от предназ
начения изделия.
В Положении приведена принципиально новая процедура под
тверждения результатов оценки при изменениях в сертифициро
ванной версии изделия. Подтверждение при изменениях может быть осуществлено двумя путями:
• посредством оценки новой версии изделия ИТ;
• посредством реализации процедур поддержки доверия без
опасности к изделию ИТ, определенных в требованиях поддерж
ки доверия в «Критериях...».
Выбор разработчиком стратегии поддержки зависит от него самого. В последнем случае в ЗБ должны быть внесены соответ
ствующие требования поддержки доверия к безопасности из «Кри
териев...».
От разработчика требуется наличие двух документов:
• план поддержки доверия, определяющий процедуры, кото
рые должен выполнять разработчик;
• отчет о категорировании компонентов изделия ИТ по их от
ношению к безопасности.
Содержание этих документов описано в Положении.
В плане указываются контрольные точки, когда разработчик должен выдавать владельцу изделия ИТ свидетельство поддержа
ния доверия. К документации поддержки доверия также относятся:
• список конфигурации изделия ИТ;
• список идентифицированных уязвимостей в изделии ИТ;
• свидетельство следования процедурам поддержки доверия, определенным в плане ПД.
Указывается также график проведения аудита поддержки дове
рия. Этот аудит выполняет испытательная лаборатория, необяза
тельно та же, что проводила сертификацию.
В цикле поддержки доверия должны предусматриваться четы
ре типа процедур:
• управление конфигурацией;
• поддержка свидетельств, в которых отражены вопросы функ
ционального тестирования;
• анализ влияния изменений в изделии ИТ на безопасность;
• устранение недостатков безопасности.
Подтверждение соответствия изделий ИТ требованиям
безопасности информации
Порядок подтверждения соответствия приведен в разд. 8 Поло
жения. Начинается этот раздел с требования обязательной сертифи
кации изделий ИТ, предназначенных для обработки информации с ограниченным доступом. Таким образом, впервые не делается различия между, например, служебной информацией государствен
ных органов власти и коммерческой информацией частных фирм.
Заявителем может быть разработчик или другое заинтересо
ванное лицо, которое обязано в этом случае оформить договор
ные отношения с разработчиком.
Работы, выполняемые при сертификации:
• подготовка к оценке изделия ИТ (работы разработчика + пред
варительное рассмотрение ЗБ лабораторией);
• оценка изделия ИТ (выполняет испытательная лаборатория);
• подтверждение соответствия изделия ИТ требованиям по без
опасности информации (независимая экспертиза результатов ра
боты лаборатории органом по сертификации).
Перечень документов, представляемых разработчиком для про
ведения сертификации, приведен в Приложении Г [39]. Этот спи
сок впечатляет. Требуется представлять не только конечные мате
риалы, но и материалы эскизного, технического и рабочего про
екта. Всего имеется 27 категорий документов, разработка которых потребует от разработчика значительных усилий.
Несколько изменен порядок проведения сертификации. Внача
ле разработчик обращается в испытательную лабораторию, которая должна выполнить предварительное рассмотрение ЗБ (но пока еще не его оценку!). При положительном результате рассмотрения лабо
ратория разрабатывает программу проведения оценки и календар
ный план проведения оценки. Разработчик представляет в орган по сертификации заявку, ЗБ и разработанные лабораторией доку
менты.
Оценка безопасности изделия ИТ включает оценку ЗБ на соот
ветствие «Критериям...» и оценку изделия на соответствие требо
ваниям безопасности информации на основании «Методологии...».
Инструментальные средства оценки должны быть сертифици
рованы. Орган по сертификации выполняет независимую экспер
тизу результатов, приведенных в техническом отчете лаборато
рии, утверждает их и выдает сертификат. В случае проведения
сертификации изделия, находящегося на поддержке доверия к бе
зопасности, в орган по сертификации подается заявка с приложе
нием отчета поддержки доверия, разработанного испытательной лабораторией, включающего оценку анализа разработчиком влия
ния изменений на безопасность и результаты своих аудитов ПД.
зопасности, в орган по сертификации подается заявка с приложе
нием отчета поддержки доверия, разработанного испытательной лабораторией, включающего оценку анализа разработчиком влия
ния изменений на безопасность и результаты своих аудитов ПД.
1 2 3 4 5 6 7 8 9 ... 41