Смекни!
smekni.com

Безопасность как процесс (стр. 1 из 2)

Зигфрид Хубер

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

Без надежной и стабильной инфраструктуры информационных технологий промышленные предприятия, как и другие современные компании, не смогут работать продуктивно в течение длительного времени. Поставщики же с готовностью эксплуатируют эту тему для рекламы своих продуктов и услуг, при этом в качестве конкурентного преимущества подчеркивается их защищенность. Как следствие, множество предложений создает обманчивое впечатление, что безопасность можно просто купить и что однажды достигнутый высокий уровень будет сохраняться вечно. В действительности все наоборот. Недавнее исследование немецкого Федерального управления информационной безопасности показало, что наибольшую угрозу представляет недостаточная сенсибилизация управления, отсутствие анализа процессов и слабо проработанные планы поведения в случае кризисных и аварийных ситуаций («Состояние безопасности ИТ в Германии», 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 поступают так же, как и с системами брандмауэров: определение политики, реализация политики и ее развертывание.