Перейти к содержанию

Работа над ашыпками


Рекомендуемые сообщения

В работе любой секюрити-компании иногда случаются неприятные косяки. Мы тоже люди и иногда допускаем ошибки. Здесь важно как можно быстрее во всём публично признаться, исправить, уведомить и скорректировать работу, чтобы в будущем косяк не повторялся (что мы и делаем). В общем, задача проста – минимизировать ущерб для пользователей.

 

Но есть одна проблема. С бородатых времён антивирусам сопутствует одна особенность – ложные срабатывания («фалсы»). Как вы догадываетесь, это когда чистый файл или сайт детектится как зараженный. И, увы, пока никто не смог эту проблему решить на 100%.

 

Технически в этом замешаны и пресловутый человеческий фактор, и недостатки технологий, и действия третьих разработчиков софта и веб-программеров. Самый простой пример - аналитик неправильно проанализировал код зловреда и добавил детект на кусок внедрённой библиотеки. А библиотекой той пользуется ещё 10тыс. других программ, в том числе бело-пушистых. В результате через пару десятков минут после выхода такого обновления с «кривым» детектом техподдержка ложится под напором писем от испуганных пользователей, аналитик аврально перевыпускает базу, а масс-медиа пишет разоблачительно-ругательные статьи. И это ещё что – представьте, что будет, если ошибочно задетектить Explorer, svchost или Kremlin.ru? :o

 

Другой пример: частенько случается, что даже уважаемые разработчики серьёзных корпоративных продуктов (не говоря уже о китайских поделках) начинают использовать в своём, совсем даже не вредоносном софте библиотеки, которые ранее были замечены в малваре! Ага! И такие случаи тоже надо как-то решать.

 

С первого взгляда может показаться, что есть прямая зависимость между количеством ложных срабатываний и объёмом пользовательской базы. Математика простая: чем больше пользователей, тем разнообразнее у них софт и тем больше вероятность что-то неправильно задетектить. На самом деле нет. Точнее так: если вы действительно наблюдаете такую зависимость, то это явный признак, что компания не вкладывается в совершенствование технологий для борьбы с «фалсами». Вероятно – в другие технологии тоже, предпочитая «тырить» детект у коллег по цеху или просто забивая на проблему. Серьёзный звоночек переосмыслить предпочтения в выборе продукта.

 

Тут есть и другая крайность. Скажем так – горе от ума. Некоторые технологии обнаружения неизвестной малвары по её поведению (поведенческие блокираторы, эвристика, детект по метаданным) действительно улучшают защиту, но без симметричных действий по минимизации ложных срабатываний приводят к нелинейному росту риска «фалсов».

 

Как же антивирусные компании борются с ложными срабатываниями? Ну, каждый по-разному. Некоторые (есть такое впечатление) – вообще никак (смотрим таблицу в конце поста). На «фалсы» не все тесты обращают внимание, а зачем тогда вкладываться в разработку, если прямо завтра это не отразится на росте продаж? Ага?

 

Расскажу лучше как это делаем мы.

 

В начале бородатых 90-х прошлого века, когда и вирусы и антивирусы были сродни «крокодилам в нью-йоркской канализации» (с) Питер Нортон, мы делали проверку обновлений на ложные срабатывания в полуавтоматическом режиме. У нас была специальная «помойка» с чистым софтом и сайтами и мы проверяли на ней каждую новую версию. Разумеется, также «прогоняли» все обновления по базе вредоносов, чтобы не потерять какой-либо детект.

 

Ну, тогда вирусов было мало, обновления выходили всего несколько раз в месяц, да и софта было, мягко скажем, поменьше :D Где-то под конец 90-х, когда количество софта и малвары стало «душить» мы перевели систему в полностью автоматический режим. Регулярно (а с 2004г. – ежечасно) робот собирает у дежурных аналитиков антивирусные обновления и запускает процедуру их многоуровневого тестирования.

 

Как вы догадываетесь, проверка по «помойке» - это уже вчерашний день. Условие необходимое, но не достаточное. Сегодня надо не просто засечь «фалсу», но как можно быстрее её поправить и доставить пользователю. В плане «засечь» у нас уже накоплен внушительный арсенал, в том числе запатентованных технологий. Например, иногда мы используем т.н. «silent detect» - когда в очередное обновление добавляются тестовые записи, срабатывание которых не выдаёт предупреждений пользователю. Такой подход применяется для проверки самых сложных детектов.

 

А вот в плане исправления ложных срабатываний нам больше всего помогают облачные технологии. На самом деле, KSN (видео, подробности) – это лучшее решение, которое помогает нам решать многие технические задачи для улучшения защиты. Здесь и качественный и количественный анализ угроз, быстрое обнаружений вредоносных аномалий, предоставление интерактивных репутационных сервисов и многое другое. Разумеется, странно было бы не использовать KSN и для борьбы с «фалсами».

 

А мы и используем! Каждый раз при обнаружении подозрительного объекта на защищённом компьютере наши продукты отправляют запрос в специальную базу данных в KSN. Там разными алгоритмами проводится дополнительная проверка сработавшей записи на «фалсы». Если «фалса» действительно имеет место быть, то система запускает процесс изменения статуса этой записи и доставляет исправление со следующим обновлением. Однако такой способ доставки означает 1-2-3-часовую, а то и 1-2-3-дневную задержку – зависит от привычек пользователя обновляться и наличия Интернета. Тем временем, «фалса» будет продолжать проявляться и нервировать, причём, возможно, у других пользователей тоже. Непорядок.

 

Для решения этой проблемы с прошлого года мы подключили через KSN к нашим персональным и корпоративным продуктам следующую фишечку из разряда «фичей невидимого фронта». На неё мы уже подали патентную заявку в России, Европе и США. Расскажу про неё на примере.

 

Итак, наш продукт на защищённом ПК засёк зловреда. Технически произошло вот что: один из защитных модулей (сигнатурный сканер, эмулятор, эвристик, анти-фишинг и т.д.) при проверке объекта нашёл совпадение его кода с одной из записей в локальной антивирусной базе данных. До вывода предупреждения пользователю продукт отправляет в KSN запрос с данными о а) обнаруженном объекте и б) сработавшей записи. KSN проверяет наличие объекта в whitelist-списке, а записи – в списке «фалсов». При совпадении с любым из этих списков KSN тут же посылает на защищённый ПК сигнал о ложном срабатывании. После этого наш продукт деактивирует запись или переводит её в режим «silent detect» и делает пометку для всех остальных защитных модулей во избежание повторения «фалсы». И наоборот, если на компьютере срабатывает запись со статусом «silent detect» , но KSN подтверждает её готовность заступить на «боевое дежурство», то наш продукт тут же переводит запись обратно в рабочий режим.

 

Со стороны может показаться, что логика хоть и простая, но чересчур ресурсоёмкая. В действительности совсем не так. Что защищённому ПК, что KSN – обоим нужно только обменяться очень короткими запросами. Всем остальным уже в фоновом режиме занимаются другие сервисы.

 

На самом деле, на ниве ложных срабатываний отметились, пожалуй, все антивирусные компании. Ну, мы тоже не без греха, было, несколько раз, ага. Хотя по этому показателю мы одни из лучших. Недавно проанализировали результаты 4 самых уважаемых тестовых площадок за 2011г. (AV-Comparatives.org, AT-Test.org ,Virus Bulletin и PCSL - всего 24 теста) и получили вот такую любопытную картину:

 

* средний % ложных срабатываний в 24 тестах за 2011г.

** макс.количество ложных срабатываний в 2011г.

 

Да, по отсутствию ложных срабатываний впереди нас только Микрософт. Но если сравнить эти данные с качеством защиты, то за тот же 2011г., по тому же самому списку площадок наш показатель детекта в Real World и т.н. Dynamiс-тестах – на 37% (sic!) лучше!

 

Планов (как обычно :) у нас громадьё. На самом деле у нас есть очень интересные идеи как вообще можно снизить количество «фалсов» практически до нуля за счёт добавления массы интеллекта. Увы, сейчас у нас режим «тсссс!» по этому вопросу, чтобы случаем не взболтнуть лишнего до подачи патентных заявок. Но буду держать вас в курсе!

 

 

Источник

post-8056-1340221918_thumb.png

post-8056-1340221930_thumb.png

Изменено пользователем lom
Ссылка на комментарий
Поделиться на другие сайты

В росте фолсов виноваты в большей степени вендоры которые воруют детект. Когда на том же вирустотале армия воров детектит чистый файл, то у других вендоров нет выбора, надо детектить что бы не опускаться в глазах пользователей. Яркий пример Symantec, работают честно, но под напором армии воров(а их процентов 60 на тотале) ломаются и добавляют детект.

Именно из-за воровства детекта уровень лечения активных вредоносов отвратительный, как назвать ситуацию когда вылечить систему без скачиваня дополнительных утилит могут только каспер и доктор? Если посмотреть последний тест на АМ, то можно увидеть что армия воров не то что вылечить, даже задетекить не может активную мальвару.

Ссылка на комментарий
Поделиться на другие сайты

Уже был положительный опыт выявления недобросовестных вендоров, которые занимаются воровством детектов - ЛК несколько чистых файлов добавила в свои антивирусные базы, затем постепенно детект появлялся у конкурентов, потом были оглашены результаты "соревнования". Такие публичные мероприятия надо проводить чаще, и тогда пользователи сами увидят - кто работает честно, а кто тырит чужой труд.

Ссылка на комментарий
Поделиться на другие сайты

Яркий пример Symantec, работают честно, но под напором армии воров(а их процентов 60 на тотале) ломаются и добавляют детект.

Если правда - то зря

Нефик идти на поводу

Ссылка на комментарий
Поделиться на другие сайты

И это ещё что – представьте, что будет, если ошибочно задетектить Explorer, svchost или Kremlin.ru?

Что-то можно и зафолсить и ничего страшного не случится ^_^

 

Ну а серьезнее...Касперский и Доктор Веб на моей практике не отличаются паранойей и обычными фолсами. Авира и иные здесь мастера.

Изменено пользователем Nikolay Lasarenko
Ссылка на комментарий
Поделиться на другие сайты

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • Elly
      От Elly
      Вопросы по работе форума следует писать сюда. Вопросы по модерированию, согласно правилам, сюда писать не следует.
      Ответ можно получить только на вопрос, который грамотно сформулирован и не нарушает правил\устава форума.
    • Anix
      От Anix
      Отключил винт и подцепил его к виртуалке,
      нашёл лог работы заразы.
      Может поможет в создании лекарства
      temp.rar
    • Mrak
      От Mrak
      В этой теме осуществляется приём конкурсных работ на конкурс осенней фотографии 2024 года.
      Правила конкурса размещены ТУТ.
    • Sandynist
      От Sandynist
      Добрый вечер! Давно хотел написать о проблеме, но всё руки не доходили. 
       
      Немного истории: с большими усилиями компании удалось выкупить региональный домен https://www.kaspersky.kz/
      Можете погуглить, история мутная, какой-то предприимчивый делец зарегистрировал это имя себе и запросил много бабла с компании. 
       
      Но вот теперь казалось бы всё должно наладится, и сайт должен заработать корректно, но ничего подобного.
      Если у нас попытаться открыть ссылку в виде:
      https://www.kaspersky.ru/about/press-releases/zhertvami-novoj-versii-troyanca-necro-mogli-stat-milliony-vladelcev-android-ustrojstv
      то происходит автоматический редирект на наш региональный домен:
      https://www.kaspersky.kz/about/press-releases/zhertvami-novoj-versii-troyanca-necro-mogli-stat-milliony-vladelcev-android-ustrojstv
      на котором никакой статьи не наблюдается. 
       

       
      Так всё это не работает уже более года, а может даже и двух. Хотел традиционно задать этот вопрос Евгению Валентиновичу, но он заметно нервничает, когда его начинают спрашивать по технической части. А я в свою очередь не знаю куда и кому адресовать жалобу, это же не антивирусный продукт.
      Написал письмо на адрес info@kaspersky.com , но очень сомневаюсь, что будет хоть какой-то результат.
       
      P.S. Раньше тут появлялись технические специалисты компании, которым напрямую можно было написать про такие проблемы, как сейчас с этим обстоят дела?
    • KL FC Bot
      От KL FC Bot
      Хотя искусственный интеллект можно применять в ИБ-сфере разными способами, от детектирования угроз до упрощения написания отчетов об инцидентах, наиболее эффективными будут применения, которые значительно снижают нагрузку на человека и при этом не требуют постоянных крупных вложений в поддержание актуальности и работоспособности моделей машинного обучения.
      В предыдущей статье мы разобрались, как сложно и трудоемко поддерживать баланс между надежным детектированием киберугроз и низким уровнем ложноположительных срабатываний ИИ-моделей. Поэтому на вопрос из заголовка ответить очень легко — ИИ не может заменить экспертов, но способен снять с них часть нагрузки при обработке «простых» случаев. Причем, по мере обучения модели, номенклатура «простых» случаев будет со временем расти. Для реальной экономии времени ИБ-специалистов надо найти участки работ, на которых изменения происходят более медленно, чем в «лобовом» детектировании киберугроз. Многообещающим кандидатом на автоматизацию является обработка подозрительных событий (триаж).
      Воронка детектирования
      Чтобы иметь достаточно данных для обнаружения сложных угроз, современная организация в рамках своего SOC вынуждена ежедневно собирать миллионы событий с сенсоров в сети и на подключенных устройствах. После группировки и первичной фильтрации алгоритмами SIEM эти события дистиллируются в тысячи предупреждений о потенциально вредоносной активности. Изучать предупреждения обычно приходится уже людям, но реальные угрозы стоят далеко не за каждым таким сообщением. По данным сервиса Kaspersky MDR за 2023 год, инфраструктура клиентов генерировала миллиарды событий ежедневно, при этом за весь год из них было выделено 431 512 предупреждений о потенциально вредоносной активности. Но лишь 32 294 предупреждения оказались связаны с настоящими инцидентами ИБ. То есть машины эффективно просеяли сотни миллиардов событий и лишь ничтожный процент из них отдали на просмотр людям, но от 30 до 70% этого объема сразу помечаются аналитиками как ложные срабатывания, и около 13% после более глубокого расследования оказываются подтвержденными инцидентами.
       
      View the full article
×
×
  • Создать...