Принципы реализации функций безопасности информационных технологий (NIST SP 800-27 Rev A)

Принципы реализации функций безопасности информационных технологий
(Ключевые моменты)
NIST Special Publication 800-27 Rev A. Engineering Principles for Information Technology Security (A Baseline for Achieving Security).

 

1. Введение.

2. Предпосылки.

2.1. Generally Accepted Principles and Practices for Securing Information Technology Systems (SP 800-14).

2.2 CommonCriteria

2.3. Многоуровневаязащита (Information Assurance Technical Framework)

 

3.Принципы безопасности.

3.1. Введение.

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

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

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

В настоящем документе модель жизненного цикла (ЖЦ) систем в соответствии с NISTSP 800-14 (GenerallyAcceptedPrinciplesandPracticesforSecuringInformationTechnologySystems), включающая в себя пять стадий:

  • инициирование,
  • разработка/приобретение,
  • внедрение,
  • эксплуатация/сопровождение,
  • снятие с эксплуатации.

 

Для того чтобы связать каждый принцип с соответствующими стадиями ЖЦ, используется таблица (пример приведен ниже таблице). В таблице в наименованиях столбцов, перечислены стадии ЖЦ. Для обозначения применимости принципа к конкретной стадии используется «Х» или «ХХ». «Х» — означает, что принцип может применяться на указанной стадии ЖС, «ХХ» — означает, что принцип является ключевым для успешного завершения стадии ЖС и должен быть применен на указанной стадии.

 

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ Х Х

 

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

 

3.2. Описание стадий ЖЦ систем.

Нижепредставленократкоеописание, каждойизпятистадийЖЦ, всоответствиис NIST SP 800-14 (Generally Accepted Principles and Practices for Securing Information Technology Systems):

  • Инициирование. На данной стадии определяется необходимость, и документируются цели разработки/приобретения системы, и проводится оценка воздействия в соответствии с FIPS-199 (http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf).
  • Разработка/приобретение. На данной стадии, система проектируется, разрабатывается, приобретается. На стадии «разработка/приобретение» могут использоваться другие модели ЖЦ, например, ЖС разработки систем. Стадия включает следующую деятельность: определение требований безопасности, документирование требования к безопасности в спецификации.
  • Внедрение. На данной стадии система проверяется и внедряется. Стадия включает следующую деятельность: установка / настройка функций безопасности, тестирования безопасности, сертификацию и аккредитацию.
  • Эксплуатация/сопровождение. На данной стадии, система функционирует и осуществляется ее поддержка и модернизация. Стадия включает следующую деятельность: администрирование функций безопасности, функционирование системы безопасности, контроль, мониторинг и аудит функций безопасности.
  • Снятие с эксплуатации. На данном этапе осуществляется перемещение, архивирование, утилизация, уничтожения информации и зачистка носителей информации.

 

3.3. Принципы безопасности информационных технологий

33 принципа безопасности ИТ сгруппированы в следующие 6 категорий:

  • Основы безопасности.
  • Риск-ориентированнось.
  • Простота использования.
  • Повышение устойчивости.
  • Снижение уязвимостей.
  • Проектирование.

 

3.3.1. Основы безопасности

Принцип 1. Создайте политику безопасности как основу для проектирования.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ Х Х Х Х

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

 

Принцип 2. Учитывайте требований безопасности при проектировании всех систем.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ ХХ ХХ ХХ Х

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

 

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

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ ХХ Х Х Х

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

 

Принцип 4. Убедитесь что разработчики ПО обучены вопросам создания безопасного ПО.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ ХХ Х

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

 

3.3.2. Риск-ориентированность

Принцип 5. Снижайте риск до приемлемого уровня.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ ХХ ХХ ХХ ХХ

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

 

Принцип 6. Считайте все внешние системы – опасными.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ ХХ ХХ ХХ Х

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

 

Принцип 7. Находите компромисс между снижением рисков и увеличение расходов и снижением других аспектов эффективности функционирования.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ ХХ ХХ

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

 

Принцип 8. Внедряйте меры безопасности ориентированные на удовлетворение целей обеспечения безопасности организации.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х ХХ Х

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

 

Принцип 9. Защищайте информацию при обработке, передаче и хранении.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х ХХ Х

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

 

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

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х Х

Описание: Дизайнеры должны учитывать, что в некоторых случаях невозможно достигнуть целей безопасности в системах, построенных полностью на готовых коммерческих решениях (Commercial off the Shelf, COTS-решения). В таких случаях, необходимо сочетать COTS-решения другими решениями, разрабатываемые/дорабатываемые под заказ, с учетом особенностей организации.

 

Принцип 11. Защищайтесь  от всех вероятных видов «атак».

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х Х Х

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

 

3.3.3. Простота использования.

Принцип 12. По возможности создавайте системы на основе открытых стандартов.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х

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

 

Принцип 13. Используйте общий (стандартный) подход к описанию требований безопасности.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ ХХ ХХ

Описание: Использование общего подхода (например, Common Criteria) при разработке требований безопасности позволяет организациям оценивать и сравнивать продукты и их функции.

 

Принцип 14. Проектирование системы безопасности с возможностью дальнейшей модернизации.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ Х ХХ

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

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

 

Принцип 15. Стремитесь к простоте использования.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х ХХ

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

 

3.3.4. Повышение устойчивости.

Принцип 16. Внедряйте многоуровневую безопасность.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х ХХ Х

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

 

Принцип 17. Разрабатывайте системы с учетом возможности ограничения ущерба и быстрого восстановления.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ ХХ

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

 

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

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х ХХ Х

Описание: Необходимо чтобы система продолжала устойчивое и безопасное функционирование при попытках обойти меры безопасности.

 

Принцип 19. Снижайте возможности эксплуатации уязвимостей.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ Х Х

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

 

Принцип 20. Изолируйте общедоступные системы от критически важных ресурсов (данных, процессов и т.д.).

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х Х

Описание: В случаях, когда чувствительность или критичность информации высока, организации может потребоваться ограничить количество систем, на которых хранятся (обрабатываются) критичные данные и изолировать их от остальных (физически или логически). Физическая изоляция — отсутствие физического соединения между общедоступными ресурсами организации и критически важной информацией организации. Для реализации логической изоляции, могут использоваться выделенные (при помощи межсетевого экрана) зоны безопасности. Также необходимо определить политики и процедуры использования общедоступных и критических ресурсов/систем.

 

Принцип 21. Изолируйте механизмы разделения вычислительных систем и сетевой инфраструктуры.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ Х ХХ

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

Определите:

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

 

Принцип 22. Разработайте и внедрите функции аудита для обнаружения несанкционированного использования и поддержки возможности расследования инцидентов.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ ХХ Х

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

 

Принцип 23. Разработайте и тестируйте процедуры на случай непредвиденных обстоятельств и аварийного восстановления для обеспечения требуемой доступности систем.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х Х Х ХХ

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

 

3.3.5. Снижение уязвимостей.

Принцип 24. Стремитесь к простоте.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х ХХ

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

 

Принцип 25. Минимизируйте количество элементов, которым необходимо доверять.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х ХХ

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

 

Принцип 26. Предоставляйте минимальные привилегии.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х Х Х ХХ

 

Принцип 27. Не используйте необоснованные меры безопасности.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ ХХ Х Х

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

 

Принцип 28. Обеспечивайте требуемую безопасность при отключении или утилизации систем.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х Х ХХ

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

 

Принцип 29. Выявляйте и устраняйте распространенные ошибки и уязвимости.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ ХХ Х

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

 

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

Принцип 30. Внедряйте безопасность, комбинируя физическое и логическое распределение мер.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N ХХ Х Х Х

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

 

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

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х ХХ Х Х

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

 

Принцип 32. Используйте аутентификацию пользователей и процессов, как в пределах, так и между системами (доменами).

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х Х Х ХХ

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

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

 

Принцип 33. Используйте уникальные учетные записи для обеспечения подотчетности.

иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип N Х Х Х ХХ

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

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

 

3.4. Сводная таблица принципов.

Применимые стадии жизненного цикла
иниц. разраб./приобр. внедр. экспл./сопр. сн. с экспл.
Принцип 1 ХХ Х Х Х Х
Принцип 2 ХХ ХХ ХХ ХХ Х
Принцип 3 ХХ ХХ Х Х Х
Принцип 4 ХХ ХХ Х
Принцип 5 ХХ ХХ ХХ ХХ ХХ
Принцип 6 ХХ ХХ ХХ ХХ Х
Принцип 7 ХХ ХХ ХХ
Принцип 8 Х ХХ Х ХХ Х
Принцип 9 Х ХХ Х ХХ Х
Принцип 10 Х ХХ Х Х
Принцип 11 Х ХХ Х Х Х
Принцип 12 Х ХХ Х
Принцип 13 ХХ ХХ ХХ
Принцип 14 ХХ Х ХХ
Принцип 15 Х ХХ Х ХХ
Принцип 16 Х ХХ Х ХХ Х
Принцип 17 Х ХХ ХХ
Принцип 18 Х ХХ Х ХХ Х
Принцип 19 ХХ Х Х
Принцип 20 Х ХХ Х Х
Принцип 21 ХХ Х ХХ
Принцип 22 Х ХХ ХХ Х
Принцип 23 Х Х Х ХХ
Принцип 24 Х ХХ Х ХХ
Принцип 25 Х ХХ Х ХХ
Принцип 26 Х Х Х ХХ
Принцип 27 Х ХХ ХХ Х Х
Принцип 28 Х Х ХХ
Принцип 29 ХХ ХХ Х
Принцип 30 ХХ Х Х Х
Принцип 31 Х ХХ Х Х
Принцип 32 Х Х Х ХХ
Принцип 33 Х Х Х ХХ