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

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

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

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

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

Раздел 1 - Введение - в этом разделе обсуждаются свойства ЛВС и проблемы с защитой, являющиеся следствиями этих свойств.

Раздел 2 - Угрозы, уязвимые места, службы и механизмы - Этот раздел описывает угрозы, соответствующие уязвимые места и возможные службы и механизмы защиты, которые могут быть использованы для защиты ЛВС от этих угроз.

Раздел 3 - Управление риском - Этот раздел описывает процесс управления риском и как он может быть использован для планирования и внедрения соответствующей защиты ЛВС.

Институт Инженеров Электриков и Электроников (IEEE) определяет ЛВС как “ систему передачи данных, обеспечивающую некоторому числу независимых устройств возможность прямого взаимодействия в ограниченном географическом пространстве посредством физического канала взаимодействия ограниченной производительности”[MART89]. Типичная ЛВС принадлежит только одной организации, которая ее использует и управляет ею . Обычная ЛВС с помощью сетевой ОС объединяет серверы, рабочие станции, принтеры и стриммеры, позволяя пользователям совместно использовать ресурсы и функциональные возможности ЛВС.

В соответствии с [BARK89] типы приложений, обеспечиваемые ЛВС, включают распределенное хранение файлов, удаленные вычисления и обмен сообщениями.

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

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

Удаленными вычислениями называют запуск приложения или приложений на удаленных компонентах. Удаленные вычисления позволяют пользователям (1) удаленно подключаться к другим компонентам ЛВС, (2) удаленно выполнять приложение, находящееся на другой компоненте или (3) удаленно запускать приложение на одной или более компонент, в то же время создавая для пользователя представление, что они выполняются локально. Удаленное подключение позволяет пользователям устанавливать сеанс с удаленной ЭВМ (такой, как многопользовательская ЭВМ) так, как будто пользователь непосредственно подключен к удаленной ЭВМ. Возможность запуска приложений на одной или более компонент позволяет пользователю использовать всю вычислительную мощь ЛВС.

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

Преимущества использования ЛВС были кратко обсуждены в предыдущем разделе. Эти преимущества, однако, сопряжены с дополнительным риском, который приводит к проблемам безопасности ЛВС.

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

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

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

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

Прочие проблемы безопасности ЛВС включают: (1) неадекватную политику управления и безопасности ЛВС, (2) отсутствие обучения особенностям использования ЛВС и защиты, (3) неадекватные механизмы защиты для рабочих станций и (4) неадекватную защиту в ходе передачи информации.

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

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

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

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

Должны быть поставлены следующие цели при разработке эффективной защиты ЛВС:

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

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

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

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

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

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

Идентификация угроз предполагает рассмотрение воздействий и последствий реализации угроз. Воздействие угрозы, которое обычно включает в себя проблемы, возникшие непосредственно после реализации угрозы, приводит к раскрытию, модификации, разрушению или отказу в обслуживании. Более значительные долговременные последствия реализации угрозы приводят к потере бизнеса, нарушению тайны, гражданских прав, потере адекватности данных, потере человеческой жизни или иным долговременным эффектам. Последствия угроз будут обсуждаться в разделе 3, Управление риском. Подход, описываемый здесь, состоит в классификации типов воздействий, которые могут иметь место в ЛВС, так чтобы специфические технические угрозы могли быть сгруппированы по своим воздействиям и изучены некоторым образом. Например, такие технические угрозы, реализация которых влечет воздействие “Компрометация трафика ЛВС”, могут быть отделены от тех угроз, которые влекут воздействие “Нарушение функционирования ЛВС”. Следует понимать, что реализация многих угроз приводит к более чем одному воздствию, однако в рамках этого обсуждения каждая угроза будет рассматриваться в связи только с одним воздействием. Воздействия, которые будут использоваться для классификации и обсуждения угроз среде ЛВС:

Неавторизованный доступ к ЛВС - происходит в результате получения неавторизованным человеком доступа к ЛВС.

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

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

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

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

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

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

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

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

Так как ЛВС используются повсюду в организациях или отделах, некоторые из хранящихся или обрабатываемых данных в ЛВС могут требовать некоторого уровня конфиденциальности. Раскрытие данных или программного обеспечения ЛВС происходит, когда к данным или программному обеспечению осуществляется доступ, при котором они читаются и, возможно, разглашаются некоторому лицу, которое не имеет доступа к данным. Это может производиться кем-либо путем получения доступа к информации, которая не зашифрована, или путем просмотра экрана монитора или распечаток информации. Компрометация данных ЛВС может происходить при использовании следующих типов уязвимых мест:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В большинстве ЛВС используется механизм идентификации и аутентификации на основе схемы идентификатор пользователя/пароль. В [BNOV91] констатируется, что “парольные системы могут быть эффективны, если управляются должным образом [FIPS112], но это бывает редко. Аутентификация, которая полагается исключительно на пароли, часто не может обеспечить адекватную защиту для АС по ряду причин. Пользователи имеют тенденцию создавать пароли, которые являются легкими для запоминания и, следовательно, легкими для угадывания. С другой стороны, если пользователи должны использовать пароли, сгенерированные из случайных символов, которые трудно угадывать, то пользователям также трудно их запомнить . Это вынуждает пользователя записывать пароль куда-либо, и наиболее вероятно, в месте, легко доступном при работе”. Исследовательские работы , такие как [KLEIN] , детализируют степень простоты, с которой могут угадываться пароли. Надлежащий выбор пароля (компромисс между легкостью для запоминания пользователем и трудностью для угадывания другим человеком) всегда был проблемой. Генераторы паролей, которые создают пароли, состоящие из произносимых слогов, позволяют создавать более запоминающиеся пароли, чем те , что создаются генераторами, которые производят просто строки из случайных символов. [FIPS180] определяет алгоритм, который может использоваться для создания случайных произносимых паролей. Программы проверки паролей - это программы, которые позволяют пользователю определить, являются ли новые пароли легкими для угадывания и поэтому недопустимыми. Механизмы с использованием только паролей, особенно те, которые передают по ЛВС пароль в открытом виде(в незашифрованной форме) уязвимы с точки зрения наблюдения и перехвата. Это может стать серьезной проблемой, если ЛВС имеет неконтролируемые связи с внешними сетями. Организации, решившие связать свои ЛВС с внешними сетями, особенно с Интернетом, должны изучить документ [BJUL93] перед тем, как сделать это. Если после рассмотрения всех вариантов аутентификации, политика ЛВС определяет, что системы аутентификации только на основе паролей приемлемы, то самой важной мерой защиты становится надлежащее управление созданием паролей, их хранением, слежением за истечением срока их использования, и удалением. Документ [FIPS 112] является руководством по управлению паролями. [NCSC85] обеспечивает дополнительные рекомендации, которые также могут быть учтены.

Из-за уязвимых мест, которые все еще существуют при использовании механизмов на основе только паролей, могут использоваться более надежные механизмы. [BNOV91] обсуждает новые разработки, которые были сделаны в области систем аутентификации, основанных на смарт-картах и использовании биометрии. Механизм, основанный на интеллектуальных картах, требует, чтобы пользователь владел смарт-картой и дополнительно может потребовать, чтобы пользователь знал персональный код идентификации (ПКИ-PIN) или пароль. Смарт-карта реализует аутентификацию с помощью схемы запрос/ответ, использующей указанные выше параметры в реальном масштабе времени. Использование параметров в реальном масштабе времени помогает предотвратить получение злоумышленником неавторизованного доступа путем воспроизведения сеанса регистрации пользователя. Эти устройства могут также шифровать сеанс аутентификации, предотвращая компрометацию информации аутентификации с помощью наблюдения и перехвата.

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

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

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

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

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

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

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

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

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

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

Механизмы привилегий позволяют авторизованным пользователям игнорировать ограничения на доступ, или другими словами некоторым способом легально обходить управление доступом, чтобы выполнить какую-либо функцию, получить доступ к файлу, и т.д.. Механизм привилегий должен включать концепцию минимальных привилегий. [ROBA91] определяет минимальные привилегии как “принцип, согласно которому каждому субъекту в системе предоставляется наиболее ограниченное множество привилегий, которые необходимы для выполнения задачи, которую должен решить пользователь.” Например, принцип минимальных привилегий должен применяться при выполнении функции резервного копирования. Пользователь, кто авторизован выполнять функцию резервного копирования, должен иметь доступ по чтению ко всем файлам, чтобы копировать их на резервные носители информации. (Однако пользователю нельзя давать доступ по чтению ко всем файлам через механизм управления доступом). Пользователю предоставляют “привилегию” обхода ограничения по чтению (предписанного механизмом управления доступом) для всех файлов, чтобы он мог выполнить функцию резервного копирования. Чем более детальные привилегии могут быть предоставлены, тем больше будет гарантий, что пользователю не даны чрезмерные привилегии для выполнения им авторизованной функции. Например, пользователю, который должен выполнять функцию резервного копирования, не нужна привилегия обхода ограниченя на запись в файлы, но механизмы привилегий, которые не обеспечивают такую точность, могут привести к предоставлению ему такой привилегии. Типы механизмов защиты, которые могли бы быть использованы для обеспечения службы управления доступом, приведены в списке ниже:

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

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

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

Криптография может быть разделена на использующую секретные ключи или использующую открытые ключи. Криптография секретных ключей основана на использовании единственного криптографического ключа, известного двум сторонам. Один и тот же ключ используется для шифрования и расшифровки данных. Этот ключ хранится в тайне обоими сторонами. Если необходимо шифрование критической, но несекретной информации (кроме информации, соответствующей поправке Уорнера), требуется использовать Стандарт Шифрования Данных (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. Типы механизмов безопасности, которые могли бы быть реализованы, чтобы обеспечить службу конфиденциальности сообщений и данных, приведены в списке ниже.

Механизмы

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

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

Использование контрольных сумм обеспечивает возможность обнаружения модификации. Код Аутентификации Сообщения (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.4 Целостность Данных и Сообщений для описания и использования электронных подписей. Механизм защиты, который мог бы быть реализован для обеспечения службы контроля участников взаимодействия, приведен ниже.

Механизм

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

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

Механизмы

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

Задачей читателя является определение соответствующего уровня защиты, требуемой для его ЛВС. Это осуществляется посредством управления риском. [KATZ92] определяет управление риском как процесс:

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

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

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

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

Защита ЛВС должна учитывать интересы и потребности организации в целом. Эта цель может быть достигнута только тогда, когда в решении задачи участвуют представители соответствующих отделов организации. Как минимум, в организации защиты должны принимать участие:

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

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

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

Использование ЛВС связано с риском. Термин “управление риском” обычно используется для обозначения процесса определения риска, применения мер и средств защиты для сокращения риска, и определения после этого, приемлем ли остаточный риск . Управление риском преследует две цели: измерение риска (оценка риска) и выбор соответствующих мер и средств защиты, сокращающих риск до приемлемого уровня (уменьшение риска). Проблемы, которые должны быть решены при оценке защищенности ЛВС, включают:

1. Ценности - Что должно быть защищено?

2. Угрозы - От чего необходимо защищать ценности и какова вероятность того, что угроза реализуется?

3. Воздействия - Каковы будут непосредственные разрушения после реализации угрозы (например, раскрытие информации, модификация данных)?

4. Последствия - Каковы будут долгосрочные результаты реализации угрозы (например, ущерб репутации организации, потеря бизнеса)?

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

6. Риск - После реализации мер защиты приемлем ли остаточный риск?

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

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

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

Рис. 3.1 - Процесс управления риском

Оценка риска

1. Определение степени детализации, границ анализа и методологии.

2. Идентификация и оценка ценностей.

3. Идентификация угроз и определение вероятности.

4. Измерение риска.

Уменьшение риска

5. Выбор соответствующих средств защиты.

6. Внедрение и испытания средств защиты.

7. Проверка остаточного риска.

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

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

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

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

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

Так как стоимость ценности должна быть основана не только на стоимости замены, оценивание ценности по большей части - субъективный процесс. Однако, если оценка ценности выполняется с учетом конечной цели процесса, то есть определения ценностей в терминах иерархии важности или критичности, относительное сопоставление ценностей становится более важным, чем назначение им “правильной” стоимости.

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

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

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

рис. 3.2 - Простая Оценка Ценности

Стоимость ценности может быть представлена в терминах потенциальных потерь. Эти потери могут быть основаны на стоимости восстановления, потерях при непосредственном воздействии и последствий. Одна из самых простых методик оценки потерь для ценности состоит в использовании качественного ранжирования на высокие, средние и низкие потери. Назначение чисел этим уровням (3 = высокие, 2 = средние, и 1 = низкие) может помочь в процессе измерения риска.

Одним из косвенных результатов этого процесса является то, что создается детальная конфигурация ЛВС и функциональная схема ее использования. Эта конфигурация должна описывать подключенные аппаратные средства ЭВМ, главные используемые приложения, важную информацию, обрабатываемую в ЛВС, а также то, как эта информация передается через ЛВС. Степень знания конфигурации ЛВС будет зависеть от использовавшихся границы и степени детализации. Рис. 3.3 показывает на примере некоторые из областей, которые должны быть включены.

Рис 3.3 - Определение конфигурации ЛВС

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

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

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

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

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

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

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

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

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

Рис. 3.4 Назначение Меры Вероятности

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

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

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

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

Имеется большое количество способов измерения и представления риска. [KATZ92] уточняет, что в зависимости от специфической методологии или подхода, мера может быть определена в качественных терминах, количественных терминах, одномерных, многомерных, или некоторой их комбинации. Процесс измерения риска должен быть согласован с (и больше чем вероятно определен ) методологией оценки риска, используемой организацией. Количественные подходы часто связаны с измерением риска в терминах денежных потерь (например FIPS 65). Качественные подходы часто связаны с измерением риска в качественных терминах, заданных с помощью шкалы или ранжирования. Одномерные подходы рассматривают только ограниченные компоненты (например риск = величина потери * частота потери). Многомерные подходы рассматривают дополнительные компоненты в измерении риска, такие как надежность, безопасность, или производительность. Одним из наиболее важных аспектов меры риска является то, что представление должно быть понятным и логичным для тех, кто должен выбирать средства защиты и решать вопросы минимизации риска.

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

Рис. 3.5 - Одномерный Подход Вычисления Риска

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

Риск = вероятность появления угрозы (через определенное уязвимое место) * понесенная потеря

Стоимость потерь определяется как число в интервале от 1 до 3. Поэтому риск может быть рассчитан, как число в интервале от 1 до 9; значения риска 1 или 2 будут считаться низким риском, риск 3 или 4 будет умеренным риском, и риск 6 или 9 будет высоким риском.

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

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

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

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

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

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

После того, как необходимые службы защиты определены, рассматривают список механизмов защиты для каждой службы. Для каждой отбираемой службы защиты определяют механизмы - кандидаты, которые лучше всего обеспечили бы службу. При использовании отношений угроза/уязвимое место/риск, выработанных в предыдущих процессах, выбирают те механизмы, которые могли бы потенциально сократить или устранить уязвимое место и таким образом сократить риск угрозы. Во многих случаях отношению угроза/уязвимое место будет соответствовать более чем одного механизма - кандидата. Например, риск от уязвимого места - использования слабых паролей мог бы быть уменьшен использованием механизма генератора пароля, использованием механизма смарт-карт и т.д.. Выбор механизма - кандидата является субъективным процессом, который будет изменяться от одной реализации ЛВС к другой. Не каждый механизм, представленный в разделе 2, подходит для использования в каждой ЛВС. Для того, чтобы этот процесс был приносил пользу, представляется необходимым некоторая фильтрация механизмов, которую необходимо cделать в течение этого этапа.

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

Рис. 3.6 - Вычисление Меры Стоимости

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

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

Рис. 3.7 - Сравнение Риска и Стоимости

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

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

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

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

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

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

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

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

Политика безопасности ЛВС должна ясно определить и установить ответственность за защиту информации, которая обрабатывается, хранится и передается в ЛВС, и самой ЛВС. Основная ответственность может быть возложена на владельца данных, то есть, на менеджера отдела организации, который создает данные, обрабатывает их и т.д.. Дополнительная ответственность может быть, кроме того, возложена на пользователей и конечных пользователей, то есть на тех лиц внутри организации, которым предоставлен доступ к информации теми лицами, кто отвечает за нее в первую очередь. Администраторы ЛВС должны ясно определить роль отдельных лиц, ответственных за поддержание работоспособности ЛВС. Пример политики защиты ЛВС, приведенный ниже, определяет обязанности функциональных менеджеров (тех, на кого может быть возложена основная ответственность), пользователей (тех, на когоможет быть возложена дополнительная ответственность), администраторов ЛВС (кто отвечает за внедрение и поддержание работоспособности защиты ЛВС и ее самой), и местных администраторов (тех, кто отвечает за поддержание защиты в их части ЛВС). Местные администраторы обычно отвечают за один или группу серверов и автоматизированных рабочих мест в ЛВС. Эти обязанности были скомпилированы из [OLDE92], [COMM91], [WACK91], и [X9F292].

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

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

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

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

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

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

2. Администраторы ЛВС (АД) - служащие, кто участвуют в ежедневном управлении и поддержании работоспособности ЛВС XYZ. Они отвечают за обеспечение непрерывного функционирования ЛВС. Администраторы ЛВС отвечают за осуществление соответствующих мер защиты в ЛВС в соответствии с политикой безопасности ЛВС XYZ .

3. Местные Администраторы (МА) - служащие, которые являются ответственными за предоставление конечным пользователям доступа к необходимым ресурсам ЛВС, которые разамещены на серверах, входящих в их зону ответственности. Местные администраторы отвечают за обеспечение защиты своих серверов - в соответствии с политикой безопасности ЛВС XYZ.

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

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

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

ОП2. Чтобы предотвратить неавторизованный доступ к данным ЛВС, программному обеспечению, и другим ресурсам, находящимся на сервере ЛВС, все механизмы защиты сервера ЛВС должны находиться под монопольным управлением местного администратора и местного персонала Администраторов ЛВС.

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

ОП4. За все изменения(замены) программного обеспечения и создание резервных копий данных на серверах отвечают Администраторы ЛВС.

ОП5. Каждому пользователю должен быть назначен уникальный ИДЕНТИФИКАТОР ПОЛЬЗОВАТЕЛЯ и начальный пароль (или другая информация для идентификации и аутентификации), только после того, как закончено оформление надлежащей документации. Пользователи не должны совместно использовать назначенные им ИДЕНТИФИКАТОРЫ ПОЛЬЗОВАТЕЛЯ.

ОП6. Пользователи должны аутентифицироваться в ЛВС перед обращением к ресурсам ЛВС.

ОП7. ИДЕНТИФИКАТОР ПОЛЬЗОВАТЕЛЯ должен удаляться после продолжительного периода неиспользования.

ОП8. Использование аппаратных средств ЛВС типа мониторов / регистраторов трафика и маршрутизаторов должно быть авторизовано и проводиться под контролем Администраторов ЛВС.

ОП9. Акт о Компьютерной безопасности 1987 года (P.L. 100-235)устанавливает, что “ Каждое агентство должно обеспечить обязательное периодическое обучение в области компьютерной безопасности и правил работы на компьютере, и принимать зачеты по правильности работы на компьютере всех служащих, кто участвует в управлении, использовании, или функционировании каждой Федеральной компьютерной системы, которая находится в зоне ответственности этого агентства”.

ОП10. Отчеты о безопасности должны готовиться и рассматриваться ежедневно.

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

П1. Отвечают за понимание и соблюдение соответствующих Федеральных законов, политик и процедур министерства, политик и процедур XYZ и других применимых политик безопасности и связанных с ними последствий для ЛВС XYZ.

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

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

П2.2. Выбирает и использует хорошие пароли. Использует FIPS 112, Использование Паролей как руководство при выборе хороших паролей. Не записывает паролей, и не раскрывает их другим. Не использует совместно идентификаторы пользователей.

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

П4. Отвечает за уведомление местного администратора или члена руководства о нарушении защиты или обнаруженном отказе.

П5. Отвечает за неиспользование слабых мест АС.

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

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

П6. Отвечает за гарантию выполнения резервного копирования данных и программного обеспечения находящегося на жесктом диске их собственного автоматизированного рабочего места.

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

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

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

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

П11. Отвечает за знание и использование процедур по обеспечению непрерывной работы для сдерживания и восстановления при потенциальных инцидентах.

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

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

ФМ2. Отвечает за гарантию того, чтобы каждый пользователь получил, как минимум, копию политики безопасности и местного руководства (если таковые есть в наличии ) до внесения его в списки пользователей АС.

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

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

ФМ5. Отвечает за информирование местного администратора и администраторов ЛВС об изменениях в статусе любого служащего, который использует ЛВС XYZ. Это изменение статуса может включать переход из организации в организацию в одном ведомстве, переход из отдела в отдел, или окончание службы в XYZ.

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

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

ОУ1. Отвечают за корректное применение доступных механизмов защиты для осуществления местных политик безопасности.

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

ОУ3. Отвечает за защищенность среды ЛВС внутри организации и интерфейсов с глобальными сетями.

ОУ4. Отвечает за оперативное и эффективное улаживание происшествий с компьютерной безопасностью.

ОУ4.1. Уведомляет местных администраторов о проникновении злоумышленника в ЛВС , помогает другим местным администраторам улаживать происшествия с безопасностью.

ОУ4.2. Сотрудничает с местными администраторами при выявлении нарушителя и помогает им это сделать.

ОУ5. Отвечает за использование надежных и доступных средств аудирования для облегчения обнаружения нарушений безопасности.

ОУ6. Отвечает за проведение своевременных проверок системных журналов серверов ЛВС.

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

ОУ8. Отвечает за крайнюю осторожность и корректность при применении им своих экстраординарных полномочий и привилегий. Безопасность пользователей должна всегда стоять на первом месте.

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

ОУ10. Отвечает за своевременное создание резервных копий всех данных и программного обеспечения на серверах ЛВС.

ОУ11. Отвечает за выявление и рекомендацию пакетов программ для обнаружения и удаления злонамеренного программного обеспечения.

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

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

ОУ14. Отвечает за оказание помощи при определении источника злонамеренного программного обеспечения и зоны его распространения.

ОУ15. Отвечает за обеспечение помощи в удалении злонамеренного программного обеспечения.

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

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

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

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

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

МA4. Отвечает за сканирование сервера ЛВС антивирусным программным обеспечением через регулярные интервалы времени для гарантии того, что никакому вирусу не удалось разместиться на сервере ЛВС.

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

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

МA6.1. Уведомляет Администраторов ЛВС о проникновении в ЛВС , помогает другим местным администраторам улаживать нарушение безопасности.

МА6.2. Сотрудничает с другими местными администраторами и Администраторами ЛВС в поиске нарушителя и помогает им это сделать.

МA7. Отвечает за обеспечение помощи при выявлении источника злонамеренного программного обеспечения и зоны его распространения.

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

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

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

Для общих рекомендаций по защите ПК см. [STIE85]. Рекомендации по защите против злонамеренного программного обеспечения можно найти в [WACK89].

Инцидент с компьютерьной безопасностью - любой неблагоприятный случай, в ходе которого может оказаться под угрозой некоторый аспект компьютерьной безопасности: потеря конфиденциальности данных, потеря данных или целостности системы, разрушение или отказ в обслуживании. В среде ЛВС понятие инцидента с компьютерьной безопасностью может быть распространено на все области ЛВС (аппаратные средства ЭВМ, программное обеспечение, данные, передачу данных, и т.д.) включая саму ЛВС. Планы восстановления в среде ЛВС должны быть разработаны таким образом, чтобы любой инцидент с защитой ЛВС мог быть своевременно улажен, с наименьшим, насколько это возможно, воздействием на возможности организации по обработке и передаче данных. План восстановления должен описывать (1)действия по улаживанию инцидента, (2) действия по резервированию и (3) действия по восстановлению.

1. Цель действий по улаживанию инцидента состоит в том, чтобы уменьшить потенциально опасные последствия проблемы, связанной с безопасностью ЛВС. Это требует не только наличия возможности улаживать инциденты, но и ресурсов для предупреждения пользователей. Это требует сотрудничества со всеми пользователями для гарантий того, что об инцидентах будет сообщено и они будут улажены, а будущие инциденты - предотвращены [WACK91,5]. [WACK91] рекомендуется как руководство при разработке действий по улаживанию инцидента.

2. Планы действий по резервированию подготавливаются, чтобы гарантировать, что необходимые организации задачи (выявленные при анализе риска) могут быть корректно завершены при разрушении ЛВС и продолжены впоследствии, когда ЛВС будет восстановлена [NIST74,65].

3. Планы восстановления создаются, чтобы обеспечить плавное, быстрое восстановление среды ЛВС после перерыва в ее работе [NIST74,65]. Должен быть разработан и поддерживаться ряд инструкций, чтобы минимизировать время, требуемое для восстановления. Приоритет нужно отдавать тем приложениям, службам, и т.д., которые считаются критическими для функционирования организации. Процедуры действий по резервированию должны гарантировать, что эти критические службы и приложения доступны пользователям.

Акт о Компьютерной безопасности 1987 года (P.L. 100-235)устанавливает, что “ Каждое агентство должно обеспечить обязательное периодическое обучение в области компьютерной безопасности и правил работы на компьютере, и принимать зачеты по правильности работы на компьютере всех служащих, кто участвует в управлении, использовании, или функционировании каждой Федеральной компьютерной системы, которая находится в зоне ответственности этого агентства”.

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

Чтобы поддерживать безопасность в среде ЛВС, пользователи ЛВС должны получить обучение в определенных областях работы и использования ЛВС. Механизмы защиты, процедуры, и т.д. не могут быть действенными, если они используются неправильно. Нижн приведены списки требований к программам обучения для функционального руководства, администраторов ЛВС и пользователей. Целью обучения для функционального руководства является (1) понимание важности политики безопасности и (2) понимание того, как эта политика должна осуществляться в ЛВС для того, чтобы она была эффективной. Целью обучения для администраторов ЛВС является понимание, как обеспечивается защита ЛВС при ее повседневной работе. Также важно подчеркнуть необходимость эффективных действий по улаживанию инцидента. Целью обучения для пользователей являются (1) осознании роли пользователя в политике безопасности и обязанностей, возлагаемых на него в этой области, (2) обучении использованию служб и механизмов защиты для эффективного поддержания безопасности, и (3) понимании того, как использовать процедуры действий по улаживанию инцидента. Конкретно требования к курсам обучению обсуждаются ниже.

Функциональное руководство должно:

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

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

Администраторы ЛВС должны:

1. Понимать во всех аспектах, как работает ЛВС. Быть способны отличать нормальную работу системы от ненормальной работы системы.

2. Понимать роль администратора ЛВС в реализации политики безопасности ЛВС.

3. Понимать, как работают службы и механизмы безопасности. Быть способны распознать неправильное использование механизмов защиты пользователями.

4. Понимать, как надо эффективно использовать возможности по улаживанию инцидентов.

Пользователи ЛВС должны:

1. Понимать политику безопасности и обязанности пользователя, проистекающие из нее. Понимать, почему важно поддержание безопасности ЛВС.

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

3. Понимать, как использовать возможности по улаживанию инцидентов, занть, как сообщать об инциденте, и т.д..

4. Отличать нормальную работу автоматизированного рабочего места или ПК от неправильной работы.

[MART89] Martin, James, and K. K. Chapman, The Arben Group, Inc.; Local Area Networks, Architectures and Implementations, Prentice Hall, 1989.

[BARK89] Barkley, John F., and K. Olsen; Introduction to Heterogenous Computing Environments, NIST Special Publication 500-176, November, 1989.

[NCSC87] A Guide to Understanding Discretionary Access Control in Trusted Systems, NCSC-TG-003, Version 1, September 30, 1987

[NCSL90] National Computer Systems Laboratory (NCSL) Bulletin, Data Encryption Standard, June, 1990.

[SMID88] Smid, Miles, E. Barker, D. Balenson, and M. Haykin; Message Authentication Code (MAC) Validation System: Requirements and Procedures, NIST Special Publication 500-156, May, 1988.

[OLDE92] Oldehoeft, Arthur E.; Foundations of a Security Policy for Use of the National Research and Educational Network, NIST Interagency Report, NISTIR 4734, February 1992.

[COMM91] U.S. Department of Commerce Information Technology Management Handbook, Attachment 13-D: Malicious Software Policy and Guidelines, November 8, 1991.

[WACK89] Wack, John P., and L. Carnahan; Computer Viruses and Related Threats: A Management Guide, NIST Special Publication 500-166, August 1989.

[X9F292] Information Security Guideline for Financial Institutions, X9/TG-5, Accredited Committee X9F2, March 1992.

[BJUL93] National Computer Systems Laboratory (NCSL) Bulletin, Connecting to the Internet: Security Considerations, July 1993.

[BNOV91] National Computer Systems Laboratory (NCSL) Bulletin, Advanced Authentication Technology, November 1991.

[KLEIN] Daniel V. Klein, “Foiling the Cracker: A Survey of, and Improvements to, Password Security”, Software Engineering Institute. (This work was sponsored in part by the Department of Defense.)

[GILB89] Gilbert, Irene; Guide for Selecting Automated Risk Analysis Tools, NIST Special Publication 500-174, October, 1989.

[KATZ92] Katzke, Stuart W. ,Phd., “A Framework for Computer Security Risk Management”, NIST, October, 1992.

[NCSC85] Department of Defense Password Management Guideline, National Computer Security Center, April, 1985.

[NIST85] Federal Information Processing Standard (FIPS PUB) 112, Password Usage, May, 1985.

[ROBA91] Roback Edward, NIST Coordinator, Glossary of Computer Security Terminology, NISTIR 4659, September, 1991.

[TODD89] Todd, Mary Anne and Constance Guitian, Computer Security Training Guidelines, NIST Special Publication 500-172, November, 1989.

[STIE85] Steinauer, Dennis D.; Security of Personal Computer Systems: A Management Guide, NBS Special Publication 500-120, January, 1985.

[WACK91] Wack, John P.; Establishing a Computer Security Incident Response Capability (CSIRC), NIST Special Publication 800-3, November, 1991.

[NIST74] Federal Information Processing Standard (FIPS PUB) 31, Guidelines for Automatic Data Processing Physical Security and Risk Management, June, 1974.

[1] Berson, T.A, and Beth, T. (Eds.); Local Area Network Security Workshop LANSEC ‘89 Proceedings, Springer-Verlag, Berlin, 1989.

[2] Federal Information Processing Standard Publication (FIPS PUB) 83, Guideline on User Authentication Techniques for Computer Network Access Control, September, 1980.

[3] Gahan, Chris; LAN Security, the Business Threat from Within, BICC Data Networks Limited, November, 1990.

[4] Muftic, Sead; Security Mechanisms for Computer Networks, Ellis Horwood Limited, West Sussex, England, 1989.

[5] National Research Council; Computers At Risk: Safe Computing in the Information Age, National Academy Press, Washington, D.C., 1991.

[6] Schweitzer, James A.; Protecting Information on Local Area Networks, Butterworth Publishers, Stoneham, MA, 1988.