Основные принципы централизованного управления безопасностью

 

М. Ю. Кадер ,

инженер_консультант компании Cisco Systems

mkader@cisco.com

 

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

 

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

Второй интересный аспект заключается в том, чем и как мы собственно управляем? И здесь полезно упомянуть о таком понятии, как канал управления, то есть сетевая среда, обеспечивающая доступ нашим системам управления к объектам управления, например к рабочим станциям, серверам, сетевому оборудованию, средствам обеспечения безопасности.

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

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

И тут нам на помощь приходит «псевдовнеполосное» управление , означающее, что для задач управления мы строим отдельную логическую сеть в рамках существующей инфраструктуры. Если мы говорим о сегментах локальной сети, то в них используем виртуальные локальные сети. Если о территориально-распределенных сетях, то либо используем туннельные протоколы, такие как IPsec или GRE, либо применяем защищенные протоколы сетевого управления, такие как SSH, SCP, SSL/TLS и т. п. При этом с точки зрения сетевой адресации сеть управления по-прежнему отделена от пользовательской сети. Такой подход позволяет нам реализовать безопасную систему управления, при этом используя инвестиции, уже сделанные нами в построение сети передачи данных нашего предприятия.

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

Такие системы должны уметь управлять конфигурацией групп устройств, включая ведение библиотек файлов конфигурации, выполнять инвентаризацию устройств, уметь импортировать конфигурацию уже существующих устройств, отслеживать изменения настроек, управлять полномочиями по управлению оборудованием, иметь возможность разделения ролей администрирования, многопользовательский режим и т. п. Важной особенностью работы подобных систем является «оффлайновый» принцип функционирования: администратор работает не напрямую с устройством, а с хранящейся на станции управления копией конфигурационного файла одного или множества устройств. После того как изменения были выполнены, осуществляется их проверка на непротиворечивость и только затем загрузка по определенному расписанию непосредственно на объекты управления. Причем на каждом шаге управления конфигурацией существует процесс контроля и «одобрения» изменений. Такой подход позволяет эффективно разделить функции управления безопасностью между соответствующими сотрудниками и подразделениями. В качестве примера подобной системы можно привести продукт управления безопасностью компании Cisco Systems – CiscoWorks VMS.

Безусловно, одной из важнейших составляющих любой системы управления безопасностью является система мониторинга событий, для которой также существует несколько возможных вариантов. Начиная от простейшего, когда система обеспечивает сбор событий только от тех типов оборудования, которые она умеет настраивать, и заканчивая полнофункциональными системами мониторинга разнообразных средств безопасности. В качестве первого варианта можно упомянуть продукт Security Monitor из комплекта CiscoWorks VMS, который умеет контролировать работу средств безопасности компании Cisco. Примером для второго варианта могут служить такие решения, как CiscoWorks Security Information Management Solutions (CW SIMS) или Cisco Monitoring Analyzes and Response System (CS MARS).

Давайте рассмотрим, что умеют делать подобные системы. Они обеспечивают выполнение четырех основных задач, а именно консолидации (event consolidation), агрегирования (event aggregation), корреляции (event correlation) и приоритезации (event prioritization).

Что представляют собой эти задачи и в чем их суть? Начнем с консолидации.

Консолидация – это объединение информации обо всех событиях, поступающей от разнородных средств защиты информации, на одной консоли. Несколько сотен тысяч событий безопасности в день являются типичными для сети обычного предприятия. Поэтому консолидация – это не просто сбор и помещение данных в единое хранилище, это еще и их нормализация, то есть устранение избыточной информации. Другими словами, в процессе нормализации такие системы мониторинга как CW SIMS и CS MARS, удаляют повторяющиеся данные об атаках, полученных, например, от системы обнаружения атак и межсетевого экрана, и исключает противоречивость в их хранении. Идеальной является ситуация, когда одно сообщение об атаке хранится только в одном месте.

На этом же этапе должно происходить приведение всех данных к единому времени. При этом, собрав все данные в одном месте, мы не избавились от проблемы огромных объемов информации, отображаемых на консоли администратора безопасности. Устранить ее должно агрегирование – группировка однотипных событий, позволяющая получить на экране вместо 10 тыс. повторяющихся строк «UDP-Scan» всего лишь одну строчку, дополненную новым параметром «число событий». Таким образом, агрегирование облегчает отображение данных и их анализ, не спасая при этом от появления сообщений об атаках, которые не несут в себе никакой угрозы. И в этом случае нам на помощь приходит корреляция, процесс которой может быть разделен на три основных типа.

• Локальная корреляция , осуществляемая непосредственно на защищаемом узле. В этом процессе участвует система обнаружения и предотвращения атак уровня узла (host-based ID&PS), которая должна не только зафиксировать атаку, но и оценить ее воздействие на атакуемый узел.

• Корреляция со сведениями об операционной системе . Если Windows-атака направлена на Unix-узел, ее можно проанализировать и позже. Если же атака «применима» к данной ОС, то в действие вступает следующий вариант корреляции.

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

Результатом работы механизма корреляции может служить одно из следующих сообщений в строке статуса атаки (с разъяснением причины полученного вывода):

• вероятно удачная атака (узел уязвим);

• вероятно неудачная атака (узел не уязвим);

• вероятно неудачная атака (блокированы некоторые пакеты, составляющие атаку);

• вероятно неудачная атака (атака не применима к данной операционной системе);

• неудачная атака (узел блокировал атаку);

• воздействие неизвестно (узел не сканировался);

• воздействие неизвестно (операционная система не определена);

• воздействие неизвестно (уязвимость не определена);

• воздействие неизвестно (корреляция не проводилась).

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

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

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

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

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

• наличие единой консоли управления средствами защиты, находящимися на различных объектах сети предприятия;

• обеспечение единого, унифицированного интерфейса управления разнородными средствами защиты;

• снижение издержек на поддержку управляемых средств защиты;

• обеспечение масштабируемости систем обеспечения безопасности;

• снижение числа специалистов, отвечающих за безопасность сети предприятия;

• снижение затрат на обучение администраторов безопасности, вынужденных в обычных условиях изучать несколько различных продуктов со своими консолями управления;

• существенный рост эффективности работы персонала, отвечающего за обеспечение информационной безопасности.

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

 

Защита информации. INSIDE № 6’2005