Учредитель журнала

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

УДК 004.056.2

DOI 10.52815/0204-3653_2022_02186_4
EDN: KXLRPO

Козьминых Сергей
Доцент, д. т. н., профессор Департамента информационной безопасности Финансового университета при Правительстве РФ.
E-mail: SIKozminykh@fa.ru, mvdprof@mail.ru

Жилина Алена
бакалавр Департамента информационной безопасности Финансового университета при Правительстве РФ.
E-mail: alen.zhilina@yandex.ru

Введение

На сегодняшний день основная тенденция обеспечения информационной безопасности (ИБ) как состояния защищённости интересов организации состоит в том, чтобы не допускать реализации злоумышленником кибератак. По оценкам экспертов доля атак, в особенности на энергетический сектор, растёт с каждым годом, и, следовательно, возникающие при этом инциденты приводят к прерываниям как операционных, управленческих, так и вспомогательных бизнес-процессов. Таким образом, задачи информационной безопасности сводятся к минимизации ущерба, а также к прогнозированию и предотвращению случайных или преднамеренных негативных воздействий. Различные стандарты безопасности призваны помочь компаниям выстроить линию защиты наиболее эффективно, чтобы получить достаточно высокий уровень защищённости всех компонентов инфраструктуры организации. Выбор решений спорных вопросов и проблемных ситуаций при этом остаётся задачей высококвалифицированных специалистов.
Внедрение программных, технических средств защиты, а также инструментов мониторинга информационной безопасности основывается на нормативных документах, которые дают рекомендации по внедрению организационных и технических мер защиты информации.
Внедрение стандарта PCI DSS проводится на предприятиях, работающих с международными платёжными системами, такими как банки, торгово-сервисные предприятия, поставщики технологических услуг и других организаций, деятельность которых связана с обработкой, передачей и хранением данных о держателях платёжных карт. Выполнение предъявляемых требований позволяет обеспечить комплексную защиту всех компонентов информационной инфраструктуры объектов. С этой целью компаниям часто необходимо внедрение различных программных решений. Рассмотрим спорные моменты при выборе программных решений, возможной реализации архитектуры такой системы, и функциональных особенностей выбранных решений в соответствии с требованиями PCI DSS [1].

Проектирование системы

Разработка архитектуры

Мониторинг внутренней инфраструктуры организации необходим для:
1. Отслеживания состояния системы в целом и её компонентов с целью обеспечения непрерывности работы компании путем своевременного выявления сбоев в информационных и операционных системах, а также в аппаратном обеспечении.
2. Сбора и хранения событий безопасности с целью выявления и расследования инцидентов посредством анализа и обработки событий, поступающих от различных систем.
Одной из задач системы мониторинга является оповещение специалистов по информационной безопасности о выявленных инцидентах в зависимости от специфических настроек, таких как уровень критичности события, периодичности их возникновения (BruteForce-атаки), сервиса приёма оповещений (почтовый сервер, мессенджеры и т. д.).
Можно выделить следующие проблемы, которые необходимо решить компании при организации мониторинга и реагирования на инциденты:
1. Источники событий представляют собой журналы большого количества информационных систем. Здесь специалистам необходимо в первую очередь оценить критичность данных, представляющих собой информационные активы, циркулирующих в сервисах организации, и определить связанные с этими данными риски. Также необходимо оценить каналы, по которым данные передаются, что в результате позволит определить источники тревожных событий, специфичных для каждого сервиса, виртуальной машины или сервера. Далее на основе требований или рекомендаций регуляторов необходимо сформировать перечень тревожных событий, общих для конкретного вида систем или сервисов. К ним могут относиться: данные о подключении и аутентификации пользователей; повышения привилегий; события контроля целостности системных и конфигурационных файлов; журналы событий системных служб. Далее необходимо выделить сообщения от внешних систем, установленных на различных уровнях информационной инфраструктуры организации. Среди них: антивирусные программы, сканеры уязвимостей, средства обнаружения и предотвращения вторжений (IDS / IPS), средства мониторинга сетевого трафика (Netflow), системы защиты информации от несанкционированного доступа (СЗИ от НСД) и так далее.
2. Второй проблемой является широкий и разнообразный рынок SIEM-систем. Проблема заключается в том, что выбор SIEM-системы необходимо осуществлять в зависимости от целей и источников, сформированных на первом этапе. При подготовке организации к прохождению аудита для сертификации по стандарту PCI DSS компания может сделать выбор в пользу SIEM-системы, записывающей события, сбор которых регламентирован данным стандартом, а также проводит проверку конфигурационных файлов и политик безопасности на соответствие указанному стандарту.
Второй вопрос относится к интеграции SIEM с системами, выбранными в ходе определения источников событий. Журналы событий, поступающие в SIEM, должны корректно распознаваться, чтобы определённые значения, относящиеся к событию, попадали в конкретные поля. Это может зависеть от встроенных или подключаемых модулей, или плагинов. При их отсутствии возможна необходимость внедрения дополнительной системы, осуществляющей фильтрацию журналов событий перед непосредственной отправкой их в SIEM-систему.
Дополнительно необходимо решить вопрос хранения событий, полученных в результате мониторинга и логирования, организованного в компании посредством проектируемой системы. PCI DSS, регламентируя требования по данному вопросу, определяет год в качестве срока хранения журналов событий. Это важно также при расследовании инцидента ИБ, так как такие журналы являются непосредственной доказательной базой. Также стоит задуматься о периодической выгрузке данных с сервера, на котором запущены компоненты системы, на сторонний сервер журналов неактуальных событий.
На сегодняшний день рынок продуктов по информационной безопасности достаточно обширный, и многие из решений могут дублировать функционал друг друга. По этой причине необходим грамотный подход к выбору стека систем и сервисов, которые обеспечат эффективное покрытие функций защиты всех компонентов инфраструктуры. Так как большинство решений относятся к платным и требуют приобретения лицензии, то для выполнения поставленной задачи предлагается стек программных решений, которые находятся в открытом доступе и позволяют выполнить данные задачи на безвозмездной основе.
Архитектура разработанной системы представлена на рис. 1.

Рис. 1. Архитектура системы программных решений в области безопасности


Организация работы модулей проектируемой системы

Перечислим программные компоненты проектируемой системы, представим их конфигурацию и рассмотрим преимущества такой настройки:
1. ELK stack: Elasticsearch, Logstash и Kibana. ELK дает возможность агрегировать журналы из всех систем и приложений, анализировать эти журналы и создавать визуализации для мониторинга приложений и инфраструктуры для быстрого устранения неполадок, а также для аналитики безопасности и т. д. [2].
Elasticsearch – масштабируемое нереляционное хранилище данных, аналитическая NoSQL-СУБД с широким набором функций полнотекстового поиска. Используется для хранения, анализа, поиска по журналам событий.
Kibana – веб-интерфейс для вывода индексированных Elasticsearch журналов событий.
Logstash – сервис для сбора журналов из многочисленных источников, их преобразования и передачи в хранилище. Поддерживает множество входных типов данных. При получении журналов структурирует, фильтрует, анализирует и идентифицирует информацию, упрощая последующий анализ.
Все три компонента устанавливаются как отдельные службы. Kibana и Logstash подключаются к Elasticsearch через localhost. Наружу открыты порты для приёма данных от агентов.
Elasticsearch работает как кластер из трёх узлов, один из которых имеет статус мастера, остальные два являются узлами данных. Мастер-узел отвечает за весь кластер, добавляет и удаляет узлы из кластера, отслеживает живые узлы. Узлы данных хранят данные и выполняют операции, связанные с ними, такие как поиск и манипулирование.
Предлагаются следующие разработанные настройки, включённые в конфигурационный файл Elasticsearch, мастер-узла:
node.master=true
node.data=true
Узла данных:
node.master=false
node.data=true
Такая организация хранилища даёт следующие преимущества:
1. Распределенность. Данные реплицируются между узлами данных, расположенными на разных виртуальных серверах. В случае выхода из строя одного узла, данные могут быть восстановлены с узла реплики, что позволяет избежать единой точки отказа.
2. Масштабируемость. Благодаря возможности введения в кластер новых узлов увеличивается производительность и надежность поиска.
3. Возможность внедрения политик жизненного цикла индекса. ILM (Index management lifestyle) представляет собой политики управления жизненным циклом индекса. Это делает возможным организацию ротации индексов в соответствии с принятой политикой хранения собираемых данных о событиях систем и сервисов.
В данном решении настройка фаз ILM производится следующим образом:
− Hot phase.
Индексы в горячей фазе активно используются и запрашиваются. Создание нового индекса происходит при достижении им размера в 50Гб или по прошествии 14 дней с момента его создания. Индексы в этой фазе расположены на мастер-узле и реплицируются на первый узел данных. Параметр в конфигурационном файле для данных узлов:
node.roles: [«data_hot»]
Реплики являются копиями осколков (составляющих индексы, в которых непосредственно хранятся данные) и обеспечивают надежность в случае потери узла.
− Cold phase.
Переход индекса в данную фазу происходит спустя 90 дней с момента создания, индексы также переходят в статус замороженных, и, таким образом, они доступны только для чтения, не обновляются, информация доступна для поиска, но запросы выполняются более медленно, потребляют гораздо меньше кучи, чем обычные индексы. Индексы в этой фазе расположены на втором узле данных. Параметр в конфигурационном файле:
node.roles: [«data_cold»]
− Delete phase
Спустя установленные 365 дней индексы безопасно удаляются.
2. Nginx. Используется в качестве прокси для Kibana для добавления ssl-сертификатов и HTTP-заголовков для защиты веб-приложения, таких как X-Frame-Options, X‑XSS-Protection, X‑Content-Type-Options, Strict-Transport-Security.
3. Apache Kafka. Apache Kafka – это распределенное, отказоустойчивое, горизонтально масштабируемое хранилище, основной структурой данных в котором является append-only лог и которое поддерживает потоковую обработку данных, имеет развитую экосистему коннекторов для интеграции с базами данных и другими хранилищами. В ELK-стеке Kafka может использоваться как временный буфер для сохранения информации в случае временной остановки кластера или его компонентов при сбоях или при необходимости перезапуска, а также для выравнивания пропускной способности [3].
4. Beat-агенты:
A. Filebeat – сборщик журналов. Отслеживает изменения в файлах журналов. Имеет ряд модулей для конкретного ряда систем, что делает возможным корректный парсинг файлов с определением правильного типа для каждого поля и установку панелей мониторинга (дашбордов) в Kibana, которые можно использовать для визуализации файлов журнала соответствующей системы [4].
Источники для сборки агентом Filebeat можно условно разделить на 2 категории:
− события систем и служб: системные события (syslog и auth в модуле system), логи Nginx, Postgresql, Redis, Kafka, vSphere с использованием модулей соответствующих названий. Агенты направляют события данной группы напрямую в Elasticsearch, так как в дополнительной проработке полей нет необходимости;
− события веб-сервисов: события с веб-сервисов, работающих на виртуальных серверах dev- и prod-сегментов. Отправка производится в Kafka с указанием топика (dev или prod). Оттуда журналы извлекаются Logastash, где лог проходит процесс парсинга, ему присваивается индекс (в соответствии с топиком), и перенаправляется в Elasticsearch.
В качестве примера на рис. 2 представлена панель мониторинга событий входа по SSH.

Рис. 2. Визуализация работы системы сбора событий

B. Auditbeat – агент, используемый для аудита действий пользователей и процессов, а также контроля целостности критических файлов и файлов конфигурации (каждой из функций соответствует отдельный модуль).
Для протоколирования событий доступа к файлам и действий, которые произвел пользователь, применяется модуль Auditd [5].
Правила протоколирования, требуемые для осуществления аудита стандартом PCI DSS, предлагается представить в конфигурационном файле следующим образом:
– module: auditd
audit_rule_files: [‘$ {path.config} / audit.rules.d / *.conf’]
audit_rules: |
– w / etc / passwd –p rw;
– w / etc / shadow –p rw;
– w / etc / hosts –p rw;
– w / etc / sysconfig / * -p rw
– w / etc / ssh / sshd_config –p rw;
– w / etc / audit / auditd.conf – p rw;
– w / etc / audit / audit.rules –p rw;
– w / etc / syslog.conf –p rw;
– w / var / log / * -p w;
Для обеспечения контроля целостности критичных конфигурационных файлов системы, исполняемых и системных файлов, архивов журналов аудита используется модуль File Integrity.
Пути до файлов данного перечня в конфигурационном файле должны быть настроены следующим образом:
– module: file_integrity
paths:
- / bin
- / usr / bin
- / sbin
- / usr / sbin
- / etc
- / etc / .login
- / etc / X11 / gdm / gdm.conf
- / etc / cron.allow
- / etc / cron.deny
- / etc / hosts.allow
- / etc / hosts.deny
- / etc / issue
- / etc / motd
- / etc / passwd
- / etc / shadow
- / etc / audit / auditd.conf
- / etc / audit / audit.rules
- / etc / ssh / sshd_config
- / etc / syslog.conf
- / etc / login.defs
- / etc / pam.d / system-auth

C. Metricbeat – агент, предназначенный для cбора метрик и статистики операционных систем и служб, работающих на серверах, применяется для разбора и визуализации данных с различных систем. Более конкретный пример использования данного агента представляет собой анализ информации об эксплуатации CPU, ОЗУ и дискового пространства виртуальных серверов и своевременного реагирования при достижении данными показателями отметок, критических для работы системы.
D. Heartbeat – агент, используемый для мониторинга доступности серверов и служб. Проверяет с заданной периодичностью состояние серверов и веб-сервисов. Сервис запускается в одной реплике и разворачивается на виртуальном сервере, имеющем доступ ко всем отслеживаемым серверам и сервисам. Мониторы предлагается настроить в конфигурации следующим образом:
heartbeat.monitors:
– type: icmp
schedule: ‘* / 5 * * * * * *’
hosts: [«some-host1.example.com», «192.168.10.1»]
id: hosts
name: ICMP Service
– type: http
schedule: ‘@every 5s’
urls: [«https://some-host2.example.com», «https://some-host3.example.com»]
service.name: web1
id: web-services1
name: HTTP Service
check.response.status: [200, 403]
На указанные IP-адреса и доменные имена агент отправляет запросы по протоколам ICMP и HTTP, чтобы проверить доступность серверов или служб. Это позволяет получить статистику работы систем, вовремя отследить сбои и своевременно отреагировать на них.
5. Wazuh – это платформа с открытым исходным кодом для обнаружения угроз, мониторинга безопасности, реагирования на инциденты и обеспечивания соблюдения нормативных требований.
Данный компонент может быть установлен в качестве SIEM-системы, имеет серверную часть, состоящую из wazuh-manager и wazuh-api компонентов, и агентов, которые должны быть установлены на каждом виртуальном сервере и зарегистрированы в wazuh-manager.
Для визуализации данных Wazuh может быть использован плагин для Kibana, получающий информацию об изменениях через wazuh-api.
Со стороны пользователя системы для управления настройками данных компонентов используются модули. Их настройка производится через конфигурационные файлы агентов и wazuh-менеджера ( / var / ossec / etc / ossec.conf). Просмотр результата работы каждого модуля возможна в Kibana после подключения плагина wazuh.
В данном решении настроены и используются следующие модули:
A. PCI DSS. Настройка данного модуля производится через настройку параметров rootcheck и syscheck в конфигурации сервера. Веб-интерфейс в Kibana предоставляет отчеты и информационные панели, которые помогают отследить, какие из требований не соблюдаются для определённого хоста, а также мониторить события, сбор которых регламентирован стандартом. Rootcheck представляет собой инструмент проверки процессов, файлов, параметров на соответствие принятым политикам безопасности. Syscheck отвечает за мониторинг целостности файлов и изменений в реестре (база данных параметров и настроек в большинстве ОС Microsoft Windows).
B. Vulnerabilities. Модуль подключается в файле сервера и должен быть настроен в соответствии с используемой ОС, например для Ubuntu OS:

no< / enabled>
5m< / interval>
6h< / ignore_time>
yes< / run_on_start>


no< / enabled>
trusty< / os>
xenial< / os>
bionic< / os>
focal< / os>
1h< / update_interval>
< / provider>
< / vulnerability-detector>
Собранная с агентов информация сопоставляется с постоянно обновляемыми базами данных CVE (Common Vulnerabilities and Exposure), чтобы идентифицировать общеизвестное уязвимое ПО.
Дашборд позволяет визуализировать и фильтровать данные об уязвимостях, к примеру, по имени хоста или степени критичности.
C. Security events. Настройка данного модуля производится через настройку параметров rootcheck и syscheck в конфигурации сервера. Модуль используется для сбора, агрегирования, индексации и анализа данных безопасности, помогая обнаруживать вторжения, угрозы и аномалии поведения. Обнаружение аномалий представляет собой действия по поиску в системе шаблонов, которые не соответствуют ожидаемому поведению.
В контексте данного модуля удобно использование функции MITRE ATT&CK. Удобство в данном случае заключается в том, что оценка найденных событий или групп событий производится в соответствии с общепринятой системой. Матрица MITRE позволяет сопоставить их с тактиками атак. Тактики сгруппированы по техникам, каждой технике присваивается идентификатор. На рис. 3 представлена визуализация работы такой системы.

Рис. 3. Визуализация работы системы обнаружения событий безопасности

D. Docker listener. Модуль позволяет пользователям отслеживать образы, тома, параметры сети и запущенные контейнеры.
Активация модуля должна производиться в конфигурационном файле сервера:

no< / disabled>
< / wodle>

Для более детальной настройки модулей и сценариев их поведения, в том числе для обработки ложных срабатываний, можно ознакомиться с наборами правил в каталоге / var / ossec / ruleset / rules / на сервере.
Также в системе настроены сценарии реагирования посредством active response механизма Wazuh. Модуль должен активироваться и настраиваться на сервере следующим образом:

firewall-drop < / command>
10< / level>
all< / location>
web, accesslog, web_scan, recon< / rules_group>
< / active-response>
В вышеприведённом примере при появлении события с уровнем критичности 10 и относящееся к указанным группам правил выполняется скрипт firewall-drop. Реализация срабатывания системы продемонстрирована на рис. 4. После нескольких попыток получения доступа, определённых системой как техника T1110 (Brute Force) в соответствии с MITRE ATT&CK, хост, с которого были осуществлены такие попытки, блокируется на заданное время средствами файерволла.

Рис. 4. Пример реагирования системой на атаку Brute Force

Автоматизация развёртывания и внедрения компонентов проектируемой системы информационной безопасности

Предлагаемая архитектура системы логирования, мониторинга и реагирования на инциденты включает большое количество компонентов. Серверная часть должна содержать несколько узлов БД, буфер событий, агрегатор журналов, веб-панель и прокси-сервер. Клиентская часть представляет собой агенты, устанавливаемые на все обслуживаемые компоненты инфраструктуры и отдельные для каждого описанного модуля. Установка и конфигурирование такого числа компонентов не только затратно по времени, но и требует определённых компетенций от специалиста, осуществляющего внедрение. Таким образом, необходимым является решение по шаблонизации для предварительной настройки определённых в данной статье параметров, а также по автоматизации процесса установки и масштабирования в целях экономии времени.
В этой связи предлагается использование микросервисной архитектуры, основанной на Docker-контейнерах. Представление каждого компонента системы в виде контейнера даст такие преимущества как легковесность и экономия ресурсов. Контейнеры могут быть запущены на физических серверах или внутри виртуальных машин исходя из особенностей инфраструктуры организации и располагаемых ресурсов, что делает решение гибким. Каждый контейнер содержит только минимальное ПО и сервисы, необходимые для работы конкретного компонента. Кроме того, становится возможным осуществление автоматизированной установки каждого компонента посредством запуска новых контейнеров через сценарии Ansible.
Рассмотрим предлагаемый процесс контейнеризации и развёртывания на примере агента для сбора системных событий.
Для каждого контейнера необходимо предварительное создание образа. В нашем случае образ контейнера должен включать:
− указание на базовый образ в соответствии с видом агента [6];
− копирование внутрь образа конфигурационного файла службы с изменённым адресом Elasticsearch;
− копирование внутрь образа сертификатов для подключения агента к Elasticsearch;
− подключение нужного модуля;
− копирование внутрь образа конфигурационного файла модуля.
Составленный таким образом Dockerfile должен выглядеть так:
FROM docker.elastic.co / beats / filebeat:7.11.1
COPY filebeat.yml / usr / share / filebeat / filebeat.yml
COPY certs / etc / filebeat / certs
RUN filebeat modules enable system
COPY system.yml / usr / share / filebeat / modules.d / system.yml
Сборка образа для нового типа агента производится один раз, что также экономит время, так как все необходимые параметры будут прописаны в конфигурационные файлы агента при первой сборке. Созданные образы рекомендуется хранить в специальных реестрах образов, таких как Harbor. На рис. 5 представлен пример хранения компонентов проектируемой системы.

Рис. 5. Использование реестра образов Harbor для хранения компонентов системы

Далее из реестра скачиваются образы, из которых можно разворачивать контейнеры для каждого компонента с помощью Ansible-плейбука. Под Ansible-плейбуком понимается сценарий работы инструмента управления конфигурацией Ansible [7]. При запуске данным инструментом производится подключение к целевому серверу и осуществляются действия, описанные в плейбуке.
Рассмотрим сценарий установки агента сбора системных событий:
– –
– name: System_log_collector
hosts: all
become: yes
tasks:
– name: Hostname getting
shell: hostname
register: hostname
– name: Packages installing
apt:
name: python3‑docker
– name: Copy system_log_collector image
copy:
src: ~ / system_log_collector.tar
dest: / home / a_zhilina / 
– name: Loading images
shell: docker load -i / home / a_zhilina / system_log_collector.tar
– name: Running system_log_collector
docker_container:
name: “ { {service_name}}»
image: system_log_collector
state: started
user: root
hostname: “ { {hostname.stdout}}»
volumes:
- / var / log / syslog: / var / log / host_log / syslog
- / var / log / auth.log: / var / log / host_log / auth.log
restart_policy: always
Приведённый сценарий включает следующие задачи:
1. Получение имени сервера. Это необходимо для корректного отображения отправляемых агентами событий в систему логирования, мониторинга и реагирования на инциденты. Так как значение hostname контейнера и сервера, на котором он запускается, не совпадают, при запуске контейнера данный параметр должен быть переопределён.
2. Установка пакета python3‑docker для корректной работы модулей Ansible осуществляющих запуск контейнера.
3. Копирование образа контейнера с машины, на которой запущен Ansible, на целевой сервер. При использовании реестра образов данный шаг может быть заменён скачиванием образа из хранилища.
4. Загрузка образа. На данном шаге осуществляется загрузка образа из архива, в котором он был скопирован на целевой сервер. Эта задача должна быть пропущена при использовании реестра образов.
5. Запуск контейнера. Из полученного образа запускается контейнер. Дополнительно настраиваются параметры «имя контейнера», «имя хоста», «пользователь», «имя образа», «политика перезапуска». К контейнеру монтируется директория с системными событиями и событиями аутентификации. При этом монтирование производится в подкаталог в контейнере, чтобы файлы с событиями контейнера и хоста не перемешивались.
Команда запуска плейбука system_log_collector.yml для сервера с именем , определённого в файле hosts настроек Ansible должна иметь следующий вид:
ansible-playbook system_log_collector.yml -i hosts -l
Подобным образом осуществляется настройка и развёртывание каждого компонента. Конфигурационные файлы, образ и сценарий развёртывания подготавливаются один раз и далее запуск производится в одну команду.

Заключение

В данной статье была определена проблема проектирования, настройки и внедрения системы логирования, мониторинга и реагирования на инциденты в компаниях энергетического сектора, проходящих аудит на соответствие стандарту PCI DSS. В процессе рассмотрения предметной области определены задачи, решаемые каждой организацией при внедрении процессов мониторинга внутренней инфраструктуры. Для разработки комплексной системы информационной безопасности, отвечающей таким требованиям как гибкость, отказоустойчивость, масштабируемость, распределенность хранилища и возможность организации автоматизированного развёртывания всех компонентов, была предложена соответствующая архитектура. Для каждого компонента серверной части описано назначение и параметры конфигурации. В качестве модулей, представляющих собой подсистемы безопасности, представлены возможные клиентские компоненты. Данные подсистемы включают сборщик журналов событий, подсистемы аудита, контроля целостности, сбора метрик, мониторинга доступности, систему, обеспечивающую соответствие стандарту PCI DSS, обнаружения уязвимостей и событий безопасности, сканирования Docker-образов. Для каждой подсистемы приведены конфигурации, настроенные в соответствии с требованиями PCI DSS. В качестве результата в работе представлены авторские скриншоты демоверсии предлагаемого решения. С целью ускорения процессов установки и настройки компонентов предложен сценарий организации системы с использованием микросервисной архитектуры и автоматизированного развёртывания средствами инструмента управления конфигурацией Ansible.
Конечным результатом работы, рассмотренной в данной статье, является проект системы логирования, мониторинга и реагирования на инциденты, включающий архитектуру, описание настроек каждого компонента, модули, образы контейнеров компонентов серверной и клиентской частей, сценарии для автоматизированного внедрения этих компонентов.
В качестве недостатка системы можно выделить высокий порог вхождения в используемые технологии для специалистов базовой квалификации. Это, однако, компенсируется сведением их числа к минимуму при использовании развёртывания через Ansible, так как в данном случае для внедрения необходимо применение только этого инструмента. Не до конца исследованным остаётся вопрос соотношения ресурсов, потребляемых отдельными компонентами, и количества подключаемых агентов. Следует отметить, что в данный момент система была апробирована и успешно внедрена в организации, при прохождении аудита по стандарту PCI DSS с подключением 50 агентов.
В качестве вывода следует отметить, что представленное решение является универсальным и может быть применено не только при прохождении аудита, но и в качестве комплексной системы информационной безопасности. Внедрение данного программного обеспечения позволяет повысить уровень ИБ организации в целом и, как следствие, повысить качество и стабильность бизнес-процессов.