Шаг 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-тестирования разрабатывается на основе данных о планируемом использовании приложения, технических условий проектирования и функциональной спецификации.
Динамический анализ ПО. Для того чтобы убедиться, что все функции программы работают так, как планировалось, необходима проверка ПО во время выполнения.
Такая проверка предполагает выбор инструментов, которые во время работы приложения отслеживают возможные сбои, связанные с работой данного ПО с памятью, нарушениями при управлении правами пользователей и другие важные аспекты безопасности.
Статический анализ. Группы проекта должны выполнять статический анализ исходного кода. Такой анализ обеспечивает масштабируемую возможность проверки безопасности кода и может помочь убедиться в выполнении политик создания безопасного кода.
Сам по себе статический анализ обычно не может заменить ручную проверку кода. Члены группы безопасности и советники по безопасности должны четко понимать все сильные и слабые стороны инструментов статического анализа и при необходимости заменять эти инструменты другими средствами или проверкой вручную.