3.3.3 Роли и ответственности в безопасности сети

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

1. Провайдер сервисов - менеджер группы и/или организации, который предо­ставляет сервисы обработки информации. Обычно эта организация отвечает за обеспечение безопасности компьютерной среды;

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

• оценка уровня конфиденциальности данных с целью их классификации;

• установление определенного уровня защиты (в соответствии с этой классификацией);

• разрешение или запрет на доступ к данным под его личную ответственность;

3. Аудитор - это лицо, ответственное за:

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

• исполнение процессов безопасности;

• периодическое выполнение контрольной оценки безопасности;

• задание требований для приложений/инструментов/решений в целях обеспечения требуемой безопасности;

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

• обеспечение настройки безопасности системы в соответствии со стандартами и правилами, то есть Администратор безопасности отвечает за установку системных политик, включая парольную политику, политику ауди­та, политику входа в систему и стандартный доступ к типам ресурсов;

• управление атрибутами доступа пользователей путем замены паролей, определения новых и удаления старых идентификаторов пользователей;

• выполнение периодических проверок с целью контроля состояния безопасности компьютерной среды;

5. Пользователь данными - в обязанности Пользователя данными входят:

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

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

3.3.4 Аудит и оповещение

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

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

При формировании политики аудита нужно учитывать два аспекта:

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

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

Вот рекомендация минимального перечня событий для регистрации:

1. все нарушения безопасности, такие как:

• неавторизованный доступ к системе;

• неправильный пароль;

• аннулированный пароль;

• неавторизованный доступ к ресурсу;

2. все попытки доступа к чувствительным/важным областям систем;

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

4. все попытки доступа к ресурсам операционных систем, за исключением доступа по умолчанию.

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

Приведем пример последовательности процессов для обнаружения проблемы и выдачи сигнала тревоги:

• каждое нарушение безопасности должно генерировать системное событие;

• одно системное событие не является неизбежно достаточным, чтобы утверждать, что это опасность; в таком случае подобные события должны накапливаться;

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

• если результат этой совокупности превышает пороговую величину, выдается сигнал тревоги.

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

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