Ведомственные и корпоративные стандарты управления ИБ

Рядом организаций и ведомств предложены свои спецификации для базового уровня ИБ. Ниже рассматриваются некоторые из них: спецификация сервисов базового уровня XBSS, стандарт NASA «Безопасность информационных технологий» и др.

0.4.1 XBSS-спецификации сервисов безопасности Х/Ореп

Консорциум Х/Open выпустил документ под названием «Спецификации сервисов базового уровня ИБ» [129][1]⁾ .

Спецификация применима к информационным системам, построенным на базе типовых проектных решений. Предполагается, что концепция обеспечения ИБ организации соответствует стандарту BS 7799 (ISO 17799). При разработке спецификации использовалось понятие профиля защиты с компонентами, удовлетворяющими требованиям «Good Practice», формализованным в виде четких критериев.

В спецификации определены:

– требования в области ИБ к сервисам информационной системы;

– параметры, устанавливаемые по умолчанию, соответствующие требованиям ИБ.

Требования к подсистеме идентификации и аутентификации

– администрирование для непривилегированного пользователя запрещено;

– требуется возможность разграничения доступа по группам пользователей, местоположению, времени;

– перед сменой пароля необходима аутентификация;

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

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

– требования к паролям (по длине, допустимым символам и т.п.) следует проверять;

– установлено ограничение на доступ к системной базе паролей и на показ паролей на экране;

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

– пароли обязательно периодически сменяются, новые пароли непременно должны отличаться от старых;

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

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

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

Требования к подсистеме протоколирования/аудита

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

– система должна позволять идентифицировать и показывать текущие события;

– события, которые могут привести к нарушению целостности регистрационного журнала, следует перечислить в документации администратора безопасности;

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

– события, подлежащие регистрации, устанавливаются для пользователей, групп пользователей, объектов базы данных;

– действия пользователей с полномочиями администраторов подвергаются аудиту на предмет адекватности текущей ситуации;

– средства протоколирования/аудита должны иметь возможность отслеживать события следующих классов:

- использование механизмов идентификации и аутентификации;

- помещение объектов в адресное пространство пользователя;

- создание, модификация, удаление объектов;

- действия привилегированных пользователей;

- передача данных за пределы системы;

- начало и окончание работы системы, сеансов, точки входа;

- модификация прав доступа и привилегий.

Минимальные требования к протоколированию/аудиту

– следует регистрировать удачные и неудачные попытки входа в систему;

– необходимо регистрировать изменения, вносимые в процессе администрирования базы данных, и использовать системные сервисы;

– при попытке несанкционированного доступа к регистрационным журналам надо отправлять сообщение администратору безопасности, а процесс-нарушитель - блокировать;

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

Требования к подсистеме управления доступом

– для управления доступом служат следующие атрибуты: идентификатор пользователя и права доступа на чтение, запись, выполнение программ; профиль пользователя; подразделение;

– должны быть установлены правила доступа, основанные на атрибутах доступа, и правила доступа по умолчанию;

– доступ к устройствам ввода/вывода следует регламентировать административными и программно-техническими мерами;

– в базе данных необходимо определить атрибуты доступа для объектов и субъектов, причем для объектов атрибуты устанавливаются в процессе операций импорта/экспорта;

– правила доступа распространяются только на пользователей, прошедших авторизацию;

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

– если права доступа для объектов и субъектов различаются, их надо проверять на согласованность;

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

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

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

Требования к подсистеме защиты повторного использования объектов

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

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

Требования к защите критичной информации

– когда пользовательский сеанс приостановлен (блокирован), вывод также необходимо приостановить, а экран монитора погасить;

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

Требования к средствам обеспечения целостности

– процедуры (решаемые задачи) требуется документировать, в частности описать вопросы восстановления в случае сбоев оборудования и нарушения целостности данных;

– после успешного входа в систему пользователю следует предоставить следующую информацию:

- кто последний раз входил в систему (пользователь, процесс и т.п.);

- дату и время последнего успешного входа/выхода в систему;

- сервис, который был использован во время сеанса;

- число неудачных попыток входа в систему после завершения последнего сеанса;

- данные о пользовательском идентификаторе;

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

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

– по умолчанию для пользователей недоступны каталоги, созданные другими пользователями и программами;

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

– восстановление данных всех категорий - вплоть до минимального уровня защищенности - в результате работы процедуры восстановления данных является обязательным;

– процедуру восстановления можно проводить только в режиме технического обслуживания.

Требования к средствам обеспечения доступности

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

Обеспечение безопасности порождения и получения информации

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

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

– база данных должна вести отчетность по каждому пользователю отдельно.

Требования к средствам управления ИБ

– надежность средств управления безопасностью обеспечивается разделением ролей и обязанностей администраторов;

– должны присутствовать как минимум администратор безопасности, системный администратор, пользователи;

– следует особо контролировать вопросы перераспределения и добавления должностных обязанностей, связанных с ИБ;

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

– в системе нужны механизмы защиты при регистрации новых пользователей;

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

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

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

– в базе данных:

- при установке обязательно наличие механизма выбора и обновления параметров конфигурации;

- любые установки администратора могут производиться только после этого;

- нужна защита механизма регистрации параметров пользователя от несанкционированного удаления, модификации, ознакомления;

- следует предусмотреть механизм удаления пассивных пользователей;

- администратор должен иметь возможность отменить команду удаления пользователя из списков;

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

0.4.2 Стандарт NASA «Безопасность информационных технологий»

Минимальные требования к базовому уровню защищенности соответствуют документу «Руководство по политике безопасности для автоматизированных информационных систем» [206] и конкретизируют его положения. Принят дифференцированный подход: вводится 4 уровня критичности технологии, для которых по 30 позициям специфицируются требования. Следует отметить, что подобный подход - определение нескольких вариантов базовых требований для различных типов технологий - безусловно оправдан и позволяет принять во внимание их специфику. Этот документ доступен в Internet и является весьма полезным при разработке спецификаций на подсистему информационной безопасности с учетом ее специфики.