Темп Кібератак у Майбутньому
Вступ
З розвитком AI, експлуатація мереж стає все більш автоматизованою. Якщо вже існують компанії, що продають автономний AI-пентест (як от Pentera чи XBow), можна припустити, що й зловмисники вже розвивають власні AI-рішення. У цьому пості я розповім, чому за такого розвитку подій SIEM та SOC команди не зможуть вижити без змін, а також поділюся думками, що можна зробити вже зараз.
Класичні Атаки
Рансомварь атаки на Active Directory мережі часто тривають декілька тижнів, а то й місяців. Проте, чим зумовлені такі затримки? Що заважає пройти зловмисникам пройти шлях від Initial Access до Impact за годину? З моїх спостережень, причинами затримок був людський фактор:
- Аналіз даних, отриманих на етапі Discovery
- Тривале дослідження платоспроможності жертви
- Методичний збір та ексфільтрація даних жертви
- Також, зловмисники не завжди працюють щодня :)
За тиждень часу у SOC команди є більш ніж достатньо часу на виявлення загрози до етапу шифрування, навіть якщо SIEM генерує алерти раз в годину, а аналіз алерту займає пів доби. Ніби все чудово, рухаємось далі.
Автоматизовані Атаки
Тепер, уявіть що затримок через людський фактор в атаці немає. Наприклад, якщо AI планує стадію атаки, скрипти швидко виконують заплановані дії, AI аналізує вивід скриптів, і знову по колу. Для невеликих компаній, такий сценарій цілком може означати “From Zero to Domain Admin in 10 minutes”. А для SOCів такий сценарій є справжньою бідою, адже:
- Не завжди атаку можна виявити на етапі Initial Access
- SIEM алертить з затримкою (2+ хвилин, часто 10+)
- SOCу потрібен час на аналіз (2+ хвилин, часто 20+)
- Локалізація загрози часто робиться вручну (5+ хвилин)
Якими б крутими не були аналітики, затримки SOCу просто не лишають шансу на протидію автоматизованим атакам. Навряд чи є чарівна паличка для цієї проблеми, проте все ж хочу поділитись рекомендаціями щодо усіх п’яти наведених пунктів.
Оптимізація SOC та SIEM
№1: Етап Initial Access
Досить часто Initial Access неможливо помітити, як от якщо це критичний 0-day на фаєрволі, і видимість SOCу починається лише коли хакер уже в мережі. Ну й нехай! Більш важливо, щоб між Initial Access та Impact стояло якомога більше контролів безпеки, адже кожна перешкода для хакера - це можливість для систем моніторингу.
У попередньому пості я вже згадував, що чим складніший шлях хакера до цілі, тим більше часу на виявлення матиме SOC команда. Сегментація мережі, сильні паролі, пропатчений софт, політики безпеки, антивіруси - все це може затримати атаку, навіть повністю автоматизовану.
№2: Затримка SIEM Алертів
Перша затримка буде на етапі логів. Наприклад, логи Google Workspace доходять до 4 годин. Друга затримка буде на етапі правил, від хвилини для NRT в MS Sentinel, до години для вбудованих правил Splunk ES. І наостанок, з різних причин, може бути затримка в самому алертингу на пошту, в чат, ITSM, SOAR, чи деінде. Тому:
- Перевірте які логи приходять з затримкою та гугліть чи це нормально. Іноді, це можна виправити
- Зменште період запуск (cron schedule) правил де це тільки можливо. В ідеалі - до 2 хвилин
- Переконайтесь що алерти прилітають швидко, а аналітики отримують на алерти сповіщення (!)
№3: Повільний SOC Аналіз
Якщо атакує AI - захищати теж має AI, і цю ідею вже підхопили десятки стартапів та всі SOAR вендори. Проте, перед тим як переходити до автоматизацій та впровадження AI, я б рекомендував прості кроки що можуть сильно пришвидшити SOC аналіз:
- Повимикати дурні алерти, як от на порт скан фаєрволу ззовні
- Створити 3-5 зручних SIEM дашбордів під найбільш типові алерти
- Впровадити процеси ескалації та знати дії у випадку інциденту
- Тримати контакт з ІТ та усвідомлювати що і навіщо під захистом
№4: Повільна Локалізація
Бувають ситуації, коли інцидент давно виявлено, але саме дії з локалізації загрози (Containment) займають найбільше часу. Причини можуть бути політичні, як от коли CEO чи CTO не дозволяє ізолювати критичний для бізнесу сервер, - так і технічні, як от коли SOC команда не знає як вимкнути обліковий запис чи не має на це прав. Щоб зменшити такі затримки, рекомендую:
- Попередньо узгодити з топменеджментом IR план, щоб далі вже діяти автономно
- Розробити інструкції (плейбуки) для типових Containment сценаріїв
- Регулярно тестувати різні сценарії локалізації хоча б раз в рік
- Мати надійну точку контакту з IT та мережевиками у разі інциденту
Додаткові Рекомендації
Якщо подивитися наперед і припустити, що атаки з використанням AI триватимуть лише лічені хвилини, то можливості SIEM суттєво обмежуються. Це пояснюється тим, що ані детект, ані тим більше респонс у SIEM не є миттєвими. Наведу банальний приклад нижче:
Натомість мені подобаються рішення, що стоять ближче до джерел даних: AV/EDR на ендпойнтах, NDR/IPS/WAF на фаєрволах, CSPM/CWPP в клаудах і так далі. Так, вони не ідеальні, проте я бачу їх як кращу протидію автоматизованим атакам, адже, на відміну від SIEM, їх фокус на автоматичному та миттєвому блокуванні загроз.
Приклад з EDR
Поки пройде навколосвітня подорож з картинки вище, стілер вже розпакується та вкраде сесії. EDR натомість проводить більшість операцій локально на хості та здатний блокувати загрози точково та без затримок. Саме тому для захисту кінцевих точок я б в першу чергу орієнтувався на EDR, а правила SIEM би вже фокусував на техніках, які EDR не ловить.
Приклад з IPS
З мого досвіду, мережевий трафік у SIEM занадто дорогий та не сильно допоміжний. Особливо якщо його заводять виключно заради трет інтел фідів. Чому б не зінтегрувати MISP напряму з фаєрволом, а виявлення та блокування порт сканів та інших мережевих атак делегувати на вендорський чи опен-сорсний IPS? Така зв’язка краще підходить для протидії автоматизованим атакам, адже блокує загрози одразу, без затримок. А ось результати спрацювання IPS вже можна слати в SIEM для подальшого аудиту.
У Підсумку
У підсумку, я вірю що атаки ставатимуть дедалі швидшими, а час реакції захисників буде вимірюватись секундами, а не годинами. Наразі до цього можна підготуватись покращенням SIEM та SOC процесів, приклади чого я навів у цьому пості.
Втім, із часом така оптимізація може досягнути свого ліміту, і тоді SIEM-орієнтований підхід поступово втратить актуальність. На мою думку, аналіз загроз стане більш AI-керованим та автономним, а локалізація загроз зміститься від кардинальних мір типу ізоляції хостів до автоматизованого, точкового блокування конкретних індикаторів атак.