Екипите по сигурност разполагат с повече механизми за контрол на периметъра (edge controls) от всякога и всеки от тях играе важна роля. Въпреки това, независимо от най-добрите налични системи за проверка на заявки, валидация на идентификационни данни, пръстови отпечатъци на устройства и сигнали за автоматизация, атакуващите все още успешно се укриват в трафик, който изглежда изключително подобен на легитимната потребителска активност.
Една от причините за това е, че всеки механизъм за контрол на сигурността се фокусира върху различен фрагмент от потребителската сесия.
Ако атакуващ, който иначе изглежда легитимен, използва жилищен IP адрес (residential IP) или комерсиална VPN услуга, той може да премине през няколко слоя за сигурност, без да задейства предупреждение или действие.
Това е фундаменталният проблем с съществуващите инструменти за периметрова сигурност: липсата на контекст относно базовата инфраструктура.
Какво виждат съществуващите механизми за контрол и какво могат да пропуснат
Сигурността на приложенията разчита на множество слоеве на защита, всеки от които е предназначен да отговори на различен въпрос относно входящия трафик.
CDNs и WAFs са изключително ефективни при проверка на заявки, прилагане на политики, филтриране на известни заплахи и защита на приложенията в периметъра. Но самата заявка може да не разкрие, че наглед обикновена връзка се пренасочва през инфраструктура, предназначена да прикрие нейната идентичност и произход.
Управлението на ботове помага за идентифициране на автоматизацията и разграничаване на ботовете от реалните потребители. Но не всяка злонамерена сесия е автоматизирана, а киберпрестъпниците все повече комбинират автоматизация с инфраструктура, проектирана да наподобява легитимен потребителски трафик.
Системите за идентичност и автентификация се опитват да определят дали потребителите могат да докажат кои твърдят, че са. Но валидните идентификационни данни не означават непременно, че лицето, което ги представя, е легитимният титуляр на акаунта.
Анализът на устройства и браузъри осигурява слой на доверие, като описва крайната точка. Той обаче не разкрива мрежовата инфраструктура, свързваща тази крайна точка с приложението.
Взети поотделно, тези сигнали предоставят ценна и съществена информация. Но атакуващите все повече се възползват от пролуките между тях, създавайки сесии, които изглеждат легитимни за всеки отделен механизъм за контрол, докато скриват съществен контекст за инфраструктурата зад връзката.
Какво пропуска вашата периметрова сигурност?
Вижте как платформата Monocle Session Enrichment на Spur добавя контекст за инфраструктурата в реално време към съществуващите ви механизми за контрол.
Вземайте по-интелигентни решения за прилагане на мерки за сигурност, като разкривате кога сесиите се крият зад VPN, проксита, анонимизиращи услуги, трафик от центрове за данни и AI активност.
От отделни сигнали към доверие в сесията
Това създава необходимост от друг слой контекст: информация за инфраструктурата зад сесията на живо. Spur създаде Monocle Session Enrichment, за да осигури този слой.
Monocle обогатява всяка потребителска сесия със сигнали за доверие в реално време – включително статус на анонимизация, принадлежност към прокси услуги, жилищна инфраструктура и зараждащи се мрежи на атакуващи. Това разширява възможностите за анализ на съществуващия ви стек за периметрова сигурност и позволява на екипите по сигурност и предотвратяване на измами да вземат по-интелигентни решения в периметъра, които намаляват рисковете при автентификация и затрудненията за легитимните потребители.
Monocle комбинира видимостта на Spur върху интернет инфраструктурата с телеметрия от сесии в реално време, за да създаде оценка за доверие в сесията (Session Trust Assessment) в реално време. Вместо просто да маркира даден IP адрес като „добър“ или „лош“, платформата предоставя атрибути, които слоят за прилагане на политики може да използва при вземането на решение как да обработи сесията.
Една оценка за доверие в сесията може да изглежда така:
Оценката предоставя три вида контекст: сигнали, описващи какво Monocле наблюдава за сесията; решение въз основа на конфигурираната политика на организацията; и данни за управление (governance data), които правят оценката проследима.
Атрибути като „vpn“, „proxied“, „anon“, „rdp“ и „dch“ описват характеристиките на инфраструктурата и връзката, наблюдавани от Monocle, докато „service“ идентифицира конкретната използвана услуга.
Допълнителни сигнали като „ai_agentic“ и „ai_crawling“ предоставят контекст за новите видове трафик, генериран от изкуствен интелект.
Вместо да оставя приложението само да тълкува сигналите, полето „allowed“ предоставя получената препоръка за политиката, докато „reason“ обяснява защо е взето това решение. В този пример сесията не е позволена, тъй като конфигурираната политика блокира анонимни връзки.
Полета включително „decisionId“, „id“, „sid“ и „ts“ осигуряват идентификатори и времева информация, които помагат на екипите да проследят дадено решение обратно до конкретна оценка и контекст на приложението.
Целта на обогатяването на сесиите е да разкрие базовите атрибути на инфраструктурата, така че организацията да може да реши какво означават тези сигнали в контекста на нейните собствени потребители, приложения и толерантност към риск – и след това да приложи съответната политика.
Прилагане на обогатяване на сесиите: Контекстът прави съществуващите механизми за контрол по-полезни
Да предположим, че финансова институция регистрира успешно влизане от IP адрес в САЩ. Само по себе си това не е особено интересно.
Въпреки това, обогатяването на сесията може да разкрие, че връзката е анонимна, произхожда от инфраструктура на център за данни и е свързана с комерсиална VPN услуга. Това осигурява...