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

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

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

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

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

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

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

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

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

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

Ну, тогда вирусов было мало, обновления выходили всего несколько раз в месяц, да и софта было, мягко скажем, поменьше :) Где-то под конец 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, AV-Test.org ,Virus Bulletin и PCSL — всего 24 теста) и получили вот такую любопытную картину:

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

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

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

На этом всё, всем пока!