Безопасность как процесс
Зигфрид Хубер
«Безопасность — это процесс». В последнее время подобное заявление можно услышать на всех конференциях и прочитать в журнальных статьях, однако немногим предприятиям удается воплотить данный лозунг в жизнь. Остальные, как правило, забывают об адаптации процессов обеспечения безопасности к конкретным условиям.
Без надежной и стабильной инфраструктуры информационных технологий промышленные предприятия, как и другие современные компании, не смогут работать продуктивно в течение длительного времени. Поставщики же с готовностью эксплуатируют эту тему для рекламы своих продуктов и услуг, при этом в качестве конкурентного преимущества подчеркивается их защищенность. Как следствие, множество предложений создает обманчивое впечатление, что безопасность можно просто купить и что однажды достигнутый высокий уровень будет сохраняться вечно. В действительности все наоборот. Недавнее исследование немецкого Федерального управления информационной безопасности показало, что наибольшую угрозу представляет недостаточная сенсибилизация управления, отсутствие анализа процессов и слабо проработанные планы поведения в случае кризисных и аварийных ситуаций («Состояние безопасности ИТ в Германии», http://www.bsi.de, стр. 31). Так, предприятий, внедривших у себя непрерывный процесс обеспечения безопасности, как и прежде, очень мало.
При этом путь от заведомой жертвы атак и нападений до всесторонне и профессионально защищенного предприятия не столь долог и не так уж труден, как может показаться. Достаточно провести поэтапный анализ рисков, чтобы выяснить, как на основе полученных результатов запустить процесс обеспечения безопасности и тем самым добиться стабильно высокого уровня защиты.
С малыми затратами достичь многого
Патентованных решений, распространенных в других областях ИТ, в сфере безопасности ИТ не существует. Стандартным подходом к защите демилитаризованной зоны и Intranet является применение брандмауэров. Сравнительно недавно столь же обязательными стали системы обнаружения вторжений. Зачастую составными частями «надежной» инфраструктуры ИТ являются инфраструктура с открытыми ключами (Public Key Infrastructure, PKI), виртуальные частные сети (Virtual Private Network, VPN) и многое другое.
Если речь идет о безопасности ландшафта ИТ, не следует делать ставку исключительно на размещение перед шлюзом внутренней корпоративной сети максимально укрепленного бастиона, состоящего из устройств обеспечения безопасности, поскольку одно лишь их наличие не гарантирует лучшую защиту. Иногда они могут сами превратиться в источник опасности, к примеру, когда в результате излишне усложняется система в целом, что приводит к ослаблению контроля над ней. Нередко решения по обеспечению безопасности инсталлируются без установления взаимосвязи между защищаемым объектом и реальным риском.
В этой ситуации необходим непрерывный процесс, в рамках которого учитывались бы все относящиеся к ИТ угрозы и определялись соответствующие меры. Многие все еще недооценивают значение анализа рисков и опасаются неизбежных административных издержек. Однако для планирования безопасности ИТ такой анализ очень важен, поскольку он позволяет выяснить индивидуальный потенциал опасности для всех значимых компонентов ИТ предприятия. Лишь после этого четко определяется, какие защитные меры необходимо реализовать. Если говорить точнее, то без анализа рисков невозможно сделать правильное заключение о защитном потенциале отдельных областей инфраструктуры ИТ.
Все предприятия работают по-разному
В контексте инфраструктуры ИТ о рисках говорят всегда, когда есть опасность кражи, повреждения или уничтожения ценностей, т. е. компонентов корпоративной инфраструктуры ИТ. Уже сама по себе оценка стоимости и опасности представляет собой первый этап анализа рисков. Однако результаты обсуждения могут быть совершенно разными — все зависит от специфики предприятия.
Например, компания А разрабатывает приложения в соответствии со стандартной общественной лицензией (General Public License, GPL), а значит, обязана публиковать исходные коды. Компания В создает приложения и продает их без публикации кода под собственной лицензией. Если обе станут анализировать опасности, то результаты получатся разными: компания А, вероятно, посчитает, что ее находящемуся в открытом доступе исходному коду вообще ничто не угрожает, и присвоит ему очень низкую оценку по пятибалльной шкале; а вот для компании В ее исходный код имеет высокое, возможно, жизненно важное значение -- видеть его разрешается лишь определенному кругу лиц. Ввиду опасности хищения и публикации исходного кода ему присваивается оценка в диапазоне от трех до пяти.
Особенно серьезный риск для предприятия возникает в том случае, когда один из компонентов процесса имеет еще и слабое место. Это могут быть, к примеру, «бреши» в подсистеме безопасности операционной системы, не защищенное шифрованием соединение или ошибка в коде приложения. С учетом всех этих факторов влияния риск вычисляется в соответствии со следующей формулой: риск = опасность х слабое место х оценка. В контексте рассмотренного выше примера для компаний А и В можно построить соответствующие матрицы рисков (см. Таблицы 1 и 2).
Четыре шага к всеобъемлющему процессу обеспечения безопасности
Ричард Бейтлич в «Дао мониторинга сетевой безопасности» пишет: «Безопасность — это процесс регулярной проверки имеющихся приемлемых рисков» (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