Способы защиты информации (работа 1)

НМИНИСТЕРСТВО СВЯЗИ И ИНФОРМАТИЗАЦИИ

РЕСПУБЛИКИ БЕЛАРУСЬ

Учреждение образования

"ВЫСШИЙ ГОСУДАРСТВЕННЫЙ КОЛЛЕДЖ СВЯЗИ"

КОНТРОЛЬНАЯ РАБОТА

по дисциплине: "Способы защиты информации"

Выполнил: студент

6 курса группы ТЭ262

Жук В.П..

Проверил: Киркоров С.И.

МИНСК 2005

ЗАДАНИЕ

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

    Разработайте политику безопасности.

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

    Обоснуйте экономическую целесообразность принятых решений.

Введение

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

обеспечение сохранности информации;

контроль доступа к информации (обеспечение конфиденциальности).

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

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

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

В свою очередь вопрос контроля со стороны абонентских ЭВМ касается не только одиночных ЭВМ, но и ЭВМ, работающих в локальных сетях.

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

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

практически полная незащищенность файловой системы.

Ставшие популярными в последнее время новые операционные системы, такие, как OS/2 и Windows NT, также не позволяют полностью решить упомянутые проблемы, что, по-видимому, объясняется тем, что за рубежом не разрабатываются серьезные программные комплексы для персональных компьютеров.

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

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

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

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

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

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

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

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

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

Проблема защиты электронных документов

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

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

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

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

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

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

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

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

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

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

Таким образом, к основным задачам защиты электронных документов относятся:

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

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

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

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

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

2. Разработайте политику безопасности

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

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

Степень детализации

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

Цели

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

Гарантировать, что в среде ЛВС обеспечивается соответствующая безопасность, соответствующая критичности информации и т.д.;

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

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

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

Гарантировать проверяемость среды ЛВС;

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

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

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

Ответственность

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

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

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

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

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

Наказания

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

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

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

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

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

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

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

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

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

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

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

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

Оценка риска

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

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

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

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

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

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

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

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

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

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

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

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

Этап 2 - Идентификация и оценка ценностей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Этап 4 - Измерение риска

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

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

Этап 5 - Выбор подходящих мер и средств защиты

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

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

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

Этап 6 - Внедрение и тестирование средств защиты

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

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

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

Этап 7 - Одобрение остаточного риска

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

4. Обоснуйте экономическую целесообразность принятых решений

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

Литература

    Защита информации и безопасность компьютерных систем / В.В. Домарев. - К.: Издательство "ДиаСофт", 1999. - 480 с.

    www.kiev-security.org.ua