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

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

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

В сфере информационной безопасности на практике часто приходится сталкиваться с фактами информационной перегрузки ряда терминов, например понятия «концепция». Под термином «концепция информационной безопасности организации» порой понимают всю совокупность нормативов по информационной безопасности, набивая документ различными по своей информационной иерархии разделами и делая его трудночитаемым. Встречаются более чем 100-страничные концепции, где во введении говорится о том, что текущий документ описывает основные принципы (что теоретически верно), а на 50-й странице указывается, что должен делать оператор при поступлении от пользователя сообщения о нарушении безопасности.

Обратимся к определению слова «концепция» [лат. conceptio] — 1) система взглядов, то или иное понимание явлений, процессов; 2) единый, определяющий замысел, основополагающая идея, напр. к. романа, к. экономической реформы.

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

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

Каким же должен быть документ, под которым ИТ-директор предприятия поставит утверждающую подпись? На данном этапе не важно, как будет называться этот документ — концепцией или политикой информационной системы, хотя целесообразнее было бы назвать его техническим заданием или требованием по информационной безопасности. Возможно, этот документ войдет составной частью в общее техническое задание на информационную систему.

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

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

Таким средством является стандарт Common Criteria for Information Technology Security Evaluation, известный в России под названием «ГОСТ Р ИСО/МЭК 15408-2001. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий». В данном случае обращение к англоязычному источнику производится по причине его свободной доступности на официальном Web-сайте организации, поддерживающей стандарт (http://csrc.nist.gov/cc/).

В настоящее время доступна версия 2.1, которая, собственно, и была формально признана ISO под номером 15408.*

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

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

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

Аудит безопасности

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

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

Генерация данных аудита. Такая система обладает возможностью настройки списка событий, подлежащих аудиту, включая следующий набор событий (но не ограничиваясь им): появление и удаление объектов в системе; назначение и изменение прав доступа и атрибутов безопасности объектов; использование функций идентификации и аутентификации; импорт/экспорт данных системы; проверка на соблюдение политики безопасности. Зафиксированное событие имеет признаки однозначной идентификации (номер, дата, время) для его распознавания. В системе должна быть обеспечена возможность по зафиксированному событию однозначно установить связанного с событием субъекта (пользователя или процесса).

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

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

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

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

Коммуникации

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

Апеллируемость (неотказуемость) источника и получателя данных. Система должна иметь список типов информационных данных (электронные письма, сообщения, файлы данных), для которых требуется апеллируемость источника и/или получателя, и иметь возможность определения, для какой части набора данных определяется апеллируемость (заголовок, тело данных, пр.). В системе должна быть предусмотрена возможность определения права пользователя запрашивать подтверждение источника/получателя, возможность определения независимого субъекта (арбитра), который имеет право получать подтверждение об источнике или получателе, а также того, что может верифицировать подтверждение. Информация об источнике/получателе должна содержать такие параметры, как идентификатор, время отправки/получения, местоположение и т. д.

Поддержка криптографии

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

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

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

  • установку и проверку электронно-цифровой подписи (ЭЦП);
  • генерацию и верификацию контрольных сумм;
  • расчет хеш-функций;
  • шифрацию и дешифрацию данных и ключей;
  • согласование ключей;
  • генерацию случайных чисел.

Защита данных пользователей

Требования предназначены для определения параметров работы с данными.

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

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

Аутентификация данных. В системе должно быть позволено выделение наборов данных (объекты, типы информации), которые аутентифицируются перед использованием. Для верификации указанной аутентификации должны быть определены соответствующие субъекты.

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

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

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

Импорт из внешней подсистемы безопасности. В системе необходимо наличие возможности распознавания атрибутов безопасности в импортируемых данных. Если указанные данные снабжены атрибутами безопасности внешней подсистемы в соответствии с импортируемыми атрибутами, то система должна предоставлять возможность настройки прав доступа к импортируемым данным, а также возможность отдельной настройки права на работу с импортируемыми данными, если они не снабжены атрибутами безопасности внешней подсистемы безопасности.

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

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

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

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

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

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

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

Искандер Конеев — CISSP, консультант, ЗАО «МЦФЭР-консалтинг», IKoneev@mcfr.ru

*При изучении первоисточника следует учесть, что в доступном в Internet документе есть опечатки. Например, во второй части (которую мы рассматриваем) на рис. L.1, с. 341, семейство FTA_SSL (блокировка сессий) ошибочно обозначено как Limitation of multiple concurrent.