Дупка като инструмент за сигурност – 2, или как да ловим APT „на живо“

(за идея заглавия благодаря Sergey G. Brester sebres)

Колеги, целта на тази статия е да споделя опита си от годишното тестово експлоатиране на нов клас IDS решения, базирани на технологии за заблуда.

За да запазя логическата свързаност в изложението, считам за необходимо да започна с предпоставките. Започваме с проблема:

1. Целенасочените атаки са най-опасният вид атаки, макар че в общия брой заплахи техният дял не е голям.
2. Все още няма гарантирано ефективно средство за защита на периметъра (или комплект от такива средства).
3. Обикновено целенасочените атаки протичат в няколко етапа. Преодоляването на периметъра е само една от началните стъпки, която (можете да ме замеряте с камъни) не нанася големи щети на 'жертвата', ако, разбира се, не става дума за DEoS (Destruction of service) атаки (шифровачи и т.н.). Наистина 'болезнено' става по-късно, когато завладените активи започнат да се използват за пренасочване и развитие на атака 'в дълбочина', а ние не сме го забелязали.
4. Тъй като започваме да понесем действителни загуби, когато злонамерените лица наистина достигнат целите на атаката (сървъри на приложения, СУБД, хранилища на данни, хранилища, елементи на критичната инфраструктура), логично е, че една от задачите на ИТ сигурността е да прекрати атаките преди това мизерно събитие. Но за да прекратим нещо, първо трябва да разберем за него. И колкото по-рано - толкова по-добре.
5. Съответно, за успешното управление на рисковете (т.е. намаляване на щетите от целенасочени атаки) е критично важно наличието на инструменти, които осигуряват минимално TTD (time to detect – време от момента на проникване до момента на откритие на атаката). В зависимост от индустрията и региона, този период средно е 99 дни в САЩ, 106 дни в региона EMEA, 172 дни в региона APAC (M-Trends 2017, A View From the Front Lines, Mandiant).
6. Какво предлага пазарът?
   • «Пясъчници». Още един превантивен контрол, който е далеч от идеала. Има множество ефективни техники за откриване и заобикаляне на пясъчници или решения за бели списъци. Хората от 'тъмната страна' тук все още са крачка напред.
   • UEBA (системи за профилиране на поведението и откриване на аномалии) теоретично може да бъде много ефективна. Но според мен това е нещо отдалечено в бъдещето. В практиката обаче тя е все още много скъпа, ненадеждна и изисква много зряла и стабилна ИТ и ИБ инфраструктура, където вече съществуват всички инструменти, които ще генерират данни за поведенчески анализ.
   • SIEM е добър инструмент за разследвания, но не е способен да открие и навреме покаже нещо ново или оригинално, тъй като корелационните правила всъщност са същите сигнатури.

7. В резултат на това възникна необходимост от такъв инструмент, който:
   • успешно да работи в условия на вече компрометирана периферия,
   • да открива успешни атаки в почти реално време, независимо от инструментите и уязвимостите, които се използват,
   • да не зависи от сигнатури/правила/сценарии/политики/профили и други статични елементи,
   • да не изисква наличие на големи масиви данни и техните източници за анализ,
   • да позволява определяне на атаки не като риск-оценка в резултат на работа на "най-добрата в света, патентована и следователно затворена математика", която изисква допълнително разследване, а практически като бинарно събитие – "Да, имаме атака" или "Не, всичко е ОК",
   • да бъде универсален, ефективно мащабируем и реално внедрим в всяка хетерогенна среда, независимо от използваната физическа и логическа топология на мрежата.

На ролята на такъв инструмент в момента претендират така наречените решения за заблуда. Тоест решения, базирани на старата добра концепция за хипотези, но с напълно различно ниво на реализиране. Тази тема определено е на възход в момента.

Според Gartner Security&Risk management summit 2017 Решенията за заблуда влизат в ТОП-3 стратегии и инструменти, които се препоръчва да се прилагат.

Според доклад TAG Cybersecurity Annual 2017 Заблудата е едно от основните направления на развитие на IDS (Intrusion Detection Systems) решения.

Цяла секция от последния доклад на Cisco за състоянието на ИТ-сигурността, посветена на SCADA, е изградена на данни от един от лидерите на този пазар, TrapX Security (Израел), решение, което вече година работи в нашата тестова зона.

TrapX Deception Grid позволява централизирано да изгражда и експлоатира масивни разпределени IDS, без увеличаване на лицензионната тежест и изискванията за хардуерни ресурси. Всъщност TrapX е конструктор, който позволява да се създаде от елементи на съществуващата ИТ инфраструктура един голям механизъм за откритие на атаки на ниво на цялото предприятие, своеобразна разпределена мрежова "сигнализация".

Структура на Решението

В нашата лаборатория постоянно проучваме и тестваме различни новинки в сферата на ИТ безопасността. В момента тук са разположени около 50 различни виртуални сървъра, включително и компоненти на TrapX Deception Grid.

И така, отгоре надолу:

1. TSOC (TrapX Security Operation Console) – мозъкът на системата. Това е централна конзола за управление, с помощта на която се осъществява настройка, разгръщане на решението и ежедневната работа. Тъй като е уеб услуга, може да бъде разположена навсякъде – в периметъра, в облака или при MSSP доставчика.
2. TrapX Appliance (TSA) – виртуален сървър, към който свързваме подмрежите, които искаме да обхванем с мониторинг, чрез trunk порт. Тук всъщност "живеят" всички наши мрежови сензори.

   В нашата лаборатория е разположен един TSA (mwsapp1), но на практика може да има много. Това може да е необходимо в големи мрежи, където няма L2 свързаност между сегментите (типичен пример – "Холдинг и дъщерни предприятия" или "Главен офис на банка и клонове") или ако в мрежата има изолирани сегменти, например, АСУТП. Във всеки такъв клон/сегмент може да бъде разположен свой TSA и да бъде свързан към единен TSOC, на който цялата информация ще бъде централизирано обработвана. Такава архитектура позволява изграждане на разпределени системи за мониторинг без необходимост от радикална реконструкция на мрежата или нарушаване на съществуващата сегментация.

   Също така, на TSA можем да подадем копие на изходящия трафик чрез TAP/SPAN. В случай на откритие на свързвания с известни ботнети, командни сървъри, TOR сесии, също ще получим резултати в конзолата. За това отговаря Network Intelligence Sensor (NIS). В нашата среда тази функция е реализирана на междусетевия екран, така че тук не я използвахме.

3. Application Traps (Full OS) – традиционни хани-потси на базата на Windows сървъри. Не се изискват много, тъй като основната задача на тези сървъри е да предоставят ИТ услуги на следващото ниво на сензорите или да идентифицират атаки срещу бизнес приложения, които могат да бъдат разположени в Windows среда. В нашата лаборатория имаме инсталиран един такъв сървър (FOS01)

   

4. Емулирани капани – основен компонент на решението, което ни позволява с помощта на една единствена виртуална машина да създадем много плътно „минно“ поле за атакуващите и да наситим мрежата на предприятието, всички негови VLAN, с нашите сензори. Атакуващият вижда такъв сензор или фантомен хост, като истински Windows ПК или сървър, Linux сървър или друго устройство, което решаваме да му покажем.

   
   
   За полза на делото и от любопитство, разположихме „на всяка твар по двойка“ – Windows ПК и сървъри на различни версии, Linux сървъри, банков автомат с Windows embedded, SWIFT Web Access, мрежов принтер, Cisco суич, IP камера Axis, MacBook, PLC устройство и дори умна крушка. Общо – 13 хоста. Всъщност, доставчикът препоръчва да разположим такива сензори в количество минимум 10% от реалните хостове. Горната граница е наличното адресно пространство.

   Много важен момент е, че всеки такъв хост не е пълноценна виртуална машина, която изисква ресурси и лицензии. Това е „измама“, емулатор, един процес на TSA, който има набор от параметри и IP адрес. Ето защо, с помощта на дори един TSA можем да наситим мрежата със стотици такива фантомни хостове, които ще функционират като сензори в системата за сигнализация. Тази технология позволява икономически ефективно мащабиране на концепцията за „хани-поти“ в мащабите на всяко голямо разпределено предприятие.

   Тези хостове от гледна точка на атакуващата страна са атрактивни, тъй като съдържат уязвимости и изглеждат относително лесни цели. Атакуващият вижда услугите на тези хостове и може да взаимодейства с тях, да ги атакува, използвайки стандартни инструменти и протоколи (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus и т.н.). Но не е възможно да се използват тези хостове за развитие на атака или стартиране на собствен код.

5. Комбинирането на тези две технологии (FullOS и емулирани капани) позволява да се постигне висока статистическа вероятност, че атакуващият в крайна сметка ще се сблъска с някакъв елемент от нашата сигнална мрежа. Но как да направим така, че тази вероятност да бъде близка до 100%?

   В битката влизат т. нар. токени (Deception tokens). Благодарение на тях можем да включим в състава на нашата разпределена IDS всички налични компютри и сървъри на предприятието. Токените се разполагат на реални компютри на потребителите. Важно е да разберем, че токените не са агенти, които консумират ресурси и могат да предизвикат конфликти. Токените са пасивни информационни елементи, нещо като "хлебни трохи" за атакуващата страна, които я водят в капан. Например, свързани мрежови дискове, отметки към фалшиви уеб администраторски панели в браузъра и запазени пароли за тях, запазени ssh/rdp/winscp сесии, нашите капани с коментари в файловете hosts, запазени в паметта пароли, данни за несъществуващи потребители, офисни файлове, отварянето на които ще активира системата, и много други. По този начин поставяме атакуващия в изкривена среда, наситена с онези вектори на атаки, които всъщност не представляват заплаха за нас, а, по-скоро, напротив. И той няма възможност да определи къде е истинската информация, а къде е фалшивата. Чрез това не само осигуряваме бързо определяне на атаката, но и значително забавяме нейния ход.

Пример за създаване на мрежов капан и настройка на токени. Приятелски интерфейс и никаква ръчна редакция на конфигурации, скриптове и т.н.

В нашата среда конфигурирахме и разположихме редица такива токени на FOS01, управляван от Windows Server 2012R2 и тестов ПК с Windows 7. На тези машини е стартиран RDP и периодично "излагаме" тях в DMZ, където е изведен също редица наши сензори (емулирани капани). По този начин получаваме постоянен поток инциденти, така да се каже, естествено.

И така, кратка статистика за годината:

56 208 – инциденти, регистрирани,
2 912 – източника на атаки, открити.

Интерактивна, кликаема карта на атаките

При това решението не генерира никакъв мега-лог или поток от събития, в който да се налага дълго разглеждане. Вместо това решението само класифицира събитията по техните типове и позволява на екипа по информационна сигурност да се фокусира в първия момент върху най-опасните – когато атакуващата страна се опитва да установи управляващи сесии (interaction) или когато в трафика ни се появят бинарни пейлоадове (infection).

Всяка информация за събитията е четима и се представя, на мое мнение, по лесен за разбиране начин дори за потребител с основни знания в сферата на информационната сигурност.

Повечето от регистрираните инциденти са опити за сканиране на нашите хостове или единични свързвания.

Или опити за брутфорс на пароли за RDP.

Но имаше и по-интересни случаи, особено когато на злодеите им се „успяваше“ да подберут парола за RDP и получат достъп до локалната мрежа.

Злодеят се опитва да изпълни код с помощта на psexec.

Злодеят е намерил запазена сесия, която го е довела в капан под формата на Linux-сървър. Веднага след свързването с подготвения набор от команди, той се е опитал да унищожи всички файлове с журнали и съответните системни променливи.

Атакуващият се опитва да проведе SQL инжекция на капан, който имитира SWIFT Web Access.

Освен такива "естествени" атаки, ние проведохме и редица собствени тестове. Един от най-показателните е тестът на времето за откриване на мрежов червей в мрежата. За това използвахме инструмент от GuardiCore, наречен Infection Monkey. Това е мрежов червей, който може да завладее Windows и Linux, но без конкретна „полезна“ насоченост.
Разгърнахме локален команден център, на една от машините пуснахме първия екземпляр на червея и получихме първото уведомление в консолата TrapX за по-малко от минута и половина. TTD 90 секунди в сравнение с 106 дни средно...

Благодарение на възможността за интеграция с други класове решения можем да преминем от бързо откриване на заплахи към автоматично реагиране на тях.

Например, интеграцията с NAC (Network Access Control) системи или с CarbonBlack ще позволи автоматично изключване на компрометирани ПК от мрежата.

Интеграцията с пясъчници позволява автоматично прехвърляне за анализ на файловете, участващи в атаката.

Интеграцията с McAfee

В решението има вградена система за корелация на събития.

Но възможностите ѝ не ни удовлетвориха, затова интегрирахме с HP ArcSight.

Справянето с откритите заплахи "всички заедно" помага вградената тикетинг система.

Тъй като решението "от самото начало" е разработено за нуждите на държавни органи и голям корпоративен сегмент, там естествено е реализирана ролевата модел на достъп, интеграция с AD, развита система за отчети и тригери (системи за известяване на събития), оркестрация за големи холдинг структури или MSSP доставчици.

Вместо резюме

Ако има такава система за мониторинг, която, образно казано, ни пази отзад, то с компрометирането на периметъра всичко едва започва. Най-важното е, че се появява реална възможност за борба с инцидентите в информационната сигурност, а не да се занимаваме с отстраняване на последствията.

Източник: habr.com