Визначення, мета, завдання та види захисту інформації 6 страница

💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

6) вибір апаратного і програмного забезпечення для реалізаці функцій ЗІ.

Для формального доведення у пунктах 3 і 5 можуть використову ватися математичні методи, якщо сама ПБ була визначена достатнь строго, можливо, у термінах деякої формальної мови. Популярні підх~ ди до формалізації ґрунтуються на станах системи або на її діях. У пі ході, який ґрунтується на станах, функціонування системи розгляд ється як послідовність станів, де стан - це набір значень множин змінних. Підхід, який ґрунтується на діях, розглядає діяльність си стеми у вигляді набору реакцій на події. Ці два різних підходи певному сенсі еквівалентні. Дії можуть бути змодельовані зміною стан а стани можуть бути представлені класами еквівалентності послідо ностей дії. Однак описані підходи звичайно базуються на різних фо мальних теоріях. Моделювання станів у більшості випадків грун ється на логіці, а специфікації представляються формулами в деяк' логічній системі. При моделюванні дії звичайно користуються алге рою, а специфікаціями є об'єкти, з якими оперують алгебраїчни методами. Основою доведень, які проводяться в п. З і 5, як правило, набір теорем. Однак проводити подібний аналіз для кожної систе складно і дорого. Крім того, методика проведення аналізу держави систем - конфіденційна інформація. Вихід було знайдено в тому, * умови теорем, які доводять підтримку ПБ, формулюються без дов дення у вигляді стандарту. Саме такий підхід уперше застосува.і американці 1983 року, опублікувавши відкрито проект стандарту з в електронних системах обробки даних («Оранжева книга»), де ефо мульовано вимоги гарантованої підтримки двох класів політик - ди креційної та мандатної. Пізніше цей метод було застосовано в 1987 для опису гарантовано захищених розподілених мереж, у я підтримуються ті самі політики, а в 1991 p.- для опису вимог гар товано захищених баз даних. Цей же шлях використали канадц європейські держави, створивши свої стандарти з ЗІ. В Україні так розроблено стандарт захисту, аналогічний канадському. Наведені вище підходи до формалізації політики ЗІ дають можливість проаналізувати розроблені стандарти на повноту і коректність.

Серед ПБ найбільш відомі дискреційна, мандатна та рольова. Перші дві досить давно відомі і досліджені [6, 7], а рольова політика (недавнім досягненням теорії та практики захисту інформації [32].

Основою дискреційної політики безпеки (ДПБ) є дискреційне управління доступом (Discretionary Access Control - DAC), яке визначається двома властивостями:

• всі суб'єкти і об'єкти повинні бути однозначно ідентифіковані;

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

Назва пункту є дослівним перекладом терміна Discretionary policy, ще один варіант перекладу - розмежувальна політика. Ця політика -одна з найпоширеніших у світі, в системах по умовчанню мається на увазі саме ця політика.

ДПБ реалізується за допомогою матриці доступу (access matrix), яка фіксує множину об'єктів та суб'єктів, доступних кожному суб'єкту.

Існує декілька варіантів задання матриці доступу.

1.Листи можливостей (privilege list, profile): для кожного суб'єкта створюється лист (файл) усіх об'єктів, до яких він має доступ.

2.Листи контролю доступу (access control list): для кожного об'єкта створюється список усіх суб'єктів, що мають доступи до нього.

До переваг ДПБ можна віднести відносно просту реалізацію відпо-ідних механізмів захисту. Саме цим зумовлений той факт, що біль-jicTb поширених сьогодні захищених АС забезпечують виконання по-ожень ДПБ. Крім того, при її реалізації досягається велика економія ам'яті, оскільки матриця доступів звичайно буває дуже розрядженою.

Однак багатьох проблем захисту ця політика розв'язати не може, 'введемо найбільш суттєві вади ДПБ.

1. Один із найсуттєвіших недоліків цього класу політик - те, що вони
ін- витримують атак за допомогою «Троянського коня». Це, зокрема,
- іпачає, що СЗІ, яка реалізує ДПБ, погано захищає від проникнення

ірусів у систему й інших засобів прихованої руйнівної дії.

2. Наступна проблема ДПБ - автоматичне визначення прав. Так як
(і(> (ктів багато і їх кількість безперервно змінюється, то задати за-
піл легідь вручну перелік прав кожного суб'єкта на доступ до об'єктів
неможливо. Тому матриця доступу різними способами агрегується,
■ иприклад, як суб'єкти залишаються тільки користувачі, а у відпові-
ді^ клітину матриці вставляються формули функцій, обчислення
имі\ визначає права доступу суб'єкта, породженого користувачем, до
■ 'єкта. Звичайно, ці функції можуть змінюватися з часом. Зокрема

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

4.При використанні ДПБ виникає питання визначення правил поширення прав доступу й аналізу їх впливу на безпеку АС. У загальному випадку при використанні ДПБ перед органом, який її реалізує і який при санкціонуванні доступу суб'єкта до об'єкта керується деяким набором правил, стоїть задача, яку алгоритмічно розв'язати неможливо: перевірити, призведуть його дії до порушень безпеки чи ні.

Отже, матриця доступів не є тим механізмом, який дозволив би реалізувати ясну і чітку СЗІ в АС. Більш досконалою ПБ виявилася мандатна ПБ.

Основу мандатної (повноважної) політики безпеки (МПБ) становить мандатне управління доступом (Mandatory Access Control -МАС), яке передбачає, що:

• всі суб'єкти і об'єкти повинні бути однозначно ідентифіковані;

• задано лінійно упорядкований набір міток секретності;

• кожному об'єкту системи присвоєна мітка секретності, яка визначає цінність інформації, що міститься в ньому - його рівень секретності в АС;

• кожному суб'єкту системи присвоєна мітка секретності, яка визначає рівень довіри до нього в АС - максимальне значення мітки секретності об'єктів, до яких суб'єкт має доступ; мітка секретності суб'єкта називається його рівнем доступу.

Основна мета МПБ - запобігання витоку інформації від об'єктів з високим рівнем доступу до об'єктів з низьким рівнем доступу, тобто: протидія виникненню в АС інформаційних каналів зверху вниз. Вона оперує, таким чином, поняттями інформаційного потоку і цінності; (певним значенням мітки секретності) інформаційних об'єктів.

Цінність інформаційних об'єктів часто дуже важко визначити. Однак досвід показує, що в будь-якій АС майже завжди для будь-якої пари об'єктів X та Y можна сказати, який із них більш цінний. Тобтй можна вважати, що таким чином фактично визначається деяка однозначна функція с(Х), яка дозволяє для будь-яких об'єктів X і я сказати, що коли Y більш цінний об'єкт, ніж X, то с(У) > с(Х). I HaenaJ ки, з огляду на однозначність, якщо с(У) > с(Х), то Y - більш цінний об'єкт, ніжХ. Тоді потік інформації від Хдр /дозволяється, якщо с(Х) < c(Y), і не дозволяється, якщо с(Х) > с(У).

Таким чином, МПБ має справу з множиною інформаційних потоків, яка ділиться на дозволені і недозволені дуже простою умовою -значенням наведеної функції. Інакше кажучи, управління потоками інформації здійснюється через контроль доступів.

МПБ в сучасних системах захисту на практиці реалізується мандатним контролем. Він реалізується на найнижчому апаратно-програмному рівні, що дозволяє досить ефективно будувати захищене середовище для механізму мандатного контролю. Пристрій мандатного контролю називають монітором звернень. Мандатний контроль ще називають обов'язковим, оскільки його має проходити кожне звернення суб'єкта до об'єкта, якщо вони знаходяться під захистом СЗІ. Організується він так: кожний об'єкт має мітку з інформацією Про свій рівень секретності; кожний суб'єкт також має мітку з інформацією про те, до яких об'єктів він має право доступу. Мандатний контроль порівнює мітки і приймає рішення про допуск.

Найчастіше МПБ описують у термінах, поняттях і визначеннях Властивостей моделі Белла-Лападула [5]. У рамках цієї моделі дово-Ьиться важливе твердження, яке вказує на принципову відмінність кистем, що реалізують мандатний захист, від систем з дискреційним Ьахистом: якщо початковий стан системи безпечний і всі переходи Системи зі стану до стану не порушують обмежень, сформульованих ПБ, то будь-який стан системи безпечний.

1.Для систем, де реалізовано МПБ, характерним є більш високий рупінь надійності. Це пов'язано з тим, що за правилами МПБ відсте-■ суються не тільки правила доступу суб'єктів системи до об'єктів, а й сіан самої АС. Таким чином, канали витоку в системах такого типу Не закладені первісно (що є в положеннях ДПБ), а можуть виникнути рільки при практичній реалізації систем внаслідок помилок розробника.

2.Правила МПБ більш ясні і прості для розуміння розробниками і Користувачами АС, що також є фактором, який позитивно впливає на рівень безпеки системи.

4.МПБ допускає можливість точного математичного доведення, то дана система в заданих умовах підтримує ПБ.

\ Однак МПБ має дуже серйозні вади - вона складна для практичної реалізації і вимагає значних ресурсів обчислювальної системи. Це ■ ов'язано з тим, що інформаційних потоків у системі величезна кпи.кість і їх не завжди можна ідентифікувати. Саме ці вади часто Ііінажають її практичному використанню.

МПБ прийнята всіма розвинутими державами світу. Вона розроблялася, головним чином, для збереження секретності (тобто конфіденційності) інформації у військових організаціях. Питання ж цілісності

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

Розглянемо ще один вид ПБ - рольову ПБ. Рольову політику безпеки (РПБ) (Role Base Access Control - RBAC) не можна віднести ані до дискреційної, ані до мандатної, тому що керування доступом у ній здійснюється як на основі матриці прав доступу для ролей, так і за допомогою правил, які регламентують призначення ролей користувачам та їх активацію під час сеансів [32]. Отже, рольова модель є цілком новим типом політики, що базується на компромісі між гнучкістю керування доступом, яка є характерною для ДПБ, і жорсткістю правил контролю доступу, яка притаманна МПБ.

У РПБ класичне поняття суб'єкт заміщується поняттями користувач і роль. Користувач - це людина, яка працює з системою і виконує певні службові обов'язки. Роль - це активно діюча в системі абстрактна сутність, з якою пов'язаний обмежений, логічно зв'язаний набір повноважень, необхідних для здійснення певної діяльності.

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

Тому цілком логічно здійснювати керування доступом і призначать повноваження не реальним користувачам, а абстрактним (не персо-< ніфікованим) ролям, які представляють учасників певного процесу] обробки інформації. Такий підхід до ПБ дозволяє врахувати розподі ¹обов'язків і повноважень між учасниками прикладного інформацій ного процесу, оскільки з точки зору РПБ має значення не особистіс користувача, що здійснює доступ до інформації, а те, які повнова ження йому необхідні для виконання його службових обов'язків Наприклад, у реальній системі обробки інформації можуть працюва системний адміністратор, менеджер баз даних і прості користувачі.

У такій ситуації РПБ дає змогу розподілити повноваження між ци ми ролями відповідно до їх службових обов'язків: ролі адміністратор ра призначаються спеціальні повноваження, які дозволять йому кон тролювати роботу системи і керувати її конфігурацією; роль мене джера баз даних дає змогу здійснювати керування сервером БД; права простих користувачів обмежуються мінімумом, необхідним запуску прикладних програм. Крім того, кількість ролей у систеї може не відповідати кількості реальних користувачів - один корис тувач, якщо він має різні повноваження, може виконувати (водноч або послідовно) кілька ролей, а кілька користувачів можуть корист ватись однією і тією ж роллю, якщо вони виконують однакову роботу.

При використанні РПБ керування доступом здійснюється в стадії: по-перше, для кожної ролі вказується набір повноважень, являють собою набір прав доступу до об'єктів, і, по-друге, кожно

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

Р - множина повноважень на доступ до об'єктів, що подається, наприклад, у вигляді матриці прав доступу;

S - множина сеансів роботи користувачів із системою.

Для перелічених множин визначаються такі відношення:

PAczPxR- відображає множину повноважень на множину ролей, встановлюючи для кожної ролі набір наданих їй повноважень;

UAczUx R - відображає множину користувачів на множину ролей, визначаючи для кожного користувача набір доступних йому ролей.

Правила керування доступом рольової політики безпеки визначаються такими функціями:

user. З¹—> U— для кожного сеансу s ця функція визначає користувача и, який здійснює цей сеанс роботи з системою: user{s) = и;

roles: S—+R - для кожного сеансу s ця функція визначає набір ролей з множини R, що можуть бути одночасно доступні користувачу и в цьому сеансі: roles(s) = {r \ (user(s), г) є UA}; permissions: S —* Р - для кожного сеансу s ця функція задає набір доступних у ньому повноважень, який визначається як сукупність повноважень усіх ролей, що беруть участь у цьому сеансі: permissions(s) = {р \ (р, г) є РА}. Як критерій безпеки рольової моделі використовується таке правило: система вважається безпечною, якщо будь-який користувач системи, що працює в сеансі s, може здійснити дії, які вимагають повноважень р тільки в тому випадку, колир є permissions^).

З формулювання критерію безпеки моделі РПБ випливає, що управління доступом здійснюється головним чином не за допомогою призначення повноважень ролям, а шляхом задання відношення UA, яке призначає ролі користувачам, і функції roles, що визначає доступний у сеансі набір ролей. Тому численні інтерпретації рольової моделі відрізняються видом функцій user, roles і permission, а також обмеженнями, що накладаються на відношення РА та UA. Як приклади розглядається рольова політика управління доступом з ієрархічною організацією ролей, а також кілька типових обмежень на відношення РА та UA і функції user та roles, що найчастіше зустрічаються на практиці.

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

Завдяки гнучкості та широким можливостям РПБ суттєво перевершує інші політики, хоча іноді її певні властивості можуть виявитися негативними. Так, вона практично не гарантує безпеки за допомогою формального доведення, а тільки визначає характер обмежень, виконання яких і є критерієм безпеки системи. Хоча такий підхід дозволяє отримати прості і зрозумілі правила контролю доступу (перевага), які легко застосовувати на практиці, але позбавляє систему теоретичної доказової бази (вада). В деяких ситуаціях ця обставина утруднює використання РПБ, однак, у будь-якому разі, оперувати ролями набагато зручніше, ніж суб'єктами (знову перевага), оскільки це більше відповідає поширеним технологіям обробки інформації, які передбачають розподіл обов'язків і сфер відповідальності між користувачами.

Крім того, РПБ може використовуватися одночасно з іншими ПБ, коли повноваження ролей, що призначаються користувачам, контролюються ДПБ або МПБ, що дає змогу будувати багаторівневі схеми контролю доступу.

5 МЕХАНІЗМИ ЗАХИСТУ ІНФОРМАЦІЇ ВІД НЕСАНКЦІОНОВАНОГО ДОСТУПУ

Доступ до інформації (access to information) - вид взаємодії двох об'єктів КС, унаслідок якого створюється потік інформації під одного об'єкта до іншого і/або відбувається зміна стану системи. Доступ характеризується типом та атрибутами [1-3].

Тип доступу (access type) - сутність доступу до об'єкта, що характеризує зміст здійснюваної взаємодії, а саме: проведені дії, напрям потоків інформації, зміни в стані системи (наприклад, читання, запис, запуск на виконання, видалення, дозапис).

Атрибут доступу (tag, access mediation information) - будь-яка пов'язана з об'єктом КС інформація, яка використовується для керування доступом.

Кожному доступу передує запит на доступ. Запит на доступ (access request) - звернення одного об'єкта КС до іншого з метою отримання певного типу доступу.

Керування доступом (access control) - це сукупність заходів із визначення повноважень і прав доступу, контролю за додержанням ПРД. Воно включає питання обмеження доступу, розмежування доступу, розподіл доступу (привілеїв), контроль та облік доступу.

Існує чотири основні способи керування доступом:

• фізичний, коли суб'єкти звертаються до фізично різних об'єктів;

• часовий, коли суб'єкти з різними правами доступу звертаються до одного об'єкта в різні проміжки часу;

• логічний, коли суб'єкти отримують доступ до спільного об'єкта в рамках однієї ОС;

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

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

Розмежування доступу в АС полягає в поділі інформації, яка в ній обробляється, на частини та організації доступу до них відповідно до функціональних обов'язків та повноважень.

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

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

• технічне обслуговування АС у процесі експлуатації має виконуватися окремим персоналом без доступу до інформації, що підлягає захисту;

• перезавантаження програмного забезпечення і його зміни повинні здійснюватися спеціально виділеним для цієї мети перевіреним фахівцемфункції забезпечення безпеки інформації повинні виконуватися спеціальним підрозділом в організації (власнику АС, обчислювальної мережі і т. п.) - службою безпеки;

• організація доступу до даних АС забезпечує можливість розмежування доступу до інформації, що обробляється в ній, з достатнім ступенем деталізації і відповідно до заданих рівнів повноважень користувачів;

• реєстрація і документування технологічної та оперативної інформації повинні бути розділені.

Розмежування доступу користувачів повинно відбуватися за такими параметрами:

• за видом, характером, призначенням, ступенем важливості та секретності інформації;

• за способами її обробки: зчитувати, записувати, модифікувати, виконати команду;

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

Розподіл доступу (привілеїв) до інформації полягає в тому, що з числа допущених до неї посадових осіб виділяється група, яка може отримати доступ тільки при одночасному пред'явленні повноважень всіх членів групи. Завдання такого методу — суттєво утруднити навмисне перехоплення інформації порушником. Прикладом такого доступу є сейф з декількома ключами, замок, який можна відчинити тільки за наявності всіх ключів. Аналогічно в АС може бути застосований іакий механізм при доступі до особливо важливих даних. Хоча даний метод ускладнює процедуру доступу, проте має високу ефективність.

Контроль та облік доступу реалізується за допомогою такої послуги, як реєстрація. Реєстрація (audit, auditing) - це процес розпізнавання, фіксування й аналізу дій і подій, що пов'язані з дотриманням політики безпеки інформації. Використання засобів перегляду й аналізу журналів, а особливо засобів настроювання механізмів фіксування подій, повинно бути прерогативою спеціально авторизованих користувачів. Часто [ 12] сам процес реєстрації підрозділяється на протоколювання та аудит. Під протоколюванням розуміється збір і нагромадження інформації про події, що відбуваються в інформаційній системі. Аудит - це аналіз накопиченої інформації. Оскільки в нормативних документах України [17-20] визначено тільки поняття реєстрації, далі буде використовуватися саме воно. Опис усього, що пов'язано з реєстрацією, який наводиться нижче, цілком відповідає [17-20].

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

• Для жодного з рівнів послуги не встановлюється ніякого фіксованого набору контрольованих подій [12], оскільки для кожної КС їх перелік може бути специфічним. Критична для безпеки подія визначається як гака, що пов'язана зі звертанням до якої-небудь послуги безпеки чи відбулася в результаті виконання якої-небудь функції СЗІ, чи що-небудь інше, що хоча прямо і не обумовлено функціонуванням механізмів, які реалізують послуги безпеки, але може призвести до порушення політики безпеки. Остання група подій визначається як така, що маєфункції забезпечення безпеки інформації повинні виконуватися спеціальним підрозділом в організації (власнику АС, обчислювальної мережі і т. п.) - службою безпеки;

• реєстрація і документування технологічної та оперативної інформації повинні бути розділені.

Розмежування доступу користувачів повинно відбуватися за такими параметрами:

• за видом, характером, призначенням, ступенем важливості та секретності інформації;

• за способами її обробки: зчитувати, записувати, модифікувати, виконати команду;

Для жодного з рівнів послуги не встановлюється ніякого фіксованого набору контрольованих подій [12], оскільки для кожної КС їх перелік може бути специфічним. Критична для безпеки подія визначається як гака, що пов'язана зі звертанням до якої-небудь послуги безпеки чи відбулася в результаті виконання якої-небудь функції СЗІ, чи що-небудь інше, що хоча прямо і не обумовлено функціонуванням механізмів, які реалізують послуги безпеки, але може призвести до порушення політики безпеки. Остання група подій визначається як така, що має непряме відношення до безпеки. Для з'ясування ступеня небезпеки таких подій часто є необхідним їх аналіз у контексті інших подій, що відбулися.

Для реалізації найбільш високих рівнів даної послуги необхідна наявність засобів аналізу журналу реєстрації (audit trail), що виконують більш складну, ніж перегляд, оцінку журналу з метою виявлення можливих порушень політики безпеки, що дозволяє адміністратору здійснювати сортування, фільтрацію за визначеними критеріями й інші подібні операції. СЗІ повинна надавати адміністратору можливість вибирати події, що реєструються. Це може бути досягнуто шляхом передвибірки або поствибірки. Передвибірка подій дозволяє виділити при ініціалізації системи з усієї множини доступних для реєстрації подій підмножину тих, котрі необхідно реєструвати в журналі. Використовуючи передвибірку, адміністратор може зменшити кількість подій, що реально реєструються, і, отже, розмір остаточного журнального файла. Недоліком є те, що обрані події не можуть уже пізніше бути проаналізовані, навіть якщо виникне така необхідність. Перевага ж поствибірки полягає в гнучкості можливості аналізу постфактум, однак така організація ведення журнального файла вимагає виділення значного обсягу пам'яті під дані реєстрації.

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

• політика реєстрації в СЗІ визначає перелік подій, що реєструються;

• СЗІ здійснює реєстрацію подій, що мають безпосереднє чи непряме відношення до безпеки;

• журнал реєстрації містить інформацію про дату, час, місце, типи і успішність або неуспішність кожної зареєстрованої події, а також інформацію, достатню для встановлення користувача, процесу і/або об'єкта, що мали відношення до кожної зареєстрованої події;

• СЗІ забезпечує захист журналу реєстрації від НСД, модифікації чи руйнування. Адміністратори і користувачі, яким надані відповідні повноваження, мають у своєму розпорядженні засоби перегляду й аналізу журналу реєстрації;

• СЗІ здатна контролювати одиничні чи повторювані події, що можуть свідчити про прямі (істотні) порушення політики безпеки КС. СЗІ повинна бути здатною негайно інформувати адміністратора про перевищення порогів безпеки і, якщо небезпечні події повторюються, здійснити дії для їх припинення;