(за ідею заголовка дякую Sergey G. Brester )
Колеги метою цієї статті є бажання поділитися досвідом річної тестової експлуатації нового класу IDS-рішень на основі Deception-технологій.
Щоб зберегти логічну зв'язність викладу матеріалу, вважаю за потрібне почати з передумов. Отже, проблематика:
- Спрямовані атаки – найбільш небезпечний вид атак, незважаючи на те, що в загальній кількості загроз їхня питома вага невелика.
- Якогось гарантованого ефективного засобу захисту периметра (або комплексу таких засобів) поки що не придумано.
- Як правило, спрямовані атаки проходять у декілька стадій. Подолання периметра — це лише одна з початкових стадій, яка (можете закидати мене камінням) великої шкоди для «жертви» не зазнає, якщо це, звичайно, не DEOS (Destruction of service) атаки (шифрувальники тощо). По-справжньому «боляче» починається пізніше, коли захоплені активи починають використовуватися для пивотингу та розвитку атаки «в глибину», а ми цього не помітили.
- Так як ми починаємо нести справжні втрати тоді, коли зловмисники все-таки дістаються цілей атаки (сервера додатків, СУБД, сховища даних, репозитарії, елементи критичної інфраструктури), логічно, що одним із завдань служби ІБ є переривання атак до цієї сумної події. Але щоб щось перервати, треба про це спочатку дізнатися. І чим раніше – тим краще.
- Відповідно, для успішного управління ризиками (тобто зниження збитків від спрямованих атак) критично наявність інструментів, які забезпечать мінімальне TTD (time to detect – час з моменту вторгнення до моменту виявлення атаки). Залежно від галузі та регіону цей період із середньому становить 99 днів у США, 106 днів у регіоні EMEA, 172 дні у регіоні APAC (M-Trends 2017, A View From the Front Lines, Mandiant).
- Що пропонує ринок?
- "Пісочниці". Ще один preventive control, який далекий від ідеалу. Існує маса ефективних технік виявлення і обходу пісочниць або білихлистів-рішень. Хлопці з «темного боку» тут поки що на крок попереду.
- UEBA (системи профілювання поведінки та виявлення відхилень) – теоретично може бути дуже ефективно. Але, як на мене, це колись у далекому майбутньому. На практиці – це поки що дуже дорого, ненадійно і вимагає дуже зрілої та стабільної ІТ- та ІБ-інфраструктури, де вже є всі інструменти, які генеруватимуть дані для поведінкового аналізу.
- SIEM - хороший інструмент для розслідувань, але щось нове, оригінальне, побачити і вчасно показати не в змозі, тому що правила кореляції суть ті ж сигнатури.
- У результаті, назріла необхідність у такому інструменті, який би:
- успішно працював в умовах вже скомпрометованого периметра,
- виявляв успішні атаки в режимі близькому до реального часу незалежно від інструментарію та тих уразливостей, що використовуються,
- не залежав від сигнатур/правил/сценаріїв/політик/профілів та інших статичних речей,
- не вимагав наявності великих масивів даних та їх джерел для аналізу,
- дозволяв би визначати атаки не як якийсь ризик-скоринг у результаті роботи «найкращої у світі, запатентованої і тому закритої математики», який вимагає додаткового розслідування, а практично як бінарна подія – «Так, нас атакують» або «Ні, все ОК»,
- був універсальним, що ефективно масштабується і реально впроваджується в будь-якому гетерогенному середовищі, незалежно від використовуваної фізичної та логічної топології мережі.
На роль такого інструменту зараз претендують так звані deception-рішення. Тобто рішення, в основі яких лежить стара добра концепція ханіпотів, але з зовсім іншим рівнем реалізації. Ця тема зараз однозначно на піднесенні.
За результатами Deception-рішення входять до ТОП-3 стратегій та інструментів, які рекомендується застосовувати.
За даними звіту Deception є одним із магістральних напрямків розвитку IDS (Intrusion Detection Systems) рішень.
Ціла секція останнього , присвячена SCADA, побудована на даних одного з лідерів цього ринку, TrapX Security (Ізраїль), вирішення яких уже рік працює у нашій тестовій зоні.
ТрапХ Deception Grid дозволяє коштувати та експлуатувати масовані розподілені IDS централізовано, без збільшення ліцензійного навантаження та вимог до апаратних ресурсів. Фактично, ТрапХ – це конструктор, який дозволяє створити з елементів ІТ-інфраструктури один великий механізм виявлення атак масштабу всього підприємства, свого роду розподілену мережеву «сигналізацію».
Структура Рішення
У нашій лабораторії ми постійно вивчаємо та тестуємо різні новинки в галузі ІТ-безпеки. Наразі тут розгорнуто близько 50 різних віртуальних серверів, у тому числі й компоненти TrapX Deception Grid.
Отже, зверху донизу:
- TSOC (TrapX Security Operation Console) – мозок системи. Це центральна консоль управління, за допомогою якої здійснюється налаштування, розгортання рішення та вся щоденна робота. Так як це веб-сервіс, він може бути розгорнутий будь-де - в периметрі, в хмарі або в MSSP провайдера.
- TrapX Appliance (TSA) – віртуальний сервер, на який ми за допомогою trunk-порту підключаємо ті підмережі, які ми хочемо охопити моніторингом. Також тут фактично «живуть» усі наші мережеві сенсори.
У нашій лабораторії розгорнуть один TSA (mwsapp1), але насправді їх може бути багато. Це може знадобитися у великих мережах, де між сегментами немає L2-зв'язності (типовий приклад – «Холдинг та дочірні підприємства» або «Головний офіс банку та філії») або якщо у мережі є ізольовані сегменти, наприклад, АСУТП. У кожній такій філії/сегменті можна розгорнути свій TSA і підключити його до єдиного TSOC, на якому вся інформація буде централізовано оброблятися. Така архітектура дозволяє будувати розподілені системи моніторингу без необхідності кардинальної перебудови мережі чи порушення наявної сегментації.
Також на TSA ми можемо подати копію вихідного трафіку через TAP/SPAN. У разі виявлення з'єднань з відомими ботнетами, командними серверами, TOR-сесій ми отримаємо результат у консолі. За це відповідає Network Intelligence Sensor (NIS). У нашому середовищі цей функціонал реалізований на міжмережевому екрані, тому ми його не використовували.
- Application Traps (Full OS) - традиційні ханіпоти на базі Windows-серверів. Їх не потрібно багато, тому що основне завдання цих серверів – надати ІТ-сервіси наступному рівню сенсорів або виявляти атаки на бізнес-додатки, які можуть бути розгорнуті у Windows-середовищі. У нас в лабораторії встановлено один сервер (FOS01)
- Emulated traps – основний компонент рішення, який дозволяє нам за допомогою однієї єдиної віртуальної машини створити дуже щільне «мінне» поле для атакуючих та наситити мережу підприємства, всі його vlan-и, нашими сенсорами. Атакуючий бачить такий сенсор, або фантомний хост, як справжній Windows ПК або сервер, Linux сервер або інший пристрій, який ми вирішуємо йому показати.
Для користі справи та цікавості заради, ми розгорнули «кожній тварюці по парі» — Windows ПК і сервери різних версій, Linux-сервери, банкомат з Windows embedded, SWIFT Web Access, мережевий принтер, комутатор Cisco, IP-камера Axis, макбук, PLC -Пристрій і навіть розумну лампочку. Усього – 13 хостів. Взагалі, вендор рекомендує розгортати такі сенсори у кількості щонайменше 10% від кількості реальних хостів. Верхня планка – це доступний адресний простір.Дуже важливим моментом є те, що кожен такий хост – це не повноцінна віртуальна машина, яка потребує ресурсів та ліцензій. Це «обманка», емуляція, один процес на TSA, який має набір параметрів і IP-адресу. Тому ми за допомогою навіть одного TSA можемо наситити мережу сотнями таких фантомних хостів, які працюватимуть як датчики системи сигналізації. Саме ця технологія дозволяє економічно ефективно масштабувати концепцію «ханіпотів» у масштабах будь-якого великого розподіленого підприємства.
Ці хости з погляду атакуючої сторони є привабливими, оскільки містять уразливості та виглядають відносно легкими цілями. Атакуючий бачить сервіси на цих хостах і може з ними взаємодіяти, атакувати їх, використовуючи стандартні інструменти та протоколи (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus тощо). Але використовувати ці хости для розвитку атаки та запуску свого коду неможливо.
- Поєднання цих двох технологій (FullOS та емульованих пасток) дозволяє досягти високої статистичної ймовірності, що атакуючий все-таки рано чи пізно зіткнеться з будь-яким елементом нашої сигнальної мережі. Але як зробити так, щоб ця ймовірність була близькою до 100%?
У бій вступають звані токени (Deception tokens). Завдяки їм ми можемо включити до складу нашого розподіленого IDS усі наявні ПК та сервери підприємства. Токени розміщуються на реальних ПК користувачів. Важливо розуміти, що токени – це не агент, який споживає ресурси та може викликати конфлікти. Токени - це пасивні інформаційні елементи, свого роду "хлібні крихти" для атакуючої сторони, які ведуть її в пастку. Наприклад, підключені мережеві диски, закладки на фейкові веб-адмінки в браузері та збережені паролі до них, збережені ssh/rdp/winscp сесії, наші пастки з коментарями в hosts файлах, збережені в пам'яті паролі, облікові дані неіснуючих користувачів, офісні файли, відкриті яких спричинить спрацювання системи, та багато іншого. Таким чином, ми поміщаємо атакуючого у спотворене середовище, насичене тими векторами атак, які насправді не становлять для нас загрози, а швидше навпаки. І він не має можливості визначити де правдива інформація, а де помилкова. Таким чином, ми не тільки забезпечуємо швидке визначення атаки, а й суттєво уповільнюємо її перебіг.
Приклад створення пастки та налаштування токенів. Доброзичливий інтерфейс і наякої ручної правки конфігів, скриптів і т.п.
У нашому середовищі ми налаштували та розмістили ряд таких токенів на FOS01 під керуванням Windows Server 2012R2 та тестовому ПК під Windows 7. На цих машинах запущено RDP і ми періодично «вивішуємо» їх у DMZ, куди виведено також ряд наших сенсорів (emulated traps). Таким чином, ми отримуємо постійний потік інцидентів, так би мовити, природним чином.
Отже, коротка статистика за рік:
56 208 – інцидентів зафіксовано,
2 912 – хостів-джерел атак виявлено.
Інтерактивна, клікабельна карта атак
При цьому рішення не генерує якийсь мега-лог або стрічку подій, в якій треба довго розбиратися. Натомість рішення саме класифікує події за їх типами і дозволяє команді ІБ фокусуватися в першу чергу на найнебезпечніших - коли атакуюча сторона намагається піднімати сесії (interaction), що управляють, або коли у нас у трафіку з'являється бінарні пейлоади (infection).
Вся інформація про події читається і представляється, на мій погляд, у легкому для розуміння вигляді навіть користувачеві з базовими знаннями в галузі ІБ.
Більшість із зафіксованих інцидентів – це спроби сканування наших хостів чи поодиноких з'єднань.
Або спроби перебору паролів для RDP
Але зустрічалися і цікавіші кейси, особливо коли зловмисникам «вдавалося» підібрати пароль для RDP і отримати доступ до локальної мережі.
Зловмисник намагається виконати код за допомогою psexec.
Зловмисник знайшов збережену сесію, яка привела його до пастки у вигляді Linux-сервера. Відразу після підключення одним заздалегідь заготовленим набором команд він спробував знищити всі файли журналів та відповідні системні змінні.
Атакуючий намагається провести SQL-ін'єкцію на пастці, яка імітує SWIFT Web Access.
Окрім таких «природних» атак ми проводили й низку своїх власних тестів. Одним із найбільш показових є тестування часу виявлення мережевого черв'яка в мережі. Для цього ми використовували інструмент від GuardiCore, який називається . Це мережевий черв'як, який вміє захоплювати Windows і Linux, але без якогось «корисного» навантаження.
Ми розгорнули локальний командний центр, на одній із машин запустили перший екземпляр черв'яка і отримали першу оповіщення в консолі TrapX менш ніж за півтори хвилини. TTD 90 секунд проти 106 днів у середньому.
Завдяки можливості інтеграції з іншими класами рішень ми можемо перейти лише від швидкого визначення загроз до автоматичного реагування на них.
Так, наприклад, інтеграція з NAC (Network Access Control) системами або CarbonBlack дозволить автоматично відключати скомпрометовані ПК від мережі.
Інтеграція з пісочницями дозволяє автоматично передавати для аналізу файли, що беруть участь у атаці.
Інтеграція з McAfee
Також у рішенні є вбудована система кореляції подій.
Але її можливості не влаштували, тому ми інтегрували його з HP ArcSight.
Впоратися з виявленими погрозами «усього світу» допомагає вбудована система тікетингу.
Оскільки рішення зі старту розроблялося для потреб держорганів і великого корпоративного сегменту, то там, природно, реалізована рольова модель доступу, інтеграція з AD, розвинена система звітів і тригерів (подійних оповіщень), оркестрація для великих холдингових структур або MSSP провайдерів.
Замість резюме
Якщо є подібна система моніторингу, яка, образно кажучи, прикриває спину, то з компрометацією периметра все тільки починається. Найголовніше, що з'являється реальна можливість боротися з ІБ-інцидентами, а не усунення їх наслідків.
Джерело: habr.com