XI Международная студенческая научная конференция Студенческий научный форум — 2019
Оценка автоматизированных информационных систем
Создание автоматизированных вычислительных машин помогло человечеств упростить обработку данных в разных направлениях деятельности.
Одним из самых популярных классов систем обработки данных являются информационные системы.
При работе с автоматизированной информационной системой для каждого потребителя один и тот же ресурс может иметь разную степень оценки. Для одного потребителя данный ресурс может являться каким-то полезным и актуальным, а другой же потребитель может не придать, как такового значения предоставляемой информации.
Автоматизированная информационная система (далее АИС)- это совокупность информации, программных и технологических средств, математических моделей, предназначенных для оптимизации процесса управления и принятия управленческих решений в различных сферах человеческой деятельности.
Для оценки качества разработанной АИС ещё в процессе её создания проводятся различные виды испытаний. К ним, в частности, относят опытную эксплуатацию самой системы и её компонентов.
Главным критерием оценки результатов работы АИС является оценка качества и управление ими.
Таким образом, были сформированы следующие критерии:
Требования к техническим и программным средствам.
Совместимость или возможность работы с другими программными продуктами для реализации задач компании по другим видам операций (ведение бухгалтерского учета, организация закупок и продаж, организация перевозок и доставок).
Периодическое обновление версий.
Наличие пробной версии.
Возможность ведения единой БД.
Размер занимаемой памяти.
Показатель времени (сколько времени нужно для получения продукта).
Целостность (регулирование доступа, контроль доступа).
Наличие официального сайта.
Критерии формулируются на основе поставленных целей.
В первой группе признаков (положительных) приняты такие градации:
Требования к техническим и программным средствам. Документация с требованиями, которые должны быть выполнены при производстве, поставке услуг. Кроме того, в ней должны быть указаны процедуры, с помощью которых можно установить, соблюдены ли данные требования. Данный критерий имеет такие градации: «отсутствует», «имеется, но на платной основе», «имеется в бесплатном варианте».
Периодическое обновление версий. Период за который выходит новое обновление версии АИС. Входит 3 градации: «раз в несколько месяцев», «раз в год», «больше года»
Возможность ведения единой БД. Операции, выполняемые над БД для поддержания ее в актуальном состоянии. Этот признак можно дифференцировать по 2 градациям: «возможно», «невозможно».
Наличие официального сайта. Предполагает наличие сайта данного продукта на котором пользователь может найти нужную для себя информацию и задать вопросы продавцу. Критерий можно разделить на следующие градации: «присутствует», «отсутствует».
Показатель времени. Указывает на о, сколько времени потребуется для получения автоматизированной информационной системы. В градации критерия входят: «получение в течение нескольких часов», «получение в течение недели», «неизвестно время получения».
Возможность обучения. Имеет в себе 3 градации: «платное обучение», «бесплатное обучение», «обучение отсутствует».
Целостность (регулирование доступа, контроль доступа). Состояние ресурсов информационной системы, при котором их изменение осуществляется только преднамеренно субъектами, имеющими на него право, при этом сохраняются их состав, содержание и организация взаимодействия. Градации критерия: «Пользователя», «Предприятия», «ИС».
Во второй группе признаков (негативных) приняты четыре признака:
Наличие пробной версии. Представляет собой наличие пробной версии АИС, которую можно установить и протестировать на правильность и удобство использования для определения необходимости установки полной версии. Градации, которые входят в данный критерий: «присутствует», «отсутствует».
Размер занимаемой памяти. Говорит о том, сколько потребуется памяти для установления данной автоматизированной информационной системы.
Критерий имеет 3 градации: «входит в допустимые (стандартные рамки) рамки», «мало памяти », «большой объем памяти».
Совместимость или возможность работы с другими программными продуктами для реализации задач компании по другим видам операций (ведение бухгалтерского учета, организация закупок и продаж, организация перевозок и доставок). В критерий входят градации: «присутствует», «присутствует для некоторых программ», «отсутствует».
4.«Затраты». Представляет собой информацию о цене автоматизированной информационной системе, которую придется заплатить пользователю для приобретения данного продукта. Каждый пользователь сам решает, что для него означает «мелкие» и «крупные» расходы. Градации для критерия: «бесплатный», «мелкие», «высокие».
Тестирование оценки автоматизированной информационной системы «1с: управление торговлей 8» разными способами.
На рисунке 1 представлена оценка АИС с помощью «Пользовательского» метода.
Рисунок 1 — Оценка автоматизированной системы
Оценка экспертным режимом и представлена на рисунках 1 и 2.
Рисунок 2 – Ввод коэффициентов весомости
При окончании проведения оценки качества информационных систем можно сделать вывод, что она позволят потребителю данного системы самостоятельно делать выводы о дальнейшем применении и использовании.
Информационные ресурсы и технологии в экономике [Текст] : учеб. пособие / под ред. Б.Е. Одинцова и А.Н. Романова. – М. : ИНФРА-М, 2013. – 462 с.
Хорошилов, А.В. Управление информационными ресурсами / А.В. Хорошилов, С. Селетков, Н. Днепровская. –М: Финансы и статистика, 2006. -272 с.
Источник
Законодательная база Российской Федерации
Бесплатная горячая линия юридической помощи
Бесплатная консультация
Навигация
Федеральное законодательство
Действия
- Главная
- «ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. ОЦЕНКА БЕЗОПАСНОСТИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ. ГОСТ Р ИСО/МЭК ТО 19791-2008» (утв. Приказом Ростехрегулирования от 18.12.2008 N 525-ст)
| Наименование документ | «ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. ОЦЕНКА БЕЗОПАСНОСТИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ. ГОСТ Р ИСО/МЭК ТО 19791-2008» (утв. Приказом Ростехрегулирования от 18.12.2008 N 525-ст) |
| Вид документа | приказ, стандарт, гост |
| Принявший орган | ростехрегулирование |
| Номер документа | 525-СТ |
| Дата принятия | 01.10.2009 |
| Дата редакции | 18.12.2008 |
| Дата регистрации в Минюсте | 01.01.1970 |
| Статус | действует |
| Публикация |
|
| Навигатор | Примечания |
8 Оценка автоматизированных систем
Автоматизированные системы должны оцениваться с использованием общей модели оценки, определенной в ИСО/МЭК 15408-1, с расширениями (дополнениями), определенными в настоящем разделе.
Существуют виды деятельности, необходимые для оценки автоматизированной системы. Ими являются:
— разработка свидетельств оценки (включающих в себя оценку рисков, спецификацию ЗБС, свидетельства разработки и интеграции, эксплуатации, модификации);
— оценка (включая сертификацию результатов оценки);
Для каждого из перечисленных видов деятельности должен быть назначен соответствующий персонал, его полномочия должны быть согласованы и необходимые задачи должны быть выполнены. Эти виды деятельности и связанные с ними роли и обязанности персонала представлены в таблице 1. Действия, необходимые в соответствии с требованиями настоящего стандарта, должны легко сопоставляться с ролями и обязанностями, определенными в данной таблице. Все действия следует также сопоставлять с разделами СЗБ, идентифицированными в таблице 1.
Роли и обязанности по оценке автоматизированных систем
| Вид деятельности | Роль | Обязанность | Разделы ЗБС |
| Разработка свидетельств для оценки | Высший менеджмент | Общая ответственность за безопасность. Определяет приемлемые риски. Санкционирует действия уполномоченных должностных лиц | Не определено |
| Уполномоченные должностные лица организации | Оценивают и принимают остаточные риски | Определение проблемы безопасности | |
| Агентство безопасности | Устанавливает политики безопасности всей организации | ||
| Владелец системы | Проводит оценку рисков. | Определение проблемы безопасности. | |
| Определяет проблемы безопасности, которые должны быть учтены а системе (включая цели, требования). | Цели безопасности. | ||
| Требования безопасности. | |||
| Подготавливает любой ПЗС (возможно, как представитель консорциума владельцев аналогичных систем). Санкционирует переоценку, связанную с изменениями в системе или ее среде. Анализирует состояние системы на основе отчетов о непрерывном мониторинге | |||
| Описание СОО | |||
| Разработчик/интегратор/проектировщик системы | Разработка или поддержка разработки ЗБС на основе проблемы безопасности, определенной владельцем системы. | Описание СОО. | |
| Технические меры безопасности. | |||
| Разработка свидетельств разработки. | Требования доверия, относящиеся к разработке. | ||
| Содействие (помощь) владельцу системы а уменьшении или устранении уязвимостей. выявленных во время оценки | |||
| Архитектура и краткая спецификация | |||
| Оператор/администратор/ ответственный за сопровождение | Поддержка разработки СЗВ. | Организационные меры. | |
| Разработка эксплуатационных свидетельств. | |||
| Требования доверия, относящиеся к эксплуатации. | |||
| Содействие (помощь) владельцу системы в уменьшении ипи устранении уязвимостей. выявленных в процессе оценки | |||
| Архитектура и краткая спецификация | |||
| Оценка | Оценщик/лицо, осуществляющее сертификацию (сертификатор) | Оценивает систему на основе требований безопасности, сформулированных в СЗБ. чтобы сделать заключение о способности системы удовлетворять требованиям безопасности в данный момент времени. | Все |
| Обеспечивает независимую оценку безопасного функционирования системы на этапе ее эксплуатации. | |||
| Выполняет переоценку, которая требуется, для поддержки изменений системы и ее среды. | |||
| Сертифицирует результаты оценки. | |||
| Сертифицирует результаты оценки. Предоставляет отчет об оценке и отчет о сертификации владельцу системы с рекомендациями, которые требуются для поддержки аттестации /авторизации системы | |||
| Аттестация | Аттестующий | Авторизует систему для использования или подтверждает приемлемость прогнозирования остаточных рисков перед уполномоченным должностным лицом | Определение проблемы безопасности |
Перед оценкой автоматизированной системы владелец системы должен оценить границы автоматизированной системы, определить активы, требующие защиты, и вместе с уполномоченным должностным лицом или должностным лицом из числа высшего менеджмента определить уровень риска, который организация готова принять, когда некоторый актив может быть потерян, испорчен или скомпрометирован.
Затем владелец системы должен провести оценку рисков, охватывающую все активы автоматизированной системы. При этой оценке должны идентифицироваться все возможные риски этой системы, включая риски, которым противостоят реализованные меры обеспечения безопасности или которые устраняются ими. Эти реализованные меры обеспечения безопасности должны документироваться как часть оценки риска, чтобы их можно было включить в описание целей безопасности в ЗБС.
Примечание — В настоящем стандарте не предписывается какая-либо определенная модель или форма оценки риска. Дальнейшую информацию относительно риска для систем информационных и телекоммуникационных технологий можно найти в ИСО/МЭК 13335-1 [1].
При наличии рисков, превышающих уровень, который организация готова допустить, владелец системы должен определить предполагаемое направление действий по уменьшению рисков до приемлемого уровня. Предполагаемое направление действий по уменьшению рисков может принять форму:
— принятие повышенного риска и осознание ответственности за последствия, если риск будет реализован;
— переноса рисков; перенос рисков или ответственности за их последствия на другую сторону;
— избежания риска; отказ от деятельности, которая приводит к риску;
— уменьшения или устранения рисков; уменьшение рисков до приемлемого уровня путем применения в рамках автоматизированной системы оцененных контрмер для уменьшения вероятности и/или последствий риска.
После этого анализа необходимо категорировать каждый риск как «приемлемый» или «неприемлемый» по отношению к автоматизированной системе. Приемлемые риски должны быть допустимыми, принятыми, перенесенными или рисками, которых избежали. Неприемлемыми рисками являются те, которые должны быть снижены или устранены.
При неприемлемости рисков владелец системы вместе с разработчиком системы должен идентифицировать и специфицировать технические меры и организационные меры безопасности, которые должны быть применены в качестве контрмер. Владелец системы совместно с ее разработчиком должны также определить и обозначить меры доверия для подтверждения того, что риск неспособности технических и организационных мер безопасности выполнять их цели безопасности в качестве мер противодействия снижен до допустимого для организации уровня.
Как часть стадии эксплуатации жизненного цикла системы владелец системы должен периодически повторять оценку рисков, чтобы определить:
— имеются ли изменения в бизнес-активах;
— имеются ли новые риски или изменения в рисках для активов;
— остаются ли надлежащими реализованные контрмеры.
Затем владелец должен определить, имеется ли необходимость в переоценке системы для подтверждения адекватности и эффективности мер обеспечения безопасности АС с учетом повторной оценки рисков.
Владелец системы должен определить проблему безопасности, стоящую перед автоматизированной системой, подвергающейся оценке. Описание проблемы безопасности должно включать в себя:
— результаты оценки риска;
— политики безопасности организации, применимые к системе.
Владелец системы должен подготовить формулировки целей безопасности для автоматизированной системы. Цели безопасности должны содержать четкую формулировку предполагаемого реагирования на проблемы безопасности, стоящие перед автоматизированной системой.
В целях оценки автоматизированных систем необходимо различать два типа целей безопасности:
а) функциональные цели безопасности, которые достигаются техническими и организационными мерами безопасности, используемыми в автоматизированной системе;
b) цели доверия к безопасности, которые достигаются мерами доверия (например, деятельностью по верификации).
При оценке по стандартам серии ИСО/МЭК 15408 функциональные цели безопасности обычно достигаются исключительно техническими мерами безопасности, поскольку среда эксплуатации не оценивается, а рассматривается в рамках определения проблемы безопасности в качестве предположений. В целях оценки автоматизированных систем среда эксплуатации включена в область оценки, и функциональные цели безопасности могут быть реализованы техническими, организационными мерами безопасности или сочетанием этих мер. Как технические, так и организационные меры могут повлечь за собой меры или действия по управлению.
Формулировка целей безопасности должна покрывать все требуемые меры обеспечения безопасности, включая как уже реализованные, так и те, которые необходимо применить как часть реализации автоматизированной системы.
При оценке по стандартам ИСО/МЭК 15408 требования доверия обычно не следуют из проблемы безопасности. Они выбираются аксиоматически или путем принятия «политического» решения. В рамках автоматизированной системы для различных компонентов или подсистем могут потребоваться различные формы мер доверия в зависимости от различных типов доступной информации, а также разработки или формы доверия могут также зависеть от типов выбранных функциональных мер (организационные меры могут быть наилучшим образом обеспечены различными техническими мерами). Исходя из вышесказанного, следует, что цели доверия должны рассматриваться как часть решения проблемы безопасности.
Владелец системы должен подготовить набор требований безопасности для автоматизированной системы. Требования безопасности должны определить набор мер обеспечения безопасности, которые должны быть реализованы в автоматизированной системе (функциональные требования безопасности), и способы оценки того, что эти меры реализованы корректно и эффективно (требования доверия к безопасности).
8.6.2 Функциональные требования безопасности
Технические меры безопасности должны выбираться из функциональных классов, определенных в ИСО/МЭК 15408-2. Если в ИСО/МЭК 15408-2 нет подходящих функциональных компонентов, тогда в соответствии с процедурой, определенной в ИСО/МЭК 15408-1, в приложении B, должны быть самостоятельно разработаны и определены дополнительные компоненты.
Организационные меры безопасности должны выбираться из функциональных классов, в соответствии с приложением В. Если в приложении В нет подходящих функциональных компонентов, тогда в соответствии с процедурой, определенной в ИСО/МЭК 15408-1, в приложении B, должны быть самостоятельно разработаны и определены дополнительные компоненты.
Сравнение функциональных классов, определенных в стандартах серии ИСО/МЭК 15408 и настоящем стандарте, а также их применимость при оценке автоматизированных систем приведены в таблице 2.
Сравнение функциональных классов
| Стандарты серии ИСО/МЭК 15408 | Автоматизированная система: ИСО/МЭК ТО 19791 | Применимость и область применения |
| Аудит безопасности (FAU) | Аудит безопасности (FAU) | Применимо |
| Связь (FCO) | Связь (FCO) | |
| Криптография (FCS) | Криптография (FCS) | |
| Зашита данных пользователя (FDP) | Защита данных пользователя (FDP) | |
| Идентификация и аутентификация (FIA) | Идентификация и аутентификация (FIA) | |
| Управление безопасностью (FMT) | Управление безопасностью (FMT) | |
| Приватность (FPR) | Приватность (FPR) | |
| Защита ФБО (FPT) | Защита ФБО (FPT) | |
| Доступ к OO(FTA) | Доступ к 00 (FTA) | |
| Доверенный маршрут/канал (FTP) | Доверенный маршрут/канал (FTP) | |
| Аудит безопасности (FAU) | Аудит безопасности (FAU) | |
| Организационные меры безопасности (FOD) | Политика, персонал, менеджмент рисков, менеджмент инцидентов, организация безопасности, соглашение об услугах | |
| Меры обеспечения безопасности систем HT(FOS) | Политика, конфигурация, сетевая безопасность, мониторинг, управление персоналом, активы автоматизированных систем, регистрация и запись | |
| — | Меры обеспечения безопасности активов пользователей (FOA) | Зашита приватности данных, активы пользователей |
| — | Меры обеспечения безопасности бизнес-процесса в (FOB) | Политика, непрерывность |
| Меры обеспечения безопасности аппаратуры и оборудования (FOP) | Мобильное оборудование, съемное оборудование, удаленное оборудование, система, аппаратура | |
| Меры обеспечения безопасности по отношению к третьей стороне (FOT) | Управление | |
| Управление (FOM) | Параметры безопасности, классификация активов, обязанности персонала, организация безопасности, отчеты о безопасности |
8.6.3 Требования доверия к безопасности
Требования доверия должны выбираться в соответствии с ИСО/МЭК 15408-3 и приложением С настоящего стандарта. Если в ИСО/МЭК 15408-3 и приложении С настоящего стандарта нет подходящих компонентов доверия, то в соответствии с процедурой, определенной в ИСО/МЭК 15408-1, приложение В, должны быть самостоятельно разработаны и определены дополнительные компоненты.
Сравнение классов доверия, определенных в стандартах серии ИСО/МЭК 15408 и настоящем стандарте, а также их применимость при оценке автоматизированных систем приведено в таблице 3.
Сравнение классов доверия
| Стандарты серии ИСО/МЭК 15408 | Автоматизированная система. ИСО/МЭК ТО 19791 | Применимость |
| АРЕ: оценка профиля защиты | Оценка профиля защиты для системы (ASP) | Зависит от отличий ПЗС |
| ASE: оценка задания по безопасности | Оценка задания по безопасности для системы (ASS) | Зависит от отличий ЗБС |
| АСМ: управление конфигурацией | Управление конфигурацией автоматизированных систем (АОС) | Композиционные требования для составных продуктов. Управление конфигурацией (изменение, отслеживание, сопровождение). Подтверждение и верификация (во время эксплуатации) |
| ADO; поставка и эксплуатация | Безопасная установка системы (ASI) | Информирование и связь ФБС. Подтверждение и верификация (во время эксплуатации) |
| ADV: разработка | Документация по проектированию архитектуры автоматизированных систем и конфигурационная | Интерфейсы и конфигурация компонентов. Внешние интерфейсы. Архитектура, информационные потоки, доступ к СОО. Режим эксплуатации/условия развития |
| AGD: руководства | Руководства для автоматизированных систем (AOD) | Правила и процедуры для пользователя и администратора. Конфигурация. Подтверждение и верификация (во время эксплуатации) |
| ALC: поддержка жизненного цикла | Поддержка жизненного цикла автоматизированных систем (AOL) | Аналогична мерам обеспечения безопасности для среды разработки/интеграции. Подтверждение и верификация (во время эксплуатации) |
| ATE:тестирование | Тестирование автоматизированных систем (АОТ) | Функциональное тестирование, глубина тестирования и покрытие тестами ФБС. Независимое тестирование ФБС. Регрессивное тестирование на этапе поддержки (сопровождения/модификации |
| AVA: Оценка уязвимостей | — | Анализ уязвимостей автоматизированных систем (AOV) |
| Регистрация и запись в автоматизированных системах (ASO) | Записи в журналы ФБС. Административный анализ ФБС. Независимая верификация ФБС. Подтверждение и верификация записей |
Владелец системы должен зафиксировать определение проблемы безопасности, цели безопасности и требования безопасности для автоматизированной системы в ЗБС. Владелец также должен получать и документировать другую информацию, необходимую для завершения ЗБС, которая определена в приложении А.
Если владелец автоматизированной системы хочет определить требования для автоматизированной системы независимым от реализации способом, он может сначала разработать или заимствовать ПЗС. Обязательное и необязательное содержание ПЗС определено в приложении А.
ЗБС служит основой как для документирования возможностей обеспечения безопасности автоматизированной системы, так и для оценки этих возможностей в СОО. Оно обеспечивает свидетельство и информацию, необходимые для проведения оценки.
ЗБС отличается от ЗБ своей направленностью как на технические, так и на организационные меры безопасности автоматизированной системы. ЗБС можно подразделить на несколько отдельных доменов безопасности с различными функциональными мерами и мерами доверия. Однако, как и ЗБ, ЗБС может оцениваться на согласованность (непротиворечивость) независимо от самого СОО.
Впоследствии при оценке СОО могут быть идентифицированы несоответствия между ЗБС и СОО. Типы расхождений могут включать в себя:
a) аспекты реализованной среды автоматизированной системы, не согласующиеся со средой АС, которая специфицирована в ЗБС;
b) аспекты реализованных функциональных возможностей безопасности автоматизированной системы, отличающиеся от функциональных возможностей безопасности, которые специфицированы в ЗБС;
c) аспекты реализованных интерфейсов и соединений автоматизированной системы и их режимы работы, не согласующиеся с интерфейсами автоматизированной системы, которые специфицированы в ЗБС.
Владелец системы должен определить, реализованы ли среда, функциональные возможности или интерфейсы/соединения требуемым образом, а описание в ЗБС является неправильным, или среда, функциональные возможности или интерфейсы/соединения должны быть такими, как специфицировано в ЗБС. После завершения оценки необходимо внести соответствующие изменения. Эти изменения могут привести к изменениям в ЗБС и/или автоматизированной системе. По этим причинам после оценки ЗБС невозможно вынести окончательный вердикт, является ли ЗБС корректным представлением автоматизированной системы. Только после того, как оценка СОО будет завершена и несоответствия будут разрешены (устранены), можно будет подтвердить, что ЗБС является корректным представлением.
Сравнение элементов ЗБ, определенного в стандартах серии ИСО/МЭК 15408, и ЗБС, определенного в настоящем стандарте, а также их применимость для оценки автоматизированных систем приведены в таблице 4.
Сравнение элементов заданий по безопасности
| ИСО/МЭК 15408 | Автоматизированная система: ИСО/МЭК ТО 19791 | Применимость к автоматизированным системам |
| Введение | Введение | Должны быть определены ИТ/эксплуатационные части СОО и интерфейсы с внешними автоматизированными системами. |
| Описание ОО | Может быть определена доменная организация | |
| Среда безопасности ОО | Проблемы безопасности | Вместо угроз следует определить риски. Предположения не должны быть определены, так как среда является реальной |
| Цели безопасности | Цепи безопасности | Должны быть определены цели безопасности для ИТ-частей и эксплуатационных частей СОО. а также для внешних автоматизированных систем |
| Требования безопасности ИТ | Требования безопасности | Функциональные требования для ИТ-частей СОО. Эксплуатационные требования для эксплуатационных частей СОО. Должны быть определены требования доверия |
| Краткая спецификация 00 | Краткая спецификация СОО | Должна быть описана функциональная, эксплуатационная спецификация и спецификации доверия |
| Утверждения о соответствии ПЗ | Утверждение о соответствии | Могут быть определены утверждения о соответствии ПЗС, ПЗ и/или 35 |
| — | Введение (доменная часть) | Должны быть определены ИТ/эксплуатационные части домена |
| — | Проблемы безопасности (доменная часть) | Должны быть определены риски и ПБОр |
| — | Цели безопасности (доменная часть) | Должны быть определены цели безопасности для ИТ- и эксплуатационных частей домена |
| — | Требования безопасности (доменная часть) | Должны быть определены функциональные требования для ИТ- и эксплуатационных частей домена. Должны быть определены требования доверия для домена |
| Краткая спецификация (доменная часть) | Должна быть описана функциональная, эксплуатационная спецификация и спецификации доверия для домена | |
| Утверждение о соответствии (доменная часть) | Могут быть определены утверждения о соответствии ПЗС. ПЗ и/или ЗБ для домена |
Владелец системы должен специфицировать меры обеспечения безопасности для обеспечения того, чтобы результаты оценки автоматизированной системы оставались действительными во время эксплуатации системы.
Спецификация может быть выполнена следующими способами:
— могут быть специфицированы управленческие меры безопасности для периодической проверки того, что конфигурация технических мер поддерживается, а организационные меры правильно применяются.
Для этого должен быть разработан набор процессов и процедур с тем, чтобы управлять влиянием на безопасность изменений, которые происходят в среде системы. Спецификация управленческих мер может включать в себя регрессионное тестирование всех изменений системы для того, чтобы удостовериться, что меры обеспечения безопасности системы не модифицированы и не отключены;
— оценщик может периодически переоценивать СОО (автоматизированную систему), уделяя особое внимание тому, необходима ли корректировка совокупности технических и организационных мер для удовлетворения изменяющихся требований безопасности организации, а также с тем, чтобы подтвердить, что эксплуатационные процессы и процедуры применяются эффективно.
Источник
