Завантаження звичайної програми, вхід адміністратора до системи чи незвичний мережевий запит самі по собі не завжди означають атаку. У колонці для SecurityWeek віцепрезидент із аналізу загроз Cato Networks Етай Маор пропонує оцінювати не один алерт, а послідовність подій і обставини навколо неї.
Проблема, за його описом, не у браку даних. Організації вже збирають відомості про облікові записи, пристрої, програми, мережеві з’єднання та відомі слабкі місця. Але ці дані часто зберігаються в різних інструментах. Поки фахівець вручну зіставляє окремі сповіщення, атака може перейти від непомітної дії до серйозного інциденту.
Легітимна програма може бути частиною підозрілої послідовності
Маор наводить ілюстративний сценарій: працівник фінансового відділу завантажує програму для віддаленого адміністрування. Такі інструменти використовують і внутрішні ІТ-команди, тому саме завантаження не є доказом загрози. Однак система може побачити інші деталі: цей користувач раніше не працював з такою програмою, а файл отримано з домену з низькою репутацією.
Якщо згодом той самий працівник завантажує ще один подібний інструмент, дві події варто розглядати разом. У цьому і полягає контекстуальний захист: він відповідає не лише на питання, чи є дія шкідливою, а й намагається визначити, до чого може привести цей ланцюжок і якою найменш обтяжливою дією його зупинити.
Для такої оцінки, за словами автора, потрібно поєднувати дані про особу та звичну поведінку користувача, важливість пристрою чи системи, мережеву активність, відомі уразливості, попередні інциденти й відомості про типові схеми атак. Та сама дія матиме різний ризик залежно від того, хто її виконав, на якому пристрої та з якими попередніми подіями вона пов’язана.
Автоматична реакція не повинна одразу зупиняти роботу
Контекст допомагає обрати пропорційну відповідь. Замість негайного блокування пристрою система може, наприклад, запросити додаткове підтвердження входу або тимчасово обмежити доступ до певної програми. Це дає змогу стримати ризик і водночас менше заважати працівнику, якщо підозра не підтвердиться.
Маор радить заздалегідь визначати межі автоматичних дій, особливо для привілейованих облікових записів і доступу до фінансових або клієнтських даних. Кожне автоматичне обмеження має бути зафіксоване, зрозуміле для команди та придатне до скасування після появи нових відомостей.
Основою такого підходу автор називає якісні дані: актуальні записи про користувачів, перелік пристроїв і систем, а також повну інформацію про події в мережі. Результат варто оцінювати не кількістю пов’язаних алертів, а часом виявлення й стримування інциденту та шкодою від хибних спрацювань.