Требования к защищенной инфраструктуре

Управление административной деятельностью по сопровождению

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

• Четко ли определены допустимые пределы полномочий и приемлемость их использования?
• Очевидны ли процессы управления назначением полномочий и своевременным удалением полномочий при окончании индивидуальной необходимости ведения бизнеса?
• Имеет ли персонал, в обязанности которого входит эксплуатация и поддержка операционной системы, заданные их индивидуальным пользовательским ID системные полномочия? Если нет, может ли вся их деятельность отслеживаться точно индивидуально с абсолютной достоверностью?
• Имеет ли персонал, в обязанности которого входит администрирование безопасности, заданные их индивидуальным пользовательским ID полномочия администрирования безопасности?
• Может ли запуск служебных механизмов и агентов (служб, "демонов", заданий по расписанию), являющихся частью операционной системы, задаваться в отделе эксплуатации и поддержки системы способом, отличным от индивидуального?
• Имеет ли каждый, кто способен начать работу или модифицировать служебные механизмы или агенты, действительную необходимость в этом для ведения бизнеса?
• Могут ли члены групп с административными полномочиями быть индивидуально идентифицируемы и управляемы?
• Как часто будет пересматриваться членство в группе для обеспечения гарантии того, что полномочия доступа удалены своевременно по окончании индивидуальной необходимости ведения бизнеса?

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

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

Технические факторы

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

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

Безопасная программная оболочка [SSH (Secure Shell)] являет собой более безопасную альтернативу telnet. SSH использует шифрование для регистрационных имени и пароля в процессе аутентификации. Большинство платформ маршрутизаторов Cisco поддерживают SSH первой версии, и мы настоятельно рекомендуем использовать для административного доступа к маршрутизаторам SSH вместо telnet.

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

Применение обновлений, связанных с уязвимостями в безопасности

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

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

Уязвимости в программном обеспечении, как правило, разделяются на три категории:

1. Дефекты операционной системы.
2. Дефекты прикладного программного обеспечения.
3. Неправильная конфигурация.

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

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

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

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

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

http://www.cert.org

Ресурсы, требуемые для выполнения исправлений (патчей) на серверах, будут широко различаться в зависимости от размеров вашей организации, количества различных операционных систем, количества приложений. Ресурсы, требуемые для выполнения патчей на рабочих станциях, также будут сильно различаться в зависимости от того, применяется или нет центральный механизм распространения программного обеспечения, и ряда других факторов. Обновления, патчи и другие "заплатки" могут загружаться на рабочие станции с использованием традиционных инструментов распространения ПО либо с использованием специализированных продуктов патч-менеджмента, таких, как Patchlink Update (www.patchlink.com), BigFix Patch Manager (www.bigfix.com), Security Update Manager (www.configuresoft.com), LANguard Network (www.gfi.com) и др.

Запись действий для аудита и отчетности

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

Далее перечислены функции, которые должны быть предоставлены.

1. На случай расследования должен быть доступен журнал системной активности, который потребуется для установления фактического применения (или неправильного применения) каких-либо средств. Журналы должны сохраняться в системе, отдельной от генерирующей журнал системы и расположенной физически внутри защищенной сетевой зоны. Журнал должен сохраняться и быть доступным администраторам безопасности в течение количества дней, определенного стандартами и процедурами безопасности бизнеса. Мы рекомендуем сохранять журналы активности как минимум 60 дней, так как зачастую расследование инцидента потребует промежутка в несколько недель.
2. Все попытки доступа к системам также должны фиксироваться в журналах. Компоненты должны иметь возможность создавать журнал доступа, системный журнал, журнал ресурсов и журнал активности (журнал действий). Исключения должны быть понятно описаны в политике безопасности организации для согласования.
3. Системы должны быть способны вести журнал ошибочных попыток доступа, опираясь на определенные и одобренные политики управления доступом для системы (другими словами, необходимо определить, что представляют собой не попадающие в журнал исключения). Журнал должен содержать всю информацию, которая может иметь отношение к расследованию инцидента с безопасностью, такую, как: ID пользователя, исходный адрес, адрес назначения, время, дата, протокол, порт, процесс и NETID.
4. Система должна иметь процесс для обнаружения систематических атак или обнаружения вторжений по отношению к системе. Для этой цели эффективны журналы активности, но они не должны быть единственным методом обнаружения вторжений. Если не существует специального инструмента обнаружения вторжений, совместимого с заданной системой, то должна выполняться процедура, при помощи которой регулярно и часто просматриваются журналы системы, например как минимум еженедельно.
5. Политика безопасности организации должна определять процедуры ведения отчетности по инцидентам, касающимся систем и компонентов. В ней должны содержаться инциденты, созданные как внутренними, так и внешними источниками. Благодаря расширению нормотворческой деятельности, процедуры обработки и сохранения потенциальных улик должны быть определены как часть плана организации по реагированию на инциденты.

Оценка рисков

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

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

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

3.3 Краткие выводы

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

Обеспечение гарантированной конфиденциальности данных

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

Обеспечение гарантированной целостности данных

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

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