Во второй части рассмотрены следующие вопросы:
- Политика ведения журналов регистрации событий
- Рабочий процесс анализа журналов регистрации событий
- Процедура анализа журналов регистрации событий
- Подготовка к анализу журналов регистрации событий
- Выделение типов событий из журналов регистрации событий
- Создание первоначального профиля «нормальной» деятельности с использованием автоматизированных средств
- Создание первоначального профиля «нормальной» деятельности вручную
- Руководство по выявлению «заведомо плохих событий»
- Ежедневный анализ журналов регистрации событий
- Частота периодического анализа журналов регистрации событий
- Процедура анализа журналов регистрации событий
- Процедура расследования и анализа необычных событий
- Первичное расследование
- Внешние источники информации для расследования
- Эскалация расследования и проведение совместного анализа
С учетом перечисленных выше требований PCI DSS, Политика ведения журналов регистрации событий должна содержать, по крайней мере, следующее:
- Журналирование событий в достаточном объеме, при котором в журнале сохраняется тип события и детальная информация о нем
- Агрегирование и хранение журналов (1 год)
- Защита журналов регистрации событий
- Анализ журналов регистрации событий
Предусмотренные в PCI DSS процедуры тестирования и проверки соблюдения требований п.10.6, указывают, что QSA должен «получить и проанализировать политики и процедуры безопасности на предмет наличия в них процедур анализа журналов регистрации событий безопасности, которые выполняются не реже одного раза в день, и требуют проведения дополнительного анализа при выявлении любых необычных событий». Кроме того, QSA должен «посредством наблюдения и проведения интервью проверить, что регулярный анализ журналов регистрации событий для всех системных компонентов действительно выполняется».
Рабочий процесс анализа журналов регистрации событий включает в себя следующие процедуры:
- Выполнение задач анализа журналов регистрации событий
- Проведение расследования и анализа необычных событий
- Документирование выполнения процедур и сбор доказательств, формирование отчетности для руководства
Общая связь между тремя типами процедур, требуемых PCI DSS, показана на Рисунке 1.
Рисунок 1. Общая связь между тремя типами процедур, требуемых PCI DSS
Другими словами, «Процедуры периодического анализа журналов регистрации событий» выполняется каждый день (или реже, если выполнение ежедневного анализа невозможно) и любые выявленные необычные события эскалируются для выполнения «Процедуры расследования и анализа необычных событий». Выполнение обоих этих процедур должно документироваться, как описано далее в разделе «Подтверждение проведения анализа журналов регистрации событий», для создания доказательств их реального выполнения и обеспечения соответствия требованиям PCI DSS. Теперь рассмотрим эти три задачи более подробно.
В этом разделе рассматривается процедура периодического анализа журналов регистрации событий. Она может выполняться администратором приложения или администратором безопасности (см. раздел «Роли и обязанности»).
Анализ журналов регистрации событий может выполняться с использованием специальных автоматизированных систем, либо вручную, при отсутствии автоматизированных систем или их несовместимости с форматом журналов, которые создают отдельные приложения. Давайте создадим необходимые процедуры для обоих этих случаев, а затем проиллюстрируем их работу, используя различные источники событий, относящиеся к области PCI DSS.
Основной целью периодического анализа журналов регистрации событий в соответствии с PCI DSS (далее мы будем называть его «ежедневным анализом журналов регистрации событий», даже если он в действительности будет выполняться с другой периодичностью для отдельных приложений) является:
- Убедиться, что данные платежных карт не были скомпрометированы злоумышленниками
- Как можно раньше выявить возможные угрозы данным платежных карт
- Обеспечить соответствие требованиям PCI DSS по анализу журналов регистрации событий
- Убедиться, что системы, обрабатывающие данные платежных карт, работают надежно и эффективно
- Обеспечить соблюдение других требований и нормативных документов, предусматривающих выполнение анализа журналов регистрации событий
- Согласовать все выявленные в журналах аномалии с событиями в других системах (например, изменение кода приложения и установку обновления).
Рисунок 2. Процесс анализа журналов регистрации событий на основе профиля «нормальной» деятельности
Если выявленное при анализе необычное событие произошло впервые, и в процессе расследования мы получили подтверждение, что оно не указывает на нарушение безопасности, мы добавляем его к профилю «нормальной» деятельности, чтобы оно также считалось «нормальным» и игнорировалось при последующем анализе.
Перед тем, как приступить к выполнению процедуры ежедневного анализа журналов регистрации событий, нужно создать и проанализировать профиль «нормальной» деятельности, учитывающий все приложения, находящиеся в области действия PCI DSS.
Выделение типов событий из журналов регистрации событий
Профиль строится на основе типов событий. Для этого последовательно просматриваются все записи журнала регистрации событий и при первом появлении каждого нового типа события, этот тип добавляется к профилю «нормальной деятельности. Например, в операционной системе Windows сведения о типе события можно увидеть, в частности, в окне просмотра информации о событии:
Важно отметить, что не все системы создают журналы регистрации событий со столь явным указанием типов событий. Примером могут быть отдельные журналы Unix. В таких случаях нужно создать неявные типы событий следующим образом:
- Анализ события в журнале – определение приложения или устройства, которое его сгенерировало (если журналы различных систем собираются и хранятся вместе)
- Определение части информации события, которая определяет его смысл
- Определение, является ли эта часть информации уникальной
- Использование этой части информации для создания идентификатора этого события
Итак, рассмотрим пример:
1. Анализ события в журнале
[Пн 26 Янв 2010 22:55:37] [Информация] Криптомодуль: генерация закрытого ключа аутентификации
2. Определение части информации события, которая определяет его смысл
Скорее всего, ключевой информацией является «генерация закрытого ключа аутентификации» или даже просто «генерация закрытого ключа»
3. Определение, является ли эта часть информации уникальной
Анализ других записей о событиях в этом журнале показывает, что других записей, содержащих такую же фразу, в журнале нет. Поэтому эта фраза может использоваться для отнесения события к определенному типу.
4. Использование этой части информации для создания идентификатора этого события
Мы можем создать идентификатор или тип события «генерация_секретного_ключа». Теперь мы можем обновить наш профиль «нормальной» деятельности, добавив в него рассмотренный тип события.Первоначальный профиль «нормальной» деятельности может быть быстро построен с помощью рассмотренных ниже процессов (первый предусматривает использование автоматизированных средств управления журналами регистрации событий, второй выполняется вручную).
Помимо определения типов событий, имеет смысл провести оценку среднего объема журналов регистрации событий за 24 часа. В дальнейшем, при проведении ежедневного анализа журналов регистрации событий, выявление значительного изменения объема журнала по сравнению с «нормальным» объемом, должно расследоваться. В частности, должно расследоваться и эскалироваться в качестве инцидента безопасности существенное уменьшение объема журнала, т.к. это может свидетельствовать о вероятной потере записей о событиях.
Создание первоначального профиля «нормальной» деятельности с использованием автоматизированных средств
Для создания первоначального профиля «нормальной» деятельности с использованием автоматизированной системы управления журналами регистрации событий нужно выполнить следующее:
- Убедитесь, что необходимые журналы регистрации событий приложений, входящих в область действия PCI DSS, агрегированы системой управления журналами регистрации событий.
- Убедитесь, что это средство «понимает» (может разобрать на отдельные поля) записи событий каждого из журналов и может находить в них идентификаторы или типы событий.
- Выберите период времени для создания профиля «нормальной» деятельности: «90 дней» или «за все время», если журналы содержат события менее чем за 90 дней. В некоторых случаях может использоваться период от 7 до 30 дней.
- Запустите генерацию отчета, который покажет количество событий каждого типа. Этот отчет содержит все типы событий, которые произошли за 90 дней функционирования соответствующих систем.
- Если есть основания полагать, что за этот период времени не было фактов нарушения безопасности данных платежных карт, мы можем принять созданный в п.4 отчет в качестве профиля «нормального» ежедневного функционирования систем.
- Также, при создании профиля должны быть выполнены следующие дополнительные действия: даже если мы уверены, что никаких нарушений безопасности данных платежных карт не было, существует вероятность, что некоторые события, записанные в анализируемые журналы регистрации событий за 90 дней, были вызваны некоторыми нежелательными действиями или ошибками. Такие события называются «заведомо плохими событиями» и должны быть соответствующим образом помечены.
Теперь рассмотрим пример реализации рассмотренной выше процедуры.
1. Убедитесь, что необходимые журналы регистрации событий приложений, входящих в область действия PCI DSS, агрегированы средством управления журналами регистрации событий
На этом шаге мы смотрим, какая информация содержится в нашем средстве управления журналами регистрации событий и проверяем, что журналы от всех приложений, входящих в область действия PCI DSS, в нем агрегированы. Это может быть сделано с помощью отчета, в котором указаны все источники событий:
Период: 01 Янв 2009 – 31 Мар 2009 (90 дней)
Тип устройства Имя устройства Количество событий Windows 2003 WinSrv1 215762 Windows 2003 WinSrv2 215756 Solaris 9 DBSrv1 53445 FreeBSD 7 AppSrv1 566 Windows 2003 FileSrv1 3334444
Этот отчет показывает, что агрегация событий произведена надлежащим образом.
2. Убедитесь, что это средство «понимает» (может разобрать на отдельные поля) записи событий каждого из журналов и может находить в них идентификаторы или типы событий
На этом шаге выполняется сравнение общего количества событий, посчитанного данным средством (см. отчет, полученный на предыдущем шаге), с реальным количеством событий в исходных журналах регистрации событий.
3. Выберите период времени для создания профиля «нормальной» деятельности: «90 дней» или «за все время», если журналы содержат события менее чем за 90 дней
В нашем примере мы выбираем 90 дней, поскольку журналы за этот период времени у нас есть.
4. Запустите генерацию отчета, который покажет количество событий каждого типа
В результате мы можем получить примерно такой отчет:
Период: 01 Янв 2009 – 31 Мар 2009 (90 дней)
Идентификатор события Описание события Кол-во Среднее кол-во в день 1517 Ошибка записи в реестр 212 2,3 562 Неудачная попытка входа 200 2,2 563 Вход выполнен 24 0,3 550 Обновлены учетные данные пользователя 12 0,1
Этот отчет содержит все типы событий, которые произошли за 90 дней функционирования соответствующих систем.
5. Если есть основания полагать, что за этот период времени не было фактов нарушения безопасности данных платежных карт, мы можем принять созданный в п.4 отчет в качестве профиля «нормального» ежедневного функционирования систем
При проведении первоначального анализа этих журналов регистрации событий, может потребоваться провести расследование в отношении некоторых из записанных в них событий, чтобы убедиться в том, что они не могли привести к нарушению безопасности данных платежных карт. На следующем шаге поясняется, как это сделать.
6. Также, при создании профиля должны быть выполнены следующие дополнительные действия: даже если мы уверены, что никаких нарушений безопасности данных платежных карт не было, существует вероятность, что некоторые события, записанные в анализируемые журналы регистрации событий за 90 дней, были вызваны некоторыми нежелательными действиями или ошибками. Такие события называются «заведомо плохими событиями» и должны быть соответствующим образом помечены.
Некоторые из событий, записанных в журналы за 90 дней, реально указывают на наличие проблем и требуют проведения расследования.
Идентификатор события Описание события Кол-во Среднее кол-во в день Естественное или «плохое» 1517 Ошибка записи в реестр 212 2,3 562 Неудачная попытка входа 200 2,2 563 Вход выполнен 24 0,3 550 Обновлены учетные данные пользователя 12 0,1 665 Недостаточно памяти 1 0,0 Действие: перезапуск системы
В этом отчете мы обращаем внимание на последнюю строку, в которой указана информация о событии с типом 665 «Недостаточно памяти», которое только однажды произошло за 90 дней. Такие редкие события интересны. Описание события («Недостаточно памяти») может также указывать на потенциальную серьезную проблему и поэтому оно должно быть расследовано в соответствии с описанной ниже процедурой для таких расследований.Создание первоначального профиля «нормальной» деятельности вручную
Создание профиля «нормальной» деятельности вручную – возможно, но это значительно сложнее. Создавать профиль «нормальной» деятельности без использования автоматизированной системы управления журналами регистрации событий имеет смысл, когда эта система не совместима или плохо «понимает» имеющиеся журналы регистрации событий. Для создания профиля вручную нужно выполнить следующие действия:
- Убедитесь, что необходимые журналы регистрации событий приложений, входящих в область действия PCI DSS, сохранены в одном месте.
- Выберите период времени для создания профиля «нормальной» деятельности: «90 дней» или «за все время», если журналы содержат события менее чем за 90 дней (чтобы определить это, проверьте отметки времени на файлах с журналами).
- Проанализируйте записи в журналах от самой старой до самой новой, пытаясь идентифицировать типы событий.
- Вручную сформируйте отчет с итоговой информацией обо всех идентифицированных типах событий; по возможности, посчитайте количество событий каждого идентифицированного типа (это может быть очень сложно в случае большого объема журналов регистрации событий).
- Если есть основания полагать, что за этот период времени не было фактов нарушения безопасности данных платежных карт, мы можем принять созданный в п.4 отчет в качестве профиля «нормального» ежедневного функционирования систем.
- Также, при создании профиля должны быть выполнены следующие дополнительные действия: даже если мы уверены, что никаких нарушений безопасности данных платежных карт не было, существует вероятность, что некоторые события, записанные в анализируемые журналы регистрации событий за 90 дней, были вызваны некоторыми нежелательными действиями или ошибками. Такие события называются «заведомо плохими событиями» и должны быть соответствующим образом помечены.
Теперь рассмотрим реализацию рассмотренной выше процедуры на примере системы с операционной системой Windows, на которой работает приложение «SecureFAIL», находящееся в области действия PCI DSS.
1. Убедитесь, что необходимые журналы регистрации событий приложений, входящих в область действия PCI DSS, сохранены в одном месте
Сначала проверьте, что в Windows запущено журналирование событий:
a. Откройте «Панель управления», выберите «Администрирование» и нажмите на «Просмотр событий»
b. Нажмите правой кнопкой мыши на «Журнал безопасности» и выберите «Свойства»; в результате должно появиться такое окно:
c. Затем проверьте настройки политики аудита
После этого нужно проверить папку, в которую записывает журналы регистрации событий приложение «SecureFAIL»
a. Откройте «C:\Program Files\SecureFAIL\Logs»
b. Проверьте содержимое этой папки, оно должно выглядеть следующим образом:
2. Выберите период времени для создания профиля «нормальной» деятельности: «90 дней» или «за все время», если журналы содержат события менее чем за 90 дней
a. Журналы Windows: доступна информация по событиям не менее чем за 30 дней
b. Журналы SecureFAIIL: доступна информация по событиям не менее чем за 90 дней
Таким образом, профиль «нормальной» деятельности можно создавать по данным за 30 дней, поскольку данные для Windows у нас есть только за 30 дней.
3. Проанализируйте записи в журналах от самой старой до самой новой, пытаясь идентифицировать типы событий
a. Проанализируйте журналы Windows с помощью утилиты Microsoft LogParser Tool (может быть загружена здесь: http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en)
Запускаем утилиту:
C:\Tools\LogParser.exe "SELECT SourceName, EventCategoryName, Message INTO event_log_summary.txt GROUP BY EventCategoryName FROM Security'" -resolveSIDs:ON
И анализируем выданные ей результаты по типам событий.
b. Откройте файл «secureFAIL_log-082009.txt» с помощью «Блокнота» и проанализируйте его содержимое. Утилита LogParser, указанная выше, может также использоваться для анализа журналов регистрации событий, содержащих простой текст (детальные инструкции по работе с этой утилитой выходят за рамки настоящего Руководства).
4. Вручную сформируйте отчет с итоговой информацией обо всех идентифицированных типах событий; по возможности, посчитайте количество событий каждого идентифицированного типа
Этот шаг аналогичен соответствующему шагу при создании профиля «нормальной» деятельности с использованием автоматизированных средств. В результате должен быть получен профиль, представляющий собой таблицу со всеми типами событий, как показано ниже:
Идентификатор события Описание события Кол-во Среднее кол-во в день 1517 Ошибка записи в реестр 212 2,3 562 Неудачная попытка входа 200 2,2 563 Вход выполнен 24 0,3 550 Обновлены учетные данные пользователя 12 0,1 665 Недостаточно памяти 1 0,0
5. Если есть основания полагать, что за этот период времени не было фактов нарушения безопасности данных платежных карт, мы можем принять созданный в п.4 отчет в качестве профиля «нормального» ежедневного функционирования систем
При проведении первоначального анализа этих журналов регистрации событий, может потребоваться провести расследование в отношении некоторых из записанных в них событий (как, например, последнее событие, указанное в приведенной выше таблице), чтобы убедиться в том, что они не могли привести к нарушению безопасности данных платежных карт. На следующем шаге поясняется, как это сделать.
6. Также, при создании профиля должны быть выполнены следующие дополнительные действия: даже если мы уверены, что никаких нарушений безопасности данных платежных карт не было, существует вероятность, что некоторые события, записанные в анализируемые журналы регистрации событий за 90 дней, были вызваны некоторыми нежелательными действиями или ошибками. Такие события называются «заведомо плохими событиями» и должны быть соответствующим образом помечены
Также как и при создании профиля с использованием автоматизированных средств, мы обращаем внимание на последнюю строку, в которой указана информация о событии с типом 665 «Недостаточно памяти», которое только однажды произошло за 30 дней. Такие редкие события интересны. Описание события («Недостаточно памяти») может также указывать на потенциальную серьезную проблему и поэтому оно должно быть расследовано в соответствии с описанной ниже процедурой для таких расследований.Руководство по выявлению «заведомо плохих событий»
Какие события можно считать «заведомо плохими» для большинства приложений? Ниже приведены несколько приблизительных инструкций для пометки «заведомо плохих событий» в процессе создания профиля «нормальной» деятельности. Поиск таких событий проводится в первую очередь в рамках процедуры ежедневного анализа журналов регистрации событий. Приведенные ниже события – это только отправная точка, они должны быть дополнены множеством специфичных событий, относящихся к конкретным системам и приложениям, используемым вашей компанией.
- События регистрации в системе и события предоставления доступа, произошедшие в нерабочее время
- События изменения учетных данных и прав доступа, произошедшие вне периода времени, когда производятся такие изменения
- Любые события от имени просроченных учетных записей
- События перезагрузки / перезапуска, произошедшие вне периода времени, когда производится сопровождение системы
- События резервного копирования / экспорта данных, произошедшие вне периода времени резервного копирования (если определено)
- События удаления данных из журналов регистрации событий
- Отключение журналирования событий в системе или приложении
- Любые события внесения изменений в настройки журналирования событий в системе или приложении
- Другие события, очевидно связанные с нарушением политики безопасности
После создания профиля «нормальной» деятельности, можно приступать к выполнению ежедневного анализа журналов регистрации событий. Но остался еще один вопрос – нужно решить, с какой периодичностью реально будет выполняться этот «ежедневный» анализ.
Частота периодического анализа журналов регистрации событий
Пункт 10.6 PCI DSS требует проводить анализ журналов регистрации событий не реже одного раза в день. Соответственно, это предполагает необходимость проведение анализа журналов каждый день. Однако если существуют веские причины, по которым проведение ежедневного анализа невозможно, можно выполнять его реже, реализовав необходимые компенсирующие меры, оценить которые должен будет QSA. В приведенном ниже списке указаны некоторые приемлемые причины, по которым анализ журналов регистрации событий может выполняться реже одного раза в день.
- Приложение или система не генерирует события каждый день. Если записи в журнал не добавляются каждый день, ежедневный их анализ, скорее всего, не требуется.
- Анализ журналов выполняется с использованием системы управления журналами регистрации событий, которая собирает журналы в пакетном режиме, но пакеты с журналами поступают реже одного раза в день (такой редкий сбор журналов не рекомендуется, но иногда так бывает).
- Приложение не обрабатывает и не хранит данные платежных карт – оно находится в области действия PCI DSS только потому, что подключено к одной из систем, обрабатывающих или хранящих данные платежных карт.
Процедура анализа журналов регистрации событий
Основной частью процесса анализа журналов регистрации событий является сравнение журналов, созданных за прошедший день (в случае выполнения ежедневного анализа), со сформированным профилем «нормальной» деятельности. Рабочий процесс ежедневного анализа журналов показан на Рисунке 3, который иллюстрирует действия аналитика безопасности, выполняющего ежедневный анализ журналов.
Рисунок 3. Рабочий процесс ежедневного анализа журналов регистрации событий
Возникает вопрос, как проводить сравнение накопленных за день журналов регистрации событий с профилем «нормальной» деятельности? Возможны два метода, которые широко используются при анализе журналов регистрации событий: обычное сравнение и расширенное сравнение. Выбор может быть сделан на основе имеющихся ресурсов и используемых инструментов. На Рисунке 4 показано различие между этими методами.
Рисунок 4. Методы сравнения журналов регистрации событий с профилем «нормальной» деятельности
Первый из этих методов анализирует только тип события и проверяет, встречался ли он раньше. Этот метод подходит для выполнения как вручную, так и с помощью автоматизированных средств. Несмотря на свою простоту, он очень эффективен при выявлении множества различных инцидентов: даже простого выявления новых событий обычно достаточно для целей безопасности, эксплуатации и соответствия. Например, если события с идентификаторами 1, 2, 3, 4, 5, 6 и 7 постоянно, ежедневно и в большом количестве попадают в журналы регистрации событий, то событие с идентификатором 8, которое раньше ни разу не встречалось, будет являться поводом для проведения расследования. Если в процессе расследования выяснится, что событие 8 является естественным, не представляет угрозы и не требует каких-либо действий, оно должно быть добавлено в профиль «нормальной» деятельности.
Более подробно виды проверок, выполняемые двумя методами сравнения, приведены ниже:
- Обычный метод
- Событие обнаружено впервые (новый тип события)
- Расширенный метод
- Событие обнаружено впервые (новый тип события)
- Событие происходило чаще, чем в профиле «нормальной» деятельности
- Событие происходило реже, чем в профиле «нормальной» деятельности
- Событие обнаружено впервые для конкретного пользователя
- Событие обнаружено впервые для конкретного приложения
- Событие обнаружено впервые в выходные дни
- Событие обнаружено впервые в рабочее время
- Событие от имени нового пользователя (ранее от имени этого пользователя не было зарегистрировано ни одного события)
При использовании расширенного метода, могут применяться и другие виды проверок, реализованные в используемой системе управления журналами регистрации событий.
Процедура расследования и анализа необычных событий
Если в процессе анализа журналов регистрации событий выявлено необычное событие, мы переходим к другой процедуре в рамках ежедневного рабочего процесса – от анализа журналов регистрации событий к расследованию и анализу.
Событие, не соответствующее профилю «нормальной» деятельности, считается «необычным». Нужно отметить, что необычное событие – это не то же самое, что инцидент безопасности, но выявить его нужно как можно раньше.
В рамках данной процедуры у нас есть конкретное событие, которое выходит за рамки «нормальной» деятельности. Как определить его критичность, влияние на безопасность и состояние соответствия требованиям PCI DSS?
Первичное расследование
На Рисунке 5 приведен высокоуровневый процесс расследования (первичное расследование), которое проводится для каждого выявленного необычного события:
Рисунок 5. Процесс первичного расследования необычного события
Наиболее важным элементом приведенного выше процесса является список вопросов для проведения расследования необычного события:
1. Посмотреть, какие события происходили в то же время. Проверяются события, которые происходили за постепенно расширяемый период времени до и после расследуемого необычного события. Большинство систем управления журналами регистрации событий позволяют выбрать события за интересующий период времени из одного или нескольких (всех) журналов. Например:
a. Сначала просмотреть события, произошедшие за период времени от 1 минуты до необычного события до 1 минуты после этого события
b. Затем просмотреть события, произошедшие за период времени от 10 минут до необычного события до 10 минут после этого события
c. После этого просмотреть события, произошедшие за период времени от 1 часа до необычного события до 1 часа после этого события2. Посмотреть другие события от имени этого пользователя. Проверяются другие события в журналах, созданные в результате действий этого пользователя. Часто бывает так, что отдельное событие можно правильно интерпретировать только в окружении других событий по действиям того же пользователя. Большинство средств управления журналами регистрации событий позволяет все события по действиям определенного пользователя за определенный период времени.
3. Проверить наличие событий того же типа в других системах, что может позволить определить степень воздействия этого события.
4. Посмотреть события от того же источника. Анализируются все события, ссылающиеся на тот же сетевой адрес источника (если это нужно).
5. Посмотреть события от того же приложения. Если при проверке событий, которые происходили в то же время (см. п.1) выявляется что-то важное, проводится анализ всех события от того же прикладного модуля или компонента. Обычно это сильно помогает понять происходящее.
В некоторых случаях, выполнение приведенных выше шагов не дает результата. Остается непонятным влияние необычного события на безопасность и на соответствие требованиям PCI DSS. В таком случае, нужно получить информацию из других систем, таких как Мониторинг целостности файлов, Управление уязвимостями, Защита от вредоносного кода, Управление обновлениями, Управление идентификацией (IdM), Управление сетью и т.п.
Внешние источники информации для расследования
На Рисунке 6 показана процедура, которая должна применяться для более глубокого анализа необычного события.
Рисунок 6. Процедура углубленного анализа необычного события
Эта процедура может быть расширена, чтобы охватить все источники информации, имеющиеся в компании. Основными этапами этой процедуры являются:
- Определение возможных источников информации (например, IdM, управление изменениями, контроль целостности, анализ сетевых потоков и т.п.) на основе типа необычного события
- Выполнение запроса сведений из этих источников
- Определение степени влияния этого события на безопасность и соответствие требованиям PCI DSS, исходя из полученной информации
- Определение действий, которые необходимо предпринять (если необходимо)
В рамках процедуры определяется тип необычного события и запрашивается дополнительная информация из соответствующих источников. В случае если анализ полученной информации указывает на наличие серьезной проблемы, инициируется процедура реагирования на инцидент.
Однако бывает, что ни предварительный анализ, ни углубленный анализ с использованием дополнительной информации из внешних систем не дают результата, и необычная запись в журнале регистрации событий остается неясной. В таком случае необходимо эскалировать расследование и привлечь к нему других людей для проведения совместного анализа.
Эскалация расследования и проведение совместного анализа
Соответствующая процедура показана на Рисунке 7.
Рисунок 7. Привлечение к расследованию дополнительных людей
Эта процедура позволяет воспользоваться знаниями других сотрудников компании, которые могут что-то знать об этой «аномалии». Основной задачей данной процедуры является определение нужных людей и проведение беседы с ними с целью определения влияния необычного события и действий, которые необходимо предпринять в связи с ним (если необходимо).
Самым последним источником информации в такой ситуации может быть производитель приложения. Обычно такие запросы занимают много времени, а срочное предоставление информации может быть очень дорогим (в зависимости от условий заключенного договора на сопровождение).
Комментариев нет:
Отправить комментарий