Как это ни парадоксально, но, если мы возьмем 8 случайных бит из времени непрерывной работы и объединим их с 8 случайными аппаратными битами, мы повысим предсказуемость данных, которые мы используем, и это плохо. Конечно, это возможно делать, чтобы защитить систему от аппаратного генератора случайных чисел со смещением и какой-нибудь ошибки, недостатка конструкции или лазейки в системной криптографии. Это настолько узкоспециализированная работа, что я сам обратился бы за помощью к специалистам.
Последний аспект случайности, о котором следует знать, заключается в том, что невозможно статистически проверить, является ли поток достаточно случайным с точки зрения безопасности. Тест может найти явные недостатки, но не установить их отсутствие. Другими словами, поток данных может пройти статистическую проверку, но при этом быть в значительной степени предсказуемым для того, кто знает, как он порождается.
Проектировать системы, которые были бы одновременно удобны в использовании и лишены предсказуемости, сложно. Наилучший выход, как правило, – либо избегать компромиссов, либо скрыть случайность от пользователя слоями абстракции. Притворяться, что люди могут быстро и точно справиться со шквалом случайностей, – плохая инженерия; требовать, чтобы они тратили на это свое драгоценное внимание, – плохое использование их энергии.
Противоречие между тем, что люди могут запомнить, и эффективностью взлома паролей является одной из причин, по которой многофакторная аутентификация так важна. Существует небольшое пересечений между конфликтующими требованиями к паролям – пригодности к использованию и возможности защиты паролей.
В более общем смысле люди являются машинами обобщения. Мы ищем закономерности и причинно-следственные связи как часть нашего способа осмысливать мир. Когда безопасность кажется произвольной, непонятной или неэффективной, многие восстают против нее. Если вы объясните вашу систему безопасности так, чтобы люди могли с ней работать, это поможет и им, и вам, что подводит нас к вопросу прозрачности в противовес секретности в системах безопасности.
Некоторые злоумышленники целеустремленны и сосредоточенны и потратят время на выяснение, как работают ваши конкретные средства защиты, чтобы обойти их. Если вы обнаружите, что им это удалось, вам придется изменить свою защиту. Так что лучше предусмотреть такую возможность.
Некоторые из старейших принципов компьютерной безопасности появились еще до компьютеров, они пришли к нам из криптографии. В 1883 году голландский лингвист Огюст Керкгоффс публиковал статьи по военной криптографии. Принципы, которых он придерживался, включают такой: «Система не должна требовать сохранения ее в тайне, и попадание ее в руки врагов не должно вызывать проблем» (перевод из Petitcolas, 1997). Это означает, что безопасность системы должна зависеть от ключей, которые могут быть изменены без необходимости замены всей системы. Несмотря на выдвижение шести принципов, «принцип Керкгоффса» сегодня широко используется как сокращение от «Не полагайтесь на неясность».
Классическим примером неясности может быть хранение ключа от дома под растением в горшке. Любой, кто знает, какое это растение, может получить доступ к ключу. Если вы положите ключ в сейф с комбинацией, защитой является физическая устойчивость сейфа и комбинация. Итак, можно разместить сейф рядом с замком.
Современные криптографические системы разрабатываются с учетом этого принципа. AES-256 лучше, чем все, что мы с вами спроектируем. Он прошел многолетний тщательный анализ. Его безопасность зависит только от того, хранится ли ключ в секрете.
Переходя от криптографии к программному обеспечению в более широком смысле, локально установленное программное обеспечение, такое как Microsoft Outlook, подвергается тщательному обратному проектированию в лабораториях злоумышленников. Корпорация Microsoft исправляет определенные проблемы с порчей памяти и, чтобы усложнить эксплуатацию, рандомизирует планировку памяти при каждом запуске приложения Office. По контрасту, макросы Visual Basic for Application (VBA) были хорошо известным источником проблем безопасности. Изменение поведения VBA вызывает существенные проблемы, поскольку многие организации вложили значительные средства в документированные макросы для автоматизации бизнеса [Gatlan, 2022].
Программное обеспечение как услуга не может быть легко развернуто в лаборатории, поэтому естественно спросить: должны ли мы использовать неясность для его защиты? В конце концов, мы знаем, как трудно развернуть эту чертову штуку – злоумышленник не сможет создать копию! Как бы сложно это ни было, заставить ее работать идеально – не обязательное условие для анализа. Но гораздо важнее то, что, если (или когда) аналитик обнаруживает недостаток, лучше, если система не полагается на безопасность через неясность.
Программное обеспечение как услуга также может иметь преимущество наблюдаемости. Отправка журналов в Империю кажется навязчивой, если вы продаете классическое программное обеспечение или раздаете открытый исходный код. Когда программное обеспечение работает в вашем облаке, вы можете обнаруживать атаки по мере их развертывания и устранять их. С точки зрения злоумышленника, он больше не находится в лаборатории, и его экономический или даже личный криминальный риск может несколько измениться. (Под «экономикой» я имею в виду, что объем работы по обнаружению атаки может оказаться больше, или защитники могут отреагировать раньше, или и то и другое – во всех случаях страдает окупаемость инвестиций.)
Это подводит нас к интересному вопросу секретности моделей машинного обучения в облаке. Машинное обучение может быть одним из полезных инструментов для защитников. Такие инструменты активно используются для обнаружения спама и другого оскорбительного контента, и их создание и настройка обходятся дорого. Так как же лучше всего применить принцип Керкгоффса? С одной стороны, мы можем рассматривать модель в целом как ключ: мы ожидаем ее регулярной настройки и обновления, и поэтому наша зависимость от секретности модели ограничена. Попытки количественно оценить трудозатраты злоумышленника привлекательны на первый взгляд, но в них легко ошибиться, а результаты часто бывают нестабильными. То есть новая умная атака может значительно сократить трудозатраты атакующего.
Тем не менее существует класс атак («кража моделей») против таких моделей. Ведутся споры о том, насколько практичны такие атаки против развернутых реализаций, но сначала вспомним, что атаки становятся только лучше. Во-вторых, напомним, что мы находимся в разделе, посвященном предположению о прозрачности. Проектирование всегда сопряжено с компромиссами, и в этом случае модели могут быть менее согласованы с принципом Керкгоффса, но все же полезны для облака. (Надеюсь, теперь очевидно, что загруженную модель машинного обучения довольно легко украсть и проанализировать, поэтому ваша безопасность не должна зависеть от того, что злоумышленники этого не сделают.)
Очень заманчиво углубиться в нюансы по этому поводу, но это ловушка. Есть веские причины для того, чтобы эти принципы использовались в течение полутора веков.
Если описание вашей защиты предоставляет «дорожную карту для злоумышленников, и как ее лучше обойти», ваша защита слаба. Ваши проекты должны быть устойчивыми, даже если злоумышленник знает, что они из себя представляют, и вы должны безусловно проанализировать, что могут сделать ваши собственные сотрудники, задавая им вопросы типа «А как бы вы сами атаковали это?». Я часто удивляюсь ответам людей, не связанных с организацией безопасности.
Это подводит нас к чертежам «Звезды смерти». Во-первых, ответы на этот вопрос дают «Звездные войны». «Звезда смерти» действительно слаба. Из «Изгоя-один» мы знаем, что Гален Эрсо тайно встроил уязвимость в «Звезду смерти». Более того, недостатки конструкции очевидны. Вокруг реактора нет заслонок или противовыбросовых панелей. Повстанцам нужно совсем немного времени, чтобы найти уязвимость, спланировать атаку и проинструктировать пилотов до того, как появится «Звезда смерти». И наконец, если вы потерпите несколько минут еще более глубокого теоретизирования вокруг «Звездных войн», то поймете, что Вейдер знает об этом. Он не просто запрыгивает в свой истребитель СИД (TIE Fighter), чтобы охотиться на гнусных повстанцев – он следит за тем, чтобы не оказаться на «Звезде смерти», когда она взорвется. (Кроме того, как упоминалось во вступлении, в блестящей маленькой короткометражке Доркли «Архитектор „Звезды смерти“ высказывается», архитектор объясняет, что никто не просил его учитывать существование космических волшебников, которые могут сделать такой выстрел, что торпеда пройдет много миль по узкой шахте.)
Если отвлечься от полемики со «Звездными войнами», то проблема заключается в том, что Империя имеет привычку наказывать людей, которые ставят под сомнение ее планы, поэтому никто не считает себя вправе подвергать сомнению или критиковать систему «Звезды смерти». В результате она взрывается, унеся бесчисленное количество жизней на борту. Сделайте так, чтобы ваша защита оставалась сильной, даже если повстанцы украдут резервную копию на магнитной ленте, содержащую архитектуру вашей системы. Сейчас может показаться, что я все еще нахожусь внутри «Звездных войн», но эти уроки хорошо работают и в нашем мире.
Неясность вредит защитникам
Ряд атак, которые мы сейчас называем разбиванием стека, известны по крайней мере с начала 1970-х годов. Только после того, как они получили широкую огласку в 1990-х годах, на них обратили внимание [Shostack, 2008].
Непосредственной причиной многих из них было то, что функции str библиотеки C не имели информации о длине строк. При копировании данных можно было «разбить стек», когда копирование выполнялось в конец стека. Это приводило к тому, что содержимое копируемой строки перезаписывало память. До тех пор, пока детали оставались неясными, разработчики системы не понимали масштабов проблемы.