Написание эффективной политики безопасности

Написание эффективной политики безопасности

Введение

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

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

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

Проблема

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

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

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

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

Что такое политика? 

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

Полномочия

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

Добавление требований без одобрения приведет к нехватке ресурсов отделов для средств  управления. Средства управления стоят денег и поэтому одобрение политики руководством является крайне важным.

Структура

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

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

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

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

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

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

Сделайте элементы политики достижимыми, если они нереальны, то вся политика может быть проигнорирована, или воспринята пользователями менее  серьезно.

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

К кому должна применяться  политика?

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

Технические средства

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

Управление, защита и обработка данных

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

Отчетность

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

Резюме

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

Протоколирование  и аудит

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

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

Реализация протоколирования и аудита решает следующие задачи:

обеспечение подотчетности  пользователей и администраторов;

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

обнаружение попыток  нарушений информационной безопасности;

предоставление информации для выявления и анализа проблем.

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

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

вход в систему (успешный или нет);

выход из системы;

обращение к удаленной  системе;

операции с файлами (открыть, закрыть, переименовать, удалить);

смена привилегий или  иных атрибутов безопасности (режима доступа, уровня благонадежности пользователя и т.п.). 

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

дата и время  события;

уникальный идентификатор  пользователя – инициатора действия;

тип события;

результат действия (успех или неудача);

источник запроса (например, имя терминала);

имена затронутых объектов (например, открываемых или удаляемых  фай-лов);

описание изменений, внесенных в базы данных защиты (например, новая метка безопасности объекта).

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

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

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

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

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

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

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

Задачи контроля целостности, как отдельного направления  защиты информации от НСД

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

В нормативных документах, в части реализации контроля целостности, сформулировано следующее требование: "В СВТ пятого класса защищенности должны быть предусмотрены средства периодического контроля за целостностью программной и информационной части  КСЗ" (практически, по своей сути, аналогично формулируется требование к контролю целостности и для АС 1Г). Однако, это весьма ограниченное требование (локальное), когда речь заходит о целом направлении защиты информации.

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

Рассмотрим достоинства  и недостатки защиты на прикладном уровне, по сравнению с защитой  на системном уровне.

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

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

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

С учетом сказанного можем сделать следующий важный вывод.

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

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

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

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

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

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

Теперь посмотрим, а каким образом взаимосвязаны  механизмы контроля целостности  и аудита событий. Для этого определимся  с тем, а какую собственно информацию из состава данных аудита необходимо предоставлять администратору немедленно (в реальном времени), чтобы администратор  мог оперативно осуществить противодействие  факту НСД, либо, по крайней мере, минимизировать (опять же за счет оперативности  принятия решения) возможный ущерб  предприятия, связанный с этим событием? Можно предположить, что поскольку  основными механизмами защиты в  составе СЗИ от НСД являются системные  драйверы, которые реализуют разграничительную  политику доступа к ресурсам, следовательно, априори ведут аудит, именно данные аудита безопасности, зарегистрированные подобными механизмами защиты, и  предназначаются для отправки на сервер безопасности в реальном времени. Однако зададим себе вопрос, а зачем  эти данные администратору безопасности получать в реальном времени? Во-первых, подобные данные в большинстве своем не являются зарегистрированными фактами НСД (заметим, что если ограничиваются какие-либо права приложений и т.д., т.е. если система защиты многофункциональна и эффективна, то большинство зарегистрированных фактов отказа в доступе к ресурсам вообще никак не будет связано с действиями пользователей), во-вторых, основная задача – это оперативное реагирование на факт НСД. Однако, если механизм защиты, реализованный на системном уровне, зарегистрировал событие в качестве запрещенного, то он априори на него уже прореагировал (пользователь получил отказ в запрошенном им доступе к ресурсу). Другими словами, противоречие решения здесь состоит в том, что в реальном времени для оперативного реагирования администратору выдается информация о тех событиях, на которые соответствующие механизмы защиты уже прореагировали (например, отказали пользователю или приложению, в зависимости от субъекта доступа в разграничительной политике, в запрошенном им доступе к ресурсу), т.е. СЗИ от НСД работает корректно, что позволяет предположить, что любое повторное аналогичное событие также будет предотвращено. Если администратор безопасности здесь все равно "статист" - задача защиты решена и без его участия, то зачем дополнительно загружать канал связи отправкой данных аудита, регистрируемых механизмами защиты системного уровня, в реальном времени? Пусть получает их по запросу - в этом случае уже никакой оперативности не требуется!

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

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

С учетом всего сказанного, можем сделать крайне важный вывод.

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