Kitobdan iqtiboslar Управление риском ИТ. Основыmuallif Максим Торнов
Из приведенного примера можно сделать вывод, что при покупке программного продукта необходимо учитывать и в последующем контролировать:
• обоснованность автоматизации;
• возможность использования максимально стандартного функционала;
• возможные издержки на эксплуатацию стандартной версии ПО в противовес существенно измененной версии ПО.
Более того, глубоко кастомизированный продукт может быть проблемой не только для компании-заказчика, но и для производителя в случае неудачно сформулированного контракта. Однако для компании-разработчика такая ситуация может стать долгосрочным источником выручки, так как компании-заказчику, возможно, будет существенно дороже перейти на иной продукт, чем прекратить поддержку значительно доработанного ПО, и заказчик будет вынужден продолжать заказывать и оплачивать расходы на доработку.
Риск ИТ — это риск потерь организации, вызванный:
• нарушением конфиденциальности;
• сбоем целостности систем и данных;
• некорректной работой либо недоступностью систем и данных;
• невозможностью изменить ИТ-систему за разумное время и стоимость, в то время как среда функционирования и/или требования бизнеса меняются (то есть быстрота изменений).
Шаг 1. Начните с определения используемых ИТ-систем, автоматизированных сервисов и процессов, поймите их критичность для бизнеса, а также присущие данным технологиям риски.
Шаг 2. Понимая специфику каждого технологического решения и присущих им рисков, разработайте контрольные процедуры, направленные на снижение выявленных рисков. Реализуйте регулярность исполнения и способы оценки эффективности внедренных процедур.
Шаг 3. Зафиксируйте «правила игры» в различных регламентирующих документах. При описании процедур старайтесь придерживаться следующих вопросов: «Кто делает?», «Что делает?», «Как часто делает?», «Каков результат?» и самое главное «Зачем и какую цель достигает?».
Общайтесь открыто и конструктивно, заручитесь поддержкой владельцев ИТ-систем, автоматизированных сервисов и процессов, постарайтесь понять и учесть потребности, мнение, возможности и ограничения всех участников, в этом вам помогут следующие вопросы:
• какие цели могут быть у владельцев систем и сервисов?
• какие могут быть препятствия для достижения этих целей?
• как преодолеть препятствия и достичь цели?
Автор успел поработать в рамках каждой из линий защиты и убедился на собственном опыте, насколько важен открытый и эффективный диалог между всеми линиями, а также понимание важности управления рисками как высшим руководством организации, так и руководителями и владельцами процессов и сервисов. По убеждению автора, от этого выигрывают участники всех линий защиты
Риск ИТ можно измерить
Риск можно измерить как в количественном эквиваленте, так и в качественном. Для этого используют различные метрики. Приведу для примера несколько метрик, рекомендуемых организацией ISC[5].
Exposure Factor (SF) — фактор воздействия — процент потерь, которые организация может понести, в случае если актив будет подвержен реализации риска.
Single Loss Expectancy (SLE) — единовременный ожидаемый убыток, стоимость, присущая единовременной реализации риска в отношении актива.
Asset Value (AV) — стоимость актива.
Annualized Rate of Occurrence (ARO) — частота реализации риска в год.
Annualized Loss Expectancy (ALE) — ожидаемые годовые убытки от реализации риска.
Количественная оценка
Используя метрики, приведенные выше, можно сделать количественную оценку потенциальных потерь в случае реализации риска, присущего ИТ. Например:
AV = $ 200 000
EF = 45%
ARO = 2 раза
SLE = AV × EF
ALE = SLE × ARO
Таким образом:
SLE = $ 200 000 × 45% = $ 90 000. В случае реализации риска ⠀в ⠀отношении ⠀актива ожидается потеря организацией $ 90 000.
ALE = $ 90 000 × 2 = $ 180 000. В случае реализации риска «2 раза» организация потеряет в два раза больше.
Корректирующее обслуживание может быть необходимо либо для исправления различных ошибок, обнаруженных во время эксплуатации системы, либо для повышения производительности системы.
Адаптивное обслуживание включает в себя модификации и обновления, когда пользователям необходимо, чтобы программный продукт работал на новых платформах, в новых операционных системах, или чтобы продукт взаимодействовал с новым аппаратным и программным обеспечением.
Улучшающее обслуживание осуществляется, когда программный продукт нуждается в обслуживании для создания и поддержки новых функций, которые нужны пользователям, или для изменения различных типов функций системы в соответствии с требованиями заказчика.
Профилактическое обслуживание включает в себя модификации и обновления для предотвращения проблем с программным обеспечением в будущем. Данный тип обслуживания направлен на решение проблем, которые не являются значительными на текущий момент, но могут привести к серьезным проблемам в будущем.
В индустрии разработки ПО различают четыре типа обслуживания программного обеспечения:
1. Корректирующее обслуживание.
2. Адаптивное обслуживание.
3. Улучшающее обслуживание.
4. Профилактическое обслуживание.
К архивируемым данным относятся проектная документация, включая все спецификации и технические условия, переписка, исходный код, двоичные файлы, файлы базы данных, перечни пользователей и их роли, модели угроз, документация, планы реагирования в аварийной ситуации, условия лицензионного соглашения и обслуживания для любого ПО сторонних производителей, а также любые другие сведения, необходимые для выполнения задач поддержки и последующего развития ПО после внедрения.
Существует три возможных результата окончательной проверки безопасности:
1. Окончательная проверка безопасности пройдена. Все проблемы безопасности и конфиденциальности, обнаруженные в ходе проверки, решены полностью или частично.
2. Окончательная проверка безопасности пройдена с исключениями. Все проблемы безопасности и конфиденциальности, обнаруженные в ходе проверки, решены полностью или частично, и/или все исключения удовлетворительно разрешены. Проблемы, которые нельзя решить (например, уязвимости, вызванные проблемами унаследованного кода «уровня проектирования»), заносятся в журнал и исправляются в следующем выпуске.
3. Окончательная проверка безопасности с эскалацией. Если рабочей группе не удалось выполнить все требования SDL, а консультант по безопасности и группа продукта не смогли прийти к приемлемому соглашению, консультант по безопасности может не утвердить программный продукт, который в свою очередь не будет выпущен в промышленную эксплуатацию. В этой ситуации рабочие группы должны либо попытаться соблюсти те требования SDL, которые можно выполнить до выпуска, либо предоставить решение высшему руководству.
План реагирования на инциденты. Каждый выпуск ПО, к которому применяются требования SDL, должен иметь план реагирования на инциденты. Даже программы, в которых на момент выпуска отсутствуют известные уязвимости, могут быть не защищены от новых угроз, которые появятся в будущем.
Fuzz-тестирование. Это специальный вид динамического анализа путем намеренного ввода в приложение неверно сформированных или случайных данных, вызывающих сбой функций программного продукта.
Стратегия fuzz-тестирования разрабатывается на основе данных о планируемом использовании приложения, технических условий проектирования и функциональной спецификации.