Ведомственные и корпоративные стандарты управления ИБ
Рядом организаций и ведомств предложены свои спецификации для базового уровня ИБ. Ниже рассматриваются некоторые из них: спецификация сервисов базового уровня XBSS, стандарт NASA «Безопасность информационных технологий» и др.
0.4.1 XBSS-спецификации сервисов безопасности Х/Ореп
Консорциум Х/Open выпустил документ под названием «Спецификации сервисов базового уровня ИБ» [129][1]) .
Спецификация применима к информационным системам, построенным на базе типовых проектных решений. Предполагается, что концепция обеспечения ИБ организации соответствует стандарту BS 7799 (ISO 17799). При разработке спецификации использовалось понятие профиля защиты с компонентами, удовлетворяющими требованиям «Good Practice», формализованным в виде четких критериев.
В спецификации определены:
– требования в области ИБ к сервисам информационной системы;
– параметры, устанавливаемые по умолчанию, соответствующие требованиям ИБ.
Требования к подсистеме идентификации и аутентификации
– администрирование для непривилегированного пользователя запрещено;
– требуется возможность разграничения доступа по группам пользователей, местоположению, времени;
– перед сменой пароля необходима аутентификация;
– выполняется отслеживание неудачных попыток входа в систему, задержка после ввода неверного пароля перед следующей попыткой, оперативное оповещение администратора безопасности при нескольких последовательных неудачных попытках входа в систему;
– обеспечивается системная защита данных, которые служат для аутентификации, и регистрационных данных пользователей;
– требования к паролям (по длине, допустимым символам и т.п.) следует проверять;
– установлено ограничение на доступ к системной базе паролей и на показ паролей на экране;
– данные, необходимые при аутентификации, защищаются, а пароли хранятся только в зашифрованном виде;
– пароли обязательно периодически сменяются, новые пароли непременно должны отличаться от старых;
– пользователи при доступе к базе данных аутентифицируются в обязательном порядке;
– производится смена стандартных паролей, вводимых при установке;
– при входе пользователя в систему выдаются сведения о времени последнего входа/выхода, сервисах, числе неудачных попыток входа с данным именем после последнего сеанса.
Требования к подсистеме протоколирования/аудита
– данные, относящиеся к протоколу (регистрационный журнал), необходимо защитить от изменения;
– система должна позволять идентифицировать и показывать текущие события;
– события, которые могут привести к нарушению целостности регистрационного журнала, следует перечислить в документации администратора безопасности;
– протоколирование доступа к базе данных является обязательным;
– события, подлежащие регистрации, устанавливаются для пользователей, групп пользователей, объектов базы данных;
– действия пользователей с полномочиями администраторов подвергаются аудиту на предмет адекватности текущей ситуации;
– средства протоколирования/аудита должны иметь возможность отслеживать события следующих классов:
- использование механизмов идентификации и аутентификации;
- помещение объектов в адресное пространство пользователя;
- создание, модификация, удаление объектов;
- действия привилегированных пользователей;
- передача данных за пределы системы;
- начало и окончание работы системы, сеансов, точки входа;
- модификация прав доступа и привилегий.
Минимальные требования к протоколированию/аудиту
– следует регистрировать удачные и неудачные попытки входа в систему;
– необходимо регистрировать изменения, вносимые в процессе администрирования базы данных, и использовать системные сервисы;
– при попытке несанкционированного доступа к регистрационным журналам надо отправлять сообщение администратору безопасности, а процесс-нарушитель - блокировать;
– записи о событиях в регистрационном журнале должны содержать информацию о типе (классе) события, дате и времени начала и окончания, удачном/ неудачном завершении, пользователе.
Требования к подсистеме управления доступом
– для управления доступом служат следующие атрибуты: идентификатор пользователя и права доступа на чтение, запись, выполнение программ; профиль пользователя; подразделение;
– должны быть установлены правила доступа, основанные на атрибутах доступа, и правила доступа по умолчанию;
– доступ к устройствам ввода/вывода следует регламентировать административными и программно-техническими мерами;
– в базе данных необходимо определить атрибуты доступа для объектов и субъектов, причем для объектов атрибуты устанавливаются в процессе операций импорта/экспорта;
– правила доступа распространяются только на пользователей, прошедших авторизацию;
– наличие утвержденных списков управления доступом или правил управления доступом является обязательным;
– если права доступа для объектов и субъектов различаются, их надо проверять на согласованность;
– в базе данных должна быть обеспечена защита от чтения и модификации информации, относящейся к политике безопасности, в частности данных, касающихся идентификации и аутентификации, а также точек входа и соответствующих им параметров (системных и пользовательских);
– запрещается разглашать атрибуты, относящиеся к политике безопасности и устанавливаемые по умолчанию;
– пользователи должны иметь возможность в любой момент закрыть (приостановить) свой сеанс и возобновить его после повторной аутентификации.
Требования к подсистеме защиты повторного использования объектов
– всю информацию, касающуюся атрибутов безопасности и авторизации, не содержащуюся в объекте, следует выгружать из памяти (уничтожать) после выгрузки объекта;
– необходимо запретить доступ к данным (включая зашифрованные), относящимся к незагруженному объекту, для любых других объектов, в том числе тех, которые используют незагруженный объект.
Требования к защите критичной информации
– когда пользовательский сеанс приостановлен (блокирован), вывод также необходимо приостановить, а экран монитора погасить;
– база данных должна иметь возможность перед процедурой инициализации сеанса выдать пользователю предупреждение об ограничениях, связанных с текущей ситуацией.
Требования к средствам обеспечения целостности
– процедуры (решаемые задачи) требуется документировать, в частности описать вопросы восстановления в случае сбоев оборудования и нарушения целостности данных;
– после успешного входа в систему пользователю следует предоставить следующую информацию:
- кто последний раз входил в систему (пользователь, процесс и т.п.);
- дату и время последнего успешного входа/выхода в систему;
- сервис, который был использован во время сеанса;
- число неудачных попыток входа в систему после завершения последнего сеанса;
- данные о пользовательском идентификаторе;
– база данных должна ограничивать возможности незарегистрированного пользователя при попытках входа в систему посредством применения задержки после неудачной попытки входа в систему или блокирования доступа к данным пользователя, не вошедшего в систему;
– для базы данных необходимо обеспечить возможность работы в нормальном режиме и режиме технического обслуживания (технологическом);
– по умолчанию для пользователей недоступны каталоги, созданные другими пользователями и программами;
– функции администратора, связанные с обеспечением информационной безопасности, недоступны прочим пользователям и процессам;
– восстановление данных всех категорий - вплоть до минимального уровня защищенности - в результате работы процедуры восстановления данных является обязательным;
– процедуру восстановления можно проводить только в режиме технического обслуживания.
Требования к средствам обеспечения доступности
Должны быть определены требования по доступности для данной информационной технологии.
Обеспечение безопасности порождения и получения информации
– обычным пользователям необходимо запретить переводить систему из нормального режима в режим технического обслуживания;
– в режиме технического обслуживания обычным пользователям не следует предоставлять доступ в систему;
– база данных должна вести отчетность по каждому пользователю отдельно.
Требования к средствам управления ИБ
– надежность средств управления безопасностью обеспечивается разделением ролей и обязанностей администраторов;
– должны присутствовать как минимум администратор безопасности, системный администратор, пользователи;
– следует особо контролировать вопросы перераспределения и добавления должностных обязанностей, связанных с ИБ;
– средства администрирования, относящиеся к ИБ, необходимо контролировать на предмет их несанкционированного использования, модификации, уничтожения;
– в системе нужны механизмы защиты при регистрации новых пользователей;
– обязательным является присутствие в базе данных механизмов защиты, обеспечивающих невозможность включать/выключать механизмы защиты; выбирать или изменять события, подлежащие протоколированию/аудиту; изменять установленные по умолчанию события и атрибуты защиты;
– требуется установить предельное время пассивности пользователей, после которого они исключаются из числа легальных пользователей;
– системный администратор должен проводить аудит действий одного или выбранной группы пользователей; а средства проведения аудита необходимо защитить от неавторизованного использования, модификации, уничтожения;
– в базе данных:
- при установке обязательно наличие механизма выбора и обновления параметров конфигурации;
- любые установки администратора могут производиться только после этого;
- нужна защита механизма регистрации параметров пользователя от несанкционированного удаления, модификации, ознакомления;
- следует предусмотреть механизм удаления пассивных пользователей;
- администратор должен иметь возможность отменить команду удаления пользователя из списков;
- необходим защитный механизм, предоставляющий доступ только авторизованному персоналу к выполнению функций администратора.
0.4.2 Стандарт NASA «Безопасность информационных технологий»
Минимальные требования к базовому уровню защищенности соответствуют документу «Руководство по политике безопасности для автоматизированных информационных систем» [206] и конкретизируют его положения. Принят дифференцированный подход: вводится 4 уровня критичности технологии, для которых по 30 позициям специфицируются требования. Следует отметить, что подобный подход - определение нескольких вариантов базовых требований для различных типов технологий - безусловно оправдан и позволяет принять во внимание их специфику. Этот документ доступен в Internet и является весьма полезным при разработке спецификаций на подсистему информационной безопасности с учетом ее специфики.