Определение политики безопасности для системы

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

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

1) Каков результат такого определения? Является ли форма такой политики, например распределенной системы, документом, содержащим ряд утверждений о требованиях безопасности (что разрешено и что не является) системы?

2) Может ли политика взять машиночитаемую форму (если это имеет смысл), и если да, то как ее можно использовать?

3) Как поддерживать такую политику? Поддерживается ли политика как документация (как и вся остальная часть документации) в системе?

4) Нужно ли ссылаться на документ политики в коде?

Брайан

Ответ 1

Вы должны взять одну из стандартных политик безопасности и работать оттуда. Наиболее распространенным является соответствие PCI (индустрия платежных карт). Это очень хорошо продумано и за исключением нескольких мягких пятен, как правило, хорошо. Я никогда не слышал о машиносчитываемой политике, кроме определения Microsoft Active Directory или ряда правил iptables Linux.

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

EDIT:

Ознакомьтесь с политиками SE Linux:

http://en.wikipedia.org/wiki/Security-Enhanced_Linux

Ответ 2

Проект защиты открытых веб-приложений OWASP - это язык-агностический проект для обучения безопасности и предоставления инструментов для тестирования и поддержки программного обеспечения, Несмотря на то, что он является веб-ориентированным, многие из основных идей широко применимы. Веб-сайт ориентирован как на разработчиков программного обеспечения, так и на управление.

Ответ 3

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

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

1) Результатом такой политики являются четко определенные требования безопасности от руководства. С помощью этой политики каждый вовлеченный человек может понять ожидания руководства и при необходимости принять соответствующее решение.

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

3) Документ должен быть доступен всем заинтересованным лицам и регулярно проверяться руководством.

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

Другой тип "политик безопасности" может просто ссылаться на эти наборы параметров, которые являются программами безопасности. Я обнаружил, что некоторые программы безопасности действительно любят использовать слово "политика", чтобы сделать их конфигурации более организованными и структурами. Но в любом случае эти "политики безопасности" на самом деле являются просто ценностями и/или инструкциями для программ обеспечения безопасности. Например, Windows имеет собственный набор "политик безопасности" для пользователя для настройки журналов аудита, прав пользователей и т.д. Этот тип "политик безопасности" (параметры для программ) фактически определен на основе 1-го типа "политик безопасности", (требования от руководства), как указано выше.

Возможно, я слишком много писал об этом. Надеюсь, что это поможет.

Ответ 4

Если вам нужно разработать политику безопасности, почему бы не подумать о пользователях и разрешениях?

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

Представьте, что это веб-интерфейс JSON API. Пользователь нажимает кнопку, а JS обрабатывает запрос и отправляет его. Обычно это нормально работает, но если кто-то замалчивает запрос, сервер просто возвращает некоторый код ошибки, поскольку он выполняет управление только несколькими действиями, которые пользователь может сделать.

Поэтому я думаю, что все это сводится к пользователям и разрешениям.