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

Какое ПО следует обновлять в первую очередь | Блог Касперского


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

Установка обновлений — это по определению процесс бесконечный. Настолько бесконечный, что на обновление вообще всего имеющегося в инфраструктуре софта и примкнувшего к нему железа может просто не хватать ресурсов. В среднем каждый день — и не только рабочий — находят десятки новых уязвимостей и, соответственно, каждый месяц выпускают многие сотни и даже тысячи заплаток для них.

Возникает вопрос: какие обновления должны быть в приоритете? Вообще говоря, однозначного ответа на него нет. Стратегии установки патчей могут быть очень разными, и какая из них сработает лучше в вашем случае — зависит от разных обстоятельств. В этом же посте я собираюсь порассуждать о том, что стоит обновлять в первую очередь, исходя из потенциальной опасности эксплуатации уязвимостей.

Уязвимости есть? А если найду?

Некоторые считают, что количество обнаруженных уязвимостей говорит о качестве программного продукта. Иначе говоря, если где-то постоянно обнаруживают дырки, то это плохая программа. А хорошая — это та, где багов отродясь не находили. И, соответственно, учитывают эти соображения при выборе софта для компании.

Это, разумеется, заблуждение: количество найденных уязвимостей в общем случае говорит только о популярности программы, а вовсе не о том, насколько хорошо она сделана. Баги есть во всем. Просто обычно их находят там, где больше ищут. Конечно, можно использовать какой-то всеми забытый программный продукт, потому что в нем еще не ступала нога человека не обнаруживали уязвимости. Но это плохая политика: а ну как копнут и найдут сразу пачку?

Поэтому, если уж на то пошло, обращать внимание надо не на количество багов, найденных в том или ином софте, а на время реакции разработчика и, что тоже немаловажно, качество этой реакции. Если заплатки выпускают быстро и регулярно — это хорошо. Если медленно, спорадически и каждый раз изо всех сил пытаются делать вид, что ничего страшного не случилось, — это плохо, вот такого софта стоит избегать.

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

 

Посмотреть статью полностью

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

Quote

Некоторые считают, что количество обнаруженных уязвимостей говорит о качестве программного продукта. Иначе говоря, если где-то постоянно обнаруживают дырки, то это плохая программа. А хорошая — это та, где багов отродясь не находили. И, соответственно, учитывают эти соображения при выборе софта для компании.

Это, разумеется, заблуждение: количество найденных уязвимостей в общем случае говорит только о популярности программы, а вовсе не о том, насколько хорошо она сделана. Баги есть во всем.

Автор либо повторяет заблуждение других в статье, либо заблуждается сам, но не понимает, где именно.

Quote

если где-то постоянно обнаруживают дырки, то это плохая программа. А хорошая — это та, где багов отродясь не находили

Построено так, будто оба утверждения являются одним целым, но это заблуждение. И мало того, тут ещё недопустимые упрощения. Смотрите:

Quote

если где-то постоянно обнаруживают дырки, то это плохая программа

Кажется, что да. Однако:

  • Находят уязвимости ITW ("в дикой природе") или же находят сами разработчики или нанятые ими аудиторы? Если первое - программа действительно плохая. Если второе - разработчики делают аудит и постоянно следят за качеством
  • Уязвимости потенциальные или легко эксплуатируемые? Если первое — это вовсе не так страшно, как можно подумать. Иногда вплоть до "это не считается". Потому что стоимость атаки, напомню, должна быть ниже стоимости данных. И атаки на _потенциальные_ проблемы могут быть абсурдно дорогими, вплоть до того, что под силу только государствам. Если же проблемы легко эксплуатируемые — это однозначно плохо

Итого: если где-то постоянно находят дырки, которые не сложно эксплуатировать и это находят не разработчики/их аудиторы — это однозначно плохая программа.

 

Перейдём ко второй части:

Quote

А хорошая — это та, где багов отродясь не находили

Нет! Это фундаментальное заблуждение. Нужно осознать это и тогда будете ловить такие заблуждения сходу. Это про тестирование, но применимо и здесь:

Quote

тестирование не способно сообщить, что проблем нет. Тестирование способно сообщить, что проблемы есть. То есть если тестирование не выявило проблем, это не означает, что проблем нет. Это означает, что тестирование их не выявило и только это. Но если тестирование выявило проблемы, это означает, что проблемы есть.

То есть если дыр не находили, нельзя утверждать, что всё хорошо. И, вроде, ниже об этом сказано. Но это слеплено с прошлым утверждением про нахождение дыр, что приводит к логической ошибке.

 

В целом ниже по тексту написано уже правильно. Но начало очень странное. Если Аланна (напомню, считаю её хорошим автором для массового читателя) просто показывала рассуждение обычного человека, то претензии снимаю. Очень вероятно, что я спотыкаюсь на вот этих рассуждениях просто из-за того, что имею отношение к этой области и потому рассуждаю чуть иначе.

 

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

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

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



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

    • KL FC Bot
      Автор KL FC Bot
      Легенды гласят, что наши смартфоны нас подслушивают. Оказывается, делать им это совсем не обязательно — информации, которую передают брокерам данных практически все установленные на вашем смартфоне приложения, от игр до прогноза погоды, с лихвой достаточно, чтобы составить на вас полное досье. И если долгое время под «слежкой в Интернете» подразумевалось, что поисковые и рекламные системы — а с ними и рекламодатели — знают, на какие сайты вы ходите, то с появлением смартфонов ситуация изменилась к худшему — теперь рекламодатели знают, куда вы ходите физически и как часто. Как у них это получается?
      Каждый раз, когда любое мобильное приложение собирается показать рекламу, за ваше внимание проходит молниеносный аукцион, определяющий на основании переданных с вашего смартфона данных, какую именно рекламу вам покажут. И, хотя вы видите только рекламу победителя, данные о потенциальном зрителе, то есть о вас, получают все участники торгов. Недавно поставленный эксперимент наглядно показал, как много компаний получают эту информацию, насколько она детализирована и как мало помогают защититься встроенные в смартфоны опции «Не отслеживать меня», «Не показывать персонализированную рекламу» и аналогичные. Но мы все же посоветуем способы защиты!
      Какие данные пользователя получают рекламодатели
      Все мобильные приложения устроены по-разному, но большинство из них начинают «сливать» данные в рекламные сети еще до того, как показать какую-либо рекламу. В вышеописанном эксперименте мобильная игра сразу же после запуска отослала в рекламную сеть Unity Ads обширный набор данных:
      информацию о смартфоне, включая версию ОС, уровень заряда батареи, уровень яркости и громкости, количество свободной памяти; данные о сотовом операторе; тип подключения к Интернету; полный IP-адрес устройства; код «вендора», то есть производителя игры; уникальный код пользователя (IFV) — идентификатор для рекламной системы, привязанный к производителю игры; еще один уникальный код пользователя (IDFA/AAID) — идентификатор для рекламной системы, единый для всех приложений на смартфоне; текущую геолокацию; согласие на рекламную слежку (да/нет). Интересно то, что геолокация передается, даже если она целиком отключена на смартфоне. Правда, приблизительная, вычисленная на базе IP-адреса. Но с учетом имеющихся в общем доступе баз соответствия физических и интернет-адресов, это может быть достаточно точно — с точностью до района города или даже дома. Если же геолокация включена и разрешена приложению, передаются точные данные.
      Согласие на рекламную слежку в описанном случае было передано как «Пользователь согласен», хотя автор эксперимента такого согласия не давал.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      В галерее вашего смартфона почти наверняка найдется важная информация, сфотографированная для надежности и удобства — например, фото документов, банковских договоров или сид-фраз, позволяющих восстановить доступ к криптокошелькам. Все эти данные могут быть украдены вредоносным приложением, подобным обнаруженному нами стилеру SparkCat. В текущей конфигурации этот зловред обучен красть данные криптокошельков, но с другими настройками он может мгновенно перейти к краже любой другой ценной информации.
      Самое неприятное — этот зловред пробрался в официальные магазины приложений, и только из Google Play зараженные им аппы суммарно загрузили почти 250 тысяч раз. И если в Google Play вредоносные приложения не единожды обнаруживались и до этого, то в App Store троян-стилер обнаружен впервые. Как же устроена эта угроза и что сделать для защиты?
      Довесок к легитимным приложениям
      Приложения, содержащие вредоносные компоненты SparkCat, делятся на две группы. Некоторые из них — например, многочисленные схожие мессенджеры с заявленными функциями ИИ от одного и того же разработчика — очевидно, опубликованы сугубо как приманка. Но есть и другие — легитимные приложения сервисов доставки еды, чтения новостей, утилиты для владельцев криптокошельков. Как в них появилась троянская функциональность, мы не знаем. Возможно, это была атака на цепочку поставок, при которой был заражен один из вспомогательных компонентов — «кирпичиков», из которых собрано готовое приложение, или же разработчики намеренно встраивали трояна в свои приложения.
      Первое приложение, в котором мы обнаружили SparkCat — это сервис для доставки еды в ОАЭ и Индонезии под названием ComeCome. Зараженное приложение было обнаружено как в Google Play, так и в App Store
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Поучительный инцидент с атакой ransomware-группировки Akira наверняка на несколько лет станет любимым примером ИБ-специалистов. Злоумышленники зашифровали компьютеры организации, воспользовавшись ее видеокамерой. Хотя звучит это очень странно, в развитии событий есть логика, которую легко применить к другой организации и другим устройствам в ее инфраструктуре.
      Анатомия атаки
      Злоумышленники проникли в сеть, проэксплуатировав уязвимость в публично доступном приложении и получив возможность выполнять команды на зараженном хосте. Они воспользовались этим, чтобы запустить популярное приложение дистанционного доступа AnyDesk, а затем инициировали с этого компьютера RDP-сессию для доступа к файл-серверу организации. На сервере они попытались запустить свой шифровальщик, но EDR-система, установленная в компании, опознала вредоносное ПО и поместила его в карантин. Увы, это не остановило атакующих.
      Не имея возможности запустить свой шифровальщик на серверах и обычных компьютерах, которые находятся под защитой EDR, атакующие запустили сканирование внутренней сети и обнаружили в ней сетевую видеокамеру. В отчете команды по расследованию инцидента это устройство постоянно называют веб-камерой (webcam), но мы все же полагаем, что речь не о камере ноутбука или смартфона, а о независимом сетевом устройстве, применяемом для видеонаблюдения.
      Камера стала прекрасной мишенью для атакующих по нескольким причинам:
      устройство давно не обновлялось, его прошивка содержала уязвимости, позволяющие дистанционно скомпрометировать камеру и получить на ней права на запуск оболочки (remote shell); камера работает под управлением облегченной сборки Linux, на которой можно запускать обычные исполнимые файлы этой ОС, например Linux-шифровальщик, имеющийся в арсенале Akira; это специализированное устройство не имело (и, скорее всего, не могло иметь) ни агента EDR, ни других защитных средств, которые могли бы определить вредоносную активность. Злоумышленники смогли установить свое вредоносное ПО на эту камеру и зашифровать серверы организации прямо с нее.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Мы живём в эпоху ИИ-хайпа. Искусственный интеллект там, сям, здесь и там, везде и весь такой перспективный, слегка загадочный, но непременно сопровождающий человечество в светлое будущее технологической пока ещё непонятной чёрнодырочной сингулярности.
      Вероятно, некоторый читатель мог заметить в предыдущем предложении сарказм – а зря. Автоматизация на основе машинного обучения (ещё один термин: «ML» = «machine learning»), нейросетей и прочего ИИ уже подмяла под себя многие отрасли нашей жизни, и то ли ещё будет на линии хомосапиенсного развития. Кому интересно нырнуть в тему – поищите что уже случилось по линии промышленных революций Один, Два, Три и даже Четыре.
      В этом тренде кибербезопасность была, пожалуй, одним из пионеров использования новых, умных технологий. А что мне особенно приятно и гордо в этом процессе – наша компания была одной из первых в отрасли, начавших успешно внедрять это самое светлое ИИ-будущее. А как иначе справляться, например, с почти полумиллионом (на начало 2025 года) новых зловредов каждый день? Столько экспертов ни одна образовательная система мира не выпустит. Выход один – создавать умные системы, способные самостоятельно и с высокой точностью нейтрализовывать кибератаки. Экспертам же оставлять только самые сложные случаи и, конечно, непростую задачу такие системы изобретать и постоянно докручивать.
      На днях у нас случился радостный юбилей. 20 лет назад зародился прототип самой первой ИИ/ML технологии для автоматического анализа вредоносного кода и производства «детектов» – антивирусных обновлений, которые защищают компьютеры, гаджеты и прочие устройства от новых атак.
      Технология получила с первого взгляда странное название «Автодятел». Но на самом деле здесь всё просто: «дятлами» у нас ласково и в шутку назывались эксперты-аналитики, «долбящие» вирусы обрабатывающие входящий поток подозрительных файлов, а, соответственно, «автодятел» выполнял эту работу сам. Кстати, в то время я тоже работал «дятлом».
      Покопав архивы, мы нашли не только дату рождения первого птенца автоматИИзации, но и любопытные фотографии планов по его созданию. И место рождения вспомнили. Гнездо располагалось на 14 этаже здания «Радиофизики» на Планерной, где мы тогда снимали офис. Теперь устраивайтесь поудобнее, я расскажу вам увлекательную историю. Начиналось всё примерно вот как.
      С четверть века назад зловреды и встречались куда реже, да и были куда технологичнее современных, хотя писали их пионеры-энтузиасты, изобретательные программисты-одиночки и киберхулиганы. Поэтому и исследовать их было одно удовольствие — что ни вирус, то что-то новое узнаёшь, чему-то учишься. Я тогда вместе с остальными «дятлами» собственноручно «долбил» зловредов — анализировал поток вредоносных программ, если по-научному. Разумеется, к этому моменту собрать все существующие зловреды в одну книжку как в 1992 году уже было сложновато, но тем не менее с потоком мы справлялись, а в конце каждой рабочей недели я вручную собирал обновление антивирусных баз.
       
      View the full article
    • KL FC Bot
      Автор KL FC Bot
      Не так давно на нашем блоге для ИБ-исследователей Securelist вышел пост об атаке на российские промышленные предприятия с использованием бэкдора PhantomPyramid, которую наши эксперты с высокой степенью уверенности атрибутируют группе Head Mare. Атака была достаточно стандартной — письмо, якобы содержащее конфиденциальную информацию плюс архив со зловредом, пароль для распаковки которого находится прямо в теле письма. Но интересен способ, при помощи которого злоумышленники прятали свой вредоносный код в, казалось бы, безобидном файле, — для этого они использовали технику polyglot.
      Что такое техника polyglot
      В матрице MITRE ATT&CK polyglot-файлы описываются как файлы, относящиеся сразу к нескольким типам и работающие по-разному в зависимости от приложения, в котором они запущены. Используются они для маскировки зловредов — для пользователя, а также для некоторых защитных механизмов они могут выглядеть как что-то совершенно безопасное, например картинка или документ. А по факту внутри находится вредоносный код. Причем код может быть написан сразу на нескольких языках программирования.
      Злоумышленники используют самое разное сочетание форматов. Компания Unit42 исследовала атаку с применением файла контекстной справки в формате Microsoft Compiled HTML Help (расширение .chm), который одновременно является HTML-приложением (файлом в формате .hta). Исследователи также описывают применение картинки в формате .jpeg, внутри которой по факту находится PHP-архив .phar. В случае с атакой, исследованной нашими экспертами, внутри архива .zip был спрятан исполняемый код.
      .
      View the full article
×
×
  • Создать...