Руководство по анализу безопасности ЛВС - страница 2

26.04.2006 | 14:38
2.2.1. Идентификация и аутентификация Первый шаг к обеспечению безопасности ресурсов ЛВС - способность проверить личности пользователей [BNOV91]. Процесс подтверждения(проверки) личности пользователя назван  установлением подлинности (аутентификацией). Аутентификация обеспечивает основу для эффективного функционирования  других мер и средств защиты, используемых в ЛВС. Например, механизм регистрации позволяет получить информацию об использовании пользователями ресурсов ЛВС, основанную на идентификаторе пользователя. Механизм управления доступом разрешает доступ к ресурсам ЛВС, основываясь на идентификаторе пользователя. Оба эти средства защиты эффективны только при условии, что пользователь, использующий службу ЛВС - действительный пользователь, которому назначен данный идентификатор пользователя
Идентификация требует, чтобы  пользователь был так или иначе известен ЛВС. Она обычно основана на назначении пользователю  идентификатора пользователя. Однако ЛВС не может доверять заявленному идентификатору  без подтверждения его подлинности . Установление подлинности возможно при наличии у пользователя, чего - нибудь уникального, что только пользователь имеет, типа жетона, чего - нибудь единственного, что только пользователь знает, типа пароля, или чего - нибудь, что делает пользователя уникальным, типа отпечатка пальца. Чем больше количество таких уникальных вещей предоставлено пользователем ЛВС, тем меньше риск , что  кто-то подменит законного пользователя.
Требование, определяющее необходимость аутентификации, должно существовать в большинстве  политик безопасности ЛВС. Это требование может содержаться неявно в политике концептуального уровня , которая подчеркивает необходимость эффективного  управления доступом к информации и ресурсам ЛВС, или может быть явно выражено в политике относительно ЛВС,  в виде заявления, что все пользователи должны быть уникально идентифицированы и аутентифицированы.
В большинстве ЛВС используется механизм идентификации и аутентификации на основе схемы идентификатор пользователя/пароль. В [BNOV91] констатируется, что "парольные системы могут быть эффективны, если управляются должным образом [FIPS112], но это бывает редко. Аутентификация, которая полагается исключительно на пароли, часто не может обеспечить адекватную защиту для АС по ряду причин. Пользователи имеют тенденцию создавать пароли, которые являются легкими для запоминания и, следовательно, легкими для угадывания. С другой стороны, если пользователи должны использовать пароли, сгенерированные из случайных символов, которые трудно угадывать, то пользователям также трудно их запомнить . Это вынуждает пользователя записывать пароль куда-либо, и наиболее вероятно, в месте, легко доступном при работе". Исследовательские работы , такие как [KLEIN] , детализируют степень простоты, с которой могут угадываться пароли. Надлежащий выбор пароля (компромисс между  легкостью для запоминания пользователем и трудностью для угадывания другим человеком) всегда был проблемой. Генераторы паролей, которые создают пароли, состоящие из произносимых слогов, позволяют создавать более запоминающиеся пароли, чем те , что создаются генераторами, которые производят просто строки из случайных символов. [FIPS180] определяет алгоритм, который может использоваться для создания случайных произносимых паролей. Программы проверки паролей - это программы, которые позволяют пользователю определить, являются ли новые пароли легкими для угадывания и поэтому недопустимыми. Механизмы с использованием только паролей, особенно те, которые передают по ЛВС пароль в открытом виде(в незашифрованной форме) уязвимы с точки зрения наблюдения и перехвата. Это может стать серьезной проблемой, если ЛВС имеет неконтролируемые связи с внешними сетями. Организации, решившие  связать свои ЛВС с внешними сетями, особенно с Интернетом, должны изучить документ [BJUL93] перед тем, как сделать это. Если после рассмотрения всех вариантов аутентификации, политика ЛВС определяет, что системы аутентификации только на основе паролей приемлемы, то самой важной мерой защиты становится надлежащее  управление созданием паролей, их хранением, слежением за истечением срока их использования, и удалением. Документ [FIPS 112] является руководством по управлению паролями. [NCSC85] обеспечивает дополнительные рекомендации, которые также могут быть учтены.
Из-за уязвимых мест, которые все еще существуют при использовании механизмов на основе только паролей, могут использоваться более надежные механизмы. [BNOV91] обсуждает новые разработки, которые были сделаны в области систем  аутентификации, основанных на смарт-картах и использовании биометрии. Механизм, основанный на интеллектуальных картах, требует, чтобы пользователь владел смарт-картой и дополнительно может потребовать, чтобы пользователь знал персональный код идентификации (ПКИ-PIN) или пароль. Смарт-карта реализует аутентификацию с помощью схемы запрос/ответ, использующей указанные выше параметры в реальном масштабе времени. Использование параметров в реальном масштабе времени помогает предотвратить  получение злоумышленником неавторизованного доступа путем воспроизведения сеанса регистрации пользователя. Эти устройства могут также шифровать сеанс аутентификации, предотвращая компрометацию информации аутентификации с помощью наблюдения и перехвата.
Механизмы блокировки для устройств ЛВС, автоматизированных рабочих мест или ПК, которые требуют для разблокировки аутентификации пользователя, могут быть полезны для пользователей, кто должен часто оставлять рабочее место. Эти механизмы блокировки позволяют пользователям остаться зарегистрированными в ЛВС и покидать их рабочие места (в течение определенного периода времени, не длиннее заданного), не делая при этом свое рабочее место потенциально доступным злоумышленникам.
Модемы, которые обеспечивают пользователей доступом к ЛВС, могут потребовать дополнительной защиты. Злоумышленник, который может получить доступ к модему, может  получить доступ в АС, угадав пароль пользователя. Доступность модема для использования его законными пользователями может также стать проблемой, если злоумышленник имеет постоянный доступ к модему.
Механизмы, которые обеспечивают пользователя информацией об использовании его регистрационного имени, могут предупредить пользователя, что его  имя использовалось необычным образом (например, возникли многократные ошибки при регистрации). Эти механизмы включают уведомления о дате, времени, и местоположении последнего успешного сеанса и числе предыдущих ошибок при регистрации. Типы механизмов защиты, которые могли бы быть реализованы, чтобы обеспечить службы идентификации и аутентификации, приведены в списке ниже:
  •  механизм, основанный на паролях,
  •  механизм, основанный на интеллектуальных картах
  •  механизм, основанный на биометрии,
  •  генератор паролей,
  •  блокировка с помощью пароля,
  •  блокировка клавиатуры,
  •  блокировка ПК или автоматизированного рабочего места,
  •  завершение соединения после нескольких ошибок при регистрации,
  •  уведомление пользователя о "последней успешной регистрации" и "числе ошибок при регистрации",
  •  механизм аутентификации пользователя в реальном масштабе времени,
  •  криптография с уникальными ключами для каждого пользователя.

2.2.2. Управление доступом Эта служба защищает против неавторизованного использования ресурсов ЛВС, и может быть обеспечена при помощи механизмов управления доступом и механизмов привилегий. Большая часть файловых серверов и многопользовательских автоматизированных рабочих мест в некоторой степени обеспечивают эту службу . Однако, ПК, которые монтируют тома файловых серверов, обычно не осуществляют такое управление доступом. Пользователи должны понимать, что файлы из смонтированных дисков, используемые на ПК, находятся под управлением доступом ПК. По этой причине важно использовать службы управления доступом, конфиденциальности и целостности для ПК в максимально возможном объеме. Приложение C описывает некоторые из проблем, которые нельзя избежать при использовании ПК.
Согласно [NCSC87], управление доступом может быть достигнуто при использовании дискреционного управления доступом или мандатного управления доступом. Дискреционное управление доступом - наиболее общий тип управления доступом, используемого в ЛВС. Основной принцип этого вида защиты состоит в том, что индивидуальный пользователь или программа, работающая от имени пользователя, имеет возможность явно определить типы доступа, которые могут осуществить другие пользователи (или программы, выполняющиеся от их имени)  к информации, находящейся в ведении данного пользователя. Дискреционное управление доступом отличается от мандатной защиты, в том, что оно реализует решения по управлению доступом, принятые пользователем. Мандатное управление доступом реализуется на основе результатов сравнения  уровня допуска пользователя и степени конфиденциальности информации.
Существуют механизмы управления доступом, которые поддерживают степень детализации управления доступом на уровне следующих категорий:  владелец информации,  заданная группа пользователей и "мира" (всех других авторизованных пользователей). Это позволяет владельцу файла (или каталога) иметь права доступа, отличающиеся от прав всех других пользователей, и позволяет владельцу файла определить особые права доступа для указанной группы людей, а также для всех остальных (мира). В общем случае, существуют следующие права доступа: доступ по чтению, доступ по записи, и доступ для выполнения. Некоторые операционные системы ЛВС обеспечивают дополнительные права доступа, которые позволяют модификацию, только добавление и т.д..
Операционная система ЛВС может поддерживать профили пользователя и списки возможностей или списки управления доступом для определения прав  доступа для большого количества отдельных пользователей и большого количества различных групп. Использование этих механизмов позволяет обеспечить большую гибкость в предоставлении различных прав доступа для различных пользователей, которые могут обеспечить более строгий контроль доступа к файлам (или каталогам). (Более гибкие механизмы предотвращают предоставление пользователю больших прав доступа, чем необходимо, частой проблемы при описанном выше трехуровневом подходе). Списки управления доступом определяют права доступа специфицированных пользователей и групп к данному файлу или каталогу. Списки возможностей и профили пользователя определяют файлы и каталоги, к которым можно обращаться данным пользователям (или пользователю).
Управление доступом пользователя может осуществляться на уровне каталогов или на уровне файлов. Управление доступом на уровне каталога приводит к  тому, что  права доступа для всех файлов в каталоге становятся одинаковыми . Например, пользователь, который имеет доступ по чтению к каталогу, может читать (и ,возможно, копировать) любой файл в этом каталоге. Права доступа к  директории могут также обеспечить явный запрет доступа, который предотвращает  любой доступ пользователя к файлам в каталоге.
В некоторых реализациях ЛВС можно управлять типами обращений к файлу.  ( Это  осуществляется помимо контроля за тем, кто может иметь доступ к файлу.) Реализации могут предоставлять опцию управления доступом, которая позволяет владельцу помечать файл как разделяемый или заблокированный (монопольно используемый). Разделяемые файлы позволяют осуществлять параллельный доступ к файлу нескольких пользователей в одно и то же время. Блокированный файл будет разрешать доступ к себе только одному пользователю в данный момент времени. Если файл доступен только по чтению, назначение его разделяемым позволяет группе пользователей параллельно читать его .
Эти средства управления доступом могут также использоваться, чтобы ограничить допустимые типы взаимодействия между серверами в ЛВС. Большое количество операционных систем ЛВС могут ограничить тип трафика, посылаемого между серверами. Может не существовать никаких ограничений, что приведет к тому, что для всех пользователей будут доступны ресурсы всех серверов (в зависимости от прав доступа пользователей на каждом сервере). А могут и существовать некоторые ограничения, которые будут позволять только определенные типы трафика, например, только сообщения электронной почты, или более сильные ограничения , которые запретят трафик между определенными серверами. Политика ЛВС должна определить, какими типами информации необходимо обмениваться между серверами. На передачу информации, для которой нет необходимости совместного использования ее несколькими серверами, должны  быть наложены ограничения.
Механизмы привилегий позволяют авторизованным пользователям игнорировать ограничения на доступ, или другими словами некоторым способом легально обходить управление доступом, чтобы выполнить какую-либо функцию, получить доступ к файлу, и т.д.. Механизм привилегий должен включать концепцию минимальных привилегий. [ROBA91] определяет минимальные привилегии как "принцип, согласно которому каждому субъекту в системе предоставляется наиболее ограниченное множество привилегий, которые необходимы для выполнения задачи, которую должен решить пользователь." Например, принцип минимальных привилегий должен применяться при выполнении функции резервного копирования. Пользователь, кто авторизован выполнять функцию резервного копирования, должен  иметь доступ по чтению ко всем файлам, чтобы копировать их на резервные носители информации. (Однако пользователю нельзя давать доступ по чтению ко всем файлам через механизм управления доступом). Пользователю предоставляют "привилегию" обхода ограничения по чтению (предписанного механизмом управления доступом) для  всех файлов, чтобы он мог выполнить функцию резервного копирования. Чем более детальные привилегии могут быть предоставлены, тем больше будет гарантий, что пользователю не даны чрезмерные привилегии  для выполнения им авторизованной функции. Например, пользователю, который должен выполнять функцию резервного копирования, не нужна привилегия обхода ограничения на  запись в файлы, но  механизмы привилегий, которые не обеспечивают такую точность, могут привести к предоставлению ему такой привилегии. Типы механизмов защиты, которые могли бы быть использованы для обеспечения службы управления доступом, приведены в списке ниже:

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

2.2.3. Конфиденциальность данных и сообщений Служба конфиденциальности данных и сообщений может использоваться,  когда необходима секретность информации. Как передняя линия защиты, эта служба может включать в себя механизмы, связанные со службой управления доступом, но может также полагаться на шифрование для обеспечения большего сохранения тайны. Шифрование информации преобразует ее в непонятную форму, называемую шифротекстом, а расшифровывание преобразует информацию обратно в ее первоначальную форму. Критичная информация может храниться в шифрованной форме, в виде шифротекста. Таким образом, если служба управления доступом будет обойдена, к  файлу может быть осуществлен доступ, но информация будет все еще защищена, поскольку находится в зашифрованной форме. (Использование шифрования может быть критическим на ПК, которые не обеспечивают службу управления доступом как передней линии защиты.)
Очень трудно управлять неавторизованным доступом к трафику ЛВС, когда он передается по ЛВС. Многие пользователи ЛВС это осознают и понимают проблему. Использование шифрования сокращает риск какого-либо перехвата и чтения проходящих транзитом через ЛВС сообщений, делая сообщения нечитабельными для тех , кто сможет перехватить их. Только авторизованный пользователь, который имеет правильный ключ, сможет расшифровать сообщение после  его получения.
Хорошая политика безопасности  должна явно указывать пользователям типы информации,  которые считаются критичными настолько, что для них  требуется применение шифрования. Концептуальная политика безопасности организации  может указывать широкие категории информации, которые должны быть обязательно защищены, в то время как политика безопасности конкретной АС может детализировать определенные типы информации и определенные среды работы(ОС), для которых необходима  защита при помощи  шифрования. На каком бы уровне политики безопасности  не предписывалось использование шифрования, решение о его применении  должно быть принято лицом в руководстве организации, ответственным за защиту критической информации. Если в политике  не указывается, какая информация подлежит шифрованию,  то владелец данных полностью отвечает за принятие  этого решения.
Криптография может быть разделена на использующую секретные ключи или использующую открытые ключи. Криптография секретных ключей основана на использовании единственного криптографического ключа, известного двум сторонам. Один и тот же ключ используется для шифрования и расшифровки данных. Этот ключ хранится в тайне обоими сторонами. Если необходимо шифрование критической, но несекретной информации (кроме  информации, соответствующей поправке Уорнера), требуется использовать Стандарт Шифрования Данных (DES) FIPS 46-2, если только главой агентства не наложен запрет на его использование. DES - алгоритм с секретным ключом, используемый в криптографической системе, которая может обеспечить конфиденциальность. FIPS 46-2 предусматривает реализацию DES-алгоритма  аппаратными средствами ЭВМ, программным обеспечением, программируемым оборудованием или некоторой их комбинацией. FIPS 46-2  отличается от FIPS 46-1, который предполагал использование только аппаратных средств ЭВМ. Краткий обзор DES, информация, описывающая применимость DES и процедура отказа в его применении приведены в [NCSL90].
Криптография с открытыми ключами - форма криптографии, которая использует два ключа: открытый ключ и секретный ключ. Два ключа связаны, но имеют такое свойство, что по данному открытому ключу  в вычислительном отношении невозможно получить секретный ключ [FIPS 140-1]. В криптосистеме с открытыми ключами каждая сторона имеет собственную пару  из открытого и секретного ключей. Открытый ключ может быть известен любому лицу; секретный ключ хранится в  тайне. Можно привести следующий пример обеспечения конфиденциальности: два пользователя, Скотт и Джефф, желают обменяться критической информацией и сохранить  конфиденциальность этой информации. Скотт может зашифровать информацию на открытом ключе Джеффа. Конфиденциальность информации сохраняется, так как только Джефф может расшифровать информацию при помощи своего секретного ключа. В настоящее время не существует никаких FIPS, которые бы описывали допустимый  алгоритм шифрования на открытых ключах для обеспечения конфиденциальности.  Агентства должны отказываться от FIPS 46-2, чтобы использовать  алгоритм шифрования на открытых ключах для конфиденциальности. Технология открытых ключей в форме цифровых подписей может также обеспечить целостность и контроль участников взаимодействия. Это будет обсуждено в разделе 2.2.4. Целостность Данных
FIPS 140-1, Требования Безопасности для Криптографических Модулей, должен использоваться агентствами при определении требований безопасности,  необходимых для защиты оборудования, которое используется для  шифрования. Этот стандарт определяет требования, такие, как аутентификация, физическое управление доступом и правильное управление ключами, для всего оборудования, которое используется для шифрования. К системам, которые реализуют шифрование в программном обеспечении, выдвигаются дополнительные требования, описанные в FIPS 140-1. Серверы ЛВС, ПК, платы шифрования, модемы шифрования, и все другое оборудование ЛВС и сетей передачи данных, которое имеет возможность шифрования, должно соответствовать  требованиям FIPS 140-1. Типы механизмов безопасности, которые могли бы быть реализованы, чтобы обеспечить службу конфиденциальности сообщений и данных, приведены в списке ниже.
Механизмы

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

2.2.4. Целостность данных и сообщений Служба целостности данных и сообщений помогает защитить данные и программное обеспечение на автоматизированных рабочих местах, файловых серверах и других компонентах ЛВС от неавторизованной модификации. Неавторизованная модификация может быть намеренной или случайной. Эта служба может быть обеспечена при помощи криптографических контрольных сумм,  и очень детальных механизмов управления доступом и привилегий. Чем больше точность управления доступом или механизма привилегий, тем менее вероятна возможность неавторизованной или случайной модификации.
Служба целостности данных и сообщений также помогает гарантировать, что сообщение не изменено, не удалено или не добавлено любым способом в течение передачи. (Некорректная модификация пакета сообщения обрабатывается на уровне управления доступом к среде, осуществляемого в рамках протокола ЛВС.) Большинство из методов защиты, доступных сегодня, не могут предотвратить модификацию сообщения, но они могут обнаружить модификацию сообщения (если сообщение не удалено полностью).
Использование контрольных сумм обеспечивает возможность обнаружения модификации. Код Аутентификации Сообщения (Message Authentication Code - MAC), разновидность  криптографической контрольной суммы, может защитить против как случайной, так и намеренной , но неавторизованной, модификации данных. MAC первоначально рассчитывается путем применения криптографического алгоритма и секретного числа, называемого ключом, к данным. Начальный MAC сохраняется. Позже данные проверяются с применением криптографического алгоритма и того же самого секретного ключа к данным для вычисления другого MAC; затем этот MAC сравнивается с начальным MAC. Если два MAC равны, тогда данные считаются подлинными. В противном случае предполагается неавторизованная модификация. Любая сторона, которая пробует изменить данные,  но не знает при этом ключ, не будет знать, как вычислить MAC, соответствующий измененным данным. FIPS 113, Аутентификация Компьютерных Данных, определяет Алгоритм Аутентификации Данных, основанный на DES, который используется для  вычисления MAC. См. [SMID88] для более  подробной информации относительно использования MAC.
Также могут использоваться электронные подписи для обнаружения модификации данных или сообщений. Электронная подпись может быть создана при помощи криптографии с открытыми или секретными ключами. При использовании системы с открытыми ключами документы в компьютерной системе подписываются с помощью электронной подписи  путем применения секретного  ключа отправителя документа. Полученная электронная подпись и документ могут быть затем  сохранены или переданы. Подпись может быть проверена при помощи открытого ключа создателя документа. Если подпись подтверждается  должным образом, получатель может быть уверен в том, что документ был подписан с использованием секретного ключа его создателя и что сообщение не было изменено после того, как оно было подписано. Поскольку секретные ключи известны только их владельцам, это делает также возможным проверку личности отправителя сообщения третьим лицом. Поэтому электронная подпись обеспечивает две различных службы: контроль участников взаимодействия  и целостность сообщения. FIPS PUB 186, Стандарт Электронной Подписи, определяет алгоритм электронной подписи, который должен использоваться ,когда требуются целостность данных и сообщений.
Код аутентификации сообщения (MAC), описанный выше, также может использоваться, чтобы обеспечить возможность электронной подписи. MAC рассчитывается на основании содержания сообщения. После передачи рассчитывается другой MAC на основании содержания полученного сообщения. Если MAC, связанный с сообщением, которое посылалось, отличается от MAC, связанного с сообщением, которое было получено, тогда имеется доказательство того, что полученное сообщение не соответствует посланному сообщению. MAC также может использоваться, чтобы идентифицировать для получателя лицо, подписавшее информацию. Однако реализация этой технологии по существу не совсем  обеспечивает контроль участников взаимодействия, потому что и отправитель информации и ее получатель используют один и тот же ключ. Типы механизмов защиты, которые могли бы быть реализованы, чтобы обеспечить службу целостности данных и сообщений, представлены в списке ниже.
Механизмы

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

2.2.5. Контроль участников взаимодействия Служба контроля участников взаимодействия помогает гарантировать, что субъекты взаимодействия  не смогут отрицать участие во всем взаимодействии или какой-либо его части. Когда главной функцией ЛВС является  электронная почта, эта служба безопасности становится очень важной. Контроль участников взаимодействия с подтверждением отправителя  дает получателю некоторую степень уверенности в том, что сообщение действительно прибыло от названного отправителя. Службу контроля участников взаимодействия  можно обеспечить с помощью  криптографических методов с использованием открытых ключей, реализующих электронную подпись. См. раздел 2.2.4 Целостность Данных и Сообщений для описания и использования электронных подписей. Механизм защиты, который мог бы быть реализован для обеспечения службы контроля участников взаимодействия, приведен ниже.
Механизм

  •  использование электронных подписей с открытыми ключами.

2.2.6. Регистрация и наблюдение Эта служба исполняет две функции. Первая - обнаружение возникновения угрозы. (Однако обнаружение не происходит в режиме реального времени, если не используются какие-либо средства для наблюдения в реальном масштабе времени.) Для всех обнаруженных случаев нарушения безопасности  должна иметься возможность проследить действия нарушителя во всех частях  системы, что зависит от масштабов регистрации. Например, в случае вторжения злоумышленника в систему, журнал должен указывать, кто проводил сеанс с системой в это время, все критичные файлы, для которых имелись аварийно завершившиеся попытки доступа, все программы, которые запускались, и т.д.. Он должен также указывать критичные файлы и программы, к которым были успешные обращения в этот период времени. Может оказаться уместным иметь в некоторых областях ЛВС (автоматизированных рабочих местах, файловых серверах, и т.д.) какую-либо разновидность службы регистрации.
Вторая функция этой службы -  обеспечить системных и сетевых администраторов статистикой, которая показывает, что система и сеть в целом функционируют должным образом. Это может быть сделано при помощи механизма аудирования, который использует файл журнала  в качестве исходных данных и перерабатывает  его в информацию относительно использования системы и ее защиты. Могут также использоваться средства наблюдения за ЛВС, которые помогали бы обнаружить проблемы с ее доступностью по мере их возникновения. Типы механизмов защиты, которые могли бы использоваться, чтобы обеспечить службу регистрации и наблюдения, приведены в списке ниже.
Механизмы

  •  регистрация информации о сеансах пользователей(включая исходящую машину, модем, и т.д.),
  •  регистрация изменений прав пользователей для управления доступом,
  •  регистрация использования критичных файлов,
  •  регистрация модификаций, сделанных в критическом программном обеспечении,
  •  использование инструментов управления трафиком ЛВС,
  •  использование средств аудирования.
3. Управление риском Для определения соответствующих мер защиты ЛВС должен использоваться систематический подход. Решение, как  обеспечить защиту, где реализовать защиту в ЛВС, какими должны быть типы и мощность мер и средств защиты, требует значительных размышлений. Этот раздел будет посвящен проблемам, связанным с управлением риском ЛВС. Элементы, которые являются общими для большинства организаций при управлении риском, будут рассмотрены в терминах уникальных свойств ЛВС, которые могут потребовать специального рассмотрения, которое приведет к отличию управления риском для ЛВС от управления риском для многопользовательской ЭВМ  или приложения на ней. При представлении этой информации, будет представлена простая методология управления риском, которая может рассматриваться,  как кандидат среди различных методологий и методов, доступных в настоящее время.
Задачей читателя является определение соответствующего уровня защиты, требуемой для его ЛВС. Это осуществляется посредством управления риском. [KATZ92] определяет управление риском как процесс:
  •  оценки возможных потерь из-за использования или зависимости от технологии автоматизированной информационной системы,
  •  анализа потенциальных угроз и уязвимых мест системы, которые влияют на оценки возможных потерь, и
  •  выбора оптимальных по цене мер и средств защиты, которые сокращают риск до приемлемого уровня.
Имеется большое количество методологий управления риском, которые может использовать организация. Однако все они должны включать процесс, описанный выше. 3.1. Текущие подходы Одним из наиболее важных соображений при выборе методологии или техники является то, что результаты, полученные из оценки риска, должны быть полезны при обеспечении защиты ЛВС. Если методология очень сложна при ее использовании, если она требует очень точных исходных данных , или если ее результаты слишком сложны для того, чтобы сделать вывод, каким является  реальный риск при использовании ЛВС , то эта методология не будет полезна и не поможет создать эффективную защиту ЛВС. С другой стороны, если методология не позволяет добиться приемлемой точности при определении значений таких переменных, как потери, вероятности и стоимости, полученные результаты могут оказаться слишком простыми и не отражать истинного риска использования ЛВС. Ответственные за безопасность в организации должны использовать такой подход для оценки риска, который бы обеспечивал применение методики, являющейся понятной, легко используемой, и приводящей к результатам, которые помогают организации эффективно защищать ее ЛВС.
В 1979, NIST издал FIPS 65 [FIPS65], который описал количественный метод для выполнения анализа риска. Этот документ был выпущен как рекомендация, а не как стандарт. Поэтому использование FIPS 65 не является обязательным при выполнении анализа риска. [KATZ92] указывает на то, что он в основном предназначался для проведения анализа риска в больших центрах обработки данных. [FIPS65] описывает, как можно получить оценку риска (то есть ожидаемые ежегодные потери )  для каждого файла данных приложений, оценив : (1) частоту возникновения вредного воздействия (то есть разрушения, модификации, раскрытия или недоступности файла данных) и (2) последствия (в долларах), которые могут возникнуть в результате каждого из воздействий [KATZ92]. [KATZ92] объясняет, что "признавая отсутствие эмпирических данных относительно частоты возникновения воздействий и связанных с ними последствий, FIPS 65 предложил  использовать 'подход с применением порядка величины' для аппроксимации этих значений. То, что эта концепция была не понята людьми, использовавшими это метод, иллюстрируется многочисленными попытками получить слишком точные значения для  исходных данных  FIPS 65 и, как следствие, попытками интерпретировать результаты как имеющие большую точность, чем есть на самом деле." FIPS 65 может использоваться для оценки риска ЛВС; однако организации могут выбрать другие методологии и методы, если организация находит, что они будут более уместными и эффективными.
Имеется ряд автоматизированных средств анализа риска, которые были специально разработаны для анализа  среды ЛВС. [GILB89] указывает на большое количество преимуществ от использования автоматизированных средств анализа риска. Однако возникает ряд проблем  при использовании автоматизированных инструментов анализа риска. Имеется большое количество методов  для вычисления риска. В то время как большинство из этих методов зависят от значений потерь и значений  вероятностей, представление значений  этих переменных, вычисления, производимые с этими переменными, и способ  интерпретации значения риска, не всегда доступны пользователю. Этот недостаток усиливается из-за того, что в настоящее время не имеется стандартного метода или согласованного подхода для выполнения анализа риска. В то время как для анализа риска существует вариант  стандартной схемы его проведения [KATZ92], который дает разработчикам программ  некоторые рекомендации по разработке этих инструментов, нет согласия в отношении  методов представления переменных, необходимых для выполнения анализа риска, и в отношении методов для вычисления риска на основе  этих переменных. Из-за отсутствия  согласия среди специалистов по анализу риска, вкупе с специфичностью данных инструментов, определение эффективности конкретного метода может быть проблематичным. С другой стороны, если методология, используемая средством, понятна и считается пользователем приемлемой, то средство может оказаться вполне адекватным. Основной вопрос при определении того, будет ли инструмент эффективен для специфической окружающей среды, должен звучать так: " Что измеряет данное средство  анализа риска, и полезны ли для обеспечения требуемой защиты ЛВС  результаты, полученные при помощи этого  средства?" [GILB89] обсуждает использование автоматизированных средств анализа риска, и указывает критерии, которые могут использоваться в  процессе выбора  этих автоматизированных средств.
Другой подход при выполнении анализа риска состоит в разработке базовых  наборов средств и мер защиты, необходимых для заранее определенных стандартных уровней риска. Стандартные уровни риска могут быть основаны на ценности ресурсов как таковых (например, данные считаются критичными из-за политики организации или федерального закона), на последствиях, которые могут последовать после потери ценности (например, организация не сможет выполнить задачу) или на других факторах. Это позволяет владельцам данных и ответственным за обеспечение безопасности ЛВС определять уровень риска для определенных ценностей,  следовать рекомендациям в отношении полученного уровня риска и внедрять меры защиты, которые   считаются адекватными. Этот подход может быть полезен для организации из-за реализации  согласованной защиты для конкретных типов ценностей. Этот подход был реализован в [DOE89], [HHS91], [NASA90]. Выгода этого подхода заключается в том, что пользователя не только обеспечивают методологией анализа риска, но также информацией, позволяющей понимать политику безопасности организации, основанную на базовых наборах средств и мер защиты. В организациях, где ответственность за безопасность несет кто-либо, кто не является специалистом по защите, этот подход может дать достаточно информации, чтобы обеспечить действенную защиту.
Доступны другие методологии и подходы. Некоторые требуют ручной обработки; другие реализованы программно. Какой бы метод анализа риска не был выбран организацией, он должен оказывать  эффективную помощь при реализации надежной защиты ЛВС и при сокращении риска  в ЛВС. 3.2. Участники Защита ЛВС должна учитывать интересы и потребности организации в целом. Эта цель может быть достигнута только тогда, когда в решении задачи участвуют  представители соответствующих отделов организации. Как минимум, в организации защиты  должны принимать участие:
  • Администраторы ЛВС несут ответственность за функционирование ЛВС. Администраторы ЛВС могут обеспечить группу оценку риска информацией о корректных параметрах конфигурации ЛВС, включая аппаратные средства ЭВМ, программное обеспечение, данные, и распределение функций ЛВС по ее компонентам. Администраторы ЛВС могут также указать непосредственные воздействия, которые могут произойти, если угроза  будет реализована.
  • Руководство организацией отвечает за поддержку политики безопасности ЛВС, обеспечивая финансирование требуемых служб безопасности и разрабатывая руководящие документы,  гарантирующие достижение целей политики безопасности. Руководство организацией отвечает за правильную оценку долгосрочных последствий для организации реализации угрозы .
  • Сотрудники службы безопасности отвечают за то, что политики  безопасности организации  разработаны  и  их придерживаются.
  • Владельцы данных и приложений отвечают за гарантии того, что их данные и приложения адекватно защищены и доступны уполномоченным пользователям.
  • Пользователи ЛВС отвечают за предоставление точной информации относительно  используемых ими приложений, данных и ресурсов ЛВС.
Вышеупомянутый список включает тех лиц, которые участвуют в анализе риска для большинства  компьютерных систем и приложений (за исключением администраторов ЛВС, если не имеется никакой сети). Специфика формирования группы оценки риска ЛВС заключается в том , что  каждая группа, указанная выше, может включать не одного человека, а такое их число, которое позволяло бы  учесть при анализе деятельность всех отделов организации, обслуживаемых ЛВС,  все приложения, которое работают в ЛВС, и все разнообразные требования и указания, регламентирующие деятельность организации. Также должны быть учтены требования "владельца ЛВС" помимо  учета потребностей  всех владельцев данных и приложений.
Конечная цель эффективной полной защиты ЛВС не может быть достигнута, если с самого начала в  этой группе не будет иметься сильный лидер. Например, организации, в которых отсутствует  сильное централизованное управление ЛВС, могут столкнуться с трудностями при оценке потребностей в защите иерархическим способом, так как каждый местный администратор или  владелец приложения будет рассматривать свои потребности как приоритетные по отношению к потребностям других администраторов  и владельцев приложений, независимо от того, что показывают результаты анализа риска .
Первоначально, те люди в организации, которые отвечают за выполнение анализа риска, должны сделать некоторые предположения относительно предполагаемой глубины рассмотрения и границ анализа риска. На основе этой информации могут быть определены необходимые участники процесса анализа риска. 3.3. Элементы управления риском Использование ЛВС связано с риском. Термин "управление риском" обычно используется для  обозначения процесса определения риска, применения мер и средств защиты для сокращения риска, и определения после этого, приемлем ли остаточный риск . Управление риском преследует две цели: измерение риска (оценка риска) и выбор соответствующих мер и средств защиты, сокращающих риск до приемлемого уровня (уменьшение риска). Проблемы, которые должны быть решены при оценке защищенности ЛВС, включают:
1. Ценности - Что должно быть защищено?
2. Угрозы - От чего необходимо защищать ценности и какова вероятность того, что угроза реализуется?
3. Воздействия - Каковы будут непосредственные разрушения после реализации угрозы  (например, раскрытие информации, модификация данных)?
4. Последствия - Каковы будут  долгосрочные результаты  реализации  угрозы (например, ущерб репутации организации, потеря бизнеса)?
5. Меры защиты - Какие  эффективные меры защиты (службы безопасности и механизмы) требуются для защиты ценностей?
6. Риск - После реализации мер защиты приемлем ли остаточный риск?
Цель оценки риска состоит в том, чтобы определить риск для  ЛВС. Процесс оценки риска проводится в два шага. На первом шаге определяют границы ЛВС  для анализа,   требуемую степень детализации описания ЛВС при оценке  и методологию, которая будет использоваться. На втором шаге проводится анализ риска. Анализ риска может быть разбит на идентификацию ценностей, угроз и уязвимых мест, оценку вероятностей, и измерение риска.
Цель минимизации риска состоит в том, чтобы применить эффективные меры защиты таким образом, чтобы остаточный риск в ЛВС стал приемлем. Минимизация риска состоит из трех частей: определения тех областей, где риск является недопустимо большим; выбора наиболее эффективных  средств защиты;  оценивания мер защиты и  определения , приемлем ли остаточный риск в ЛВС.
Организации могут выбирать различные методологии управления риском. При этом организация должна выбрать подход, наиболее действенный именно для нее. Методология, обсуждаемая здесь, состоит из семи процессов (см. рис. 3.1).
Рис. 3.1 - Процесс управления риском
Оценка риска
1. Определение степени детализации, границ анализа и методологии.
2. Идентификация  и оценка ценностей.
3. Идентификация угроз и определение вероятности.
4. Измерение риска.
Уменьшение риска
5. Выбор соответствующих средств защиты.
6. Внедрение и испытания средств защиты.
7. Проверка остаточного риска. 3.4. Оценка риска

3.4.1. Этап 1 - Определение степени детализации, границ  и методологии Этот процесс определяет направление, в котором будут прилагаться усилия при управлении риском. Он определяет, что из ЛВС (граница) и с какой детальностью (степень детализации) должно рассматриваться в процессе управления риском. Граница будет определять те части ЛВС, которые будут рассматриваться. Граница может включать ЛВС в целом или части ЛВС, такие, как функции коммуникаций данных, функции сервера, приложения, и т.д.. Факторами, которые будут определять положение границы при анализе, могут быть границы владения  ЛВС или управления ею. Включение в анализ  части ЛВС, управляемой из другого места, может привести к необходимости совместного анализа, который может дать неточные результаты. Эта проблема подчеркивает необходимость сотрудничества между организациями, совместно владеющими или управляющими частями ЛВС, а также приложениями или информацией, обрабатываемой в ней.
Также должна быть определена степень детализации описания ЛВС при управлении риском. Степень детализации  можно представлять себе как  сложность созданной логической модели всей ЛВС или ее части, отражающую, в рамках заданной границы, глубину процесса управления риском. Степень детализации будет отличаться для разных областей ЛВС (в пределах заданной границы) и, как следствие, в ходе процесса управления риском будут использоваться их описания различной детальности. Например, некоторые области могут рассматриваться в общем, или менее детально, в то время как другие области могут быть рассмотрены глубоко и очень детально. Для небольших ЛВС граница может располагаться таким образом, что будет анализироваться вся ЛВС, и в таком случае нужно определить согласованную степень детализации для всех частей ЛВС. Для больших ЛВС организация может принять решение учитывать при анализе только  те области, которыми она управляет, и определить степень детализации таким образом,  чтобы учесть все области внутри границы. Однако в любом случае может потребоваться  детальное описание процесса передачи данных, соединений с внешними сетями, и ряда приложений. Кроме того, на степень детализации могут повлиять изменения в конфигурации ЛВС, появление новых внешних связей, модернизация или обновление системных или прикладных программ в ЛВС.
Соответствующая методология управления риском для ЛВС может быть определена до определения границы и степени детализации. Если методология уже была определена, то может оказаться полезным перепроверить выбранную методологию с точки зрения соответствия заданной  границе и степени детализации. Если же методология не выбрана, то граница и степень детализации  могут оказаться полезными в отборе методологии, которая производит наиболее эффективные результаты.

3.4.2. Этап 2 - Идентификация и оценка ценностей В ходе оценки ценностей выявляются и назначаются стоимости ценностям ЛВС. Все части ЛВС имеют стоимость, хотя некоторые ценности определенно более ценны, чем другие. Этот шаг дает первый признак тех областей, на которые нужно обратить особое внимание. Для ЛВС, в которых обрабатывается большое количество информации, которая не может быть разумно проанализирована, может быть сделан начальный отбор ценностей. Определение и оценка ценностей может позволить организации первоначально разделить области на те, которые могут быть опущены на  те, которые должны рассматриваться как высокоприоритетные.
Различные методы могут использоваться, чтобы идентифицировать и оценить ценности. Методология риска, которую выбирает организация, может обеспечить руководство рекомендациями по выделению ценностей и должна обеспечить его методикой оценки ценностей. Вообще ценности могут быть оценены на основании воздействий и последствий для организации. Оценка может включать не только стоимость замены ценности, но также последствия для организации раскрытия, искажения, разрушения или порчи ценности.
Так как стоимость ценности должна быть основана не только на стоимости замены, оценивание ценности по большей части - субъективный процесс. Однако, если оценка ценности выполняется с учетом конечной цели процесса, то есть определения ценностей в терминах иерархии важности или критичности, относительное сопоставление ценностей становится более важным, чем назначение  им "правильной" стоимости.
Методология оценки риска должна определить, в каком виде  представляются стоимости ценностей. Чисто количественные методологии типа FIPS 65 могут использовать долларовые стоимости. Однако необходимость назначить долларовую стоимость некоторым из последствий, которые могут происходить в современных вычислительных средах, может оказаться достаточным основанием для формирования мнения, что управление риском является глупостью.
Большое количество методологий оценки риска, используемых в наше время, требует оценки ценности в более качественных терминах. В то время как  этот тип оценки может рассматриваться как более субъективный, чем количественный подход, если шкала, используемая для  оценки ценностей,  используется согласованно в течение всего процесса управления риском, полученные результаты должны быть полезны. Рисунок 3.2 показывает один из самых простых методов оценки ценностей.
В ходе обсуждения процесса управления риском читателю будут представлены простая методика оценки ценностей (как показано на рис 3.2), определение меры риска, оценка стоимости средств защиты, и определение минимизации риска . Эта методика проста, но все же имеет силу методики; она используется здесь, чтобы показать взаимосвязи между процессами, входящими в управление риском. Методика не очень точна и может  не подходить для тех вычислительных сред, где затраты на замену, критичность информации и стоимости последствий имеют большой разброс.
рис. 3.2 - Простая Оценка Ценности
Стоимость ценности может быть представлена в терминах потенциальных потерь. Эти потери могут быть основаны на стоимости восстановления, потерях при непосредственном воздействии и последствий. Одна из самых простых методик оценки потерь для ценности состоит в использовании качественного ранжирования на высокие, средние и низкие потери. Назначение чисел  этим уровням (3 = высокие, 2 = средние, и 1 = низкие) может помочь в процессе измерения риска.
Одним из косвенных результатов этого процесса является то, что создается детальная конфигурация ЛВС и функциональная схема ее использования. Эта конфигурация должна описывать подключенные аппаратные средства ЭВМ, главные используемые приложения, важную информацию, обрабатываемую в ЛВС, а также то, как  эта информация передается через ЛВС. Степень знания конфигурации ЛВС будет зависеть от использовавшихся границы и степени детализации. Рис. 3.3 показывает на примере некоторые из областей, которые должны быть включены.
Рис 3.3 - Определение конфигурации ЛВС
Конфигурация Аппаратных средств - включает серверы, автоматизированные рабочие места, ПК, периферийные устройства, соединения с глобальными сетями, схему кабельной системы, соединения с  мостами или шлюзами и т.д..
Конфигурация Программного обеспечения - включает операционные системы серверов, автоматизированных рабочих мест и операционные системы ПК, операционную систему ЛВС, главное прикладное программное обеспечение, инструментальное программное обеспечение, средства управления ЛВС, и программное обеспечение, находящееся в процессе разработки. Она должна также включать местоположение программного обеспечения в ЛВС и указание мест, откуда к нему обычно осуществляется доступ.
Данные - включает  разделение данных на ряд типов(которое привязано к специфике задач: решаемых с помощью ЛВС), обрабатываемых и передаваемых через ЛВС, а  также  типы пользователей,  получающих доступ к данным. Важно  указать, откуда к данным обращаются, и где они хранятся и обрабатываются в ЛВС. Должно также быть уделено внимание критичности данных.
После того, как описание конфигурации ЛВС закончено и ценности определены и оценены, организация должна получить вполне адекватное  представление о том, из чего состоит ЛВС и какие области ЛВС должны защищаться.

3.4.3. Этап 3 - Идентификация угроз и определение их вероятности Результатом этого процесса должно быть явное указание враждебных действий, которые могли бы повредить ЛВС, вероятности того, что эти действия могут произойти, и уязвимые места ЛВС, которые могут использоваться для реализации этих  враждебных действий. Чтобы достигнуть этого результата, должны быть выявлены угрозы и уязвимые места, и определены вероятности того, что эти угрозы могут реализоваться.
Существует много информации относительно различных угроз и уязвимых мест. Разделы Литература и Литература для дальнейшего чтения этого документа обеспечивают некоторую информацию относительно угроз ЛВС и уязвимых мест в ней. Некоторые методологии управления риском также содержат информацию относительно потенциальных угроз и уязвимых мест. Опыт пользователей и опыт по управлению ЛВС также позволяет  выявить угрозы и уязвимые места.
Список угроз, которые будут рассматриваться, зависит от установленных границ анализа риска и степени детализации описания ЛВС. Концептуальный анализ может указать на абстрактные угрозы и уязвимые места; более детальный анализ может связать угрозу с конкретной компонентой. Например, высокоуровневый анализ может установить, что потеря конфиденциальности данных посредством раскрытия информации в ЛВС приводит к слишком большому риску.  Детальный анализ ЛВС может установить, что раскрытие данных о сотрудниках при перехвате их при передаче  по ЛВС приводит к слишком большому риску. Более чем вероятно, что абстрактность угроз, выявленных в результате концептуального анализа, в конечном счете приведет к тому, что и рекомендации относительно средств защиты тоже будут абстрактными. Это приемлемо, если проводится общая оценка риска. Более детальная оценка риска даст рекомендации относительно средства защиты, которое должно уменьшить конкретный риск, такой как раскрытие данных о сотрудниках.
Угрозы и уязвимые места, обсужденные в разделе 2, могут использоваться как отправная точка, наряду с другими источниками, там где это имеет смысл. Новые угрозы и уязвимые места должны учитываться, когда они обнаруживаются. Любая ценность в ЛВС, которая была определена как достаточно важная (то есть, не была отфильтрована в процессе отбора) должна быть исследована, чтобы можно было выявить те угрозы, которые могут потенциально повредить ей. Для более детальной оценки особое внимание должно быть уделено детализации путей, с помощью которых эти угрозы могли бы происходить. Например, методами нападения, которые приводят к неавторизованному доступу, могут быть воспроизведение сеанса регистрации, вскрытие пароля, подключение неправомочного оборудования к ЛВС, и т.д.. Эти специфические особенности обеспечивают большее количество информации при определении уязвимых мест ЛВС и будут обеспечивать большее количество информации для предложения средств защиты.
Этот процесс может раскрыть некоторые уязвимые места, которые могут быть немедленно исправлены путем улучшения административного управления ЛВС  и применения организационных мер. Эти организационные меры будут обычно сокращать риск угроз до некоторой степени , пока не будут  запланированы и осуществлены  более полные  меры и средства защиты. Например, увеличение длины и изменение алфавита символов пароля для аутентификации может быть одним из путей сокращения уязвимого места - угадывания паролей. Использование более надежных паролей - мера, которая может быть быстро осуществлена для увеличения безопасности ЛВС. Одновременно может осуществляться планирование и  внедрение более продвинутого механизма аутентификации.
Рис. 3.4 Назначение Меры Вероятности
Вероятность появления угрозы может быть нормализована как значение, которое меняется от  1 до 3. 1 будет указывать низкую вероятность,  2 будет указывать умеренную вероятность и 3 будет указывать высокую вероятность.
Существующие средства и меры защиты в ЛВС должны быть проанализированы, чтобы можно было определить, обеспечивают ли они в настоящее время адекватную защиту. Эти средства и меры, могут быть техническими, процедурными, и т.д.. Если средство защиты не обеспечивает адекватную защиту, это может рассматриваться как уязвимое место. Например, операционная система ЛВС может обеспечить управление доступом на уровне каталога, а не на  уровне файла. Для некоторых пользователей угроза компрометации информации может быть такой большой, что требовать защиты на уровне отдельного файла. В  этом примере недостаток степени точности при управлении доступом может рассматриваться  как уязвимое место.
После того, как определенные угрозы и связанные с ними уязвимые места идентифицированы,  с каждой  парой угроза/уязвимое место должна быть связана  вероятность(то есть Какова вероятность того, что угроза будет реализована при условии, что используется данное уязвимое место?). Методология риска, выбранная организацией, должна обеспечить возможность измерения вероятности. Наряду с оценкой ценностей, назначение меры вероятности может также быть субъективным процессом. Данные по угрозам для традиционных угроз (главным образом физических угроз) существуют и могут помочь при определении вероятности. Однако опыт относительно технических аспектов ЛВС и знание операционных аспектов организации может оказаться более ценным при назначении вероятности. Рис. 3.4 определяет простую меру вероятности. Эта мера вероятности согласована  с мерой оценки ценности, определенной на Рис. 3.1. Хотя меры для оценка ценности и вероятности, показанные в этом примере, кажутся одинаково взвешенными для каждой пары угроза/уязвимое место,   в течение процесса измерения риска следует постоянно помнить, что именно за пользователем остается последнее слово при назначении мер оценки и вероятности .

Предыдущая часть статьи     Продолжение статьи