9.1. Анализ журналов регистрации событий. Журнал регистрации событий

9.1. Анализ журналов регистрации событий

Журналы регистрации событий обязательно должны просматриваться и анализироваться. Это можно делать как вручную, так и с помощью автоматизированных средств. Если компания просматривает журналы вручную, необходимо систематизировать эту деятельность – что, как, когда и почему подлежит анализу. Обычно журналы регистрации событий становятся крайне востребованными после инцидента безопасности, непонятной работы системы или сбоя системы. Администратор или другой ответственный персонал пытается по-быстрому сопоставить различные действия, которые привели к этому инциденту. Такой тип анализа журналов регистрации событий называется ориентированным на события (event-oriented). Кроме того, журналы могут просматриваться на периодической основе, чтобы выявить необычное поведение пользователей и систем, а также убедиться в исправной работе системы. При этом перед администраторами должна быть поставлена соответствующая задача периодического просмотра журналов. Для контроля журналов в режиме реального времени (или близко к этому) существуют специальные автоматизированные средства. Данные журналов регистрации событий обычно должны анализироваться, а затем сохраняться в отдельное место для хранения в течение определенного периода времени. Это должно быть отражено в политике и процедурах безопасности компании. Анализ журналов регистрации событий вручную крайне трудоемок. Следует использовать для этого специализированные приложения и инструменты анализа, которые сокращают объем журналов и повышают эффективность ручных процедур анализа. Основное время при анализе журналов регистрации событий тратится на несущественную информацию, а эти инструменты позволяют выбирать необходимую информацию по заданным критериям и представлять ее в более наглядной и удобной форме. Существует три основных типа инструментов анализа журналов регистрации событий:

• Инструменты для уменьшения объема журналов (audit-reduction tool) отбрасывают обычные события работы программ и пользователей, записи счетчиков производительности системы, оставляя только те события, которые могут быть интересны специалистам по безопасности и администраторам

• Инструменты для выявления нарушений (variance-detection tool) отслеживают использование компьютера или ресурса, фиксируя стандартную картину, а затем выявляют отклонения от нее. Например, обычно использование ресурса происходит с 8:00 до 17:00 по рабочим дням. Факт использования этого ресурса ночью в выходной день является поводом отправки предупреждения администратору.

• Инструменты выявления сигнатур атак (attack signature-detection tool) имеют специализированную базу данных, содержащую информацию о событиях, которые могут указывать на определенные атаки (сигнатуры атак). В журналах отыскиваются последовательности событий, соответствующие сигнатурам атак.

9.2. Мониторинг нажатия клавиш

Мониторинг нажатия клавиш (keystroke monitoring) – это вид мониторинга, позволяющий проанализировать и записать последовательность нажатий клавиш пользователем в течение сеанса его работы. При этом все символы, набранные пользователем, записываются в специальный журнал, который может быть позднее проверен. Обычно такой тип аудита используется только для выполнения специальных задач и только на короткое время, поскольку объем собранной информации будет огромен, а ее значительная часть будет неважной. Если специалист по безопасности или администратор подозревают пользователя в проведении несанкционированных действий, они могут воспользоваться этим видом мониторинга. На некоторых санкционированных этапах проведения расследования между клавиатурой и компьютером может быть вставлено специальное устройство, перехватывающее все нажатия клавиш, включая набор пароля для загрузки системы (на уровне BIOS). Хакеры также могут использовать такой вид мониторинга. Если атакующий сможет установить троянскую программу на компьютер, она cможет внедрить специальную утилиту перехвата данных, вводимых с клавиатуры. Обычно таким программам наиболее интересны учетные данные пользователя, и они могут уведомить атакующего, когда такие данные будут успешно перехвачены. Нужно соблюдать осторожность при проведении такого мониторинга, т.к. это может нарушать законодательство. Следует заранее уведомить сотрудников о возможности такого мониторинга, а также получать разрешение руководства на его проведение. Если компания намерена использовать такой контроль, следует внести информацию об этом в политику безопасности, сообщать об этом на тренингах по вопросам безопасности, уведомить пользователей другими доступными способами о возможности такого мониторинга. Это позволит защитить компанию от претензий в нарушении неприкосновенности частной жизни, а также проинформирует пользователей об ограничениях использования рабочего компьютера в личных целях.

studfiles.net

журнал регистрации событий - это... Что такое журнал регистрации событий?

 журнал регистрации событий

1. event log

 

журнал регистрации событий-[Интент]

Тематики

• автоматизация, основные понятия

EN

Русско-английский словарь нормативно-технической терминологии. academic.ru. 2015.

• журнал регистрации скорости бурения скважины
• журнал регистрации событий на подстанции

Смотреть что такое "журнал регистрации событий" в других словарях:

• журнал регистрации событий — [Интент] Тематики автоматизация, основные понятия EN event log …   Справочник технического переводчика

• журнал регистрации событий на подстанции — Журнальная запись хронологически упорядоченных данных о событиях на подстанции. [ГОСТ Р 54325 2011 (IEC/TS 61850 2:2003)] EN log record (journal), of chronologically ordered data for example events with time tags and annotations [IEC 61850 2, ed …   Справочник технического переводчика

• интервал записи в журнал регистрации событий — периодичность записи значений (в журнале регистрации событий) [Интент] EN log interval The time between data samples being taken. For example in a vendor managed inventory application the log interval could be say 30 minutes, meaning that the… …   Справочник технического переводчика

• время выполнения записи (в журнал регистрации событий) — Тематики счетчик электроэнергии Синонимы время регистрации значения в журнал событий EN log time …   Справочник технического переводчика

• дата выполнения записи (в журнал регистрации событий) — Тематики счетчик электроэнергии EN log data …   Справочник технического переводчика

• журнал регистрации сетевых событий — аудиторское заключение — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом Синонимы аудиторское заключение EN audit trail …   Справочник технического переводчика

• Журнал — (от фр. journal дневник, газета) 1) Дневник или ведомость ежедн. регистрации к. л. событий или результатов той или иной деятельности. 2) Периодич. текстовое изд. в виде блока скрепленных в корешке листов печатного материала определ. формата.… …   Российский гуманитарный энциклопедический словарь

• ЖУРНАЛ — JOURNALВ бухгалтерии Ж. называют книгу первоначальных записей, где все операции отражаются в хронологическом порядке, т. е. по мере их проведения; в дальнейшем они поступают в БУХГАЛТЕРСКИЙ РЕГИСТР. Первоначальные записи иногда называют также… …   Энциклопедия банковского дела и финансов

• Файл регистрации — Эта статья или раздел нуждается в переработке. Пожалуйста, улучшите статью в соответствии с правилами написания статей. Файл регистрации, протокол …   Википедия

• Критика официальной версии событий 11 сентября 2001 года — Террористические акты 11 сентября 2001 года в США вызвали неоднозначную реакцию общественности. Факты, изложенные ниже, могут свидетельствовать о том, что необходимо новое независимое расследование этих терактов. Содержание 1 Официальная версия… …   Википедия

• Список событий в России, связанных с законом об экстремизме — Для улучшения этой статьи желательно?: Проставив сноски, внести более точные указания на источники. Переработать оформление в соответствии с правилами написания статей. Исправить статью согласно стилистическим правилам Вики …   Википедия

normative_ru_en.academic.ru

Журналы регистрации событий - PDF

Развитие облачных услуг

ВИРТУАЛЬНЫЙ ЦОД Развитие облачных услуг Оперативная модернизация ИТ-инфраструктуры Оптимизация текущих затрат на поддержание действующей инфраструктуры Обеспечение защиты и безопасности хранения корпоративной

Подробнее

Подсистема администрирования

Подсистема администрирования Руководство пользователя Январь, 2002 г. KASKAD Development Team Содержание: 1. Описание подсистемы. 2. Установка подсистемы. 3. Настройка сервера администрирования. 4. Настройка

Подробнее

КОММЕРЧЕСКОЕ ПРЕДЛОЖЕНИЕ

КОММЕРЧЕСКОЕ ПРЕДЛОЖЕНИЕ по оказанию услуг абонентского обслуживания компьютерной техники тел. +7 (495) 22-33-207 www.avk-company.ru [email protected] 117216, г. Москва, ул. Старокачаловская, д. 1, к.

Подробнее

Panda Endpoint Protection. С чего начать

Panda Endpoint Protection С чего начать Содержание Список рисунков... 4 Цель данного документа... 5 Предварительные действия... 5 1. Быстрый запуск Panda Endpoint Protection... 6 1.1. Подключение к консоли

Подробнее

ОБНАРУЖЕНИЕ СЕТЕВЫХ АТАК

ОБНАРУЖЕНИЕ СЕТЕВЫХ АТАК Система обнаружения вторжений (СОВ) необходимый компонент защиты Злоумышленнику, чтобы получить доступ к информации Вашей компании, необходимо пройти несколько эшелонов защиты.

Подробнее

ВПД ВПД.01 ВПД.02 ВПД.03 ВПД.04

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

Подробнее

PCI DSS 3.0: к чему готовиться?

Журналы регистрации событий PCI DSS 3.0: к чему готовиться? Андрей Гайко QSA- аудитор [email protected] 2002 2014, Digital Security Главные новости Опубликован официальный перевод стандарта Опубликованы

Подробнее

Защита баз данных в банке

Защита баз данных в банке Аналитический центр ООО «МФИ Софт» 2013 год стр. 2 / из 12 Содержание Распространенные проблемы защиты баз данных... 4 Журналирование и аудит штатными средствами Интегрированный

Подробнее

Решения Imperva для защиты СУБД

17 лет на рынке информационной безопасности Решения Imperva для защиты СУБД Бейбутов Эльман Руководитель направления защиты БД и SOC 10 апреля 2014 г. Комплекс решений Imperva SecureSphere LifeCycle защиты

Подробнее

Решения Symantec по Безопасности

Решения Symantec по Безопасности Обзор Symantec Security Information Manager 4.6 Важнейшим условием работы большинства современных организаций является обеспечение необходимого и достаточного уровня информационной

Подробнее

Новые возможности СЗИ Secret Net 7

Новые возможности СЗИ Secret Net 7 СЗИ Secret Net Secret Net предназначен для защиты конфиденциальной информации, составляющей коммерческую, государственную тайну или относящейся к персональным данным.

Подробнее

О Zecurion.

2 О Zecurion Основана в 2001 году Фокус защита от утечек (DLP) Российские и международные награды Технологический лидер российского DLP-рынка (Anti-Malware.ru) Лидер по обороту среди DLP-вендоров (CNews)

Подробнее

С Л У Ж Б А Р Е З Е Р В Н О Г О К О ПИРОВАН ИЯ

ООО НПП ЭЛЕКОМ Информационно-вычислительный комплекс ЭЛЕКОМ-Информ С Л У Ж Б А Р Е З Е Р В Н О Г О К О ПИРОВАН ИЯ Описание и руководство пользователя 2014 год ОГЛАВЛЕНИЕ Назначение службы резервного копирования

Подробнее

Руководство администратора Приложение 4

Министерство образования и науки Российской Федерации УТВЕРЖДАЮ Заместитель директора ФГУ ГНИИ ИТТ «Информика» А.Д. Ландарь 2010 г. ОТКРЫТАЯ МОДУЛЬНАЯ СИСТЕМА ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА И КОНТРОЛЯ ИСПОЛНЕНИЯ

Подробнее

Аутсорсинг процессов ИБ на основе SLA

Аутсорсинг процессов ИБ на основе SLA Гольдштейн Анна Директор по развитию ЗАО НИП «Информзащита» Содержание Предпосылки аутсорсинга процессов ИБ; Типовые сервисы ИБ; Разделение зон ответственности; Cодержание

Подробнее

Правила оказания отдельных услуг

Правила оказания отдельных услуг 1 Правила оказания услуги «Виртуальная инфраструктура» 1 Термины 1.1 Виртуальный сервер эмуляции аппаратной платформы для запуска на ней операционной системы Абонента;

Подробнее

КАКИЕ ЗАДАЧИ БИЗНЕСА РЕШАЕТ SIEM?

searchinform.ru КАКИЕ ЗАДАЧИ БИЗНЕСА РЕШАЕТ SIEM? Проблема IT-инфраструктура современной компании сложный механизм, состоящий из множества корпоративных систем: Active Directory, 1С, CRM, Exchange, антивирусы

Подробнее

INFOWATCH ENDPOINT SECURITY INSIGHT EDITION

InfoWatch EndPoint Security Insight Edition это простая и удобная система мониторинга и защиты, которая выявляет слабые места корпоративной сети, формирует картину рабочего дня персонала и предлагает инструменты

Подробнее

GPS_Sinhro_SNTP_Server SNTP_Client

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ СИНХРОНИЗАЦИИ ВРЕМЕНИ GPS_Sinhro_SNTP_Server SNTP_Client ИНСТРУКЦИЯ ПОЛЬЗОВАТЕЛЯ Харьков 2016 СОДЕРЖАНИЕ 1 Основные функции программного обеспечения... 3 2 Инсталляция и подготовка

Подробнее

F-Secure Anti-Virus for Mac 2015

F-Secure Anti-Virus for Mac 2015 2 Содержание F-Secure Anti-Virus for Mac 2015 Содержание Глава 1: Начало работы...3 1.1 Управление подпиской...4 1.2 Как убедиться, что компьютер защищен...4 1.2.1 Значки

Подробнее

Роль аудита информационной безопасности

Роль аудита информационной безопасности Директор Департамента информационной безопасности ОАО МГТС А.А. Хрусталев Москва, Что такое аудит ИБ 2 Аудит ИБ организации: Систематический, независимый и документируемый

Подробнее

С Л У Ж Б А П Е Р Е Д А Ч И М А К Е Т О В

ООО НПП ЭЛЕКОМ Информационно-вычислительный комплекс ЭЛЕКОМ-Информ С Л У Ж Б А П Е Р Е Д А Ч И М А К Е Т О В 6 3 0 02 Описание и руководство пользователя 2014 год ОГЛАВЛЕНИЕ Назначение службы передачи

Подробнее

SOC КАК РЕШЕНИЕ ИЛИ СЕРВИС ЧТО ВЫБРАТЬ?

SOC КАК РЕШЕНИЕ ИЛИ СЕРВИС ЧТО ВЫБРАТЬ? ЧТО ТАКОЕ SOC? SOC Security Operation Center. Совокупность программно-аппаратных средств, персонала и процессов, предназначенных для централизованного сбора и анализа

Подробнее

ЛЕКЦИЯ 14 УДАЛЁННЫЙ ДОСТУП И ЗАЩИТА ДАННЫХ

ЛЕКЦИЯ 14 УДАЛЁННЫЙ ДОСТУП И ЗАЩИТА ДАННЫХ Лектор Ст. преподаватель Купо А.Н. Файловая система и программные средства уплотнения носителей Удалённый доступ и программные средства ограничения доступа Файловая

Подробнее

Режим работы «Контроль обходов»

Режим работы «Контроль обходов» Краткое описание Режим работы «Контроль обходов» является частью программного обеспечения «Эпикур» и предназначен для организации контроля за работой сотрудников по патрулированию

Подробнее

docplayer.ru

журнал регистрации событий - это... Что такое журнал регистрации событий?

 журнал регистрации событий

event log

Русско-английский индекс к Англо-русскому толковому словарю терминов и сокращений по ВТ, Интернету и программированию. Э.М. Пройдаков, Л.А. Теплицкий. 1998-2004.

• журнал регистрации ошибок
• журнал регистрации транзакций

Смотреть что такое "журнал регистрации событий" в других словарях:

• журнал регистрации событий — [Интент] Тематики автоматизация, основные понятия EN event log …   Справочник технического переводчика

• журнал регистрации событий на подстанции — Журнальная запись хронологически упорядоченных данных о событиях на подстанции. [ГОСТ Р 54325 2011 (IEC/TS 61850 2:2003)] EN log record (journal), of chronologically ordered data for example events with time tags and annotations [IEC 61850 2, ed …   Справочник технического переводчика

• интервал записи в журнал регистрации событий — периодичность записи значений (в журнале регистрации событий) [Интент] EN log interval The time between data samples being taken. For example in a vendor managed inventory application the log interval could be say 30 minutes, meaning that the… …   Справочник технического переводчика

• время выполнения записи (в журнал регистрации событий) — Тематики счетчик электроэнергии Синонимы время регистрации значения в журнал событий EN log time …   Справочник технического переводчика

• дата выполнения записи (в журнал регистрации событий) — Тематики счетчик электроэнергии EN log data …   Справочник технического переводчика

• журнал регистрации сетевых событий — аудиторское заключение — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом Синонимы аудиторское заключение EN audit trail …   Справочник технического переводчика

• Журнал — (от фр. journal дневник, газета) 1) Дневник или ведомость ежедн. регистрации к. л. событий или результатов той или иной деятельности. 2) Периодич. текстовое изд. в виде блока скрепленных в корешке листов печатного материала определ. формата.… …   Российский гуманитарный энциклопедический словарь

• ЖУРНАЛ — JOURNALВ бухгалтерии Ж. называют книгу первоначальных записей, где все операции отражаются в хронологическом порядке, т. е. по мере их проведения; в дальнейшем они поступают в БУХГАЛТЕРСКИЙ РЕГИСТР. Первоначальные записи иногда называют также… …   Энциклопедия банковского дела и финансов

• Файл регистрации — Эта статья или раздел нуждается в переработке. Пожалуйста, улучшите статью в соответствии с правилами написания статей. Файл регистрации, протокол …   Википедия

• Критика официальной версии событий 11 сентября 2001 года — Террористические акты 11 сентября 2001 года в США вызвали неоднозначную реакцию общественности. Факты, изложенные ниже, могут свидетельствовать о том, что необходимо новое независимое расследование этих терактов. Содержание 1 Официальная версия… …   Википедия

• Список событий в России, связанных с законом об экстремизме — Для улучшения этой статьи желательно?: Проставив сноски, внести более точные указания на источники. Переработать оформление в соответствии с правилами написания статей. Исправить статью согласно стилистическим правилам Вики …   Википедия

computers_ru_en.academic.ru

Контроль 14 | Информационная безопасность

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

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

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

 

Реализация, автоматизация и оценка эффективности Контроля 14

1. Быстрые победы. Следует проверять настройки журналов аудита для каждого аппаратного устройства и установленного на нем ПО, удостовериться, что в журналах регистрируется дата, временная отметка, адреса источника и назначения и другие полезные элементы каждого пакета и/или транзакции. Системы должны вести записи в журналах в стандартизированном формате, например, записи syslog или рекомендованные документом Общепринятые сообщения о событиях Common Event Expression (СЕЕ). При невозможности генерации системами журналов регистрации событий записей в стандартном формате можно использовать средства нормализации журналов, которые могут устанавливаться для преобразования журналов в стандартный формат.

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

3. Быстрые победы. Весь удаленный доступ к сети, как к демилитаризованной зоне, так и ко внутренней сети (например, с помощью VPN, коммутируемого доступа или другого механизма) подлежит подробной регистрации.

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

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

6. Прозрачность/Аттрибуция. В организации должно существовать как минимум два синхронизированных датчика времени (например, Network Time Protocol – NTP)), от которых все серверы и сетевое оборудование систематически запрашивают информацию о времени для согласования временных меток.

7. Прозрачность/Аттрибуция. Устройства сетевого интерфейса, включающие МСЭ, сетевые системы предотвращения вторжений, входящие и исходящие прокси, должны быть сконфигурированы для подробной регистрации всего трафика (как разрешенного, так и блокированного), поступающего на устройство.

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

9. Прозрачность/Аттрибуция. Следует установить инструмент системы SIEM для объединения и согласования журналов с большого числа машин, а также для соотнесения и анализа их информации. Должны устанавливаться и отслеживаться стандартные сценарии для анализа журналов, возможно также применение пользовательских локальных скриптов. Используя инструмент SIEM, системные администраторы и персонал безопасности должны разрабатывать профили обычных событий в рассматриваемых системах для того, чтобы настроить обнаружение на необычную деятельность, избегать ложных срабатываний, быстрее идентифицировать аномалии и предотвращать перегрузку аналитиков ложными сигналами тревоги.

 

Процедуры и инструменты для реализации и автоматизации этого средства управления

Большинство бесплатных и коммерческих операционных систем, сетевых сервисов и технологий экранирования предлагают функции регистрации информации. Эти функции следует активировать с указанием передачи журналов на централизованный сервер журналов учета событий. МСЭ, прокси и системы удаленного доступа (VPN, коммутируемый доступ и т.д.) должны все быть сконфигурированы для подробной регистрации, сохраняя всю информацию, доступную для регистрации в событии для последующего  исследования. В дальнейшем операционные системы, в особенности установленные на серверах, должны быть сконфигурированы на создание записей управления доступом при попытках пользователя получить доступ к ресурсам без соответствующих прав. Для оценки наличия регистрации событий, следует периодически просматривать журналы и сравнивать их с реестром ресурсов, созданным в Критичном Контроле 1, для гарантии того, что каждая управляемая единица, активно подключенная к сети, периодически генерирует журналы регистрации событий.

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

 

Метрика Контроля 14

Система должны быть способна вести учет всех событий в сети. Регистрация событий должна действовать во всех сетевых и централизованных системах. Любое событие должно генерировать запись в журнале, включающую дату, временную метку, адрес источника, адрес назначения и другие детали пакета. Любая деятельность в сети немедленно должна регистрироваться во всех задействованных устройствах. При невозможности генерации записи в журнале (из-за поломки сервера журналов или по другой причине), устройство должно генерировать сигнал тревоги или эл.сообщение для административного персонала организации в течение 24 часов.  Текущая метрика составляет 24 часа, однако, для улучшения состояния системы безопасности в будущем организации должны стремиться к более скорой генерации сигналов – желательно, чтобы уведомление об отказе регистрации события высылалось через 2 минуты

 

Тестирование Контроля 14

Для периодической оценки реализации Контроля 14 группа оценки должна просматривать журналы безопасности разных сетевых устройств, серверов и хостов. Должны тестироваться как минимум следующие устройства: два маршрутизатора, два МСЭ, два коммутатора, 10 серверов и 10 клиентских систем. Группа тестирования должна использовать средства генерации трафика для передачи пакетов через анализируемые системы для подтверждения того, что трафик регистрируется. Этот анализ проводится созданием управляемых невредоносных событий и определением правильности записываемой в журналы информации (содержащей дату, временную метку, адреса источника и назначения и другие детали пакета). Группа оценки должна удостовериться, что система генерирует журналы аудита, в ином случае генерируется сигнал тревоги или эл.уведомление об отказе регистрации в течение 24 часов. Важно, чтобы группой оценки было проверено, что обнаруживается любая активность в сети. Группа оценки должна убедиться, что система предоставляет информацию о расположении каждой машины, включая информацию о владельце ресурса.

 

Сенсоры, оценка и результат для Контроля 14

Сенсор: NTP Network Time Protocol

Оценка: Убедитесь, что для синхронизации времени для всех устройств используется NTP и что все часы синхронны.

Результат: Соответствует / Не соответствует.

Сенсор: Сканер уязвимостей

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

Результат: Соответствует / Не соответствует.

Сенсор: SIEM

Оценка: Соотнесите журналы с центральным источником и определите, все ли серверы правильно регистрируют события.

Результат: 100 %, если все системы правильно регистрируют события. Минус 5% за каждую систему без регистрации.

 

Контроль 14: Диаграмма системы межобъектных отношений (System Entity RelationshipDiagram):

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

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

Шаг 1: Производственные системы генерируют журналы и отправляют их в централизованно управляемую систему баз данных журналов

Шаг 2: Производственные системы и система баз данных журналов синхронизируются по времени с центральными системами управления временем

Шаг 3: Журналы анализируются системой анализа журналов SIEM

Шаг 4: Аналитики журналов изучают данные, полученные из SIEM

itsec.by

Практика ИБ \ Процедуры анализа журналов регистрации событий в соответствии с PCI DSS. Часть 1

Антон Чувакин опубликовал в своем блоге практическое Руководство по организации процедур анализа журналов регистрации событий в соответствии с требованиями PCI DSS. Руководство достаточно универсально и может использоваться в качестве основы при организации анализа событий в рамках любых других требований, в том числе СТО БР ИББС-1.0, РС БР ИББС-2.3, ISO 27002, CobiT, либо просто в рамках реализации программы обеспечения безопасности компании без каких-либо внешних требований.

При переводе руководство было мной немного актуализировано и приведено в соответствие с требованиями новой версии PCI DSS 2.0. Руководство состоит из трех основных частей:

1. Описание требований PCI DSS в части журналирования событий, 
2. Описание процедур анализа журналов регистрации событий,
3. Описание доказательств, которые потребуются для подтверждения соответствия требованиям PCI DSS в части журналирования событий.

В первой части рассмотрены следующие вопросы:

• Цели создания Руководства
• Начальные требования и предположения
• Вопросы, которые не вошли в Руководство
• Роли и обязанности
• Требования PCI DSS в части журналирования событий
• Требования раздела 10 PCI DSS
• Другие требования, связанные с журналами регистрации событий

Руководство разработано для специалистов по информационной безопасности, которые пока не являются экспертами в области сбора и анализа журналов регистрации событий. С помощью этого Руководства они могут выполнить свои задачи в рамках требований PCI DSS и повысить свою квалификацию. Хотя Руководство направлено в первую очередь на реализацию требований PCI DSS, оно также может быть полезно в качестве эффективной практики по анализу журналов регистрации событий при реализации любых других требований.

Несколько советов тем, кто решит воспользоваться этим Руководством в своей компании:

• Если вам нужно организовать процедуры анализа журналов регистрации событий в соответствии с требованиями п.10.6 PCI DSS («анализируйте журналы регистрации событий всех системных компонентов не реже одного раза в день») – пользуйтесь этим Руководством и адаптируйте его для своей среды.
• В Руководстве больше внимания уделяется журналированию событий операционной системы и приложений, но вам потребуется также анализировать события сетевых устройств и средств безопасности. К ним применимы те же методы и подходы.
• Руководство было проанализировано QSA и было им одобрено. Однако мнение вашего QSA может быть иным.

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

1. Должна быть разработана Политика ведения журналов регистрации событий и другие нормативные документы, детализирующие и систематизирующие требования PCI DSS в отношении журналирования событий.
2. Ведение журналов регистрации событий должно быть включено на всех системах, входящих в область, к которой применяются требования PCI DSS.
3. Факты отключения или прерывания процесса журналирования событий должны регистрироваться и отслеживаться.
4. В журналы регистрации событий должны записываться все события, требуемые PCI DSS и Политикой ведения журналов регистрации событий.
5. Создаваемые журналы регистрации событий должны соответствовать требованиям PCI DSS (в частности, требованиям п.10.3).
6. Время на всех системах, входящих в область действия PCI DSS, должно быть синхронизировано с использованием надежного сервера времени (с помощью NTP или другой технологии, соответствующей требованиям п.10.4 PCI DSS).
7. Часовые пояса, в которых работают системы, выполняющие журналирование событий, должны быть известны, зафиксированы и пригодны для учета в процессе анализа журналов.

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

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

В Таблице 1 перечислены вопросы, которые не рассматриваются в настоящем Руководстве, несмотря на то, что они могут иметь важное значение для достижения соответствия требованиям PCI DSS.

Вопрос	Почему он не вошел в Руководство?
Какие события должны журналироваться в каждом приложении?	Настоящее Руководство касается только процедур анализа журналов регистрации событий. Предполагается, что само журналирование уже реализовано надлежащим образом в соответствии с требованиями PCI DSS и Политики ведения журналов регистрации событий
Какую информацию нужно записывать в журнал для каждого журналируемого события в каждом приложении?	Настоящее Руководство касается только процедур анализа журналов регистрации событий. Предполагается, что само журналирование уже реализовано надлежащим образом в соответствии с требованиями PCI DSS и Политики ведения журналов регистрации событий
Высокоуровневая политика ведения и мониторинга журналов регистрации событий	Подразумевается, что эта политика уже должна быть введена в действие
Политики и процедуры сбора, обработки и сохранения событий	Эти процедуры не рассматриваются в настоящем Руководстве
Процедуры реагирования на инциденты информационной безопасности	Настоящее Руководство касается только процедур анализа журналов регистрации событий. Выполнение этих процедур иногда приводит к необходимости инициирования процедур реагирования на инциденты и проведения расследований
Приложения, которые не входят в область действия PCI DSS	Настоящее Руководство охватывает только приложения, находящиеся в области действия PCI DSS
Сетевые устройства, которые входят или не входят в область действия PCI DSS	Настоящее Руководство охватывает только приложения, находящиеся в области действия PCI DSS. Но в вашем проекте по организации анализа журналов регистрации событий сетевые устройства обязательно должны быть учтены!
Контроль доступа к хранящимся журналам регистрации событий, защита конфиденциальности и целостности данных в журналах регистрации событий	Эти процедуры не рассматриваются в настоящем Руководстве
Компенсирующие меры для случаев, когда ведение журналов регистрации событий невозможно	Настоящее Руководство касается только процедур анализа журналов регистрации событий. Анализ журналов всегда возможен, если возможно их ведение. Ситуации, когда ведение журналов невозможно, в настоящем Руководстве не рассматриваются
Мониторинг в режиме реального времени состояния централизованной системы журналирования событий, ее производительности и т.п.	Настоящее Руководство касается только процедур анализа журналов регистрации событий
Требования к журналированию событий, помимо разделов 10 и 12 PCI DSS	Настоящее Руководство ограничивается только требованиями разделов 10 и 12 PCI DSS. Краткий обзор других требований к журналированию также приводится, но для них не приводятся детальные процедуры
Гарантии успешного прохождения аудита на соответствие требованиям PCI DSS	Только QSA каждой компании может предоставить такие гарантии после проведения аудита
Правила корреляции для мониторинга событий	Настоящее Руководство касается только процедур анализа журналов регистрации событий, но не правил корреляции. Однако некоторые вопросы, имеющие отношение к правилам корреляции, в настоящем Руководстве рассматриваются
Сохранение записей журнала регистрации событий для целей криминалистического анализа	Вопрос сохранения записей журнала регистрации событий для целей криминалистического анализа, относится к процедурам реагирования на инциденты

Таблица 1. Перечень вопросов, не вошедших в Руководство В Таблице 2 перечислены роли, использующиеся в процедурах анализа журналов регистрации событий, а также их обязанности в рамках этих процедур. Далее эти роли и обязанности будут рассмотрены более детально.

Роль	Обязанности	Пример участия в анализе журналов
Администратор приложения	Администрирует приложение	Настройка системы регистрации событий в приложении, выполнение ежедневного анализа журналов регистрации событий для выявления технических проблем
Системный и сетевой администратор	Администрирует операционную систему, на которой работает приложение, и сеть	Настройка системы регистрации событий, выполнение ежедневного анализа журналов регистрации событий для выявления технических проблем
Бизнес-владелец приложения	Руководитель бизнес-подразделения, ответственный за приложение	Утверждает изменения в конфигурации приложения в части ведения и анализа журналов регистрации событий
Администратор безопасности	Администрирует средства безопасности на одной или нескольких системах / приложениях	Настройка механизмов безопасности и системы аудита в приложении, выполнение ежедневного анализа журналов регистрации событий для выявления технических проблем (только принимает участие!)
Аналитик безопасности	Работает с процессами обеспечения безопасности при эксплуатации приложения	Использование систем безопасности, просмотр журналов регистрации событий и других данных, выполнение ежедневного анализа журналов регистрации событий
Руководитель подразделения информационной безопасности	Контролирует соблюдение политики безопасности, выполнение процессов обеспечения безопасности, эксплуатации средств безопасности	Владелец процедур анализа журналов регистрации событий, обновляет эти процедуры по мере необходимости
Ответственный за реагирование на инциденты	Участвует в мероприятиях по реагированию на инциденты безопасности	Работа с инцидентами безопасности, анализ журналов регистрации событий в рамках мероприятий по реагированию на инциденты безопасности

Таблица 2. Перечень ролей, участвующих в процедурах анализа журналов регистрации событий В этом разделе рассмотрены требования PCI DSS в части журналирования событий. Следует отметить, что вопросы ведения и мониторинга журналов регистрации событий рассматриваются не только в разделе 10, раздел 12 также затрагивает эти вопросы. Однако основной областью настоящего Руководства являются требования раздела 10. Сначала мы рассмотрим требования каждого из пунктов, а затем углубимся в детали, примеры и рекомендации по реализации.

10.1

«Реализуйте процесс, обеспечивающий связь любых фактов доступа к системным компонентам (в особенности доступа, с использованием административных привилегий, например, root) с конкретными пользователями». PCI DSS не просто требует обеспечить наличие журналов регистрации событий или организовать процесс их сбора, он требует обеспечить связь событий, отраженных в журнале регистрации, с конкретными людьми (а не компьютерами или устройствами, которые были источником события). Это требование часто создает проблемы для внедряющих PCI DSS. Многие начинают думать о журналах, как о «записях о действиях людей», тогда как в действительности они являются «записями о действиях компьютеров». Кстати, требование п.8.1 PCI DSS, которое говорит, что «каждому пользователю должно быть присвоено уникальное имя (идентификатор) до предоставления ему доступа к системным компонентам или данным платежных карт», помогает и при реализации требования п.10.1, делая журналы регистрации событий более полезными.

10.2

п.10.2 определяет минимальный перечень системных событий, которые должны журналироваться. Это требование вызвано необходимостью проведения оценки и мониторинга действий пользователей, а также других событий, которые могут оказать влияние на данные платежных карт (например, системные сбои). Ниже представлен список событий, которые должны журналироваться в соответствии с этим пунктом:

• «10.2.1. Любой доступ к данным платежных карт
• 10.2.2. Все действия, выполненные с использование административных привилегий
• 10.2.3. Доступ к любым журналам регистрации событий
• 10.2.4. Неудачные попытки логического доступа
• 10.2.5. Использование механизмов идентификации и аутентификации
• 10.2.6. Инициализация журналов регистрации событий
• 10.2.7. Создание и удаление системных объектов»

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

10.3

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

• «10.3.1. Идентификатор пользователя
• 10.3.2. Тип события
• 10.3.3. Дата и время события
• 10.3.4. Индикатор успеха или отказа
• 10.3.5. Источник события
• 10.3.6. Идентификатор или название задействованных данных, системного компонента или ресурса»

Этот минимальный перечень содержит все основные атрибуты, необходимые для анализа инцидентов и для ответа на вопросы: когда, кто, где, что и откуда. Например, если нужно выяснить, кто внес изменение в настройки работы базы данных платежных карт, чтобы все транзакции со всеми параметрами копировались в скрытый файл (типичные действия внутреннего злоумышленника), приведенная выше информация будет весьма полезна.

10.4

Следующий пункт требований учитывает очень важный аспект, про который часто забывают: необходимость использования при журналировании событий точного и согласованного времени. Очевидно, что время событий, которое будет записываться в журнал регистрации событий, будет браться на основе системного времени компьютера. Однако время на различных системах может различаться или вообще быть настроено некорректно. Это может сильно затруднить корреляцию и анализ событий с нескольких различных систем. Поэтому требуется настроить синхронизацию времени на всех критичных системах на основе надежного источника, например, службы NTP.

Во второй версии PCI DSS это требование немного детализировано, в него добавлены следующие подпункты:

• «10.4.1. На критичных системах должно быть установлено правильное и согласованное время
• 10.4.2. Данные времени должны быть защищены
• 10.4.3. Должно быть настроено получение текущего времени из надежных источников».

10.5

Далее, нужно учесть вопросы обеспечения конфиденциальности, целостности и доступности журналов регистрации событий. Пункт 10.5.1 PCI DSS касается конфиденциальности: «просмотр журналов регистрации событий должен быть разрешен только тем сотрудникам, которым это необходимо для выполнения своих должностных обязанностей». Причиной такого ограничения является высокая вероятность наличия в журналах регистрации событий конфиденциальной информации. Например, неудачные попытки аутентификации записываются в журнал с указанием использованного имени пользователя, при этом пользователь может ошибиться и ввести в поле имени свой пароль. Другим примером может быть плохо написанное приложение, которое может указывать пароль пользователя в адресах URL, которые сохраняются в журнале регистрации событий веб-сервера.

Следующим вопросом является целостность. Пункт 10.5.2 говорит, что «файлы журналов регистрации событий должны быть защищены от несанкционированных изменений». Это очевидно, поскольку, если журналы могут быть изменены неуполномоченным лицом, они не могут считаться объективной информацией о действиях пользователей и систем.

Однако это требует обеспечить защиту файлов журналов регистрации событий не только от неуполномоченных лиц, но и от системных сбоев, и от последствий ошибок при настройке систем. Это затрагивает не только целостность, но и доступность журналов регистрации событий. Эту тему продолжает требование п.10.5.3: «должно выполняться своевременное резервное копирование файлов журналов регистрации событий на централизованный лог-сервер или внешние носители информации, где эти файлы сложнее изменить». Организация централизованного хранения журналов регистрации событий на лог-сервере (одном или нескольких), на котором будет выполняться анализ собранных событий, очень важна, как для защиты журналов, так и для повышения эффективности их использования. Резервное копирование журналов регистрации событий на DVD-диски (или ленту) является еще одним следствием этого требования. Однако нужно понимать, что записанные на ленту или DVD-диски журналы не являются легко доступными, их неудобно использовать для поиска информации в случае инцидента, а PCI DSS требует сохранить возможность оперативного доступа к данным журналов регистрации событий в течение 3 месяцев.

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

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

10.6

Следующее требование является одним из самых важных, тем не менее, оно часто упускается из виду. Многие специалисты, внедряющие средства безопасности, необходимые для реализации требований PCI DSS, просто «забывают», что раздел 10 PCI DSS требует не только «иметь журналы регистрации событий», но и «контролировать их содержимое». В частности, в п.10.6 говорится, что «Просмотр журналов регистрации событий для всех системных компонентов должен выполняться не реже одного раза в день. Также должны просматриваться журналы регистрации событий серверов, выполняющих функции обеспечения безопасности (таких как системы обнаружения вторжений (IDS) и серверы аутентификации, авторизации и учета (AAA), например, RADIUS)». Далее в настоящем Руководстве процедуры и методы анализа журналов регистрации событий будут рассмотрены более подробно.

Данное требование определяет системы, журналы регистрации событий с которых должны «просматриваться ежедневно», поэтому недостаточно просто настроить на них журналирование событий и организовать копирование или централизованное хранение журналов. Учитывая, что большая ИТ-среда может производить гигабайты журналов ежедневно, анализ каждого сохраненного в них события выходит за рамки человеческих возможностей. Именно поэтому в данном пункте PCI DSS сделано примечание, которое говорит, что «для достижения соответствия требованию 10.6 могут использоваться инструменты сбора, анализа событий и передачи уведомлений». Далее будут рассмотрены ручные и автоматизированные методы анализа журналов регистрации событий.

10.7

Последний пункт требований раздела 10 связан с еще одним важным вопросом журналирования событий – сохранением журналов регистрации событий в оперативном доступе. В п.10.7 сказано, что «журналы регистрации событий должны храниться не менее одного года, при этом в течение трех месяцев журналы должны находиться в режиме постоянной готовности для немедленного проведения анализа». Таким образом, если вы не можете просмотреть журналы регистрации событий годовой давности, это будет являться нарушением.

Итак, подведем итог рассмотренных до настоящего момента требований PCI DSS в части журналирования событий:

• Раздел 10 PCI DSS устанавливает требования по ведению регистрации определенных событий и указывает уровень детализации сохраняемой в журналах информации. Эти требования распространяются на все системы, находящиеся в области действия PCI DSS.
• Необходимо обеспечить наличие связи между сохраненными в журналах действиями и конкретными пользователями.
• Системные часы на всех системах, входящих в область действия PCI DSS, должны быть синхронизированы.
• Необходимо обеспечить защиту конфиденциальности, целостности и доступности собранных журналов регистрации событий.
• Журналы регистрации событий должны регулярно просматриваться.
• Журналы регистрации событий всех систем, входящих в область действия PCI DSS, должны храниться не менее года.

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

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

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

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

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

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

Раздел 5 относится к антивирусной защите. Разумеется, чтобы подтвердить выполнение указаний п.5.2, который говорит, что «средства антивирусной защиты должны быть постоянно включены, они должны регулярно обновляться и вести журналирование событий», потребуется продемонстрировать эти журналы.

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

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

Раздел 7, в котором указано, что необходимо «ограничить доступ к данным платежных карт в соответствии со служебной необходимостью», фактически требует вести журналы регистрации событий для проверки, кто в действительности получал доступ к указанным данным. Если в журнале будут обнаружены события получения доступа к данным платежных карт пользователями, которым такой доступ не требуется для выполнения своих обязанностей, требуется, как минимум, внести соответствующие изменения в настройки прав доступа.

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

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

Раздел 9 относится к другой области безопасности – физическому контролю доступа. Даже п.9.4, в котором говорится, что «Для хранения записей о посетителях должен использоваться журнал регистрации посетителей, в котором должны указываться ФИО посетителя, название компании, которую он представляет, и ФИО сотрудника компании, который дал разрешение на пропуск этого посетителя. Данный журнал должен храниться не менее 3 месяцев, если это не противоречит законодательству», может быть связан с управлением журналами регистрации событий, если этот журнал регистрации посетителей ведется в электронной форме.

Раздел 11 говорит о необходимости «регулярного тестирования систем и процессов обеспечения безопасности». Однако п.11.4 также требует использования систем IDS или IPS: «Должны использоваться системы выявления и/или предотвращения вторжений для мониторинга всего трафика на периметре среды, в которой хранятся и обрабатываются данные платежных карт, а также на критичных узлах внутри этой среды. Эти системы должны оповещать персонал о подозрительных действиях. Должно проводиться регулярное обновление программного обеспечения и сигнатур систем выявления и предотвращения вторжений». Польза от работы системы выявления вторжений будет только в том случае, если анализируются ее журналы регистрации событий и отправляемые ей оповещения.

Раздел 12 касается более высокоуровневых вопросов безопасности – политики безопасности, а также стандартов безопасности и ежедневных процедур (например, среди них должна быть процедура ежедневного анализа журналов регистрации событий, предусмотренная в Требовании 10). Однако этот раздел затрагивает также и вопросы журналирования событий, поскольку ведение журналов регистрации событий должно быть частью любой политики безопасности. Кроме того, требования в отношении реагирования на инциденты, также связаны с журналами регистрации событий – п.12.5.3: «разработка, документирование и распределение процедур реагирования на инциденты безопасности и процедур эскалации для обеспечения своевременной и эффективной обработки инцидентов в любых ситуациях» невозможно реализовать это без эффективного сбора и своевременного анализа данных журналов регистрации событий.

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

dorlov.blogspot.ru

Создание журнала регистрации событий

Регистрация событий

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

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

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

Создание журнала регистрации событий

Откройте файл с гидравлической моделью Схема теплогидравлики 1.prt. созданный при выполнении предыдущих учебных заданий. Приступим к созданию журнала регистрации событий:

Убедитесь, что в модели существует панель управления задвижкой, для этого:

1. Запустите модель на расчет. При необходимости переведите схемное окно в режим Индикация.
2. Осуществите двойной клик по задвижке Z2. Убедитесь, что появляется панель управления задвиж-кой, созданная при выполнении учебного задания 9.
3. Остановите расчет.
4. В главном окне программы нажмите кнопку Менеджер данных (см. Рисунок 1):

   Рисунок 1. Кнопка вызова менеджера данных

5. Нажатие данной кнопки вызывает на экран диалоговое окно Менеджер данных (Рисунок 2), которое служит для настройки различных каналов воздействия на математическую модель, а также для настройки обмена данными и системы отображения информации.

   Рисунок 2. Диалоговое окно «Менеджер данных»

6. Нажмите кнопку Добавить категорию (см. Рисунок 2). Введите название новой категории «Жур-налы регистрации событий».
7. Выделите созданную категорию (выделенная категория подсвечивается синим цветом) и нажмите кнопку Журнал событий (см. Рисунок 3).

   Рисунок 3. Диалоговое окно «Менеджер данных» после добавления новой категории

8. В категории Журналы событий появится новый элемент Регистратор событий (см. Рисунок 4). При необходимости раскройте список категорий, нажав на значок «+» слева от имени категории:

   Рисунок 4. Диалоговое окно «Менеджер данных» после добавления «Регистратора событий»

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

Добавление параметров в «Регистратора событий»

Для добавления нового события необходимо осуществить следующие действия:

1. Осуществите клик правой кнопкой мыши на пункте Регистратор событий.
2. В выпадающем меню выберите пункт Добавить параметр Рисунок 5.

   Рисунок 5. Добавление параметра в журнал регистрации событий

3. В появившемся диалоговом окне введите имя блока Z1 (первая задвижка) и имя параметра State (положение задвижки) (Рисунок 6):

   Рисунок 6. Добавление параметра для регистрации

4. Закройте окно нажатием на кнопку Ок, сохранив внесенные изменения.

В окне Менеджер данных под пунктом Регистратор событий появится новый параметр Z1.State.

Кроме добавления нового параметра по имени блока можно добавлять в качестве параметров сигналы из базы данных проекта. Для этого повторите приведенные выше пункты 1–2, в диалоговом окне Изменение параметра нажмите кнопку Найти значение в базе (Рисунок 7).

Рисунок 7. Кнопка вызова поиска параметров в базе данных

Нажатие кнопки Найти значение в базе данных приводит к появлению окна редактора базы данных.

Рисунок 8. Выбор сигналов из базы данных

Выберите в базе данных сигнал yb01 («Команда Открыть») для задвижки Z2. Для этого последовательно выберите в списке панели Категории пункт Задвижки, в панели Группы сигналов выберите Z2, в таблице Сигналы и Данные для групп выберите сигнал yb01 («Команда Открыть»). Нажмите кнопку Добавить. Выбранный сигнал появится в таблице Выбранные данные в правом нижнем углу (см. Рисунок 8). Закройте окно Редактор базы данных нажатием кнопки Ok.

Аналогичным образом добавьте параметр yb02 («Команда Закрыть») для задвижки Z2.

Настройка параметров регистрации событий

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

По умолчанию регистратор настроен на изменение значения логических параметров с «0» (логическое «Нет») на «1» (логическое «Да»).

Для изменения условий срабатывания события необходимо выполнить следующие действия:

1. Осуществите клик правой кнопкой мыши по названию параметра в разделе Регистратор событий;
2. В выпадающем меню выберите пункт Дополнительно:

   Рисунок 9. Вызов диалогового окна настройки события

   После этого появляется окно настроек регистрации событий (Рисунок 10). В данном диалоговом окне необходимо настроить следующие параметры:

   • Режим регистрации – определяет изменение параметра, которое приводит к появлению события. Возможные варианты:
     • Увеличение значения;
     • Уменьшение значения;
     • Изменение значение;
     • Превышение уставки;
     • Снижение ниже уставки;
   • Приоритет – определяет очередность регистрации событий в журнале, для событий, которые произошли одновременно, первым записывается событие с более высоким приоритетом;
   • Уставка – числовая величина, с которой происходит сравнение значения параметра;
   • Описание события – текст сообщения о событии, который записывается в журнал событий;

     Рисунок 10. Настройка параметров регистрации событий

3. Задайте для параметра Z1.State следующие значения:
   1. Режим регистрации - Превышение уставки
   2. Приоритет - 0
   3. Уставка - 99.9
   4. Описание события - Задвижка Z1 открыта полностью

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

4. Нажмите на кнопку Ок, сохранив внесенные изменения и сохраните проект Схема теплогидравлики 1.prt.

Окно «Регистратор событий»

Для вызова окна «Регистратор событий» необходимо осуществить двойной клик на соответствующем пункте в окне «Менеджер данных». При этом появится окно аналогичное изображенному на рисунке ниже (Рисунок 11). Данное окно содержит в себе две закладки:

• Журнал - таблица, в которую выводится список событий модели, а также панель инструментов;
• Настройки - предназначены для настройки регистратора событий.

Панель управления на закладке Журнал содержит следующие кнопки:

• Поверх всех окон – включает и выключает этот режим для Регистратора событий;
• Очистить – удаляет все существующие записи в Регистраторе событий;
• Открыть – позволяет загрузить сохраненный ранее список событий;
• Сохранить – позволяет сохранить список событий в текстовый файл;
• Удалить – служит для удаления выбранного события из списка сигналов;
• Копировать – позволяет скопировать существующий список событий в буфер обмена Windows.

Рисунок 11. Окно «Регистратор событий» (пустое перед началом расчета)

Таблица на закладке Журнал содержит следующие столбцы:

• Время – расчетное время математической модели, когда произошло событие;
• Сигнал – имя параметра, в формате внутреннего языка программирования, для которого регистрируются события;
• Описание события – текстовый строка, заданная при настройке события, либо для сигналов из базы данных данная строка соответствует значению в поле Название редактора базы данных;

• Пред. значение – значения параметра до события;
• Новое значение – значения параметра после события;
• Приоритет – значение приоритета.

  Рисунок 12. Окно «Регистратор событий», закладка «Настройки»

Закладка Настройки содержит следующие элементы управления:

• Флаг Записывать события в общее окно сообщений проекта – при установке данного флага все сообщения в «Регистраторе событий» дублируются в окне сообщений проекта;
• Флаг Записывать события в окно журнала – при установке этого флага сообщения о событиях не выводятся в окно журнала;
• Поле Имя файла лога событий – позволяет задать имя файла, в который будут сохраняться сообщения о событиях;
• Флаг Добавлять события в существующий файл – при установке этого флага существующие записи в файле не стираются;
• Поле Файл списка сигналов – позволяет задать файл, в котором хранится список параметров, на основании которых создается журнал регистрации событий;
• Кнопки рядом предназначены для:
  • открытия диалогового окна выбора файла;
  • обновления списка сигналов из файла;
  • сохранение списка сигналов в файл;
• Строка Формат списка сигналов – позволяет задать параметры, и их последовательность, в которой они будут записываться в текстовый файл списка сигналов;
• Выпадающее меню Формат вывода модельного времени – позволяет задать формат вывода модельного времени:
  • Десятичный – время выводится в секундах;
  • Часы: минуты: секунды – время выводится с использование часов минут и секунд.

Использование журнала регистрации событий при моделировании

Выполните следующие действия:

1. Откройте комплексную модель pack2.pak, созданную при выполнении учебного задания 9; В данную комплексную модель входят два проекта Схема теплогидравлики.prt – теплогидравлическая модель и Схема автоматики 2.prt – модель системы управления. Обе этих модели загружаются автоматически при загрузке пакета.
2. Перейдите в окно проекта Схема теплогидравлики 1.prt. Для этого можно воспользоваться главным меню SimInTech, пункт – Окно;

   Рисунок 13. Переключение между окнами

3. Убедитесь, что теплогидравлическая модель содержит ранее созданный журнал регистрации событий, для этого в главном окне программы нажмите кнопку Менеджер данных;
4. Осуществите двойной клик на пункте Регистратор событий. Появится окно, в котором будет отображаться список событий, зарегистрированных в процессе моделирования.

   Рисунок 14. Окно «Регистратор событий»

5. Для удобства просмотра событий можно установить режим Поверх всех окон, нажав на соответствующую кнопку.
6. Запустите комплексную модель на расчет.
7. Осуществите двойной клик на второй задвижке в теплогидравлической модели.
8. В появившемся окне управления подавайте команды на открытие и закрытие задвижки;
9. Убедитесь, что команды на открытие и закрытие задвижки регистрируются в журнале событий.

   Рисунок 15. Регистрация событий в комплексной модели

10. Переведите задвижку Z2 в полностью открытое состояние. Дождитесь, когда алгоритм управления задвижкой Z1 выполнит необходимое открытие задвижки. Убедитесь, что для поддержания давления на уровне 117000 полное открытие задвижки Z1 не требуется и полное открытие не регистрируется журналом событий (Рисунок 15).

На этом учебные задания (с первого по десятое) завершены. Спасибо!

simintech.ru

---

Смотрите также

• 
  Шик журнал 2017
• 
  Журнал мир вокруг
• 
  Сайт журнала здоровье
• 
  Журнал учета приема
• 
  Иллюстрации из журналов
• 
  Журнал воспитательной работы
• 
  Журналы о пиве
• 
  Журналы по филологии
• 
  Отрывки из журнала
• 
  Дата выхода журналов
• 
  Человек года журнал