Добавил:
twitch.tv Заведующий методическим кабинетом, преподаватель на кафедре компьютерного спорта и прикладных компьютерных технологий. Образование - Магистр Спорта. Суета... Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Гахов С.О (3 курс 1 семестр) (2 назв. SIEM системи) / Ответы для экзамена ( теор. часть ).docx
Скачиваний:
10
Добавлен:
04.06.2023
Размер:
7.73 Mб
Скачать

Пз_т2 ббмхт-20201217t130640z-001 нужно рассказать как настраивать главную панель

49 Функція розподілу пріоритетів порушень (Offense prioritization) в IBM QRadar SIEM та її зміст.

Величина рейтингу порушення є мірою його важливості у вашому середовищі. IBM QRadar використовує рейтинг балів для визначення пріоритетності порушень і допомагає вам визначити, які порушення слід розслідувати в першу чергу.

Величина рейтингу порушення розраховується на основі релевантності, серйозності і достовірності.

Релевантність визначає вплив порушення у вашій мережі. Наприклад, якщо порт відкритий, значимість висока.

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

Рівень серйозності вказує рівень загрози, який створює джерело щодо того, наскільки ціль підготовлена для атаки.

QRadar використовує складні алгоритми для розрахунку рейтингу величини порушення і рейтинг переоцінюється, коли нові події додаються до порушення, а також за розкладом. При обчисленні величини порушення враховується наступна інформація:

кількість подій і потоків, пов'язаних з порушенням;

кількість джерел журналів;

часовий інтервал порушення;

вага мережевого об'єкта, пов'язаного з порушенням;

категорія, серйозність, релевантність і достовірність подій і потоків, які сприяють вчиненню порушення, вразливість і оцінка загрози власниками, які беруть участь в порушенні.

Величина рейтингу порушення відрізняється від оцінки величини для події. Ви можете впливати на величину порушення, встановлюючи величину події в діях правила, але ви не можете обійти алгоритми QRadar, щоб самостійно встановити величину порушення.

50 Функція розслідування порушень (Offense investigations) в IBM QRadar SIEM та її зміст.

https://www.ibm.com/support/knowledgecenter/SS42VS_7.3.2/com.ibm.qradar.doc/c_qradar_ug_offence_investigation.html

51. Правила виявлення аномалій (Anomaly detection rules): правила аномалій (Anomaly rules), порогові правила (Threshold rules) та поведінкові правила (Behavioral rules), їх зміст.

52. Порядок створення правил виявлення аномалій (Creating an anomaly detection rule) в IBM QRadar SIEM.

Лаб_Т8 ББМХТnew

53 Призначення історичної кореляції (Historical correlation) в IBM QRadar SIEM та її зміст. Профіль історичної кореляції

Історична кореляція може бути корисна в наступних ситуаціях:

при аналізі об’ємних даних

Якщо ви масово завантажуєте дані свого розгортання QRadar, ви можете використовувати історичну кореляцію для зіставлення даних з даними, зібраними в режимі реального часу. Наприклад, щоб уникнути зниження продуктивності в звичайні робочі години, ви завантажуєте події з кількох джерел журналів щоночі опівночі. Ви можете використовувати історичну кореляцію для кореляції даних по часу пристрою, щоб побачити послідовність мережевих подій, як вони відбулися за останні 24 години.

при тестуванні нових правил

Ви можете запустити історичну кореляцію, щоб перевірити нові правила. Наприклад, один з ваших серверів був недавно атакований новим шкідливим ПЗ, для якого у вас немає правил. Ви можете створити правило для перевірки цього шкідливого ПЗ. Потім ви можете використовувати історичну кореляцію, щоб порівняти правило з історичними даними, щоб побачити, чи буде правило викликати відповідь, якщо воно було на місці під час атаки. Точно так само ви можете використовувати історичну кореляцію, щоб визначити, коли атака вперше відбулася або частоту атаки. Ви можете продовжити настройку правила і потім перемістити його в робочу середу.

при відтворення порушень, які були втрачені або очищені

Якщо ваша система втратила порушення через збій або з іншої причини, ви можете відтворити порушення, виконавши історичну кореляцію подій і потоків, що надійшли за цей час.

при виявлення раніше прихованих загроз

Коли стає відома інформація про останні загрози безпеці, ви можете використовувати історичну кореляцію, щоб ідентифікувати мережеві події, які вже відбулися, але не ініціювали подію. Ви можете швидко перевірити наявність загроз, які вже скомпрометували систему або дані вашої організації.

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

Вибір даних

Профіль використовує збережений пошук, щоб зібрати історичні події і дані потоку для використання в прогоні. Переконайтеся, що ваш профіль безпеки надає дозвіл на перегляд подій і потоків, які ви хочете включити в прогін хронологічній кореляції.

Вибір правил і обробка

Консоль QRadar обробляє дані тільки проти правил, які вказані в історичній кореляції профілю.

Загальні правила перевіряють дані як в події, так і в потоках. У вас має бути дозвіл на перегляд подій і потоків, перш ніж ви зможете додати загальні правила в профіль. Коли профіль редагується користувачем, у якого немає дозволу на перегляд як подій, так і потоків, загальні правила автоматично видаляються з профілю.

Ви можете включити відключені правила в історичний профіль кореляції. Коли працює профіль, відключене правило оцінюється по вхідних подій і потокам. Якщо правило спрацювало, і дію правила полягає в створенні порушення, то порушення створюється, навіть якщо правило відключено. Щоб уникнути створення непотрібних відволікаючих чинників, відповіді правил, такі як генерація звітів і поштові повідомлення, ігноруються під час історичної кореляції.

Оскільки обробка історичної кореляції відбувається в одному місці, правила, включені в профіль, розглядаються як глобальні правила. Обробка не змінює правило з локального на глобальне, але обробляє правило так, як якщо б воно було глобальним під час прогону хронологічній кореляції. Деякі правила, такі як правила зі станом, можуть не викликати таку ж відповідь, як у звичайній кореляції, виконуваної на локальному процесорі подій. Наприклад, локальне правило з відстеженням стану, яке відстежує п'ять невдалих входів в систему за 5 хвилин від одного і того ж імені користувача, поводиться по-різному при звичайних і історичних запусках кореляції. При нормальній кореляції це локальне правило підтримує лічильник кількості невдалих входів в систему, отриманих кожним локальним оброблювачем подій. В історичній кореляції це правило підтримує єдиний лічильник для всієї системи QRadar. У цій ситуації порушення можуть створюватися по-іншому в порівнянні з нормальним прогоном кореляції.

Створення порушення

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

Максимальна кількість порушень, які можуть бути створені за допомогою історичного прогону кореляції, становить 100. Історичний прогін кореляції зупиняється, коли досягається межа.

Ви можете переглядати історичні порушення на панелі моніторингу загроз і безпеки та на вкладці Порушення одночасно з переглядом порушень в реальному часі.

Навчальне питання 3. Управління профілем історичної кореляції.

Слайд 5

Ви можете запускати хронологічні події і потоки через призначений для користувача механізм правил (Custom Rules Engine, CRE) і створювати порушення на основі правил, зконфігурованих в профілі хронологічній кореляції.

Запуски хронологічної кореляції створюють порушення, тільки якщо ініційовано правило і дія правила вказує, що потрібно створити порушення. Порушення створюється, навіть якщо правило відключено.

54. Призначення звітів. Типи звітів. Керування звітами (Report management) в IBM QRadar SIEM.

55. Інтеграця IBM X-Force, призначення, зміст даних та правил X-Force.

Величезний потенціал IBM X-Force

X-Force Threat Intelligence - це набагато більше, ніж просто компіляція даних про загрози. За цим рішенням стоїть вся міць команди досліджень і розробок IBM X-Force - однієї з найстаріших і найбільш відомих в світі дослідницьких груп, що займаються питаннями безпеки. Команда експертів з безпеки створює основу превентивного підходу IBM до захисту від загроз в Інтернеті, направляючи свої зусилля на дослідження і оцінку вразливостей і проблем безпеки, розробку технологій забезпечення безпеки для продуктів IBM і інформування користувачів про виникаючі Інтернет-загрози і тенденції.

Група X-Force грає найважливішу роль в захисті користувачів від загрози атак, оскільки її база знань і методи збору даних не мають собі рівних в галузі. З точки зору вразливостей, група обслуговує і аналізує одну з найбільших в світі баз даних ізвестнихуязвімостей безпеки, що містить понад 70 тис. Записів, включаючи детальний аналіз кожної помітної опублікованій вразливості, починаючи з 1994 року. З точки зору загроз, група щодня відстежує мільярди інцидентів безпеки, здійснює моніторинг мільйонів спам-розсилок і фішингових атак, і аналізує мільярди Web-сторінок і зображень. Група X-Force підтримує глобальну дослідницьку середовище, яке забезпечує користувачів.

56 Керування журналами (Log Source Management) в IBM QRadar SIEM та його основні функції.

https://www.ibm.com/support/knowledgecenter/SS42VS_DSM/com.ibm.dsm.doc/c_logsource_manage.html?cp=SS42VS_7.3.2

57 Ключи активації та ліцензійні ключи (Activation keys and license keys), їх призначення, зміст та порядок встановлення в IBM QRadar SIEM

https://www.ibm.com/support/knowledgecenter/SS42VS_7.3.2/com.ibm.qradar.doc/c_qif_act_lic_keys.html

58 Джерела даних про події (log sources, DSMs and automatic updates), їх зміст та технологія їх оброблення.

https://www.ibm.com/support/knowledgecenter/SS42VS_7.3.2/com.ibm.qradar.doc/c_tuning_guide_deploy_dsmupdates.html#c_tuning_guide_deploy_dsmupdates

59 Призначення служб Magistrate консолі IBM QRadar SIEM, зміст основних функцій Magistrate

Магістрат на консолі QRadar

Компонент Magistrate виконує наступні функції:

Правила порушення – моніторинг і дії щодо порушень, таких як створення повідомлень по електронній пошті.

Управління порушеннями – оновлює активні порушення, змінює статус порушень і надає користувачеві доступ до інформації про порушення з вкладки «Порушення».

Зберігання порушень – записує дані про порушення в БД PostgreSQL.

Ядро обробки магістрату (MPC) відповідає за зіставлення порушень з повідомленнями про події від декількох компонентів Event Processor. Тільки пристрій QRadar Console або багатофункціональний пристрій має компонент Magistrate.

https://www.ibm.com/support/knowledgecenter/SS42VS_7.3.3/com.ibm.qradar.doc/c_qradar_deploy_event_and_flow_pipeline.html