Четыре шага к всеобъемлющему процессу обеспечения безопасности

Ричард Бейтлич в «Дао мониторинга сетевой безопасности» пишет: «Безопасность — это процесс регулярной проверки имеющихся приемлемых рисков» (Addison Wesley, 2005). Он делит процесс безопасности на четыре следующие друг за другом, постоянно повторяющиеся этапа: оценка, защита, выявление и реакция.

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

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

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

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

• HTTP и HTTPS — для обращения через Web к любому серверу Web и FTP — для обращения к любому серверу FTP;

• DNS — для передачи данных об именах на сервер имен предприятия;

• SMTP и РОРз — для передачи трафика электронной почты на почтовые серверы предприятия;

• IPSec или SSL — для передачи трафика виртуальных частных сетей на шлюз VPN. Разрешенными протоколами для входящего трафика являются:

• HTTP и HTTPS — для обращения через Web к серверам Web предприятия;

• DNS — для обращения к серверу имен предприятия с целью определения адреса;

• протоколы для передачи трафика электронной почты на почтовые серверы предприятия.

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

На основе всей информации, собранной на этапе оценки, можно составить сметы проектов, отобрать персонал и оценить такие компоненты системы безопасности, как брандмауэры, системы обнаружения вторжения, антивирусные сканеры, фильтры спама, proxy-серверы и т. д.

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

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

Этап 3: выявление. Обнаружение нарушений директив безопасности и соответствующее реагирование на них -- вот меры, определяемые на третьем этапе. Системы обнаружения вторжений (Intrusion Detection System, IDS) записывают сетевой трафик на ключевых узлах инфраструктуры ИТ для его последующей оценки. В отличие от затрат на брандмауэры, издержки на конфигурирование и обслуживание IDS очень высоки — момент, который нередко упускают из виду. Зачастую с IDS поступают так же, как и с системами брандмауэров: определение политики, реализация политики и ее развертывание.

Как правило, в отношении брандмауэров такого образа действий достаточно, поскольку их единственная задача заключается в том, чтобы разрешать пользование одними сетевыми службами и блокировать другие. Единожды сконфигурированные, они надежно и с незначительными административными расходами делают свою работу. Другое дело IDS: любое нарушение директивы сначала должно быть проинтерпретировано системой и при определенных обстоятельствах охарактеризовано как «вторжение». Каждое вторжение в зависимости от уровня угрозы влечет за собой различные действия: одни выполняются автоматически с помощью систем предотвращения вторжений (Intrusion Prevention Systemen, IPS), другие же, напротив, требуют безусловного вмешательства администратора. Систему можно, к примеру, настроить так, чтобы в случае неразрешенного доступа к какой-либо определенной службе она самостоятельно блокировала IP-адрес отправителя. Существенно более опасные «вторжения», например заражение сети клиентами, находящимися под контролем злоумышленника и используемыми для проведения распределенных атак с целью вызвать «отказ в обслуживании», потребуют, возможно, отключения целых сегментов сети.

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

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

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

• завершение работы пострадавшей серверной службы;

• запуск соответствующего исправления на сервере;

• выключение сервера;

• подключение отсоединенных сетевых шнуров;

• повторный запуск сервера;

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

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

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

Список литературы

Журнал сетевых решений, февраль 2007