Журнал "Information Security/ Информационная безопасность" #5, 2025

он может временно заблокировать вас, применить капчу или Rate Limit. Поэтому мы постепенно научились делать сканы аккуратно: адаптивные скорости, выбор времени, привязка к бизнес-окнам. И да, это неизбежно требует диалога с вла- дельцами сервисов – никакой автомат не должен ломать рабочие процессы. Третий важный прием – корреляция. Один агент может показать порт откры- тым, другой — закрытым. Такая рассин- хронизация не повод для паники, а сигнал разобраться в сетевой маршрутизации. Если, скажем, из Москвы порт виден, а из Петербурга — нет, значит где-то на уровне сети фильтр или ошибка конфи- гурации. Такой подход резко снижает шум и ускоряет реальное реагирование. И последнее, о чем нельзя забывать, – надежность самой системы. Агенты умирают, правила меняются, конфиги теряются. Мы строили nmon так, чтобы при падении одного экземпляра другие подхватывали его задания – как в кла- стере: если одна нода легла, остальные перераспределяют нагрузку. Мониторинг живости агентов, алерты о деградации и автоматический фоллбек оказались не менее важны, чем сама логика ска- нирования. Все эти инженерные пазлы не делают систему красивее на диаграммах, но они делают ее рабочей в реальном мире – а это то, ради чего все и затевалось. Machine Learning как второй друг сканера Когда nmon начал стабильно работать, мы поняли: дальше упираемся не в ско- рость, а в понимание. Найти открытый порт – полдела, но что за ним скрывает- ся? Это обычный лендинг, микросервис, админка или вообще страница логина ВКонтакте? Так в проекте появился машинный интеллект – не ради хайпа, а чтобы отсеивать шум и подсвечивать действительно важное. Мы начали с простых задач: классифи- кация страниц по скриншотам, поиск ано- малий в дизайне (вдруг кто-то перекрасил страницу после взлома), определение административных панелей. За основу взяли готовые архитектуры вроде MobileNet, а дальше начали обучать их на собственных данных. Оказалось, это небыстро: страниц много, интерфейсы у всех разные, баннеры то появляются, то исчезают. Но постепенно модель начала различать, где просто маркетинговая страница, а где панель администрирова- ния, выставленная в интернет по ошибке. Важно понимать – ML не заменяет людей. Мы постоянно проверяем, как модель себя ведет: где ошибается, где теряет точность, где, наоборот, начинает заучивать примеры и перестает видеть новое. Модель может ошибаться – при- нять Jira за блог или наоборот. Поэтому мы выстроили процесс обратной связи: если алгоритм ошибся, человек поме- чает пример, и система учится заново. Постепенно стало ясно: машинное обучение не панацея, а инструмент прио- ритизации. Оно помогает быстрее понять, куда смотреть, какие сигналы критичны, а где просто фон. И главное – это живой цикл. Модель, как и сеть, постоянно меняется. Мы не стремимся к идеальному интеллекту, мы просто растим помощника, который каждый день становится чуть точнее. Как мы ищем уязвимости и рас- ставляем приоритеты Сканер сам по себе не делает инфра- структуру безопасной – он лишь пока- зывает, где что-то пошло не так. Дальше начинается самое скучное и при этом самое важное: анализ. Мы сознательно не лезем внутрь сервисов и не ломаем их. Первичная логика простая: сняли баннер, посмотрели версию, сверили с известными уязвимостями. Если совпа- дает – передаем на углубленное скани- рование коммерческим инструментам или запускаем Open Source-решения вроде Nuclei. Так мы делим процесс на два слоя. Первый – быстрый, наш nmon, который закрывает вопрос покрытия: кто вообще торчит наружу, какие сервисы живы, где внезапно появился новый порт. Второй – детальный, когда на основании этих дан- ных уже идут точечные проверки, часто с применением ручного анализа. Осо- бенно это касается кастомных систем, которых у нас немало. Они не попадают ни в одни шаблоны, и тут без участия инженера не обойтись: приходится захо- дить, смотреть, как построен сервис, и обучать ML на новых примерах. Приоритеты мы выстраиваем по кри- тичности ассетов. Есть сервисы, для которых даже один открытый порт – ЧП. А есть инфраструктурные зоны, где вре- менная открытость допустима. Поэтому везде стоят разные SLA: где-то сканер должен уложиться в 15 минут, где-то – в час. Это позволяет не терять скорость и одновременно не топить людей в отче- тах на десятки тысяч строк. В итоге у нас получается не просто список дыр, а живой рейтинг рисков: что требует немедленной реакции, что можно закрыть в плановом порядке, а что стоит передать в мониторинг. Все это экономит часы анализа и позволяет тратить внимание на то, что действи- тельно может привести к инциденту. Итоги и выводы За время работы над nmon мы убеди- лись: периметр – это живой организм. Его нельзя проверить раз и навсегда, потому что каждый день он меняется, растет и стареет. Новые сервисы рож- даются, старые забываются, правила в файрволах сбиваются, кто-то временно открывает доступ для теста – и вот уже наружу торчит то, что никогда не должно было быть доступно. Сканер – не волшебная палочка, но это ваш лучший друг в этой среде. Он не заменяет SOC, не закрывает уязви- мости, но дает понимание, где вы нахо- дитесь и что вообще происходит за гра- ницей вашего периметра. А машинное обучение – не магия, а способ не утонуть в потоке данных. Оно помогает увидеть закономерности и направить внимание туда, где риск действительно высок. Мы поняли, что сила не в одном инструменте, а в сочетании подходов: распределенный сканер, ML для фильт- рации, коммерческие решения для глу- бины. Вместе они дают ту самую наблю- даемость, без которой невозможно гово- рить о безопасности крупной компании. И самое важное – осознанность. Любая автоматизация, любой ML имеют смысл только тогда, когда вы понимаете, зачем их внедряете. Когда мы только начинали, идея собст- венного сканера казалась чем-то избы- точным. Сегодня трудно представить, как жить без него. В каждом релизе, в каждом изменении инфраструктуры он напоми- нает о простом факте: безопасность не измеряется количеством патчей, а ско- ростью, с которой ты замечаешь новое. Nmon не сделал нас неуязвимыми, но дал нам возможность видеть и реагиро- вать быстрее, чем проблема успевает перерасти в инцидент. l Редакция благодарит организаторов OFFZONE 2025 за содействие в подго- товке материала. • 63 УПРАВЛЕНИЕ И ПРОЦЕССЫ www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru Рисунок: ГРОТЕК