+7 499 350 77 10
+7 499 322 88 70
Алексей Краснов

Требования к информационной безопасности: кого вовлекать в выявление?

Риск-ориентированный подход. Этапы и особенности выявления требований кибербезопасности. Матрица ответственности за выявление рисков ИБ и согласование требований.
Введение

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

Вопросы, рассматриваемые в статье:

  1. Сложности, с которыми сталкиваются аналитики при выявлении требований к ИБ.
  2. Терминология риск-ориентированного подхода.
  3. Этапы процесса выявления требований к ИБ.
  4. Кого из заинтересованных лиц необходимо вовлекать в процесс выявления требований к ИБ и почему именно их.
  5. Пример RACI-матрицы заинтересованных лиц.
Статья будет полезна аналитикам, тестировщикам, разработчикам и руководителям проектов, заинтересованных в качественном сборе требований к информационной безопасности.

Время на чтение статьи: 17 минут
Не любите читать? Посмотрите видео.
Оглавление
Введение
Не любите читать? Посмотрите видео.
В чем проблематика выявления требований к ИБ?
Терминология
Этапы процесса выявления требований к ИБ
Пересмотр требований ИБ
Кого из заинтересованных лиц привлечь на каждом из этапов?
Этап 1. Определить и оценить защищаемую информацию
Этап 2. Определить архитектуру системы и границы доверия
Этап 3. Определить злоумышленников
Этап 4. Выявить и оценить уязвимости и угрозы
Этап 5. Оценить риски ИБ
Этап 6. Сформировать требования для реализации контрмер
RACI-матрица заинтересованных лиц
Заключение
Ответы на вопросы
Об авторе
В чём проблематика выявления требований к ИБ?

Многим бизнес- и системным аналитикам часто непонятно с чего начать формулирование требований к ИБ. Если при написании функциональных требований понятно, что сначала определяем бизнес-требования, затем пользовательские и функциональные, то с требованиями к ИБ всё не так просто. Возникают вопросы:

  • Кого привлечь к выявлению требований к ИБ?
  • Что именно необходимо прояснить?
  • Какая информация необходима на каждом этапе?
  • Как понять, что требования достаточно полны?

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

Различия в выявлении функциональных требований и требований к ИБ
Для выявления требований к ИБ может применяться риск-ориентированный подход (или риск-менеджмент). Суть подхода — решения по реализации мер защиты информационной системы принимаются на основе анализа и оценки рисков нанесения ущерба организации.
Управление рисками информационной безопасности регламентируется международным стандартом ISO/IEC 27 005 «Information security, cybersecurity and privacy protection — Guidance on managing information security risks» (ГОСТ Р ИСО/МЭК 27 005 «Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности»).
Далее рассмотрим систему понятий этого подхода и основные этапы процесса выявления требований к ИБ, предусмотренные этим подходом.
Терминология риск-ориентированного подхода
Основные используемые термины:

  • Информация
  • Владелец информации
  • Информационная система
  • Уязвимость
  • Угроза ИБ
  • Негативное бизнес-последствие
  • Риск ИБ
  • Нарушитель (злоумышленник)
Их связь друг с другом можно увидеть на рисунке ниже.

Система понятий риск-ориентированного подхода
В анализируемой информационной системе (ИС) обрабатывается некая информация, представляющая ценность для её владельцев и подлежащая защите. ИС может иметь или имеет уязвимости — «слабые места».

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

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

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

Для «смягчения» рисков можно предпринять контрмеры. Задача аналитика — описать требования к ИБ, которые «закроют» уязвимости системы. Контрмера должна закрывать, как минимум, одну уязвимость, иначе её реализация будет бессмысленна. При этом не нужно закрывать абсолютно все уязвимости — применение контрмер необходимо приоритизировать с учётом оценки рисков.
Не стоит забывать, что контрмеры также могут иметь уязвимости. Предположим, что в качестве протокола передачи данных используется HTTP. Уязвимость протокола известна — данные передаются в открытом виде и злоумышленник может достаточно легко этим воспользоваться. В качестве решения применяется контрмера — шифрование данных. Если выбранный алгоритм шифрования является слабым или устаревшим, такая контрмера может быть уязвимой. Соответственно для этой уязвимости нужна новая контрмера.

Разработка требований к информационной безопасности ИТ-систем


Воркшоп для системных аналитиков уровня джун и миддл и других ИТ-специалистов, которые хотят выявлять и формировать требования к ИБ
Посмотреть программу воркшопа
Этапы процесса выявления
требований к ИБ
Этап 1. Идентификация и оценка защищаемой информации. Для данного этапа нужна модель предметной области. Здесь аналитик проанализирует бизнес-правила (требования регуляторов и вышестоящих организаций к информационной безопасности) с учётом вида защищаемой информации.

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

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

Этап 5. Оценка рисков ИБ. Для оценки рисков необходимо использовать информацию, полученную на предыдущих этапах.

Этап 6. Формирование требований для реализации мер по ИБ (контрмер), направленных на устранение выявленных ранее уязвимостей системы. В первую очередь необходимо формировать требования для устранения уязвимостей с наиболее высокими рисками.

Все эти этапы отрабатываются на практике воркшопа «Разработка требований к информационной безопасности ИТ-систем».

Этапы процесса выявления требований к ИБ
Пересмотр требований ИБ

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

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

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

  1. Что именно мы ожидаем от них?
  2. Какие решения они могут принимать?
  3. Как они могут помочь?

Роли, которые перечисляются далее, могут именоваться по-другому в вашей организации. Помните, что исходить нужно в первую очередь от ожиданий и потребностей на том или ином этапе. Если используете методологию разработки Waterfall, то оценивать будете всю систему и список заинтересованных лиц будет большим. Если используете Agile-подходы, то список заинтересованных лиц будет меньше и может меняться в зависимости от рассматриваемой User Story.
Сессии в рамках каждого этапа может фасилитировать бизнес-аналитик, так как здесь требуются навыки интервьюирования и работы с фокус-группами.
Каждый этап выявления требований к ИБ проиллюстрируем примером.
Предположим, что мы реализуем новую функциональность в системе — оформление заказа на товар с оплатой при доставке.
Этап 1. Определить и оценить защищаемую информацию

На этом этапе мы ждём, что заинтересованные лица знают:

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

Заинтересованные лица, которых можно привлечь с учётом ожиданий:

  • Владелец продукта (Product owner)
  • Руководители бизнес-подразделений
  • Менеджеры по маркетингу, финансам
  • Менеджеры по работе с клиентами, поставщиками
  • Юристы
  • Руководитель службы ИБ
  • Архитектор системы
  • Бизнес-аналитик

На этом этапе мы выясняем, что наша система хранит в себе такие данные:

  • Каталог товаров со стоимостями
  • Сведения о покупателях — физических лицах: их персональные данные (ФИО, адреса, номера телефонов) и историю покупок
  • Сведения о сотрудниках (менеджеры, администраторы, курьеры)
Если кратко, то на этом этапе ожидается, что заинтересованные лица помогут определить перечень защищаемой информации и смогут дать экспертную оценку её ценности и последствий в случае наступления негативных событий.
Этап 2. Определить архитектуру системы и границы доверия

На этом этапе мы ждём, что заинтересованные лица знают:

  • Какая, где и как хранится, передаётся и обрабатывается информация
  • Где проходят границы доверия между компонентами системы
  • Ролевую модель системы (кто, куда и какого уровня имеет доступ)
  • Как строить диаграммы (DFD, ERD, UML), чтобы задокументировать архитектуру системы
  • Какие средства и меры ИБ уже используются в системе

Заинтересованные лица, которых можно привлечь с учётом ожиданий:

  • Архитектор системы
  • ИТ-архитектор организации
  • Руководитель ИТ-службы
  • Администратор баз данных
  • Системный администратор
  • Сетевой инженер
  • Инженер по эксплуатации серверного оборудования
  • Системный аналитик
  • Специалист по ИБ
  • Бизнес-аналитик

На этом этапе мы выясняем, что наша система состоит из сервисов, отвечающих за:

  • Каталог товаров
  • Пользователей системы и их роли
  • Заказы клиентов

Границы доверия системы пролегают:
  • Там, где происходит взаимодействие компонентов системы (сервисов) друг с другом
  • Там, где происходит взаимодействие системы с внешними системами (например, мы получаем информацию о наличии товара от какой-то другой системы)
  • Там, где происходит взаимодействие системы с пользователями (процессы регистрации, авторизации, оформления заказов и т. д.)
Этап 3. Определить злоумышленников
На этом этапе мы ждём, что заинтересованные лица знают:
  • Кто имеет интерес к информации и почему
  • Кто может желать негативных последствий для нашей организации и почему
  • Могут ли бывшие или текущие работники быть нарушителями и почему
  • Что может помешать нарушителю (моральные принципы, боязнь законодательной ответственности или что-то иное)
  • Существует ли возможность сговора нарушителей: какие у сговора могут быть цели, в чём выгода сговорщиков, как может произойти сговор и как можно этому помешать
  • Какие у нарушителей есть возможности в области ИТ: знание SQL, сетевых протоколов, облачных технологий, умение программировать
  • Какие у нарушителей есть возможности в области ИБ: знания защищённых протоколов передачи данных, криптографических алгоритмов, знания уязвимостей архитектурных подходов, технологий и алгоритмов, средств ИБ
  • Какими знаниями о системе владеют нарушители: знают ли предполагаемые нарушители применяемые технологии, протоколы, библиотеки, версии СУБД, архитектурные подходы, бизнес-процессы, процессы ИБ
  • Права доступа, которые могут иметь нарушители: доступ к данным, коду или компонентам системы на разных стадиях проектирования, реализации и эксплуатации системы

Заинтересованные лица, которых можно привлечь с учётом ожиданий:

  • Владелец продукта (product owner)
  • Руководитель бизнес-подразделений
  • Менеджеры по маркетингу и финансам
  • Руководитель HR-службы
  • Специалист по ИБ
  • ИТ-архитекторы
  • Администратор баз данных
  • Системный администратор/инженер эксплуатации
  • Сетевой инженер
  • Тестировщик
  • Разработчик
  • Менеджеры по работе с клиентами и с поставщиками

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

  • Мошенники, целью которых использование данных в нашей системе в собственных корыстных целях
  • Лица, выполняющие взлом по заданию некоторых конкурентов, цель которых — дискредитация компании, подрыв репутации среди клиентов

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

На этом этапе мы ждём, что заинтересованные лица:

  • Знают особенности применяемых или планируемых к применению технологий, процессов, протоколов, алгоритмов, библиотек
  • Знают участников автоматизированных процессов
  • Знают уязвимости (слабые места) участвующих людей и применяемых протоколов, процессов, алгоритмов;
  • Знают ответ на вопрос «Что может пойти не так?»
  • Умеют находить исключительные ситуации и задавать вопрос «А что если?»
  • Знают способы эксплуатации уязвимостей, сложности их нахождения и использования
  • Знают о том, какие доступы, знания и умения нужны для эксплуатации уязвимостей
  • Умеют устанавливать причинно-следственные связи

Заинтересованные лица, которых можно привлечь с учётом ожиданий:

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

Способы фиксации выявленных угроз

  1. Создать отдельный тип сущностей «Угроза» в системе управления требованиями.
  2. Указать угрозы в рассматриваемой User Story.

Пример фиксации угрозы в Jira и связывание с User Story и контрмерой
Этап 5. Оценить риски ИБ

На этом этапе мы ждём, что заинтересованные лица:

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

Заинтересованные лица, которых можно привлечь с учётом ожиданий:

  • Владелец продукта (product owner)
  • Руководители бизнес-подразделений
  • Архитектор системы
  • Руководитель ИТ-службы
  • Руководитель службы ИБ
  • Методист (специалист) по оценке рисков
  • Бизнес-аналитик
Перед оценкой рисков необходимо составить методику оценки: все участники должны знать и одинаково понимать критерии оценки. В процессе оценки необходимо использовать информацию, полученную на предыдущих этапах:

  1. Угрозы ИБ и к каким нежелательным последствиям эти угрозы могут привести
  2. Вероятности реализации угроз в зависимости от сложности эксплуатации Уязвимостей, от мотивов и возможностей злоумышленников
  3. Оценки последствий при наступлении нежелательных событий
  4. Возможности злоумышленников
На этом этапе мы выясняем, что негативные бизнес-последствия в случае создания большого числа фиктивных заказов будут очень большими. Поэтому необходимо реализовать контрмеры в порядке высокого приоритета.
Этап 6. Сформировать требования для реализации контрмер

На этом этапе мы ждём, что заинтересованные лица знают:

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

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

Заинтересованные лица, которых можно привлечь с учётом ожиданий:

  • Системный аналитик
  • Бизнес-аналитик
  • Архитектор системы
  • Специалист по ИБ

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

Пример такой пользовательской истории:
«Я как менеджер службы обработки заказов, хочу, чтобы пользователи устанавливали пароли, которые сложно было бы подобрать, для того, чтобы злоумышленник не смог путём подбора пароля оформить заказ от имени зарегистрированного пользователя».

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

  1. Проверять сложность пароля при создании аккаунта
  2. Проверять сложность пароля при изменении пароля
  3. Пароль должен состоять не менее чем из 8 символов
  4. Пароль должен содержать …
  5. Требовать смену пароля не реже, чем …
  6. Отображать уровень сложности пароля при его создании и изменении по следующим правилам:
    • простой, если …
    • средний, если …
    • сложный, если …
RACI-матрица заинтересованных лиц
Итак, мы рассмотрели 6 этапов процесса выявления требований к безопасности информационных систем. В каждый из этапов должны быть вовлечены разные заинтересованные лица. Их состав и зоны ответственности будут зависеть от организационной структуры вашей компании.

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

Пример RACI-матрицы заинтересованных лиц

В RACI-матрице есть 4 вида ответственности:

  1. R — Responsible (исполнитель). Сотрудник, выполняющий задачу.
  2. A — Accountable (ответственный). Сотрудник, ответственный за результат решения задачи. Важно, что у каждой задачи может быть только один ответственный.
  3. C — Consult (консультирующий). Эксперт, консультирующий исполнителя.
  4. I — Informed (информируемый). Сотрудник, информируемый о ходе решения задачи.

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

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

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

Разработка требований к информационной безопасности ИТ-систем


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

    Для выявления уязвимостей системы существуют различные подходы и фреймворки, один из которых мы рассматриваем на воркшопе «Разработка требований к информационной безопасности ИТ-систем».
  • Вопрос:
    Какой минимум знаний должен иметь системный аналитик, чтобы решать проблемы в области кибербезопасности?
    Ответ:

    Для системного аналитика необходимо знать основные концепции защищённого ПО, термины и основные методы информационной безопасности (аутентификация, авторизация, контроль целостности, логирование, криптографическая защита и т. д.).
    Далее, в зависимости от вида защищаемой информации, переходить к изучению требований соответствующих регуляторов (ФСТЭК, ФСБ, NIST и других), международных стандартов, например, ISO/IEC 27 001 «Системы обеспечения информационной безопасности» (ГОСТ Р ИСО/МЭК 27 001 «Системы менеджмента информационной безопасности. Требования»).
    Можно также изучить требования, необходимые для получения сертификата CSSLP. Это даст понимание о том, что нужно знать специалисту для разработки защищённого ПО. Имеется книга для подготовки к данному экзамену: «Official (ISC)2 Guide to the CSSLP CBK» (Mano Paul).

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

    1. «Threat Modeling. A Practical Guide for Development Teams» (Izar Tarandach, Matthew J. Coles).
    2. «API Security in Action» (Neil Madden).
    3. «Real World Cryptography» (David Wong).
  • Вопрос:
    Что делать, если мой проект маленький и нет отдельно выделенных ролей из перечисленных (архитектор, бизнес-аналитик и т. д.)?
    Ответ:
    Несмотря на то, что отдельно выделенных ролей нет, кто-то всё равно выполняет эти функции. Даже если нет бизнес-аналитика, кто-то обязательно занимается выявлением бизнес-требований и т. д.
  • Вопрос:
    Знания в области безопасности информационных и автоматизированных систем очень ценятся работодателями. Подскажите, какие материалы можно почитать, чтобы восполнить пробелы?
    Ответ:
    Как минимум, нужно ознакомиться с ключевыми терминами ИБ (идентификация, аутентификация, авторизация, шифрование, угроза, уязвимость и т. д.), с основными уязвимостями web-приложений, а также изучить требования регуляторов к безопасности информации, обрабатываемой в вашей системе.
Автор
Алексей Краснов
Ведущий бизнес-аналитик в EPAM Systems
  • Высшее образование в области компьютерной безопасности и 10 лет опыта в ИБ
  • Последние 7 лет занимается бизнес- и системным анализом
  • Основные бизнес-домены: информационная безопасность, телеком, электронное правительство, транспортировка нефтепродуктов, цифровая реклама