СТАТЬИ 
Двери в сеть
Противоречия

Правила безопасности

Правила безопасности в информационных технологиях в настоящее время представляют серьезный интерес для всех как в государственном, так и в частном секторе. Многие желают защитить себя и свою информацию от постоянно возрастающего количества хакерских атак. Серьезный подход к правилам обеспечения безопасности является основой для успешной защиты. Для того чтобы помочь читателю в создании собственного набора правил безопасности, первый раздел этой главы посвящается отрывкам из документа, подвергнутого наибольшему количеству критики, «Руководства по разработке планов защиты для систем информационных технологий» , разработанного в 1998 году для Национального института стандартов и технологий (National Institute of Standards and Technology, NIST). Созданный изначально как руководство по защите конфиденциальной правительственной информации, государственных служб и инфраструктур, этот документ может являться пособием при разработке плана или правил безопасности любой организации.

Введение

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

Планирование основных приложений и общей системы поддержки

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

Цели создания планов защиты

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

Ответственность за составление плана защиты

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

Рекомендуемый формат

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

Советы и комментарии

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

Кому адресован план защиты?

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

Анализ системы

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

Границы системы

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

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

Категория системы

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

Основные приложения

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

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

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

Общая система поддержки

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

Основное приложение может выполняться в общей системе поддержки. План безопасности общей системы поддержки должен содержать ссылки на план (или планы) защиты основного приложения в разделе «Описание/Цели».

Разработка плана защиты

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

Идентификация системы

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

Идентификатор и имя системы

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

Организации, ответственные за работу системы

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

Информация о контактах

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

Лицо, ответственное за обеспечение безопасности системы

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

Режим функционирования системы

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

Описание/Цели

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

Системная среда

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

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

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

Взаимосвязь систем и совместное использование информации

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

Описание правил безопасности для взаимодействующих систем и совместно используемых данных должны быть включены в документ (см. раздел «Правила поведения»). Здесь же приводятся следующие сведения, относящиеся к разрешению соединений с другими системами и совместного использования информации: список систем, участвующих в соединении (в том числе Интернет); уникальные идентификаторы системы (если они существуют); названия систем; список организаций, являющихся владельцами систем; тип межсетевого соединения (TCP/IP, телефонная линия, SNA и т. д.); краткий обзор основных проблем или обстоятельств, на которых необходимо заострить внимание в определенном соединении; имена и должности сотрудников, имеющих официальное право разрешать доступ к системам; дата авторизации; система записей, если она существует; уровень важности функционирования каждой системы; взаимодействие систем; мероприятия по защите и правила поведения, принятые для остальных систем, которые необходимо учитывать при защите рассматриваемой в документе системы.

Важность информации

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

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

Законы, правила и порядки, принятые в системе

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

Общее описание важности информации

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

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

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

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

Средства управления

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

Оценка рисков и управление

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

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

Обзор средств защиты

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

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

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

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

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

Правила поведения

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

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

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


Глава из книги Дж. Чирилло
"Защита от хакеров"

X Route.org



Winsov.ru Security
 
 
 
Сайт создан в системе uCoz