Информатизация бизнеса. Управление рисками

Авдошин Сергей Михайлович

Песоцкая Елена Юрьевна

Глава 8

Обзор информационных систем управления рисками

 

 

8.1. Требования к информационной системе управления рисками

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

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

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

• информация о поставщике и продукте;

• функциональные требования;

• технические требования;

• цены и условия.

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

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

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

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

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

• технологичность решения;

• терминология и качество локализации системы;

• модульность;

• гибкость;

• масштабируемость;

• архитектура и техническая платформа;

• операционная среда и СУБД.

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

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

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

Рис. 25. Пример портфеля критериев по выбору программного продукта

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

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

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

На верхнем уровне детализации веса определяются путем экспертной оценки (табл. 8).

Таблица 8.

Пример распределения доли критериев 

Требования могут отличаться по значимости и ранжироваться по приоритетности на три группы: «Критично», «Важно», «Желательно» (табл. 9). На основе этого каждому требованию присваивается вес в общей оценке (табл. 12). Для определения весов для оценки требований необходимо согласовать их приоритетность. Наименьший вес принимается за единицу, следующая категория присваивается группе критериев с условно в два раза большей значимостью и т. д. Веса рассчитываются на основе единиц относительной значимости. Сумма весов должна быть равна 100 %.

Таблица 9.

Приоритеты требований 

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

Среди функциональных критериев по выбору системы управления ИТ-рисками могут быть следующие:

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

• ведение единого реестра рисков;

• использование иерархии классификации;

• формирование отчетов и графических форм;

• открытость системы для дальнейшего развития и интеграции с другим ПО;

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

• механизм автоматической генерации уведомлений по электронной почте;

• возможность внесения изменений в систему с учетом пожеланий заказчика.

Могут существовать функциональные требования для связывания рисков и рисковых событий, факторов риска и бизнес-процессов.

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

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

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

Вне зависимости от выбранного типа решения программный продукт по управлению рисками в ИТ-проекте должен отвечать сформулированным требованиям и выполнять основные задачи управления рисками за счет:

• функций системного автоматизированного подхода в области управления рисками ИТ-проекта;

• механизмов анализа рисков с применением современных статистико-математических методов;

• функций контроля выполнения мероприятий по минимизации рисков и расчету экономического эффекта;

• механизмов автоматического мониторинга эффективности системы управления рисками;

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

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

 

8.2. Сравнение коробочного и собственного ПО управления рисками

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

При выборе следует обратить внимание на три фактора: сроки внедрения, качество внедрения, стоимость внедрения.

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

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

Таблица 10.

Критерии выбора заказного/готового программного продукта 

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

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

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

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

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

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

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

На начальном этапе происходят определение требований к системе управления рисками, согласование требований внутри проектной команды. Далее происходят анализ рынка решений и предварительный просмотр систем, где определяются наличие требуемой функциональности, опыт внедрения, отзывы от предыдущих аналогичных проектов. На основе предварительного просмотра систем происходит выбор сокращенного списка поставщиков. Далее осуществляется более детальный анализ на соответствие функциональным, техническим и прочим требованиям на основе взвешенной модели оценки. Если поставщикам рассылался запрос на предоставление информации (Request for Information – RFI), проводится качественный анализ ответов. Вместе с анализом ответов составляются сценарии показа систем на соответствие требованиям. Демонстрации систем оцениваются с помощью балльной оценки, основанной на анализе сильных и слабых сторон продукта, впечатления от поставщика решения. По окончании анализа поставщиков на соответствие требованиям и демонстрации системы формируется решение по выбору поставщика системы управления рисками. После заключения контракта происходит внедрение выбранного решения.

Рис. 26. Этапы отбора поставщиков ПО

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

 

8.3. Обзор ПО: преимущества и недостатки

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

В качестве продукта поддержки процессов управления рисками при реализации программных проектов может использоваться как специализированная система, так и модули управления рисками многофункциональных систем управления проектами (Microsoft Project, Open Plan, Primavera) или же модули системы управления предприятием (Oracle, SAP, Microsoft Axapta и прочие). Как было описано выше, возможно создание собственной разработки в области управления рисками программных проектов.

В зависимости от типов рисков выделяют различные системы управления рисками. Ниже представлена классификация ПО в области управления рисками, содержащая наиболее распространенные в России программные продукты.

1. Управление операционными/банковскими рисками на уровне всего предприятия реализовано в программных продуктах Egar Technology, SAS, IBM, прочих.

2. Поддержка рисков информационной безопасности (с привязкой к существующим стандартам, например ISO 17799) отражена в решениях Cramm, RiskWatch, Кондор+, Cobra, прочих.

3. Для управления рисками проектов (как один из инструментов Project Management Software) используются системы Primavera Project Planning, Spider Project, Open Plan, прочие.

4. Управление рисками программных проектов (на основе методологий разработки ПО) реализовано практически всеми крупными разработчиками программного обеспечения, наиболее известны продукты IBM Rational Portfolio Manager, OCTAVE-S.

Рис. 27. Рейтинг систем управления рисками, Standish Group Report, 2009 (RiskTech100TM)

Помимо перечисленных систем, на российском рынке также присутствуют такие многофункциональные системы в области управления рисками, как: @Risk Professional for Project, Dekker TRAKKER, Enterprise project, ER Project 1000, Intelligent Planner, Mesa/Vista Risk Manager, Risk Track, Open Plan. ERA by Methodware, NetRisk/RiskOps 2.3, Pacemetrics. Обзор наиболее популярных западных систем представлен на рис. 27.

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

1. IBM Rational Portfolio Manager (IBM). Система полностью поддерживает методологию COBИТ и предоставляет инфраструктуру для введения элементов управления, которые помогут обеспечить соответствие законодательным нормативам, таким как закон Сарбейнса-Оксли и соглашение Basel II, и устранить разрыв между потребностями управления, техническими проблемами, бизнес-рисками и требованиями показателей производительности и реализацией инструментов финансового контроля.

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

2. OCTAVE-S – Operationally Critical Threat, Asset and Vulnerability Evaluation System (SEI). Система OCTAVE-S разработана институтом Software Engineering Institute (SEI) при университете Карнеги Меллон для моделирования поведения оценки рисков в организации. OCTAVE спроектирована на основе методологии информационной безопасности и предусматривает высокую степень гибкости, достигаемую путем выбора критериев, которые предприятие может использовать при адаптации под собственные нужды, и позволяет поддерживать следующие процессы управления рисками:

• идентификацию критичных информационных активов;

• идентификацию угроз для критичных информационных активов;

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

• оценку рисков, связанных с критичными информационными активами.

Особенность данной методики заключается в том, что весь процесс анализа производится силами сотрудников организации, без привлечения внешних консультантов. Для этого создается смешанная группа, включающая как технических специалистов, так и руководителей разного уровня, что позволяет всесторонне оценить последствия возможных инцидентов и разработать контрмеры. В качестве инструмента моделирования и оценки OCTAVE предлагает при описании профиля использовать «деревья вариантов». В доступной базе данных рассматриваются компоненты следующих классов: серверы; сетевое оборудование; СЗИ; персональные компьютеры; домашние персональные компьютеры «надомных» пользователей, работающих удаленно, но имеющих доступ в сеть организации; мобильные компьютеры; системы хранения; беспроводные устройства и связанные с ними риски.

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

3. Risk Watch (RiskWatch, Inc). Компания RiskWatch разработала собственную методику анализа рисков и семейство программных средств, в том числе для информационных рисков ИТ-проектов (RiskWatch for Information Systems), и является мощным средством анализа и управления рисками. Программное обеспечение охватывает физические методы защиты ИС, а также информационные риски и служит для оценки требованиям стандарта ISO 17799. В семейство RiskWatch входят программные продукты для проведения различных видов аудита безопасности, которые позволяют вводить в модель системы безопасности новые категории, описания, а также получать качественные и количественные ответы на вопросы безопасности, исходя из данных в системе.

В качестве критериев для оценки и управления рисками используются «предсказание годовых потерь» (Annual Loss Expectancy – ALE) и оценка «возврата от инвестиций» (Return on Investment – ROI). В части оценки рисков система дает возможность устанавливать связи между ресурсами, потерями, угрозами и уязвимостями, рассчитывать математические ожидания потерь с учетом частоты возникновения угрозы риска и стоимость ресурса, который подвергается риску. Дополнительно рассматриваются сценарии «что, если», которые позволяют описать аналогичные ситуации при условии внедрения средств защиты.

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

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

4. CRAMM (CCTA Risk Analysis and Management Method – CCTA UK). Система CRAMM создана на основе методологии управления рисками CRAMM и предполагает использование технологий оценки угроз и уязвимостей по косвенным факторам с возможностью проверки результатов. В основе метода CRAMM лежит комплексный подход к оценке рисков, сочетающий количественные и качественные методы анализа. В модель оценки заложен механизм моделирования информационных систем с позиции безопасности с помощью обширной базы данных по контрмерам. Для каждой группы ресурсов и каждого из 36 типов угроз/уязвимостей генерируется список вопросов, допускающих однозначный ответ. Уровень угроз и уязвимостей оценивается, в зависимости от ответов, как очень высокий, высокий, средний, низкий и очень низкий. Далее CRAMM объединяет угрозы и уязвимости в матрице риска. Система нацелена на детальную оценку рисков и эффективности предполагаемых к использованию комбинаций методов управления рисками. Помимо анализа рисков, CRAMM позволяет решать ряд параллельных задач, включая:

• проведение обследования используемой/внедряемой ИТ и выпуск сопроводительной документации на всех этапах его проведения;

• проведение аудита на основе стандарта безопасности информации BS 7799:1995;

• разработку политики безопасности и плана обеспечения непрерывности бизнеса.

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

5. КОНДОР+ (Digital Security). Программный продукт позволяет менеджерам ИТ-проектов проверить политику информационной безопасности компании на соответствие требованиям ISO 17799. КОНДОР+ включает в себя более 200 вопросов, ответив на которые специалист получает подробный отчет о состоянии существующей политики безопасности, а также модуль оценки уровня рисков соответствия требованиям ISO 17799.

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

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

6. Отечественные программно-инструментальные комплексы «Управление рисками», «Уязвимость», «Анализ безопасности» (в составе комплекса «Моделирование процессов в жизненном цикле систем – ноу-хау», свидетельство Роспатента № 2004610858) и «Программно-вычислительный комплекс оценки качества производственных процессов» (свидетельство Роспатента № 2010614145) – см. рис. 28–35. Дружественный пользовательский интерфейс делает работу с комплексами удобной и доступной практически любому пользователю.

Рис. 28. Заставка комплекса «УПРАВЛЕНИЕ РИСКАМИ»

Комплексы базируются на применении математических методов и моделей, согласно требованиям системообразующих стандартов (ГОСТ Р ИСО 9001 «Системы менеджмента качества. Требования», ГОСТ Р ИСО/МЭК 15288 «Системная инженерия – Процессы жизненного цикла систем», ГОСТ Р ИСО/МЭК 12207 «Системная и программная инженерия – Процессы жизненного цикла программных средств», ГОСТ Р ИСО/МЭК 16085 «Менеджмент риска. Применение в процессах жизненного цикла систем и программного обеспечения», ISO/IEC 31000 «Риск-менеджмент. Принципы и руководства» и др.), в том числе в процессе разработки проекта и системы, при проведении контроля, аудита и сертификации. Применение комплексов обеспечивает аргументированное решение следующих научно-технических задач: организация эффективных систем менеджмента качества на предприятиях; обоснование системотехнического облика и количественных требований технического задания к характеристикам систем, технологиям их создания и функционирования, к квалификации разработчиков и пользователей; оценка и обоснование технических решений, анализ и снижение рисков при управлении проектами; исследование вопросов защищенности систем от потенциальных угроз безопасности (в том числе информационной безопасности), выявление «узких мест» и уязвимостей систем и рациональных путей их устранения с указанием условий, когда это принципиально возможно, и др.

Рис. 29. Исходная форма для выбора моделей

Рис. 30. Заставка комплекса «УЯЗВИМОСТЬ»