Разработка систем безопасности
         

Процесс пересмотра правил

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

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

Периодический пересмотр документов правил

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


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

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

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

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

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

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

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


Что необходимо включить в правило пересмотра

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

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

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

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

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


Комиссия по пересмотру правил

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

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

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

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

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


Документы правил безопасности не должны

Документы правил безопасности не должны быть "мертвыми" документами, изменяясь и развиваясь по мере развития организации и появления новых технологий. Для этого необходимо периодически пересматривать правила, чтобы поддерживать их актуальность. Заключительное правило должно утвердить процесс пересмотра правил, во время которого анализируется информация, собранная в результате реализации правил.
1. Периодический пересмотр документов правил. Определенных рекомендаций по поводу того, как часто нужно пересматривать правила, не существует. Однако рекомендуется, чтобы этот срок был в пределах от шести месяцев до одного года. В положения процесса пересмотра нужно включить требование создания временной комиссии при срочной необходимости внесения в правила значительных изменений. 2. Что необходимо включить в правило пересмотра. Информацию, собранную в результате процесса анализа. Данные, собранные в процессе внедрения правил и процедур, созданных на базе этих правил. Информацию, собранную в процессе анализа степени риска и аудита. Руководство должно предоставить описание бизнес-технологий и всю информацию, связанную с ними. Даже устная информация, полученная от кого угодно, в которой высказывается отношение и оценка правил и применения процедур, может рассматриваться как очень важная. 3. Комиссия по пересмотру правил. В идеале, комиссия по пересмотру правил должна состоять из представителей всех заинтересованных сторон, которые были привлечены для разработки правил. Небольшие организации могут не располагать достаточными ресурсами для создания комиссии. Эти организации могут использовать другие способы работы вместо организации встреч и совещаний.