Политика безопасности предприятия

Лекция № 9-10

Политика безопасности предприятия

Цель: познакомиться с особенностями организации политики безопасности.

Время: 4 часа.

План:

Введение. (10 мин.)

1. Целостность данных. (45 мин.)

2. Политика безопасности. (45 мин.)

3. Язык описания политики безопасности. (50 мин.)

Выводы. (10 мин.)

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

Литература:

1. Девянин П.Н. Модели безопасности компьютерных систем: Учеб. пособие / П. Н. Девянин. – М.: «Академия», 2005. – 114 с.

2. Мельников В.П. Информационная безопасность и защита информации / В.П. Мельников. – М.: «Академия», 2008. – 336 с.

3. Петров В.А. Информационная безопасность. Защита информации от несанкционированного доступа в автоматизированных системах: Учебное пособие / В.А. Петров, А.С. Пискарев, А.В. Шеин. – М.: МИФИ, 2006.

4. Северин В.А. Комплексная защита информации на предприятии. Учебник для вузов / В.А. Северин. – М: « Городец», 2008 с.

Целостность данных

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

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

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

1. корректность транзакций;

2. минимизация привилегий;

3. аутентификация пользователей;

4. разграничение функциональных обязанностей;

5. аудит произошедших событий;

6. объективный контроль;

7. управление передачей привилегий;

8. обеспечение непрерывной работоспособности;

9. простота использования защитных механизмов.

Корректность транзакций

Понятие корректности транзакций определяется в соответствии с моделью Кларка-Уилсона:

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

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

Минимизация привелегий

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

Разграничение функциональных обязанностей

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

Объективный контроль

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

Управление передачей привелегий

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

Простота использования защитных механизмов

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

Политика безопасности

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

Необходимость и важность политики

Политика безопасности определяет:

· безопасность внутри организации;

· место каждого служащего в системе безопасности.

Какой должна быть безопасность

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

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

Определение различных политик

Существуют различные политики, для которых есть три основных общепринятых раздела.

· Цель. Каждая политика и процедура имеют четко определенную цель, описывающая причины, почему создана та или иная политика или процедура, и какую выгоду от этого надеется получить организация.

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

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

Виды политик

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

Классифицирование

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

Первый уровень – общая информация.

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

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

Политика безопасности

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

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

Управление доступом

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

Аудит политики безопасности – определяет типы событий, отслеживаемых во всех системах:

· попытки входа в систему (успешные или неудачные);

· выход из системы;

· ошибки доступа к файлам или системным объектам;

· попытки удаленного доступа (успешные или неудачные);

· действия привилегированных пользователей (администраторов), успешные или неудачные;

· системные события (выключение и перезагрузка).

Каждое событие должно включать следующую информацию:

· ID пользователя (если имеется);

· дата и время;

· ID процесса (если имеется);

· выполненное действие;

· успешное или неудачное завершение события.

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

Сетевые соединения

Политика безопасности так же описывает правила установки сетевых соединений и используемые механизмы защиты.

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

В качестве устройств защиты выделенных линий используют межсетевые экраны.

Политика безопасности должна:

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

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

· быть определено размещение программ безопасности, с определенными требованиями, отслеживающих вредоносный код (вирусы, черви, “черные ходы” и “троянские кони”). Места для размещения – файловые серверы, рабочие станции и серверы электронной почты;

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

Отказ от защиты

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

Для этих целей предназначен процесс отказа от защиты. Менеджер проекта должен заполнять форму отказа следующей информацией:

· система с отказом от защиты;

· раздел политики безопасности, соответствие которому будет нарушено;

· ответвления организации (обуславливают повышенную степень риска);

· шаги, предпринимаемые для снижения или контроля степени опасности;

· план восстановления соответствия системы требованиям политики безопасности.

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

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

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

Начальное состояние системы

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

· операционную систему и ее версию;

· уровень обновления;

· работающие приложения и их версии;

· начальные конфигурации устройств, программные компоненты и приложения.

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

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

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

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

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

Создание политики

Основные моменты при создании политики организации:

1. Определение найболее важных политик.

2. Определение допустимого поведения сотрудников, в зависимости от порядков, установленных в организации.

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

4. Определение схем политик.

5. Разработка.

Развертывание политики

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

1. Понимание политики.

2. Обучение. Сотрудники, на которых распространяется новая политика, должны пройти обучение согласно доли своей ответственности.

Объекто-субъектная модель

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

Контроль операций

Монитором взаимодействий контролирует все операции, и, соответственно, операции либо разрешаются, либо запрещаются.

Все операции контролируются и либо запрещаются, либо разрешаются в соответствии с правилами политики безопасности.

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

2. Совокупность множеств субъектов, объектов и отношений между ними определяет состояние системы. Каждое состояние системы является либо безопасным, либо небезопасным в соответствии с предложенными в модели критериям безопасности.

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

Классические модели

Среди классических моделей политик безопасности можно выделить два основных класса:

· дискреционные (произвольные);

· мандатные (нормативные).

Выразительная сила

Язык определения политики безопасности должен обладать достаточной выразительной силой. На основании предлагаемого языка необходимо иметь возможность описывать достаточно широкий круг политик безопасности.

Спецификации языка

Язык определения политики безопасности в зависимости от выбранных в политике безопасности правил разрешения доступа способен специфицировать

· закрытые политики безопасности (все разрешенные виды доступа должны быть специфицированы);

· открытые политики безопасности (все запрещенные виды доступа должны быть специфицированы);

· гибридные политики безопасности;

· гибридные политики безопасности с разрешенными противоречиями.

Корректность спецификаций

Язык определения политики безопасности должен определять корректные спецификации. Спецификация политики безопасности является корректной, если она непротиворечива и полна. Под непротиворечивостью спецификации понимается наличие только одного решающего правила для каждого доступа субъекта системы к объекту (доступ не может быть одновременно разрешен и запрещен). Под полнотой спецификации понимается существование правила для каждого доступа субъекта системы к объекту, запрещающего или разрешающего его. Если для некоторого доступа не определена авторизация, должно присутствовать разрешающее правило-умолчание.

Ацикличность

Eсли член ( ), то не может быть членом ( ). Уровни , и ничего не знают друг о друге.

Роль

Именованный список привилегий, необходимых для выполнения некоторых обязанностей в системе.

Авторизация

Отображение, которое отображает четверку , , , , состоящую из объектов, пользователей, ролей и действий, в множество либо авторизованное, либо запрещенное.