Текст книги "Управление риском ИТ. Основы"

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

3. Критерии качества: заблаговременная формулировка критериев качества (например: производительность, отсутствие ошибок, проведение необходимых тестов и др.), при этом для каждого типа релиза есть своя цель по качеству. Без соблюдения критериев качества релиз не выпускается.

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

5. Минимально жизнеспособный продукт (MVP): ПО реализуется порционно, минимально необходимыми блоками, но сразу в соответствии с требованиями и с учетом различных критериев, что позволяет лучше контролировать процесс разработки, внедрения и поддержки, снижая издержки.

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

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

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

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

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

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

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

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

Подготовка

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

3.2. ОБЩИЕ РЕКОМЕНДАЦИИ ПО СНИЖЕНИЮ

РИСКОВ БЕЗОПАСНОСТИ НА ЭТАПЕ РАЗРАБОТКИ

И ПРОЕКТИРОВАНИЯ

Требования

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

Компания Microsoft в методологии безопасной разработки рекомендует определить требования к надежности для разрабатываемого ПО. Требования безопасности лучше всего определять на самых ранних этапах планирования.

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

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

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

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

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

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

Панель ошибок – это контрольное условие качества, которое применяется ко всему проекту разработки ПО в целом. Панель используется для определения порогов серьезности уязвимых мест системы безопасности ПО – например, для определения отсутствия известных уязвимостей с оценкой «критическая» или «важная» в приложении на момент его выпуска.

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

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

В ходе таких оценок необходимо получить следующие сведения:

• для каких компонентов проекта перед выпуском потребуется моделирование рисков?

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

• для каких компонентов проекта потребуется тестирование на проникновение, выполняемое взаимно согласованной группой (внешней по отношению к группе проекта), если такое тестирование необходимо?

• существуют ли дополнительные требования к тестированию или анализу, которые консультант по безопасности (эксперт, внутренний или внешний, обладающий необходимыми знаниями в области ИБ и безопасной разработки) считает необходимыми для защиты от угроз?

• какова конкретная область требований тестирования?

• какова оценка влияния на конфиденциальность?

Проектирование

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

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

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

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

• точно и полно описывать предполагаемое применение компонента или функции;

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

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

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

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

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

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

Уменьшение количества возможных направлений, векторов для проведения атак.

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

Уменьшение количества возможных векторов, направлений для атак и потенциальных угроз – это способ снизить риски, предоставляя злоумышленникам меньше возможностей для использования потенциально слабых мест или уязвимостей в ПО.

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

Моделирование рисков. Моделирование используется в средах с высокой вероятностью нарушения безопасности. Эта процедура позволяет группе разработчиков рассмотреть, задокументировать и обсудить последствия выбора разных вариантов проектирования для безопасности в контексте планируемой рабочей среды, объединяя эти данные в четкую структуру. Кроме того, моделирование рисков позволяет рассматривать вопросы безопасности на уровне компонента или приложения. В моделировании рисков принимают участие члены рабочей группы: руководители программы или проекта, разработчики и тест-инженеры. Моделирование рисков – это основная задача анализа безопасности, которая выполняется на этапе проектирования ПО

Реализация

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

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

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

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

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

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

Внедрение

3.3. ОБЩИЕ РЕКОМЕНДАЦИИ ПО СНИЖЕНИЮ РИСКОВ

НА ЭТАПЕ ВНЕДРЕНИЯ ПО

Проверка

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

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

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

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

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

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

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

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

Консультант по безопасности может потребовать проведения дополнительных fuzz-тестов или увеличения области и длительности fuzz-тестирования.

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

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

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

Внедрение

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

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

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

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

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

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

Существует три возможных результата окончательной проверки безопасности:

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

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

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

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

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

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

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

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

Эксплуатация и развитие

3.4. ОБЩИЕ РЕКОМЕНДАЦИИ ПО СНИЖЕНИЮ

РИСКОВ БЕЗОПАСНОСТИ НА ЭТАПЕ ЭКСПЛУАТАЦИИ

И РАЗВИТИЯ

План поддержки и развития ПО

В рамках жизненного цикла ПО этап его эксплуатации плотно связан с поддержкой и развитием ПО.

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

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

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

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

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

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

В индустрии разработки ПО различают четыре типа обслуживания программного обеспечения:

1. Корректирующее обслуживание.

2. Адаптивное обслуживание.

3. Улучшающее обслуживание.

4. Профилактическое обслуживание.

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

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

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

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

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

3.5. РЕКОМЕНДАЦИИ МЕНЕДЖМЕНТУ КОМПАНИЙ

ПРИ СОЗДАНИИ, ВНЕДРЕНИИ, ЭКСПЛУАТАЦИИ

И РАЗВИТИИ ПО

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

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

«Метод взвешенных коэффициентов»

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

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

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

1. Для каждой идентифицированной угрозы X_n каждого жизненного цикла ПО руководство экспертным методом определяет «важность угрозы», то есть уровень ее влияния на деятельность компании в целом по шкале от 1 до 3, где 1 – высокая критичность, 2 – средняя критичность, и 3 – низкая критичность. Важность угрозы обозначается как y_n.

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

3. Для каждой угрозы каждый эксперт из сформированной команды (возможно, анонимно) проставляет свою оценку критичности угрозы от 1 до 5, где 1 – очень критично, по мнению эксперта, и 5 – незначительная угроза. Оценка эксперта обозначается как Z_i.

4.. После проставления всех необходимых значений для угрозы X_n рассчитывается значение взвешенного коэффициента:

Формула 1

где y_i = y_n, если руководство компании считает важность угрозы равной для всех подразделений, представители которых участвуют в оценке критичности Z_i. Либо руководство выставляет разные веса y_i в диапазоне от 1 до 3, чтобы учесть различия в критичности угрозы для деятельности разных подразделений и степень влияния нарушений их деятельности на деятельность компании в целом в случае реализации угрозы.

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

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

3.6. РАЗРАБОТКА И ПРОЕКТИРОВАНИЕ

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

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

Меры минимизации рисков

Внедрение

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

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

Меры минимизации рисков

Эксплуатация и развитие

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

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

Меры минимизации рисков

⠀

3.7. ПЕРЕЧЕНЬ ВОПРОСОВ ДЛЯ РУКОВОДСТВА

КОМПАНИИ

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

Этап самодиагностики

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

Пример 1. Лист анализа готовности компании к новому ПО

Для более наглядной демонстрации проблемных областей вопросы разделены на блоки:

• полнота проработки проекта (ППП);

• обеспечение ресурсами (ОР);

• информационная безопасность (ИБ).

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

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

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