Консоль является мозгом QRadar и единственным незаменимым компонентом QRadar. Она может собирать и обрабатывать данные и выдавать предупреждения на основе правил. Это основная задача консоли. Другие (описанные ниже) компоненты в основном используются для масштабирования этих функций в той или иной форме. Теперь давайте посмотрим на три основные работающие на консоли службы и разберёмся в них.

Основная утилита данной службы предназначена для отображения UI (User Interface, пользовательского интерфейса) QRadar. Доступ к пользовательскому интерфейсу QRadar можно получить, вводя в браузере IP-адрес или имя хоста (если оно может быть разрешено).

Когда в QRadar служба tomcat отключена, у вас не будет возможности загрузки интерфейса пользователя QRadar. Она поддерживает сеансы пользователя, активные сеансы и текущих пользователей - всё то, что зарегистрировано в интерфейса пользователя QRadar. Он также частично выполняет роль при аутентификации пользователей, будь то локальная аутентификация, аутентификация LDAP (Lightweight Directory Access Protocol) или любой иной тип аутентификации. Это многопоточная служба, которая также имеет дело с экспортом данных из интерфейса пользователя QRadar. Значение состояния службы tomcat можно проверить, воспользовавшись простой командой:

systemctl status tomcat
		

В своей заключительной главе мы рассмотрим советы по устранению неисправностей для tomcat.

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

Ниже перечисляются службы, включаемые по причине hostcontext:

Существует ещё большое число служб и мы будем их подробно обсуждать при введении относящихся к ним понятий.

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

База данных ariel обладает собранными сведениями безопасности и обрабатывается hostcontext. Postgres обладает подробностями конфигурации QRadar. Она управляется службой hostservices. Postgres это RDBMS (relational database management system, система управления реляционной базой данных), которая обладает множеством таблиц, содержащих сведения относительно развёртывания, конфигурации и настроек QRadar. База данных Postgres реплицируется в различные управляемые хосты при помощи службы hostcontext. Запросы к этой базе данных Postgres, в случае необходимости, могут выполняться через командную строку psql. Мы обсудим это подробнее, когда будем обсуждать оптимизацию и тонкую настройку QRadar.

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

Всякая планирующая построить ЦОБ (SOC) организация обладает сотнями и тысячами приложений, серверов и оконечных точек, которые она желала бы отслеживать. Всякие такие службы или серверы обладают журналами безопасности и аудита. Эти журналы безопасности и аудита являются тем, что мы называем данными события (event data). QRadar поддерживает большое число протоколов, например, Syslog, JDBC и UDP со множеством линий. Он также поддерживает специфичные для продукта протоколы, такие как протокол Akamai Kona REST API и протокол CISCO NSEL. При помощи данных протоколов QRadar способен либо выполнять активную доставку из Источников журналов (Log Sources), или же мы можем настраивать Источники журналов на отправку данных в QRadar.

Эти данные отправляются в виде событий, которые подвергаются синтаксическому разбору и установке соответствия с определёнными именами событий. Такие события можно просматривать через пользовательский интерфейс QRadar в закладке Log Activity. Имеется большое число вариантов применения.

Приводимый ниже рисунок показывает снимок экрана соответствующую закладку Log Activity с применёнными фильтрами:

Здесь мы применяем в качестве Log Source термин Data Source и они взаимозаменяемы.

Ранее мы изучили, что именно Консоль выступает мозгом QRadar. Тем не менее, существует некое ограничение на тот объём данных, который может накапливаться и обрабатываться самой Консолью. Именно здесь в общей картине появляется Процессор событий (Event processor). Основная Консоль способна делегировать свою работу накопления и обработки данных событий такому Процессору событий.

Вот основные службы, запускаемые в каждом Процессоре событий:

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

Такой сервер запросов ariel выполняет запрос к своей базе данных ariel, которая расположена в её Процессоре событий и отправляет полученные в результате данные обратно в свою Консоль, где они и отображаются в Журнале активностей (Log Activity).

Процессор событий способен накапливать сведения при помощи ecs-ec-ingress, выполнять синтаксический разбор данных применяя ecs-ec и обрабатывать эти данных через ecs-ep. Вы заметите, что в каждом Процессоре событий имеется некая база данных ariel, что означает, что все данные событий хранятся локально. Получаемые в результате данные отправляются в свою Консоль только при досмотре соответствующих сведений. В соответствии с настроенными политиками эти полученные результирующие данные удаляются из общей Консоли.

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

Помимо рассмотренного нами Процессора событий важную роль в развёртывании QRadar также играет Сборщик событий. Давайте далее обсудим его.

Сборщик событий (Event Collector) это компонент, который накапливает поступающие сведения событий и далее отправляет их для хранения либо Процессору событий (если таковой присутствует), либо в основную Консоль.

Для некоторых реализаций Источники журналов (которые настроены на отправку данных в QRadar) пребывают в различных временных зонах или в различных сетевых средах и нереально отправлять данные напрямую в Процессор событий или Консоль. В подобной ситуации может применяться Сборщик событий для накопления данных событий локально (относительно его сетевой среды), выполнять их синтаксический разбор при помощи DSM и отправлять это в Процессор событий или Консоль для осуществления корреляции и хранения.

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

Вот запускаемые в Сборщике событий важные службы:

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

Потоки отличаются от событий. Потоки данных это информация конкретного сеанса между двумя хостами. Например, когда некий работник в 9 утра выполняет регистрацию и начинает пользоваться социальной сетью, QRadar перехватывает подробности этого сеанса между машиной данного сотрудника и соответствующим сайтом социальной среды. Это осуществляется перехватом сетевого обмена из зеркального (span) порта коммутатора. Имеются различные типы потоков, которые будут подробнее обсуждаться позднее в Главе 4, Интеграция журналов и потоков в QRadar. Поток данных можно просматривать в закладке Network Activity интерфейса пользователя QRadar, что показано на приводимом ниже снимке экрана:

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

Как и Процессор событий, Процессор потока это иной управляемый хост, который собирает и обрабатывает данные потока. Он имеет базу данных ariel, в которой хранятся данные потока способен выполнять запросы при помощи того же самого механизма, который обсуждался для Процессора событий.

Для Процессора событий у нас имеется ecs-ec-ingress, который накапливает данные событий, однако для ПАроцессора потока мы имеем службу qflow, которая собирает потоки и затем отправляет их в ecs-ec и ecs-ep для последующих обработки и хранения.

Вот важные службы, запускаемые в Процессоре потока:

Как и Сборщик событий, Сборщик потоков применяется для накапливания данных потоков, их анализа и отправки в свой Процессор потока или в общую Консоль для обработки.

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

Сборщик потоков запускает такие важные службы:

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

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

Например, Центральные банки могут обязывать сохранять данные о событиях и потоках на протяжении 2 лет. Доступное в Процессорах хранилище способно хранить данные только за 6 месяцев. В подобной ситуации к Процессору можно добавлять множество Узлов данных с тем, чтобы можно было сохранять обработанные данные.

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

К отдельному Процессору можно подключать множество Узлов данных. Один Узел данных не может быть подключён ко множеству Процессоров. Что это означает, так только то, что один Узел данных будет способен разделять данные лишь с одним Процессором.

Когда в в имеющееся решение добавляются Узлы данных, происходит именно такой процесс, который носит название повторной балансировки данных (data rebalancing). Все приходящие в этот процессор данные распределяются по имеющимся подключёнными Узлам данных.

Если Узел данных отключается (или испытывает крушение), входящие данные не записываются в такой Узел данных. После того как это Узел данных входит в строй, данные снова подвергаются повторной балансировке между своими процессором и Узлом данных. Мы дополнительно коснёмся Узлов данных позднее в Главе 6, Досмотрщики QRadar при обсуждении Досмотрщиков.

Помимо Сборщиков, Процессоров и Консоли а нас имеется рад дополнительных компонентов с богатыми функциональными возможностями, о которых мы и поговорим далее. Некоторые из тех компонентов, которые мы будем обсуждать являются Управляемыми хостами, в то время как Перехватчик пакетов QRadar это Неуправляемый хост.

Давайте приступим к подробному обсуждению каждого компонента.

QNI (QRadar Network Insights, анализатор сетевой среды Qradar) это ещё один компонент QRadar, который применяется для перехвата потока данных. Теперь вас может заинтересовать зачем нам нужен QNI, когда у нас уже имеется Сборщик потоков и Процессор потоков, которые также служат для перехвата потока данных.

И Сборщик потоков, и Процессор потоков обладают службой с названием qflow, которая отвечает за накопление данных потока. qflow перехватывает самые первые 64 байта каждого пакета вместо полной полезной нагрузки. Это выполняется для выделения важных сведений из пакета данных. Если в Процессоре потока сохранять пакет данных целиком, объём данных сетевых пакетов будет настолько гигантским, что он переполнил бы наш Процессор потоков в считанные дни, если не за часы. Таким образом, практичнее перехватывать самые первые 64 байт сведений пакета и сохранять их.

QNI это некое устройство (мы изучим это устройство и насколько оно отличается от установок программного обеспечения в Главе 2, Как сочетаются друг с другом компоненты QRadar), обладает особыми аппаратными средствами для перехвата гигантских фрагментов данных, обработки этих данных, выделения метаданных и отправки их в свой Процессор для хранения. Итак, когда тот же самый перехват пакетов отправлен в QNI, он способен захватывать болше сведений, чем будет перехватывать qflow со своими певыми 64 байтами информации. Например, когда полезная нагрузка содержит сведения о том, что пользователь пытается осуществить доступ в Facebook или же пытается загрузить файл в Dropbox, QNI обладает возможностью перехвата значения хэша того файла, который выгружается (когда он доступен в этой полезной нагрузке). Это значения хэша затем может применяться QRadar для определения через сопоставление значения хэша данного файла с имеющимися у него аналитическими данными угроз будет ли это известной угрозой.

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

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

До сих пор мы обсуждали управляемые хосты, которые развёртываются в среде QRadar для накопления данных и их обработки в плане событий и потоков. Когда дело доходит до криминалистической экспертизы и глубокого изучения связанного с безопасностью инцидента, на горизонте появляется QRIF (QRadar Incident Forensics, расследование инцидентов QRadar).

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

Например, ночью в прошлую пятницу кто- то из окружения банка загрузил в определённый сервер сценарий и запустил его. Через некоторое время часть учётных записей была скомпрометирована и был осуществлён перевод средств. На основании событий и потоков можно выполнить некий предварительный анализ. Однако если с зеркального (span) порта коммутатора, к которому подключался данный сервер, был осуществлён полный перехват пакетов, QRIF имел бы возможность восстановить и реконструировать полный сеанс на основе IP адреса источника и цели (любого иного запроса), причём можно наблюдать веб сеанс, который в точности показывает действия злоумышленника.

Если QRIF способен реконструировать определённый сеанс целиком, это потребует сохранения на момент происшествия полного перехвата пакетов. Именно тут вступает в игру QPCAP (QRadar Packet Capture, перехват пакетов QRadar. QPCAP это неуправляемый хост. Он может быть помещён в сети там, где соответствующий порт QPCAP способен накапливать все сетевые пакеты и сохранять их. Сетевые пакеты способны очень быстро заполнять QPCAP. Поэтому он обладает большим пространством хранения и специальным оборудованием для непосредственного доступа к дисковому вводу/ выводу.

Обычно QPCAP настраивается на перехват т хранение сетевых пакетов за 7 дней. При необходимости, в соответствии с требованиями можно применять множество перехватчиков пакетов.

Наряду с данными о событиях и потоках ещё одной важной информационной стороной с точки зрения безопасности являются сведения об уязвимостях имеющихся в вашей среде активов. Администраторы обязаны обладать сведениями о доступных средствах и степени уязвимости этих активов. Активное и пассивное сканирование представленных в вашей сетевой среде средств осуществляет QVM (QRadar Vulnerability Manager, диспетчер уязвимостей QRadar).

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

QVM это полный инструментарий управления активами, начиная с выявления активов, вплоть до создании отчётов о корректировке этих средств. С этой целью QVM запросто интегрируется с прочими продуктами, такими как BigFix и IBM SiteProtector.

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

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

QRM (QRadar Risk Manager, Диспетчер рисков QRadar) это управляемый хост, который собирает сведения конфигурации от сетевых устройств в своей среде. Эти сведения затем периодически изображаются в виде сетевой топологии.

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

QRM может быть интегрированным с QVM. В QRM могут определяться политики рисков. Для представления образца политики риска в QRM можно задать политику для выяснения того, что когда имеется веб обмен, это не обмен HTTPS. Это означает, что когда весь веб обмен идёт через HTTP, срабатывает данная политика и QRM собирает эти сведения. Данная информация полезна для изменения значений оценок риска уязвимостей для задействованных средств. Всякий раз, когда в QVM изменяются оценки риска, могут вырабатываться оповещения через электронную почту или в панели управления для лучшего отслеживания средств с высокой степенью риска.

Закладка Risk Manager отображает сведения относительно сетевых устройств в имеющейся среде. В последующих версиях QRadar, QRM и QVM будут частью единого устройства и будут продаваться как отдельное решение. Однако основополагающие идеи как QRM, так и QVM остаются теми же самыми, как это обсуждалось в данной главе.

В QRadar, в точности как и в наших смартфонах Android и Apple, имеются приложения, или прикладные приложения, которые могут устанавливаться. Такие приложения расширяют применимость QRadar, а также предоставляют дополнительные функциональные возможности. Все такие прикладные приложения общедоступны через портал QRadar App Exchange.

В разделе Разбираемся с консолью QRadar мы рассмотрели достаточно много служб и задач, которые запускаются в общей Консоли. Установка большого числа прикладных приложений в Консоли будет добавлять вычислительные накладные расходы в плане циклов ЦПУ, загруженности памяти и того дискового пространства, которое требуется этими прикладными приложениями. По этой причине у нас имеется компонент с названием Хост Прикладных приложений (App), в котором производится разгрузка ото всех прикладных приложений Консоли.

На идущем ледом рисунке мы можем наблюдать различные составляющие в сочетании друг с другом. Наиболее важным компонентом является Консоль QRadar и к нему подключаются прочие компоненты для команд и контроля (за исключением QPCAP).

Начиная с Главы 8, Внутренние угрозы - выявление и смягчение последствий мы подробно обсудим все важные прикладные приложения QRadar, которые могут устанавливаться в нём.

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

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