Специфика внедрения SOC

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

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

Безусловным плюсом при внедрении таких продуктов, как Imperva и Guardium, может стать интеграция их с SIEM-системами типа ArcSight ESM или RSA enVision. С одной стороны, Imperva и Guardium позволяют довольно гибко создавать необходимые отчеты, которые вполне удобны в использовании. С другой - анализировать инциденты для заказчика с большим количеством различных систем, как показывает практика, удобнее в центральной консоли SIEM-продукта. Это позволяет проводить корреляцию событий и выявлять инциденты гораздо быстрее и эффективнее. Вероятнее всего, заказчик будет недоволен удобством использования отдельно стоящей системы с непривычным и глубоко техническим описанием инцидентов ИБ.

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

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

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

Евгений Рудацкий, руководитель направления PCI DSS компании «Инфосистемы Джет»

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

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

Более того, Центр оперативного управления ИБ, построенный в рамках проекта PCI DSS, обычно в дальнейшем расширяется на весь банк: к централизованному мониторингу подключаются все системы компании. Таким образом, система оперативного управления важна не только для подразделений информационной безопасности, но и для ИТ-служб и аудиторов.

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

Стандарт PCI DSS претерпевает изменения как минимум раз в 2 года. Более того, каждый год необходимо проходить повторный аудит на соответствие требованиям. Таким образом, грамотно построенный SOC позволит минимизировать дальнейшие затраты банка на выполнение требований регуляторов, аудиторские проверки.

В настоящее время направление SOC в России находится на начальном этапе развития. Большинство заказчиков только начинают задумываться о создании полноценного Центра оперативного управления ИБ, многие внедряют разрозненные компоненты. Надеюсь, что это направление и дальше будет активно развиваться в отечественных компаниях, и в скором времени наши заказчики ощутят всю эффективность и пользу от внедрения таких центров.

Владислав Силуянов, эксперт по проектированию систем ИБ компании «Инфосистемы Джет»

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

 Есть и другой подход: производится полный анализ на уязвимости информационных систем, проводится сканирование, определяются недостающие «заплатки» программного обеспечения и обеспечивается поддержание в актуальном состоянии всех программных и аппаратных компонент информационных систем. В этой области безусловным лидером является продукт MaxPatrol отечественного разработчика компании Positive Technologies. Продукт известен широкому кругу заказчиков по своему "младшему брату" - решению XSpider.

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

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

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

Также нельзя не отметить подход, при котором защищается ядро хранения информации - базы данных. Такие продукты как Guardium и Imperva ведут мониторинг http и sql трафика, контролируя доступ пользователей непосредственно  к базам данным, их таблицам и различным критичным объектам серверов СУБД. Преимущества в том, что обычно наиболее критичные данные хранятся в корпоративных базах данных и злоумышленник будет пойман при попытке получить к ним доступ. Но есть у этого метода и минус –за пределами баз данных или приложений, информация не контролируется.

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

Максим Жевнерев, эксперт по системам мониторинга и управления ИБ.

 Любой проект по внедрению системы мониторинга и управления инцидентами ИБ - процесс трудоемкий и длительный. Мы рекомендуем использовать в качестве технологической платформы продукты компании ArcSight как наиболее технически совершенное и законченное решение.

Как правило, внедрение централизованной системы мониторинга событий ИБ на базе ArcSight разделяется на 2 этапа: сбор событий и настройка системы

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

Критерий завершения этапа по сбору событий - подключение всех источников к ArcSight и настройка правил, отчетов и консолей для мониторинга состояния подключенных систем и наличия событий.

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

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

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

 1) Контроллеров домена

 2) Операционных систем серверов, на которых данную активность нужно отслеживать

 3) Межсетевых экранов\сетевых устройств

 4) Систем авторизации

 5) Баз данных

 6) IDM -системы

При этом подключение антивирусных средств, систем IDS\IPS можно оставить на будущее.

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

Так, например, полезным будет подключить к системе мониторинга не только базовые элементы обеспечения ИБ, такие как антивирусы и межсетевые экраны, но и другие системы управления ИБ.Например, довольно эффективна интеграция системы мониторинга со сканерами уязвимостей. Результаты сканирования MaxPatrol лишь дополняют и расширяют возможности ArcSight. При этом следует отметить, что из MaxPatrol в ArcSight или Symantec SIM попадает только информация о найденных сервисах и уязвимостях (режимы Pentest и Audit). Режим compliance в данном случае остается незатронутым, и отчеты по нему можно получить только в MaxPatrol.

На мой взгляд, интеграция систем мониторинга и систем управления уязвимостями оправдана в следующий случаях:

 1) В ArcSight полностью сформирована сетевая модель, и есть необходимость в использовании сканера безопасности для заполнения информации об уязвимостях\используемых сервисах в Assets. В этом случае ArcSight сможет автоматически подстраивать приоритеты событий, использовать данные об уязвимостях\сервисах в корреляционных правилах и отчетах;

 2) В случае необходимости построения сетевой модели и заведения списка устройств. Для этого при выпуске отчета MaxPatrol включаются только данные об уязвимостях с уровнем "Informational";

Более сложные системы, а также программное обеспечение собственной разработки, требуют особого внимания и разработки специальных коннекторов к ним. Для реализации сбора событий с нестандартных источников нужно досконально изучить систему логирования источника. Каким образом система ведет логирование событий (база данных, файл, отправка событий по syslog\snmp и т.д.)? Какая информация есть в этих журналах? Есть ли возможность доработки системы логирования? Если это файлы, то можно ли их забирать удаленно икак часто они перезаписываются?

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

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

• Документацию на систему логирования и\или контакты разработчиков системы;
• Выборку из логов системы за достаточно длительный промежуток времени;
• Возможность доступа к самой системе либо построения аналогичной на наших стендах.

С точки зрения использования системы мониторинга и управления ИБ в качестве средства выявления угроз, финансовых рисков и утечки информации, наиболее интересны:

• функции и отчеты по отслеживанию использования "чужих" учетных записей для аутентификации в системе,
• изменения конфигурации систем,
• создание пользователей с административными привилегиями на короткий промежуток времени
• отчеты по удалению\копированию пользователями данных.

Игорь Ляпунов, директор Центра информационной безопасности компании «Инфосистемы Джет»

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