Функции для работы с удостоверениями

Работа приложения, опирающегося на интерфейс GSS-API, должна начинаться с получения удостоверения, которое засвидетельствует, что приложение имеет право выступать от имени определенного субъекта.

Интерфейс GSS-API предоставляет следующие функции для применения удостоверений:

GSS_Acquire_cred - запрос удостоверения для последующего использования;GSS_Release_cred - отказ от удостоверения, ставшего ненужным;GSS_Inquire_cred - получение информации об удостоверении;GSS_Add_cred - постепенное формирование удостоверения;GSS_Inquire_cred_by_mech - получение информации об удостоверении, связанной с конкретным механизмом безопасности.

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

Функция GSS_Acquire_cred нужна в первую очередь серверным процессам, желающим сообщить, от чьего имени они выступают. Интерактивные пользователи могут получать подразумеваемые удостоверения неявным образом при входе в систему. Аналогично, при выходе такого пользователя из системы может автоматически выполняться вызов функции GSS_Release_cred.

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

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

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

Логика работы пользователей интерфейса безопасности

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

Детали, связанные с преобразованием имен, опущены. Текст в фигурных скобках является комментарием. Стрелка --> отделяет входные параметры от выходных.

Рис. 11.1.  Примерный сценарий взаимодействия между клиентом и сервером под защитой обобщенного интерфейса безопасности.

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

Основные понятия

Обобщенный прикладной программный интерфейс службы безопасности содержит следующие основные понятия:

удостоверение;

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

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

механизм безопасности;

имя;

канал передачи данных.

Удостоверение - это структура данных, позволяющая ее владельцу доказать партнеру по общению или третьей стороне, что он (владелец) является именно тем, за кого себя выдает. Таким образом, в GSS-API удостоверения выступают как средство аутентификации.

Естественно, что служба безопасности (например, Kerberos) совместно с операционной системой должны обеспечить защиту удостоверений от несанкционированного использования и/или изменения. Процессам, действующим от имени пользователей, не предоставляется прямого доступа к удостоверениям. Вместо этого при необходимости процессы снабжаются дескрипторами удостоверений, которые не содержат секретной информации и не нуждаются в защите. Нет смысла воровать дескрипторы, поскольку их интерпретация для разных процессов-предъявителей будет различной.

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

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

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

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

Интерфейс GSS-API не зависит от используемых коммуникационных протоколов, поэтому формирование контекста безопасности никак не связано с установлением соединения в сетевом смысле. Более того, для GSS-API безразлично, какой протокол используется - с установлением соединения или без такового. Организация потока сообщений, а также выделение из входного потока данных, генерируемых в рамках GSS-API, - обязанность прикладных систем.

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

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

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



Для приложения структура токенов безопасности закрыта. Токены генерируются и контролируются исключительно функциями GSS-API. Дело приложения - переслать их и передать соответствующим функциям для обработки. Естественно, служба безопасности обнаружит попытки приложения изменить токен, если таковые будут предприняты.

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

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

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

Если токены являются структурой, закрытой для приложений, то структура имен, употребляемых при формировании контекста безопасности (имеются в виду имена партнеров по общению), закрыта для функций GSS-API. Имена рассматриваются этими функциями как последовательности байт, интерпретируемые, вероятно, коммуникационными компонентами приложений.

В GSS-API предусматривается наличие трех типов имен - внутренних, печатных и объектных. Как правило, аргументами функций GSS-API служат внутренние имена. Интерфейс GSS-API предоставляет функции для преобразования имен и выполнения некоторых других действий над ними.

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

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


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

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

Основные коды подразделяются на информирующие и сигнализирующие об ошибке. Перечислим некоторые информирующие коды:

GSS_S_COMPLETE - нормальное завершение;GSS_S_CONTINUE_NEEDED - требуется дополнительный вызов данной функции;GSS_S_DUPLICATE_TOKEN - обнаружено дублирование токена защиты сообщений.

Следующие значения входят в число кодов, сигнализирующих об ошибке:

GSS_S_BAD_NAME - задано некорректное имя;GSS_S_CONTEXT_EXPIRED - истек срок действия контекста;GSS_S_CREDENTIALS_EXPIRED - истек срок действия удостоверения;GSS_S_DEFECTIVE_TOKEN - обнаружено повреждение токена безопасности;GSS_S_NO_CONTEXT - не задан контекст;GSS_S_NO_CRED - не задано удостоверение.

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

Представление некоторых объектов интерфейса безопасности в среде языка C

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

Прежде всего, вводится тип OM_uint32, соответствующий 32-битным беззнаковым целым значениям. Большинство структурных значений представляется с помощью указателя на дескриптор (см. листинг 11.1).

typedef struct gss_buffer_desc_struct { size_t length; void *value; } gss_buffer_desc, *gss_buffer_t;

Листинг 11.1. Описание дескриптора буфера и указателя на него.

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

Идентификаторы объектов представляются следующим образом (см. листинг 11.2).

typedef struct gss_OID_desc_struct { OM_uint32 length; void *elements; } gss_OID_desc, *gss_OID;

Листинг 11.2. Описание дескриптора идентификаторов объектов и указателя на него.

Указатели elements ссылаются на начало представления идентификаторов, т. е. на последовательности байт, устроенных в соответствии с базовыми правилами ASN.1.

Наборы объектных идентификаторов представляются так, как показано на листинге 11.3.

typedef struct gss_OID_set_desc_struct { int count; gss_OID elements; } gss_OID_set_desc, *gss_OID_set;

Листинг 11.3. Описание дескриптора набора объектных идентификаторов и указателя на него.

Вводятся и некоторые другие типы, уточняющие представление структурированных значений.

На листинге 11.4 показано, как выглядит на языке C описание функции GSS_Init_sec_context.

OM_uint32 GSS_Init_sec_context ( OM_uint32 *minor_status, const gss_cred_id_t initiator_cred_handle, gss_ctx_id_t *context_handle, const gss_name_t target_name, const gss_OID mech_type, OM_uint32 req_flags, OM_uint32 time_req, const gss_channel_bindings_t input_chan_bindings, const gss_buffer_t input_token gss_OID *actual_mech_type, gss_buffer_t output_token, OM_uint32 *ret_flags, OM_uint32 *time_rec );

Листинг 11.4. Описание функции GSS_Init_sec_context.

Отметим, что параметр context_handle является здесь одновременно входным и выходным, а основной код завершения возвращается как результат функции.

Разумеется, есть еще много аспектов, оговоренных в спецификациях [85], например, кто и когда отводит память под объекты и под дескрипторы, и каким образом эту память можно освобождать. Мы, однако, не будем на этом останавливаться.

<

typedef struct gss_buffer_desc_struct

typedef struct gss_buffer_desc_struct { size_t length; void *value; } gss_buffer_desc, *gss_buffer_t;

Листинг 11.1. Описание дескриптора буфера и указателя на него.

Закрыть окно

typedef struct gss_OID_desc_struct { OM_uint32 length; void *elements; } gss_OID_desc, *gss_OID;

Листинг 11.2. Описание дескриптора идентификаторов объектов и указателя на него.

Закрыть окно

typedef struct gss_OID_set_desc_struct { int count; gss_OID elements; } gss_OID_set_desc, *gss_OID_set;

Листинг 11.3. Описание дескриптора набора объектных идентификаторов и указателя на него.

Закрыть окно

OM_uint32 GSS_Init_sec_context ( OM_uint32 *minor_status, const gss_cred_id_t initiator_cred_handle, gss_ctx_id_t *context_handle, const gss_name_t target_name, const gss_OID mech_type, OM_uint32 req_flags, OM_uint32 time_req, const gss_channel_bindings_t input_chan_bindings, const gss_buffer_t input_token gss_OID *actual_mech_type, gss_buffer_t output_token, OM_uint32 *ret_flags, OM_uint32 *time_rec );

Листинг 11.4. Описание функции GSS_Init_sec_context.

Закрыть окно

Создание и уничтожение контекстов безопасности

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

Для работы с контекстами обобщенный интерфейс безопасности GSS-API предоставляет следующие функции:

GSS_Init_sec_context - формирование "исходящего" контекста, т. е. части контекста, относящейся к инициатору общения;GSS_Accept_sec_context - формирование "входящего" контекста, т. е. части контекста, относящейся к вызываемому партнеру;GSS_Delete_sec_context - отказ от контекста, ставшего ненужным;GSS_Process_context_token - обработка полученного контекстного токена;GSS_Context_time - выяснение срока годности контекста;GSS_Inquire_context - получение информации о контексте;GSS_Wrap_size_limit - выяснение максимального размера сообщения, которое можно зашифровать в рамках заданного контекста безопасности;GSS_Export_sec_context - передача контекста другому процессу;GSS_Import_sec_context - прием контекста, переданного другим процессом.

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

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

Если инициатор общения (обычно это клиент) желает убедиться в подлинности партнера, он передает функции GSS_Init_sec_context флаг mutual_req_flag (требуется взаимная аутентификация).
В таком случае вызов GSS_Init_sec_context возвращает в качестве основного кода значение GSS_S_CONTINUE_NEEDED (а не GSS_S_COMPLETE). Соответствующим образом меняется и генерируемый контекстный токен. Партнер, приняв и обработав (с помощью функции GSS_Accept_sec_context) присланную информацию, получит на выходе установленный флаг mutual_state и новый контекстный токен, который следует вернуть инициатору. Последний должен повторно обратиться к функции GSS_Init_sec_context с полученным токеном. При отсутствии ошибок GSS_Init_sec_context вернет, наконец, основной код GSS_S_COMPLETE, и формирование контекста на этом завершится.

При формировании контекста служба безопасности может требовать обмена несколькими токенами (даже без взаимной аутентификации). Тогда инициатору придется несколько раз вызывать функцию GSS_Init_sec_context, а его партнеру - функцию GSS_Accept_sec_context. Все вызовы, кроме последнего, вернут основной код GSS_S_CONTINUE_NEEDED. Последний вызов, завершающий формирование контекста на соответствующей стороне, в нормальном случае выдаст основной код GSS_S_COMPLETE.

Партнеры должны сами определять (способами, внешними по отношению к GSS-API), что именно из пересылаемой информации представляет собой контекстный токен и какой функции его следует передать. При отказе от контекста, ставшего ненужным, функция GSS_Delete_sec_context может передать управляющий токен, подлежащий пересылке партнеру. Партнер, приняв токен, должен вызвать функцию GSS_Process_context_token, которая проанализирует управляющую информацию и удалит вторую половину сбрасываемого контекста.

Как правило, в процессе формирования контекста партнер получает информацию о его инициаторе. Инициатор может запросить формирование "анонимного" контекста посредством флага anon_req_flag. Это имеет смысл при пользовании общедоступными услугами (получение свободно распространяемой информации и т.п.). Партнер вправе принять или отвергнуть анонимный контекст.

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

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

Для приема (импорта) контекста безопасности служит функция GSS_Import_sec_context.

Обобщенный прикладной программный интерфейс службы

Обобщенный прикладной программный интерфейс службы безопасности (Generic Security Service Application Program Interface - GSS-API, см. [67], [85]) предназначен для защиты коммуникаций между компонентами программных систем, построенных в архитектуре клиент/сервер. Он предоставляет услуги по взаимной аутентификации осуществляющих контакт партнеров и по контролю целостности и обеспечению конфиденциальности пересылаемых сообщений.
Пользователями интерфейса безопасности GSS-API являются коммуникационные протоколы (обычно прикладного уровня) или другие программные системы, самостоятельно выполняющие пересылку данных.
Обобщенный интерфейс безопасности GSS-API не зависит от конкретной языковой среды и от механизмов безопасности, обеспечивающих реальную защиту. Последнее обстоятельство позволяет создавать приложения, которые на уровне исходного текста мобильны по отношению к смене механизмов безопасности. Тем самым реализуется открытость прикладных систем и соответствующих средств защиты.
Следует отметить, что средства защиты могут быть очень разными - от систем Kerberos (см. [91]) до продуктов, реализующих спецификации X.509, т. е. GSS-API имеет под собой вполне конкретную почву.
На каждом компьютере, где предполагается применять интерфейс безопасности GSS-API, должно быть установлено клиентское программное обеспечение соответствующего механизма защиты. Приложение, использующее GSS-API, локальным образом вызывает необходимые функции, получая в ответ так называемые токены безопасности. Подобный токен может содержать зашифрованное удостоверение пользователя, электронную подпись или целое зашифрованное сообщение. Приложения обмениваются токенами безопасности, достигая тем самым аутентификации, целостности и конфиденциальности общения. Поскольку коммуникационные аспекты вынесены за пределы GSS-API, он автоматически оказывается независимым от сетевых протоколов. Сетевая мобильность приложений должна обеспечиваться иными средствами.

Защита сообщений

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

Интерфейс GSS-API предоставляет следующие функции для работы с сообщениями:

GSS_GetMIC - формирование токена, позволяющего контролировать целостность сообщения и подлинность его источника;GSS_VerifyMIC - проверка целостности сообщения и подлинности источника с помощью ассоциированного токена;GSS_Wrap - формирование инкапсулированного, возможно, зашифрованного, сообщения, содержащего информацию для контроля целостности и проверки подлинности источника;GSS_Unwrap - разбор инкапсулированного сообщения.

При формировании контекста инициатор специфицирует требуемый уровень защиты сообщений. Ответные флаги показывают, обеспечивается ли этот уровень на самом деле. Флаг integ_avail информирует о возможности контроля целостности и подлинности источника сообщения, conf_avail - о доступности средств шифрования. Прежде чем обращаться к функциям GSS_GetMIC/GSS_Wrap, приложение должно проверить состояние перечисленных флагов.

Функция GSS_GetMIC на основе сообщения формирует отдельный токен безопасности. Функция GSS_Wrap "упаковывает" контрольную информацию вместе с сообщением (быть может, зашифрованным). Приложения должны уметь различать токены безопасности и сообщения (инкапсулированные или нет) и обрабатывать их соответствующим образом.

Служба безопасности способна предоставлять дополнительные услуги в виде отслеживания продублированных сообщений и усиленного контроля последовательности сообщений. При формировании контекста эти услуги могут быть заказаны (флаги replay_det_req_flag и sequence_req_flag). Ответные флаги показывают, действительно ли обеспечивается запрошенный уровень защиты - тогда в ассоциированные токены безопасности или инкапсулированные сообщения прозрачным для приложения образом могут вставляться порядковые номера, временные штампы и т.п. Соответственно, приложение должно быть готово получить от функций GSS_VerifyMIC/GSS_Unwrap основные коды завершения: GSS_S_DUPLICATE_TOKEN (обнаружено дублирование сообщений), GSS_S_OLD_TOKEN (старое сообщение), GSS_S_UNSEQ_TOKEN (опоздавшее сообщение), GSS_S_GAP_TOKEN (сообщение пришло слишком рано - некоторые предшествующие сообщения еще не получены). Подозрительные сообщения, несмотря на ненормальный код завершения, передаются приложению, которое трактует ситуацию в соответствии с избранной политикой безопасности (в частности, ничто не мешает обработать сообщение обычным образом).

Некоторые службы безопасности могут предоставлять различное качество защиты (Quality Of Protection - QOP). Выбор подходящего качества важен для приложения с точки зрения разумного расходования ресурсов, поскольку сильная защита может требовать значительных накладных расходов. В спецификациях интерфейса GSS_API определяется формат элемента данных, описывающего качество защиты. Это 32-битное целое, состоящее из двух 16-битных частей, одна из которых относится к контролю целостности, а другая - к обеспечению конфиденциальности. В обоих случаях задается степень контроля, идентификаторы используемых алгоритмов и информация, специфичная для выбранного алгоритма.

Анализ рисков, идентификация активов и угроз

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

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

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

В Руководстве фигурирует следующая классификация активов:

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

программное обеспечение: исходные тексты, объектные модули, утилиты, диагностические программы, операционные системы, коммуникационные программы;

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

люди: пользователи, обслуживающий персонал;

документация: по программам, по аппаратуре, системная, по административным процедурам;

расходные материалы: бумага, формы, красящая лента, магнитные носители.

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

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

Общие принципы выработки официальной политики предприятия в области информационной безопасности

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

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

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

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

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

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

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

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

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

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

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

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

Основы предлагаемого подхода

Формирование политики и процедур безопасности означает выработку плана действий по информационной защите, для этого необходимо:

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

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

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

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

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

В разделе "Типы процедур безопасности" перечисляются типы процедур, служащих для предотвращения нападений. Профилактика - основа безопасности.

Раздел "Реакция на нарушения безопасности" посвящен реагированию на нарушения безопасности, т. е. кругу вопросов, с которыми организация сталкивается, когда кто-то отступает от политики безопасности. Если такое случается, приходится принимать целый комплекс решений, но многие из них можно продумать заранее. По крайней мере, следует договориться о распределении обязанностей и способах взаимодействия. И здесь важнейшую роль играет политика безопасности.

Тема последнего раздела - меры, предпринимаемые после ликвидации нарушения безопасности. Планирование защитных действий - это непрерывный циклический процесс, поэтому очередной инцидент становится прекрасным поводом для пересмотра и улучшения политики и процедур.

Подход к выработке процедур для предупреждения нарушений безопасности

Политика безопасности отвечает на вопрос ЧТО:

Что следует защищать? Что является самым важным? Что за свойства у защищаемых объектов? Что за подход к проблемам безопасности избран?

Сама по себе политика безопасности не говорит, КАК защищаются объекты. Ответы на вопросы КАК дают процедуры безопасности.

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

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

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

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

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

программные ошибки;

внутренние злоумышленники.

Проблемы, с которыми может столкнуться организация

В Руководстве рассматривается гипотетическая, но весьма вероятная последовательность проблем в области информационной безопасности.

Системный администратор получает сообщение о том, что главный подпольный бюллетень крэкеров распространяется с административной машины, находящейся в его ведении, и попадает в пять тысяч американских и западноевропейских компьютеров. Спустя восемь недель тот же администратор получает официальное уведомление, что информация из одного бюллетеня была использована для выведения из строя на пять часов службы "911" в одном из больших городов. Пользователь звонит и сообщает, что он не может войти в систему под своим именем в 3 часа утра субботы. Администратору также не удается войти в систему. После перезагрузки и входа в однопользовательский режим он обнаруживает, что файл паролей пуст. К утру понедельника выясняется, что между данной машиной и местным университетом в привилегированном режиме было передано несколько файлов. Во вторник утром на университетском компьютере найдена копия стертого файла паролей вместе с аналогичными файлами с дюжины других машин. Спустя неделю администратор обнаруживает, что файлы инициализации системы изменены враждебным образом. Администратор получает сообщение о том, что в компьютер правительственной лаборатории совершено вторжение с подведомственной ему машины. Ему предлагают предоставить регистрационную информацию для отслеживания нападавшего. Спустя неделю администратор получает список подведомственных компьютеров, подвергшихся успешным атакам крэкеров. Администратору звонит репортер и интересуется подробностями проникновения на компьютеры организации. Администратор ничего не слышал о таких проникновениях. Через три дня выясняется, что случай проникновения имел-таки место. Глава организации использовал в качестве пароля имя жены. Обнаруживаются модификации системных бинарных файлов. После восстановления файлы в тот же день вновь оказываются модифицированными. Так повторяется несколько недель.

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

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

Реагирование на нарушения безопасности (процедурный уровень)

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

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

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

обзор (цели, преследуемые политикой безопасности в плане реакции на инциденты);

оценка (насколько серьезно произошедшее событие);

извещение (кого следует известить о нем);

ответные меры (что следует предпринять в ответ); правовой аспект (каковы правовые последствия случившегося); регистрационная документация (что следует фиксировать до, во время и после инцидента).

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

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

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

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

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

Меры, предпринимаемые для борьбы с нарушением, можно подразделить на основные категории:

сдерживание;

ликвидация;

восстановление;

анализ.

Цель сдерживания - ограничить атакуемую область. Например, как можно быстрее приостановить распространение червя в сети.

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

После ликвидации атаки наступает время восстановления, т. е. приведения системы в нормальное состояние.

Следует предпринять по крайней мере следующие действия:

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

Устранить все уязвимые места, сделавшие возможным нарушение режима безопасности, непросто, но необходимо. Ключевым моментом здесь является понимание механизма вторжения.

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

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

Требуется получить ответы по крайней мере на следующие вопросы:

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

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

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

<

Реагирование на нарушения политики безопасности (административный уровень)

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

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

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

Правильно организованное обучение - лучшая защита. Надо поставить дело так, чтобы не только внутренние, но и внешние легальные пользователи знали положения политики безопасности.

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

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

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

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

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

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

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

Перечень обстоятельств, обусловливающих стратегию "защититься и продолжить":

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

Когда предпочтительна стратегия "выследить и осудить":

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

Регламентация использования ресурсов

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

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

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

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

Для регламентации доступа к ресурсам нужно ответить на следующие вопросы:

Разрешается ли использование чужих счетов? Можно ли отгадывать чужие пароли? Допускается ли разрушение сервисов? Должны ли пользователи предполагать, что если файл доступен на чтение всем, то они имеют право его читать? Вправе ли пользователи модифицировать чужие файлы, если по каким-либо причинам у них есть доступ на запись? Обязаны ли пользователи разделять счета?

В большинстве случаев ответы на подобные вопросы будут отрицательными.

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

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

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

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

Разрешены ли вообще подобные исследования? Что именно разрешено: попытки проникновения, выращивание червей и вирусов и т.п.? Каким образом должны контролироваться подобные исследования (например, изолировать их в рамках отдельного сегмента сети)? Как защищены пользователи (в том числе внешние) от подобных исследований? Как получать разрешение на проведение исследований?

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

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

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

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

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

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

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



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

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

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

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

Ресурсы для предупреждения нарушений безопасности

Конфиденциальность, т. е. обеспечение скрытности или секретности, - одна из главных практических целей информационной безопасности.

Как правило, с информацией могут несанкционированно ознакомиться в трех местах:

там, где она хранится (на компьютерных системах); там, где она передается (в сети); там, где хранятся резервные копии.

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

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

Говорят, что информация находится в целостном состоянии, если она полна, корректна и не изменилась с момента последней проверки "цельности".

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

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

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

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

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

Конфигурационное управление разумно применять и к физическому конфигурированию аппаратуры.

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

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

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

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

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

Выбор регуляторов для практичной защиты

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

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

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

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

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

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

Описание правил группы реагирования

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

типы нарушений и уровень поддержки;кооперация, взаимодействие и раскрытие информации;коммуникации и аутентификация.

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

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

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

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

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

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

У некоторых поставщиков есть собственные группы реагирования, у других нет. В последнем случае группа должна работать непосредственно с поставщиком, чтобы предложить улучшения или изменения, проанализировать техническую проблему или протестировать предлагаемые решения.
Если продукты поставщика оказываются вовлеченными в нарушение, он играет особую роль в реагировании.
Группы реагирования и пользователи должны соблюдать действующее законодательство, которое существенно различается в разных странах. Группа реагирования может давать рекомендации по техническим деталям атаки или запрашивать совета по правовым последствиям нарушения. В законодательстве нередко содержатся специфические требования к предоставлению докладов и соблюдению конфиденциальности.
Время от времени от прессы поступают запросы на информацию и комментарии. Явные правила, касающиеся передачи информации такого рода, весьма полезны; они должны разъяснять все вопросы как можно подробнее, поскольку пользователи весьма болезненно воспринимают контакты с журналистами.
Подразумеваемый статус любых сведений, получаемых группой и имеющих отношение к информационной безопасности, - "конфиденциально", однако, строгое следование этому положению превращает группу в информационную "черную дыру", что может уменьшить ее привлекательность как партнера для пользователей и других организаций. Необходимо определить, что именно докладывается или раскрывается, кому и когда.
Возможно, разные группы будут являться субъектами разного законодательства, требующего раскрытия информации или, напротив, ограничивающего его, особенно, если речь идет о группах из разных стран. Кроме того, они могут руководствоваться требованиями на доклады, налагаемыми спонсорскими организациями. Все такие ограничения должны быть специфицированы, чтобы прояснить ситуацию для пользователей и других групп.
Необходимо иметь политику, определяющую методы защиты и контроля коммуникаций. Это важно для взаимодействия как между группами, так и между группой и пользователями. В дополнение к максимально полному шифрованию критичной информации ее следует снабжать цифровой подписью.
Для упомянутой выше вымышленной группы реагирования XYZ-CERT определены специальные правила.
Типы нарушений и уровень поддержки.


Группа XYZ- CERT уполномочена заниматься всеми видами нарушений безопасности, а также угрозами нарушений в университете XYZ.
Уровень поддержки, предоставляемой группой XYZ-CERT, зависит от типа и серьезности нападения, типа опекаемого сообщества, числа пострадавших, а также от количества наличных ресурсов, хотя в любом случае некоторый ресурс в течение рабочего дня будет выделен. Ресурсы выделяются в соответствии со следующими приоритетами, перечисленными по убыванию:
угрозы физической безопасности людей;
атаки на уровне суперпользователя или системном уровне на любую административную информационную систему или часть инфраструктуры магистральной сети;
атаки на уровне суперпользователя или системном уровне на любую машину, предоставляющую крупный сервис, многопользовательский или специализированный;компрометация конфиденциальных счетов пользователей на сервисах ограниченного доступа или компрометация установок программного обеспечения, особенно тех, что используются администраторами и приложениями, работающими с конфиденциальными данными;
атака на доступность сервисов, перечисленных в предыдущем пункте;любое из перечисленных выше нападений, направленных на другие системы и исходящих из университета XYZ;масштабные атаки любого типа, например: перехват пакетов, атаки в IRC путем морально-психологического воздействия, атаки на пароли;угрозы, причинение беспокойства и другие противоправные действия, направленные на отдельных пользователей;компрометация отдельных счетов пользователей в многопользовательских системах;компрометация настольных систем;подделка, неправильное представление и другие относящиеся к безопасности нарушения местных правил: подделка новостей и электронной почты, несанкционированное использование роботов IRC;
атака на доступность отдельных счетов пользователей, в частности применение почтовых бомб.
Типы нарушений, не перечисленные выше, получают приоритет в соответствии со своей наблюдаемой серьезностью и масштабом.
Непосредственная помощь конечным пользователям не предоставляется; предполагается, что они будут взаимодействовать со своим системным или сетевым администратором или уполномоченным по отделу.


С этими сотрудниками XYZ-CERT и будет работать.
В группе понимают, что уровень подготовки системных администраторов в университете XYZ может быть очень разным. Группа XYZ-CERT намерена предоставлять информацию и помощь в форме, понятной всем, тем не менее, она не может повышать квалификацию администраторов "на лету", равно как и администрировать системы вместо них. В большинстве случаев предоставляются ссылки на информацию, необходимую для принятия соответствующих мер.
Группа XYZ-CERT стремится информировать системных администраторов университета XYZ о потенциальных уязвимостях, по возможности до того, как их используют для нападений.
Кооперация, взаимодействие и раскрытие информации. Существуют законодательные и этические ограничения на раскрытие информации группой XYZ-CERT (многие из этих ограничений упомянуты в политике университета по отношению к вычислительным ресурсам; безусловно, все они будут соблюдаться), но группа подтверждает свою приверженность духу сотрудничества, создавшему Internet. Поэтому, принимая необходимые меры для сокрытия личной информации членов опекаемого сообщества и организаций-партнеров, группа, по возможности, станет свободно разделять информацию, если это целесообразно с точки зрения отражения или предупреждения нападений.
Далее в тексте под "пострадавшими сторонами" понимаются законные владельцы, операторы и пользователи вычислительных систем. В этот круг не входят неавторизованные пользователи, а также авторизованные пользователи, работающие с вычислительными системами неавторизованным образом; таким злоумышленникам не гарантируется сохранение конфиденциальности группой XYZ-CERT. Они могут иметь или не иметь законных прав на конфиденциальность; если такие права существуют, они, конечно, будут соблюдаться.
Информация, которая, возможно, будет распространяться, классифицируется следующим образом:

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


Персональные данные пользователей не будут раскрываться в узнаваемой форме за пределами группы XYZ-CERT; исключения оговорены ниже. Если личность пользователя скрыта, информация может распространяться свободно;
информация о злоумышленнике аналогична персональным данным пользователя, но относится к злоумышленнику. Хотя информацию о злоумышленнике (в частности, идентифицирующие данные) не сделают общедоступной (если только она уже не стала достоянием общественности, например, по причине возбуждения судебного преследования), ее будут свободно пересылать системным администраторам и группам реагирования, прослеживающим нарушение;
информация о частной системе - это техническая информация о конкретных системах или организациях. Она не будет разглашаться без согласия соответствующих организаций. Исключения оговорены ниже;
информация об уязвимостях - техническая информация об уязвимостях или атаках, включая исправления и сопутствующие меры. Она распространяется свободно, хотя и будут прилагаться все усилия, чтобы заинтересованный в ней поставщик получил ее раньше других;
информация, бросающая тень, - сообщение о том, что нарушение имело место, а также сведения о его масштабе или серьезности. Не будет распространяться без разрешения соответствующих организаций или пользователей. Исключения оговорены ниже;
статистическая информация - это информация, бросающая тень, снабженная удаленными идентифицирующими данными. Она распространяется по усмотрению отдела компьютерных услуг;
контактная информация позволяет обратиться к системным администраторам и группам реагирования. Она будет распространяться свободно, если только контактное лицо или организация не попросит об обратном или если группа XYZ-CERT не решит, что такое распространение вызовет недовольство.
Потенциальные получатели информации от группы XYZ-CERT также отнесены к различным категориям:
по роду своей деятельности, в том числе по соблюдению конфиденциальности, администраторы университета XYZ имеют право получать всю информацию, необходимую для эффективной реакции на нарушения безопасности, затрагивающие вверенные им системы;системные администраторы университета XYZ также, в силу возложенных на них обязанностей, допущены к работе с конфиденциальной информацией.


Однако, если эти лица не являются членами группы XYZ-CERT, они будут получать только те сведения, которые нужны им для проведения расследования или обеспечения безопасности вверенных им систем;пользователи университетских систем допущены к информации, которая касается безопасности их собственных компьютерных счетов, даже если это означает утечку "информации о злоумышленнике" или "информации, бросающей тень" на другого пользователя;университетское сообщество не будет получать никакой информации ограниченного распространения, если только стороны, затронутые нарушением, не дадут разрешения на распространение сведений. Статистическая информация может предоставляться общественности. Группа XYZ-CERT не считает себя обязанной информировать общественность о нарушениях, хотя и может делать это; в частности, вероятно, известит все заинтересованные стороны о том, каким образом они были атакованы, или одобрит распространение этими сторонами подобной информации;широкая общественность не получит никакой информации ограниченного распространения. На самом деле, к ней не будут обращаться, хотя группа XYZ-CERT понимает, что сведения, сообщенные университетскому сообществу, могут стать всеобщим достоянием;сообщество специалистов по информационной безопасности рассматривается наравне с широкой общественностью. Хотя члены группы XYZ-CERT могут принимать участие в дискуссиях в рамках этого сообщества, например, посредством телеконференций, списков рассылки (включая раскрывающий все детали список "bugtraq") и совещаний разного рода, они (члены группы) рассматривают такие форумы как обращение к широкой общественности. Хотя технические вопросы (в том числе уязвимости) могут обсуждаться сколь угодно подробно, все примеры, взятые из опыта группы XYZ-CERT, будут изменены, чтобы сделать невозможной идентификацию затронутых сторон;пресса также рассматривается как часть широкой общественности. Группа XYZ-CERT не будет вступать с ней в непосредственные контакты по поводу нарушений безопасности, если только речь не идет о распространении сведений, уже ставших всеобщим достоянием;другие организации и группы реагирования, являющиеся партнерами в расследовании нарушения безопасности, в некоторых случаях допустят к конфиденциальной информации.


При этом добропорядочность внешних организаций подлежит проверке, а передаваемая информация будет сводиться к минимуму, полезному для ликвидации нарушения. Вероятнее всего, доступ к информации доверят организациям, хорошо известным группе XYZ-CERT;поставщики, как правило, рассматриваются XYZ-CERT наравне с внешними группами реагирования. Приветствуется желание поставщиков всех видов сетевого и компьютерного оборудования, программного обеспечения и услуг повышать безопасность своих продуктов. С этой целью им будет передаваться информация об уязвимостях, обнаруженных в их продуктах, вместе с техническими деталями, позволяющими идентифицировать и ликвидировать проблему;правоохранительные органы получат от группы XYZ-CERT всю информацию, необходимую для проведения расследования, в соответствии с политикой по отношению к вычислительным ресурсам.
Коммуникации и аутентификация. Проанализировав типы информации, с которой имеет дело группа XYZ-CERT, можно сделать вывод, что телефоны без средств шифрования можно считать достаточно безопасными. Нешифрованная электронная почта не особенно защищена, однако ее можно использовать для передачи данных низкой степени критичности.
Если по электронной почте нужно передать критичные данные, будет применяться PGP. С точки зрения безопасности, передача файлов по сети рассматривается наравне с электронной почтой: критичные данные должны шифроваться.
Когда необходимо получить уверенность в подлинности партнера, например, перед началом действий на основе информации, предоставленной группе XYZ-CERT, или перед раскрытием конфиденциальной информации, с высокой степенью надежности будет проверяться его личность и репутация.

Описание услуг группы реагирования

Услуги, оказываемые группой реагирования, можно разделить на две категории:

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

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

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

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

Классификация нарушений обычно включает в себя следующие действия:

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

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

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

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

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

техническая поддержка (например, анализ "взломанных" систем);

искоренение проблем: устранение причин нарушения (использованных уязвимостей) и его проявлений (например, прерывание сеанса пользователя-нарушителя);

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

В профилактические действия входят:

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

обучение и подготовка кадров;

оценка продуктов;

оценка защищенности организации, консультационные услуги.

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

В зависимости от целей и набора услуг конкретной группы, может использоваться несколько форм. Например, форма для сообщения о новой уязвимости может существенно отличаться от доклада о нарушении. Лучше всего предоставлять формы в рамках оперативных информационных услуг группы. Точные ссылки на них должны присутствовать в документах, описывающих группу, вместе с перечнем правил пользования и руководством по порядку работы с формами. Если для "докладов по форме" поддерживаются отдельные адреса электронной почты, они также должны быть указаны.

Один из примеров - форма для доклада о нарушениях координационного центра CERT, представленная на Web-сервере http://www.cert.org/.

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

Группа XYZ-CERT предоставляет соответствующие задачам услуги.

Реагирование на нарушения. XYZ-CERT помогает системным администраторам в технических и организационных аспектах реагирования на нарушения. В частности, оказывается помощь или даются советы о следующих аспектах реагирования:

Классификация нарушений: выяснение того, действительно ли имеет место нарушение;определение масштаба нарушения.

Координация реагирования: выяснение первоначальной причины нарушения (использованной уязвимости);облегчение контактов с другими системами, возможно, затронутыми нарушением;облегчение контактов со службой безопасности университета XYZ и/или правоохранительными органами, если это необходимо;предоставление отчетов другим группам реагирования;составление уведомлений для пользователей, если это необходимо.

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

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

Чтобы воспользоваться услугами группы XYZ-CERT по реагированию на нарушения, следует направить электронное письмо по контактному адресу.

Профилактические действия. Группа XYZ-CERT координирует и предоставляет следующие услуги в объеме, возможно, зависящем от наличия ресурсов:

Информационное обслуживание: список контактных координат уполномоченных лиц по безопасности в отделах (административных и технических). Эти списки общедоступны по таким каналам, как Web;списки рассылки для информирования уполномоченных лиц о появлении новой информации, относящейся к их компьютерной среде, которые доступны только для системных администраторов университета XYZ;хранилище защитных заплат, распространяемых поставщиками или источниками, для различных операционных систем. Хранилище общедоступно, если это позволяют лицензионные соглашения. Доступ к нему предоставляется по обычным каналам - Web и/или ftp;хранилище защитного инструментария и документации для использования системными администраторами. По возможности предоставляются предварительно скомпилированные версии, готовые к установке. Как обычно, доступ предоставляется через Web или ftp;подготовка краткого изложения инцидента для различных информационных ресурсов, включая основные списки рассылки и телеконференции. Результирующие аннотации распространяются через списки рассылки с ограниченным доступом или через Web, в зависимости от критичности и срочности информации.

Повышение квалификации: члены группы XYZ-CERT периодически проводят семинары по различным аспектам информационной безопасности; системные администраторы университета XYZ приглашаются на эти занятия.

Аудит безопасности: проверка целостности основных файлов;присвоение уровней безопасности. Машины и подсети в университете XYZ проверяются на предмет присвоения им уровня безопасности. Информация об уровнях доступна университетскому сообществу, чтобы упростить установку соответствующих прав доступа;централизованное протоколирование для машин, поддерживающих удаленное протоколирование в Unix-стиле. Регистрационные журналы автоматически просматриваются анализирующей программой, а события или тенденции, указывающие на потенциальные проблемы безопасности, доводятся до сведения соответствующих системных администраторов; - сохранение записей о нарушениях безопасности. Хотя эти записи остаются конфиденциальными, периодически готовятся и распространяются статистические отчеты.

Детальное описание перечисленных выше услуг вместе с инструкциями по присоединению к спискам рассылки, скачиванию информации или получению таких услуг, как централизованное протоколирование или проверка целостности файлов, доступны через Web-сервер группы XYZ-CERT.

На этом мы завершаем рассмотрение спецификации Internet-сообщества "Как реагировать на нарушения информационной безопасности".

<

Основные понятия

Тема реагирования на нарушения информационной безопасности исключительно важна, но, на наш взгляд, она пока не получила достаточного освещения в отечественной литературе. Детальное рассмотрение спецификации Internet-сообщества "Как реагировать на нарушения информационной безопасности" [33] призвано отчасти восполнить этот пробел. В последующем изложении использована публикация [7] .

Цель интересующей нас спецификации - сформулировать ожидания Internet-сообщества по отношению к группам реагирования на нарушения информационной безопасности (Computer Security Incident Response Teams, CSIRTs). Потребители имеют законное право (и необходимость) досконально понимать правила и процедуры работы "своей" группы реагирования.

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

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

Чтобы считаться группой реагирования, необходимо:

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

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

Существуют разные виды групп реагирования. Некоторые заботятся о безопасности весьма обширных сообществ. Так, Координационный центр CERT (Computer Emergency Response Team, см. http://www.cert.org/) опекает Internet. У других масштабы деятельности не столь велики (например, группа DFN-CERT поддерживает немецкую исследовательскую сеть DFN, см.
http://www.cert.dfn.de/), у коммерческих или корпоративных групп реагирования они могут быть совсем небольшими. Группы реагирования и безопасности координируют свою работу на всемирном форуме - FIRST (Forum of Incident Response and Security Teams, см. http://www.first.org/).

Под нарушением информационной безопасности понимается любой вид компрометации каких-либо аспектов безопасности систем и/или сетей, к их числу относятся:



потеря конфиденциальности информации;

нарушение целостности информации;

нарушение доступности информационных услуг;

неправомочное использование услуг, систем или информации;

повреждение систем.

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

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

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

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

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

Порядок публикации правил и процедур деятельности групп реагирования

Правила и процедуры группы реагирования должны быть опубликованы и доведены до пользователей. Рекомендуется следовать при этом определенному шаблону. Заполненный шаблон будем называть бланком. Как правило, он должен заверяться электронной подписью группы.

Далее мы поясним назначение некоторых полей шаблона и возможные способы их заполнения.

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

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

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

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

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

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

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



виды деятельности;

клиентура;

спонсоры и вышестоящие организации;

полномочия.

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

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

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

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

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

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

В рассматриваемой спецификации приводится пример устава для вымышленной группы реагирования XYZ-CERT университета XYZ.

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

Клиентура. Опекаемое сообщество группы XYZ-CERT - сотрудники, студенты и аспиранты университета XYZ. Это определено в политике университета по отношению к вычислительным ресурсам, с ней можно ознакомиться по адресу http://www.../policies/pcf.html. Услуги группы распространяются только на производственные системы.

Спонсоры и вышестоящие организации. Спонсором группы XYZ-CERT является компания ACME Canadian Research Network, предлагающая свои услуги в Канаде и США в качестве вышестоящей организации для различных университетских групп реагирования, если они того пожелают.

Полномочия. Группа XYZ-CERT работает под покровительством и с полномочиями, делегированными отделом компьютерных услуг университета XYZ. Предполагается, что XYZ-CERT взаимодействует с системными администраторами и пользователями университета XYZ и, по возможности, избегает авторитарных решений. Однако, под давлением обстоятельств, члены группы могут обратиться в отдел компьютерных услуг, чтобы "употребить власть". Все они входят в комитет системных администраторов и сполна наделены правами и обязанностями, полагающимися администраторам вычислительных ресурсов в соответствии с политикой, либо представлены в руководстве университета. Члены университетского сообщества, желающие обжаловать действия группы XYZ-CERT, должны обратиться к заместителю директора по техническим вопросам или в университетское бюро прав и обязанностей.

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

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

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

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

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

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

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

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

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

Цели организации доверенных коммуникаций состоят в следующем:

обеспечение конфиденциальности;обеспечение целостности;обеспечение аутентичности.

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

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

---