Брюс Шнайер - Секреты и ложь. Безопасность данных в цифровом мире

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

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

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

Так никогда не бывает. Йоги Берра сказал: «Будьте осторожны, если вы не знаете, куда идете, может быть, лучше вам не попадать туда». Часто системы безопасности оказываются неспособны противостоять некоторым угрозам. Шифрование электронной почты может спрятать от посторонних глаз содержание корреспонденции, но никак не сумеет скрыть факт существования переписки. В некоторых случаях выявление корреспондентов оказывается более опасным для них, нежели знание содержания писем. В других ситуациях информация о том, что некто использует шифрование, оказывается чрезвычайно содержательной сама по себе.

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

• Следует понять, что реально угрожает системе, и провести оценку рисков.Это легче сделать, если использовать опыт «реального мира» и знания об имевших место нападениях на похожие системы.

• Определить политику безопасности для противодействия этим угрозам.

Это должен быть ряд положений вроде: «только уполномоченные банки вправе изменять баланс на картах Plasticash» или «все движения денежных средств в системе Plasticash должны быть доступны контролю».

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

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

Рассмотрение целей и методов нападающих кажется очевидным делом, однако многие организации, ведущие себя вполне разумно в других случаях, оказались неспособны сделать это. Военная контрразведка США потратила многие годы на то, чтобы построить защиту от одной хорошо финансируемой организации, имевшей единственную цель – прослушивание американских линий связи военного значения. Она преуспела в этом, однако совершенно упустила из виду опасность, исходящую от хакеров. Хакеров не интересует прослушивание. Их никто не финансирует. Они не организованы. Им не нужны военные секреты, им хочется поковыряться в системе ради развлечения и посмотреть, как она обрушится. Им хочется похвастаться перед приятелями и, может быть, увидеть свое имя в газетах. Некий сотрудник AT&T Bell Labs обнаружил дефект в реализации «Клиппер-чипа» (Clipper chip [51]) военной контрразведки и создал ей дурную славу. Зачем? Ради удовольствия поймать контрразведку на ошибке.