В этом номере мы продолжаем рассматривать рекомендации к нормативным документам по информационной безопасности.* В качестве основных рекомендаций по построению требований информационной безопасности для автоматизированной системы был выбран стандарт Common Criteria for Information Technology Security Evaluation версии 2.1 по причине его близости к российскому стандарту (ГОСТ Р ИСО/МЭК 15408-2001) и свободного доступа в Internet (http://csrc.nist.gov/cc/).
В первой части мы рассмотрели вопросы аудита безопасности, коммуникаций, поддержки криптографии и защиты данных пользователей. Здесь мы продолжаем изучение следующих разделов. Повторим только, что перечисленная функциональность безопасности будет жизнеспособна при условии, что разработка, внедрение и использование самой системы будут производиться при отсутствии злонамеренных или случайных недокументированных возможностей.
Идентификация и аутентификация
Требования предназначены для определения параметров, необходимых системе при установлении соответствия между понятием пользователя системы и реального физического лица.
Сбой при аутентификации
В данном случае система должна предоставлять средства настройки политики аутентификации с целью фиксации неудачных попыток входа в систему: общее количество неудачных попыток, привязка их к рабочему месту (терминалу), общее количество попыток за определенный период времени, время, в течение которого сохраняется информация о попытках. Кроме того, в системе предусматривается набор действий, который будет произведен в случае предпринятой неудачной попытки: блокировка счета или терминала (временная или постоянная), сообщения администратору и т. д.
Определение атрибутов пользователя
В системе должна быть предоставлена возможность определить и настроить параметры безопасности пользователя, такие как идентификатор пользователя, идентификатор группы, пароль, уровень доступа, права, роли и т. д.
Спецификация секретных параметров
Система должна предоставить средства настройки политики выбора секретного параметра (например, пароля), такие как: состав (буквы, цифры, спецсимволы), минимальная длина, ведение истории и т. д. Также в системе должна присутствовать возможность автоматической проверки пароля на слабость (при использовании парольной аутентификации).
Аутентификация пользователя
В этом направлении система предусматривает определенный набор функций, которые применяются пользователем до того, как он будет аутентифицирован, такие как контекстная помощь, предупреждение о несанкционированном использовании системы. Кроме того, система должна предотвращать попытки аутентификации путем копирования или подмены аутентификационных данных (например, для механизмов биометрической аутентификации). Система должна предусматривать возможность использования одноразовых аутентификационных механизмов (генераторов паролей, парольных таблиц и т. д.), а также различных механизмов аутентификации, их комбинаций или вариантов для различных пользователей (например: пользователь 1 — только биометрическая идентификация, пользователь 2 — токен + пароль и т. д.). Должна быть предусмотрена возможность повторной аутентификации пользователя перед выполнением критических операций или по истечении промежутка времени неактивности, а также возможность использования аутентификации двух и более пользователей перед выполнением особо критических операций. Система предусматривает возможность настройки реакции на процесс аутентификации пользователя (отображать вводимый пароль или не отображать совсем, сообщать о неверном пароле/идентификаторе или просто отказывать в доступе и т. д.).
Идентификация пользователя
Система не должна предоставлять никаких прав пользователю по работе в системе до того, как он будет идентифицирован и аутентифицирован.
Связывание понятий пользователь — субъект
Если тот или иной процесс был инициирован пользователем, то система должна предоставить средства уполномоченному пользователю системы (администратору) однозначно связать указанный процесс и пользователя, его инициировавшего.
Управление безопасностью
Требования предназначены для определения параметров установки и управления механизмами безопасности для уполномоченных пользователей.
Управление функциями подсистемы безопасности
В системе предусматривается возможность настройки ролей управления механизмами и параметрами безопасности и назначения для указанных ролей права по активации, деактивации и модификации тех или иных механизмов и параметров безопасности.
Управление атрибутами безопасности
Система должна иметь механизм определения атрибутов, по которым будут настраиваться права доступа к различным компонентам безопасности, а также определять, кто из уполномоченных пользователей (ролей) будет иметь права на доступ к указанным атрибутам. Примерами атрибутов являются: уровень доступа пользователя, приоритет работы процесса, лист доступа, права по умолчанию и т. д. Система должна контролировать состояние атрибутов безопасности таким образом, чтобы находиться в состоянии безопасности, соответствующем принятой политике безопасности, а также должна предусматривать механизм настройки атрибутов безопасности по умолчанию, которые будут присваиваться новым создаваемым объектам/субъектам.
Управление данными подсистемы безопасности
В системе должен присутствовать механизм, позволяющий контролировать соблюдение правил доступа к данным подсистемы безопасности, а также определять роли и операции, которые разрешены для выполнения над данными по безопасности. Система должна предоставлять механизм настройки предельных значений данным по безопасности (например, количество пользователей, одновременно присутствующих в системе, ограничение сессий одного пользователя и т. д.), и определять действия, предпринимаемые при достижении указанных предельных значений, а также должна контролировать значения, которые могут принимать данные по безопасности, таким образом, чтобы оставаться в безопасном состоянии.
Процедура отзыва
Система должна предоставлять возможность отзыва атрибутов безопасности у пользователя, объекта, субъекта и определения того, через какой промежуток времени отзыв начнет действовать (через некоторое время, при следующей сессии и т. д.).
Истечение времени использования атрибутов безопасности
Система должна предоставлять механизм указания времени истечения действия тех или иных атрибутов безопасности, а также действий системы, которые автоматически будут произведены по истечении срока использования того или иного атрибута.
Роли в управлении безопасностью
Для управления безопасностью системы должны быть предусмотрены отдельные роли для пользователей, такие как владелец, контролер, администратор и т. д. Система должна иметь настройку соответствия ролей, например, для определения, что один и тот же пользователь не может быть администратором и контролером безопасности.
Сокрытие данных
Требования данного класса предназначены для определения специальных параметров работы в системе.
Анонимность
Система должна предоставлять механизм настройки ситуации, когда пользователь или роль могут иметь доступ к определенному объекту, информационному ресурсу, но никакими дополнительными средствами невозможно отследить факт использования объекта (ресурса) данным пользователем. Кроме того, система должна предоставлять механизм настройки списка сервисов, которые могут быть использованы анонимно.
Псевдонимность
Система должна предоставлять механизм настройки ситуации, когда пользователь или роль могут иметь доступ к определенному объекту, информационному ресурсу и при этом система фиксирует факт использования объекта (ресурса) данным пользователем не под реальным идентификатором пользователя, а под псевдонимом. Только уполномоченный пользователь (администратор) может установить связь между указанным псевдонимом и реальным пользователем ресурса. Система должна предоставлять механизм настройки в случае применения пользовательского алиаса (дополнительного доменного имени для ресурса — сайта, домена, IP-адреса) для разграничения параметров использования ресурсов, например когда пользователь инициирует две сессии работы с системой с одного хоста. При этом уполномоченный пользователь (администратор) может установить связь между указанным алиасом и реальным пользователем ресурса.
Несвязанность
Система должна предоставлять механизм настройки ситуации, когда нет возможности установить связь между несколькими случаями использования ресурсов теми пользователями, которые не уполномочены для этого. При этом необходимо средство определения, какие именно связи между пользователем и ресурсом должны быть скрыты.
Неотслеживаемость
Система должна предоставлять механизм настройки ситуации, когда нет возможности установить факт использования какого-либо ресурса другими пользователями, кроме уполномоченного администратора или контролера. Также система должна предоставлять возможность определения того, какая информация может быть раскрыта в какой части системы (подсистеме), и в какой части не может быть раскрыта ни при каких условиях.
Защита подсистемы безопасности
Требования предназначены для определения механизмов, обеспечивающих защиту самой подсистемы безопасности. Необходимо различать эти требования от требований к защите данных пользователя, хотя отдельные положения по ним могут пересекаться или реализовываться сходными методами.
Тестирование абстрактных механизмов нижнего уровня
Под термином «абстрактные механизмы» в данном контексте понимается совокупность аппаратного и системно-программного обеспечения, обеспечивающая функционирование подсистемы безопасности. Здесь система должна обеспечить возможность определения графика и форм тестирования абстрактных механизмов: при включении, загрузке, периодически, по запросу и т. д. для определения того, что они работают согласно своим документированным функциям и не представляют угрозу для функционирования подсистемы безопасности. Дополнительно, внесистемным образом должен быть разработан список и условия проведения указанного тестирования.
Сбои в безопасности
Система должна сохранять свое безопасное состояние даже в случаях сбоев механизмов безопасности. Кроме того, система должна обеспечить возможность определения необходимых действий, которые автоматически будут предприняты при появлении сбоя того или иного механизма безопасности.
Доступность экспортируемых данных по безопасности. Конфиденциальность экспортируемых данных по безопасности
Система должна обеспечить возможность определения набора данных, доступность которых будет критична при произведении экспорта во внешнюю подсистему безопасности, и механизмов, которые будут обеспечивать доступность экспортируемых данных. Также система должна обеспечить набор параметров, которыми будут снабжены экспортируемые данные и по которым внешняя система сможет оценить доступность данных и обеспечить поддержку конфиденциальности данных. Система должна обеспечить настройку списка действий, направленных на восстановление доступности экспортированных данных (например, запрос на повторный экспорт).
Целостность экспортируемых данных по безопасности
Помимо требований, предъявляемых к доступности экспортируемых данных по безопасности, система должна обеспечить настройку списка действий, направленных на восстановление целостности экспортированных данных (например, запрос на повторный экспорт или восстановление по контрольным суммам).
Внутрисистемное перемещение данных по безопасности
В системе должен присутствовать автоматический контроль сохранения конфиденциальности, целостности и доступности данных по безопасности при перемещении их внутри системы. Перемещаемые в системе данные должны быть снабжены соответствующими атрибутами, позволяющими сохранять настроенные права доступа к ним. Система должна выявлять попытки нарушения целостности данных по безопасности и предпринимать необходимые действия (например, информировать об этом уполномоченных пользователей).
Физическая защита подсистемы безопасности
В системе должны быть предусмотрены: механизм выявления физического изменения (изъятия, подмены, модификации, уничтожения) компонента системы из определенного списка элементов аппаратного, сетевого и т. д. обеспечения, механизм информирования уполномоченных пользователей о факте физического изменения компонента системы, а также механизмы, препятствующие физическому изменению компонентов.
Доверенное восстановление
Система не должна в случаях сбоев или восстановления после сбоев переходить в состояние, которое противоречит политике безопасности. В системе должна быть предусмотрена возможность составления списка сбоев и их выявления для определения того, будет ли производиться восстановление системы автоматически или потребуется ручное вмешательство. При автоматическом восстановлении после сбоя система должна предоставить уполномоченному пользователю подробный отчет о том, какие модули и в каком порядке были восстановлены, результат восстановления, процент и/или список потерянных данных и т. д. При сбое любой из функций безопасности или группы функций система не должна утратить своего безопасного состояния либо должна выполнить процедуру восстановления безопасного состояния.
Выявление и предотвращение повторов
В данном разделе описывается защита от типовой атаки повтором (reply attack), когда производится несанкционированный повтор санкционированного действия. Система должна предоставить возможность определения списка сущностей, для которых необходим контроль отсутствия повторов, и определения списка действий, которые необходимо предпринять в случае выявления повторов.
Опосредованные ссылки
Все действия, производимые в системе, должны проходить контроль на соответствие политике безопасности, реализованной в системе. В любом из действий подсистема безопасности должна выступить посредником, который интерпретирует действие или реакцию субъекта/объекта как ссылку на список действий и транслирует ее соответствующему компоненту.
Разделение доменов
Данные и функции безопасности должны быть выделены в отдельный домен взаимоотношений, и никакие функции или данные из других функциональных доменов не должны оказывать на них влияние. Если система безопасности организована в виде различных подсистем, то каждая подсистема должна иметь возможность быть выделенной в отдельный функциональный домен.
Протокол синхронизации состояния
Система при пересылке данных должна обеспечивать информированность отправителя и получателя о состоянии процесса (пересылка начата, порция данных передана, процесс завершен, произошел сбой и т. д.). Также система должна обеспечить механизм запроса одной стороны у другой информации о состоянии процесса, требующего синхронизации.
Отметки времени
Система должна предусматривать возможность использовать достоверные (защищенные) отметки времени, которыми будут маркироваться наборы данных. Система должна предоставить возможность выбора наборов данных, на которые будет устанавливаться отметка времени, а также условий, при которых она будет выставляться.
Согласованность данных между подсистемами
Система должна предоставить возможность определения набора данных, который будет проконтролирован на согласованность при использовании в различных подсистемах. Система должна обеспечить механизмы проверки согласованности выбранных наборов данных при использовании их в различных подсистемах.
Внутрисистемное согласование копий данных
Система должна обеспечить механизмы проверки согласованности выбранных наборов данных при использовании различных копий данных
Самотестирование системы
Система должна обладать возможностью проведения самотестирования выполнения определенного набора функций безопасности. Система должна предоставить средства определения периодичности и условий выполнения самотестирования, а также предоставления результатов тестирования уполномоченным пользователям.
Использование ресурсов
Здесь перечислены параметры механизмов безопасности, позволяющие произвести контроль использования ресурсов системы.
Устойчивость к сбоям
В системе должен быть определен список сбоев, при которых возможно безопасное продолжение общего функционирования системы. Система должна быть спроектирована таким образом, чтобы сбои отдельных функций не оказывали влияния на общую безопасности системы. Кроме того, система должна предусматривать возможность настройки автоматизированных действий, которые будут предприняты при появлении предопределенных сбоев, например информирование уполномоченных пользователей, формирование отчета по сбою и т. д.
Приоритет сервиса
Система должна предусматривать возможность выставления приоритетов тому или иному сервису, субъекту и т. д., а также обеспечить преимущественное функционирование сервисов в зависимости от уровня их приоритета.
Выделение ресурса
Система должна предусматривать возможность определения квот (как максимальных, так и минимальных) по использованию ресурсов субъекту, объекту, сервису, для того чтобы исключить несанкционированное монопольное овладение тем или иным ресурсом. Система должна обеспечить функционирование сервисов, объектов и субъектов в соответствии с установленными квотами.
Доступ к системе
Требования этого класса предназначены для определения параметров работы пользователя с системой.
Ограничение рамок выбираемых атрибутов
Система должна предоставить возможность выбора атрибутов безопасности для пользовательской сессии работы с системой, по которым будут производиться ограничения доступа, такие как уровень доступа пользователя, роль, уровень контроля целостности, время дня для работы и т. д. Система должна иметь механизм контроля указанных атрибутов при обеспечении доступа в систему.
Ограничение множества конкурентных сессий
Система должна предоставить возможность определения максимального количества сессий для пользователя, которые он может открыть одновременно, а также должна обеспечить работу механизма контроля количества открываемых пользовательских сессий.
Блокировка сессий
В системе должна быть возможность определения условий, при которых сессия пользователя может быть автоматически заблокирована или прекращена, а также механизм ручной блокировки сессий уполномоченным пользователем. Система должна обеспечить работу механизмов автоматической блокировки или прекращения сессий при выполнении определенных условий, а также предоставить пользователю средства для блокировки собственной сессии.
Заставка при доступе в систему
Перед входом пользователя в систему система должна обеспечить заставку с информацией о том, что пользователю следует знать перед началом ввода идентификатора и пароля, например предупреждение об ответственности за несанкционированное использование ресурсов системы.
История доступа в систему
В системе должна быть предоставлена возможность сбора сведений, касающихся предыдущих сеансов работы с системой, которые будут сообщены пользователю после его аутентификации (например, дата и время последнего входа в систему, количество неудачных попыток со времени последнего входа и адрес, с которого производились попытки). Также система должна обеспечить сохранение указанных сведений в течение заданного времени.
Установка сессии с системой
Система должна предоставить возможность определения атрибутов (набора атрибутов), по которым либо пользователю может быть отказано в сессии работы с системой, либо открытая сессия может быть дополнительно функционально ограничена. Система должна обеспечить работу механизмов отказа либо ограничения функциональности сессии в зависимости от заданных условий.
Доверенный канал и путь передачи данных
Требования предназначены для определения параметров информационных потоков в системе.
Доверенный канал между подсистемами
В данном контексте доверенный канал передачи данных подразумевает обеспечение такого уровня безопасности передачи данных подсистемами, который не ниже, чем при передаче данных внутри замкнутой подсистемы. Система должна предоставить возможность определения функций и данных, которые могут быть выполнены/переданы только по доверенному каналу, а также должна обеспечить работу механизмов создания доверенного канала для межподсистемной работы предопределенного списка функций/данных.
Доверенный путь
В данном контексте доверенный путь подразумевает передачу данных только через уполномоченные компоненты от авторизованного источника до авторизованного получателя. Система должна предоставить возможность определения функций и данных, для которых необходимо определение доверенного пути, а также должна обеспечить работу механизмов контроля функционирования доверенного пути для заранее определенного списка функций или данных.
На этом рассмотрение рекомендаций закончено. Теперь руководитель или специалист, ответственный за постановку задачи по построению или описанию подсистемы информационной безопасности конкретной информационной системы, как минимум знает, на какие вопросы ему следует обратить внимание. Это позволит избежать непрофессионализма при создании документа, когда требования к системе указывают как «система должна обеспечивать информационную безопасность» или как «система должна обеспечивать вход по паролю и шифрование данных». Таким образом, была сделана попытка передать все многообразие и сложность проблемы. Однако на этом вопрос не закрыт. Технологи и разработчики, читая статью, возможно, уже отметили, что и здесь многие требования определены довольно в общем виде. Для создания документа, который можно применять к конкретной системе, придется приложить еще значительные усилия. Помимо конкретизации требований, необходимо включить описание угроз, которым может подвергаться система, типы используемых механизмов (таких, как подробное руководство администратора системы или средство обнаружения повторов), описание реализации защиты и ряд других параметров, то есть построить полноценный профиль защиты (Protection Profile).* Понятно, что построение таких подробных документов под силу только подготовленным профессионалам. Тем не менее надеемся, что представленный здесь материал помог читателю получить представление о данной проблеме и дать по меньшей мере инструмент выявления некачественной работы непрофессиональных исполнителей.
Искандер Конеев — CISSP, консультант, ЗАО «МЦФЭР-консалтинг», IKoneev@mcfr.ru
*Часть 1 см. в журнале «Директор информационной службы», 2004, № 8
*Примеры сформированных таким образом профилей защиты можно найти в Internet по ссылке http://www.commoncriteriaportal.org/public/consumer/index.php?menu=5