В огляді CISO Assistant я вже казав, що інструмент подобається мені саме інженерним підходом до GRC. Найкраще це видно на прикладі оцінки ризиків: замість одного “правильного” способу порахувати ризик, платформа з коробки дає три різні методологічні рівні - і це не маркетингова фіча, а різні математичні моделі під різні задачі.

Якісний підхід: категоріальна матриця

Найпростіший і найпоширеніший спосіб - матриця ризиків, лукап-таблиця “ймовірність × вплив → рівень ризику”. У бандлі є більше десятка готових матриць: базові 3x3/4x4/5x5/6x6, галузеві (PGSSI-S для охорони здоров’я, DORA ICT RTS для фінсектору), і що цікаво - матриця, побудована прямо на основі EBIOS RM (4x4).

Ключова риса якісної матриці - рівень ризику в кожній клітинці не обчислюється, а призначається експертом при побудові матриці. “Ймовірна × критична” - це просто домовленість “хай буде критичний”, а не результат формули. Матриця фіксується на весь час існування оцінки ризиків: аудитори не люблять, коли шкала тихцем змінюється посеред оцінки.

Напівкількісний підхід: мультиплікативний скоринг

Проміжний варіант - матриці на кшталт вбудованої “3x3 multiplicative”. Тут ймовірності та впливу присвоюються числа (1, 2, 3), а підсумковий бал ризику - це буквально їх добуток: 1×1=1 (низький), 2×3=6 (високий), 3×3=9 (критичний).

Різниця з чисто якісним підходом на перший погляд непомітна - в UI так само бачиш кольорову клітинку - але під капотом там уже арифметика, а не довільне експертне рішення. Це дає прозоріше пріоритезування (числа можна сортувати й агрегувати) без складності повноцінного кількісного аналізу. Класичний місток між “просто категоріями” і “статистикою”.

Кількісний підхід: гроші, а не кольори

Третій рівень - кількісні дослідження ризику (Quantitative Risk Studies), і це вже зовсім інша модель, ближча до методології FAIR. Замість матриці кожен сценарій ризику параметризується двома розподілами:

  • частота настання збитку - як часто “погана подія” стається за рік,
  • величина збитку - у скільки вона обходиться, коли стається.

Платформа проганяє ці розподіли через Monte-Carlo симуляцію і будує криву перевищення втрат, а на її основі рахує очікувані втрати, вартість під ризиком (Value-at-Risk) та хвостові втрати. Це вже не “низький/середній/високий”, а конкретна сума в євро з довірчим інтервалом - мова, зрозуміла фінансовому директору, коли треба обґрунтувати бюджет на контроль.

Спільна риса всіх трьох

Хай яким підходом ви рахуєте ризик, CISO Assistant завжди веде три стадії одного сценарію:

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

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

Що з цим робити

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

Кількісний аналіз - не питання вибору “коли треба обґрунтувати цифрами”, а питання наявності даних. Щоб побудувати розподіли частоти й величини збитку, потрібна або статистика інцидентів (яка в більшості компаній або відсутня, або надто скупа для довірчого інтервалу), або достатньо кваліфіковане експертне судження, яке ці розподіли зможе обмежити хоча б орієнтовно. Немає ні того, ні іншого - кількісна оцінка перетвориться на псевдоточні цифри з повітря, що гірше за чесну якісну матрицю.

Окремо CISO Assistant підтримує ще й повноцінну EBIOS RM (французьку національну методологію ANSSI з п’ятьма воркшопами) - але це вже тема для окремої статті.