• Все разделы
  • Статьи
  • Медиа
  • Новости
  • Нормативные материалы
  • Конференции
  • Глоссарий

Статьи по теме: «Информационная безопасность»

Главная Специалистам Статьи Формирование требований к будущей системе ИБ организации

Формирование требований к будущей системе ИБ организации

Формирование требований к системам информационной безопасности — важный и трудоемкий процесс. Необходимо учесть множество факторов, от которых зависит надежность системы. Эта статья поможет систематизировать знания требований по созданию СИБ.

Формирование требований к будущей системе ИБ организации

Введение

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

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

Основные работы по созданию СИБ, включая формирование требований к ней, приведены на рисунке:

Роли заказчиков и исполнителей при формировании требований к СИБ

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

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

Один сотрудник может выполнять несколько ролей.

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

  • внутренним, то есть работать в той же организации, что и заказчик;
  • внешним – это сторонняя компания.

Со стороны исполнителя в минимальном варианте также рекомендуется выделять следующие роли:

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

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

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

Сбор исходных данных об информационной системе

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

Данные задачи вытекают из модели взаимоотношений между владельцами, объектами защиты, уязвимостями, нарушителями, угрозами, рисками и контрмерами согласно ГОСТ Р ИСО/МЭК 15408-1-2008.

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

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

Анализ угроз безопасности информации

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

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

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

Разработка отчета и определение состава подсистем обеспечения ИБ

На данном этапе осуществляется подготовка отчета, содержащего:

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

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

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

  • общие данные, такие как страна-производитель;
  • заявленные основные функциональные возможности, предъявляемые по назначению класса СЗИ;
  • заявленные показатели производительности;
  • условия применения СЗИ и требования к среде эксплуатации;
  • заявленная совместимость с аппаратным и программным обеспечением, используемым в ИТ-инфраструктуре;
  • возможности масштабирования;
  • специализированные возможности СЗИ с учетом их назначения;
  • ценовая характеристика и стоимость владения;
  • наличие документов, подтверждающих соответствие нормативным требованиям регуляторов (ФСТЭК, ФСБ).

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

Разработка концепции (плана реализации мер защиты)

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

  1. обследование;
  2. проектирование СИБ;
  3. разработка эксплуатационной документации на СИБ;
  4. внедрение СЗИ и организационных мер защиты, при необходимости - настройка используемых штатных средств объекта защиты;
  5. обеспечение мониторинга ИБ и эксплуатация СЗИ.

При необходимости предлагаемая программа проектов может быть скорректирована, например, некоторые проекты могут быть объединены, а внедрение СЗИ разбито по подсистемам.

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

Документ «Технико-экономическое обоснование создания СИБ» (ТЭО) предназначен для обоснования технических решений и экономической целесообразности создания или развития СИБ.

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

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

Тестирование рассматриваемых вариантов подсистем СИБ

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

Существуют следующие виды тестирования:

  • демонстрация;
  • экспресс-пилот (Proof-of-Concept);
  • пилотный проект.

Информация по видам тестирования приведена в таблице:

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

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

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

Целью проведения пилотного проекта является подтверждение на тестовом стенде функциональных возможностей СЗИ предъявляемым требованиям. В состав тестового стенда должны входить СЗИ, определенные на этапе разработки отчета и определения состава подсистем обеспечения ИБ, а также часть ИТ-инфраструктуры в соответствии с разработанными рекомендациями (условиями) для проведения пилотного проекта.

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

В рамках пилотного проекта выполняется:

  • комплектация программным/программно-аппаратным обеспечением (при необходимости могут использоваться демонстрационные, но полнофункциональные версии СЗИ);
  • монтаж и пусконаладка средств защиты информации (при необходимости);
  • конфигурирование средств защиты информации (политик и правил безопасности);
  • стендирование работы СЗИ.

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

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

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

Разработка технического задания на создание СИБ

Техническое задание (ТЗ) на СИБ является основным документом, определяющим требования и порядок создания СИБ, в соответствии с которым проводится разработка СИБ и ее приемка при вводе в действие.

Формат ТЗ на СИБ согласуется между заказчиком и исполнителем. Рекомендуемая структура и содержание документа «Техническое задание» приведены в ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» и руководящих документах в области защиты информации.

Согласно ГОСТ 34.602-89, ТЗ на СИБ содержит следующие разделы, которые могут быть разделены на подразделы:

  1. общие сведения;
  2. назначение и цели создания СИБ;
  3. характеристика объектов защиты;
  4. требования к СИБ;
  5. состав и содержание работ по созданию СИБ;
  6. порядок контроля и приемки СИБ;
  7. требования к составу и содержанию работ по подготовке объекта защиты к вводу СИБ в действие;
  8. требования к документированию;
  9. источники разработки.

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

Заключение

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

Авторы:

Валентина Старостина, эксперт ЦИБ, компания «Инфосистемы Джет»,
Андрей Янкин, заместитель директора ЦИБ, компания «Инфосистемы Джет».
Моделирование угроз на основе сценариев или Как Cyber Kill Chain и ATT&CK помогают анализировать угрозы ИБ Инструкции и регламенты информационной безопасности: второй уровень организационно-распорядительной документации СИБ