Выбрать главу

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

Источник другой модели безопасности – быстро меняющийся, ничем не ограниченный, крайне запутанный и пока еще безобидный мир ПО. Ее девиз: «Убедитесь, что защита легко адаптируется», или, если придерживаться лексикона небезызвестной соцсети: «Двигайтесь вперед как можно быстрее»{120}. Действуя в соответствии с этой концепцией, мы стараемся удостовериться, что, обнаружив уязвимость, сумеем оперативно обновить наши системы. Пытаемся построить жизнеспособные системы, которые быстро и с минимальными потерями восстановятся после взлома, подстраиваться под меняющиеся обстоятельства и противостоять новым угрозам. Но, по большому счету, мы проектируем системы, на которые сможем оперативно и эффективно устанавливать патчи[17]. О том, насколько хорошо решаются эти задачи, можно спорить, но мы смиряемся с ситуацией, поскольку потенциальные издержки не слишком велики.

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

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

В любом сегменте ПО масса необнаруженных уязвимостей. Большинство может находиться в состоянии покоя в течение месяцев и даже лет, но некоторые обнаруживаются довольно быстро. Найти уязвимость ПО могут как сотрудники компаний или государственных структур, так и независимые исследователи или киберпреступники. Безопасность поддерживается следующим образом: 1) те, кто обнаруживает уязвимость, сообщают об этом разработчику ПО и общественности; 2) разработчик оперативно выпускает соответствующий патч; 3) пользователи так же оперативно устанавливают этот патч.

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

Сегодня исследователи предупреждают разработчиков, а следом представляют информацию публике. Факт обнародования становится тем самым «кнутом», который подстегивает производителей к оперативному выпуску соответствующего патча, а также инструментом, позволяющим аналитикам обмениваться опытом и приобретать известность в своем сообществе. Кроме того, публикации помогают исследователям отслеживать тенденции в области безопасности, стимулируют их развивать навыки. Выражение «ответственное раскрытие информации» как раз об этом{121}.

Множество аналитиков, от хакеров-одиночек до научных работников и инженеров – сотрудников корпораций, находят и ответственно раскрывают информацию о проблемах. Руководители корпораций предлагают премии тем хакерам, которые сообщают об уязвимостях, вместо того чтобы обнародовать эту информацию или использовать ее в преступных целях. В структуре Google есть подразделение Project Zero, задача которого – поиск слабых мест в наиболее популярном ПО, как находящемся в открытом доступе, так и в персональном{122}. Можно спорить о том, что на самом деле мотивирует исследователей (многие действуют ради известности или вознаграждения), но не об эффективности их работы. Несмотря на то что количество «дыр» стремится к бесконечности, устранение хотя бы одной из них обеспечивает безопасность целого сегмента ПО{123}.

вернуться

121

Stephen A. Shepherd (22 Apr 2003), “How do we define responsible disclosure?” SANS Institute, https://www.sans.org/reading-room/whitepapers/threats/define-responsible-disclosure-932.

вернуться

122

Andy Greenberg (16 Jul 2014), “Meet ‘Project Zero,’ Google’s secret team of bug-hunting hackers,” Wired, https://www.wired.com/2014/07/google-project-zero. Robert Hackett (23 Jun 2017), “Google’s elite hacker SWAT team vs. everyone,” Fortune, http://fortune.com/2017/06/23/google-project-zero-hacker-swat-team.

вернуться

123

Andy Ozment and Stuart Schechter (1 Jul 2006), “Milk or wine: Does software security improve with age?” in Proceedings of the 15th USENIX Security Symposium, https://www.microsoft.com/en-us/research/publication/milk-or-wine-does-software-security-improve-with-age.