Дупка като средство за сигурност - 2, или как да хванете APT "на жива стръв"

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

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

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

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

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

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

Според резултатите Среща на върха на Gartner Security&Risc management 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 сесии, ние също ще получим резултата в конзолата. За това отговаря мрежовият интелигентен сензор (NIS). В нашата среда тази функционалност е внедрена на защитната стена, така че не я използвахме тук.

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

   

4. Емулираните капани са основният компонент на решението, което ни позволява, използвайки една единствена виртуална машина, да създадем много плътно „минно поле“ за нападателите и да наситим мрежата на предприятието, всички нейни vlans, с нашите сензори. Нападателят вижда такъв сензор или фантомен хост като истински Windows компютър или сървър, Linux сървър или друго устройство, което решим да му покажем.

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

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

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

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

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

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

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

И така, ето малко бърза статистика за годината:

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

Интерактивна карта на атака с възможност за кликване

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

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

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

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

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

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

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

Нападател се опитва да извърши SQL инжектиране на honeypot, който имитира SWIFT уеб достъп.

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

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

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

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

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

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

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

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

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

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

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

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