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

[KL FC Bot 189]

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

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

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

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

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

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

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

 

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

[Umnik 1 282]

Quote

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

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

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

Quote

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

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

Quote

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

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

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

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

 

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

Quote

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

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

Quote

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

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

 

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