Английский термин compliance означает соответствие одному из высокоуровневых стандартов (таким как SOX, PCI DSS, Basel II, GLBA). Проводить проверку на соответствие этим документам необходимо для того, чтобы определить, насколько хорошо в вашей организации соблюдаются требования, описанные данными стандартами (разрешенная длина паролей, наличие внутренних регламентов и политик, время устранения уязвимостей и т. п.).
Помимо международных стандартов существуют их отечественные аналоги, корпоративные политики и требования NIST.Проводить оценку соответствия этим документам также необходимо. Стандарты содержат наборы требований: выполнение всех требований стандарта фактически означает соответствие ему. Пример отдельного требования: «Должен иметься дисциплинарный процесс для служащих, которые произвели нарушение защиты» (ИСО/МЭК 2005 A.8.2.3).
Проводить проверку на соответствие стандартам необходимо не только для отчетности: чем больше требований выполняется, тем выше уровень защищенности и тем ниже риски финансовых потерь при возникновении угроз. Очевидно, что обеспечивать соответствие стандартам необходимо постоянно и непрерывно — иначе при очередной аудиторской проверке придется потратить кучу сил и нервов на поспешное внесение изменений в конфигурации и инфраструктуру в соответствии с требованиями.
Как проводить проверку соответствия стандарту
На курсах аудиторов по ISO 27001 мне довелось встретить сотрудников департамента ИБ одной организации, которые при проверке соответствия использовали стандарт 27001, но оценивали соответствие и просчитывали риски в экселевской таблице. Зрелище не для слабонервных, признаюсь вам.
Конечно, можно проверять соответствие подобным образов, выписывая требования стандарта на лист бумаги или в Excel. Можно воспользоваться специальным ПО, в котором сотрудники, ответственные за те или иные аспекты безопасности, будут отвечать на типовые вопросы: «Да, нет, не знаю». Но насколько достоверной будет полученная информация? Уверены ли вы, что администратор домена действительно установил минимальную длину паролей равную 7 символам? А вы действительно уверены, что этот администратор не сделал фейковый скриншот, а потом не вернул настройки групповых политик в состояние, которое он (!) считает необходимым? Часть требований можно проверить только с помощью опроса сотрудников, но выполнение остальных требований вполне можно проверять автоматизированными средствами.
Типы требований
Требования делятся на технические и нетехнические. К техническим требованиям относится та информация, которую можно проверить с помощью средств автоматизации (выполнив команду в консоли, парсером по файлу конфигурации, через параметр реестра).
Приведу простой пример технического требования, упоминающегося в большинстве стандартов: PCI DSS 8.5.10 “Require a minimum password length of at least seven characters”, PCI DSS Requirements 5.1. “Deploy anti-virus software on all systems сommonly affected by malicious software (particularly personal computers and servers)”.
Нетехнические требования, соответственно, проверить с помощью средств автоматизации не получится. Пример такого требования — упомянутый выше ИСО/МЭК 2005 A.8.2.3.
Ни один стандарт нельзя полностью описать с помощью одних лишь технических требований. При отсутствии средств автоматизации мы можем их все считать нетехническими. Появляется возможность автоматической проверки требования — оно становится техническим. Чем больше таких требований мы сможем проанализировать (проверить выполнение их в системе), тем оперативнее можно будет снижать риски, устраняя несоответствия.
Необходимо сразу пояснить, что процесс проверки соответствия вообще принято делить на compliance (без префикса standard; имеется в виду соответствие высокоуровневым стандартам по умолчанию), regulatory compliance (требования надзорных органов, к примеру СТО БР ИББС) и policy compliance (соответствие политикам, будь то корпоративная политика или NIST). Все эти термины в рамках данной статьи мы будем понимать как «проверку на соответствие стандартам (политикам)».
От стандартов к политикам
Что делать, если вам не нужны никакие стандарты, но хочется контролировать соблюдение политик ИБ?
Понятие «проверка соответствия» применимо не только для высокоуровневых стандартов (ISO, руководства NIST, SOX, Basel II) и руководств NIST, но и для внутренних политик компаний. Многие требования корпоративных политик состоят из требований стандартов. Это означает, что можно выделить технические требования из стандартов, описанных в вашей корпоративной политике ИБ, объединить их в политику и отслеживать уже ее.
Другой вопрос — как автоматизировать процесс получения и обработки требований для оценки соответствия стандарту? Ответ прост: такими средствами автоматизации, как сканеры уязвимостей, системы класса CMS (compliance management system), SIEM или в крайнем случае самописными сценариями.
Как это работает?
Для CMS и сканеров уязвимостей в задании на сканирование соответствия определенному стандарту определяются IP-адреса информационных систем организации. Затем производится сканирование системы для определения соответствия требованиям выбранного стандарта (как правило, при этом сканер получает все доступные данные), после чего осуществляется оценка того, все ли технические требования данного стандарта выполняются на выбранных активах.
Как правило, в системе существует список доступных шаблонов стандартов с предопределенным набором требований, которые можно выбрать для оценки соответствия. Если же чего-то не хватает, то можно докупить у производителя сканера лицензии на отсутствующие стандарты или разработать свой собственный.
Разработка собственного стандарта
В сканерах уязвимостей с функцией проверки соответствия стандартам есть возможность создать свой стандарт с нуля или на базе уже имеющегося. В процессе создания можно переопределить значения, которые проверяются в рамках требований или добавить собственные.
Добавление собственных требований возможно благодаря гибким механизмам проверок. В каждой системе требования состоят из одной или нескольких проверок. Как правило, проверки эти реализованы с помощью нескольких сценариев с различными методами и транспортами (WMI, RPC и т. п.). У McAfee VM, например, часть сценариев, хранящихся в базе данных, выглядит как на рис. ниже.
Однако нам нет необходимости копаться в базе данных и вообще знать — какой сценарий что проверяет. Как правило, производители ПО предоставляют графический интерфейс для работы с требованиями. В свой новый стандарт или политику мы можем включить практически любые технические требования и переопределить значения их параметров.
Если же такого интерфейса нет, то должна по крайней мере быть доступна документация по созданию собственного стандарта (например, в формате XML). Немного усилий — и уникальный стандарт, отражающий требования к ИБ в конкретной организации, готов.
SIEM
Теперь поговорим о SIEM. Некоторые понятия, связанные с подобными системами, мы рассматривали ранее в нашем блоге:
1) Что такое SIEM http://blog.ptsecurity.ru/2012/10/siem.html
2) Для чего нужна интеграция SIEM и сканера уязвимостей http://blog.ptsecurity.ru/2012/10/siem_1.html
3) Что такое сигнатурные методы корреляции http://blog.ptsecurity.ru/2012/10/siem_17.html
4) Как управлять инцидентами ИБ http://blog.ptsecurity.ru/2012/11/blog-post.html
Теперь давайте зададимся вопросом, зачем в принципе в SIEM нужна проверка соответствия. Что под этим процессом понимается в SIEM? И почему бы не использовать для такой проверки только сканеры уязвимости и compliance management systems?
Во-первых, в стандартах существуют требования по журналированию части событий, связанных с учетными записями, доступом к объектам, изменения групповых политик и т. п. Контролировать выполнение этих требований тоже необходимо, поскольку есть возможность проверить, поступают ли эти типы событий в наш SIEM.
Во-вторых, в отличие от различных сканеров, SIEM-системы непрерывно получают информацию, которую можно использовать для динамической оценки соответствия в режиме реального времени. Как быстро вы узнаете об отключении антивирусной защиты на вашем сервере или изменении доменной политики? В подобных ситуациях запуск сканера, как правило, нагружает сеть и информационные системы, поскольку процесс проверки соответствия стандарту (например, PCI DSS) часто влечет за собой и сканирование на уязвимости (а это огромная нагрузка, которая может «уронить» вашу производственную систему).
SIEM в данном случае выступает пассивным источником данных о соответствии тому или иному стандарту, получаемых в режиме реального времени: снимается проблема менеджмента журналов. В то же время у нас есть возможность на основе поступающих данных о различных событиях определять, что именно приводит к несоответствию. Далее проверяется соответствие определенному требованию выбранного стандарта, и в случае обнаружения несоответствия администратору информационной системы отправляется уведомление.
Кроме того, если в системе осуществляется инцидент-менеджмент, то ответственному сотруднику будет также поставлена задача по устранению несоответствия.
Звучит красиво, не правда ли? Теперь вернемся к нашим SIEM-системам и посмотрим, каким образом они, собственно, оценивают соответствие тому или иному стандарту.
Высокоуровневые стандарты предполагают сбор и хранение информации об определенных событиях (указаны в таблице).
С учетом отдельных стандартов получается следующая картина.
Повторю еще раз: акцент здесь делается на сборе и хранении. Мы не увидим ничего похожего на «анализ», «аудит полученных данных» (не путать с «аудитом входа в систему», это обычные данные из журналов).
Если вы ожидаете, что результатом контроля соответствия стандарту с использованием SIEM станет сообщение вида «Установлена минимальная длина пароля» с указанием соответствующего или не соответствующего требования, — вы, к сожалению, ошибаетесь.
После запуска проверки на соответствие любому высокоуровневому стандарту из списка доступных в SIEM-системе в отчете вы получите только лишь список событий и систем с разбивкой по требованиям или (в лучшем случае) отчет по событиям в рамках этого требования (например, Data flows).
Отсюда можно сделать вывод, что SIEM-системы не предназначены для оценки соответствия, а нужны как техническое средство для соблюдения отдельных требований стандартов по сбору и хранению событий и имеют лишь функциональность track@report.
Конечно, есть и исключения, но их немного. Некоторые вендоры пытаются частично извлечь из поступающих событий полезную информацию, влияющую на соответствие стандартам. В этом случае требования соотносятся с правилами корреляции SIEM. При этом одному требованию соответствует несколько правил. Это объясняется тем, что конкретный факт (например, изменение минимальной длины пароля в доменной политике) может включать в себя много событий от разных источников данных, да и содержание самого события может быть разным.
Кроме того, в журнале событий каждого источника данных конкретное событие может быть описано различными служебными словами, с разными event_id.
Однако выполнение проверки соответствия подобным образом требует слишком большого количества ресурсов, поэтому разработчики SIEM отказываются от этой затеи.
Почему же возникли трудности в реализации полноценного анализа на соответствие? Кратко рассмотрим основные причины.
Причина первая. В SIEM отсутствует понятие объекта. Тут можно вспомнить метод корреляции “MBR model based reasoning”, описанный в одной из предыдущих статей. С помощью данного метода, к примеру, можно было бы описать состояние объекта, приводящее к несоответствию.
В модели SIEM хранятся события, категории и классы событий, статистика. Однако там отсутствуют состояния объектов или активов (хотя этого понятия для SIEM и не существует).
Причина вторая. В SIEM-системах большинства производителей события не нормализуются (не приводятся к одному стандартизированному виду), поэтому нужно составлять большое количество логических правил корреляции. Это, в свою очередь, приводит к нерациональности составления полноценного standard compliance.
Почему так происходит? Все производители стремятся выполнить требование NIST 800-92 («Original event is preserved and no data is changed during normalization») и, дабы обеспечить неизменность исходных событий, хранят их формате RAW.
Что же делать? Как вариант — применять стандарт CEE (http://cee.mitre.org). Это позволит стандартизировать события без противоречия с NIST 800-92.
В SIEM не получится описать все технические требования стандартов по одной простой причине: значения требований не передаются в событиях от источников. Соответственно, SIEM без дополнительного функционала сканера в SIEM-агенте эти значения не получит. Однако, тренд сейчас — использование безагентных технологий. Несмотря ни на что с помощью SIEM можно отследить большую часть состояния требований в режиме реального времени. Разработчикам SIEM нужно лишь сделать шаг для исправления ошибок.
Надеюсь, в этой статье мне удалось развеять миф о проверке соответствия стандартам в SIEM-системах, а также дать представление о понятиях standard compliance, policy compliance, regulatory compliance.
До встречи в новых публикациях! Ждем ваших вопросов и замечаний в комментариях.
Автор: Олеся Шелестова, Исследовательский центр Positive Research.
