В обоих случаях я бы описал свою цель как поиск «гарантий». Правительства часто используют это слово в смешанном значении. Как это ни парадоксально, один и тот же термин применяется к работе создателей при обеспечении «гарантий» и к работе покупателей, часто делегируемой для проверки оценщикам.
Цель гарантирования может быть подорвана на каждом этапе процесса разработки. При проектировании, если не моделировать угрозы или не учитывать, «что может пойти не так», может случиться так, что при разработке будут упущены важные угрозы. Выбор небезопасной среды разработки, отсутствие обучения разработчиков или игнорирование качеств безопасности включенного кода могут угробить лучшие проекты. Неудачное тестирование может привести к тому, что будут пропущены ошибки. Репутация сутяги может привести к тому, что те, кто видит проблемы с безопасностью, не будут сообщать вам о них, а глухота к тем, кто это делает, может вызвать бурю непонимания.
Каталоги защит
Существует великое множество каталогов защитных средств. Большинство из них, такие как NIST Cybersecurity Framework или CIS Controls Центра интернет-безопасности, сосредоточены на операционных потребностях компаний, приобретающих бóльшую часть кода, который они развертывают. Другие ориентированы на конкретную потребность, например руководство по усилению защиты Windows компании SANS Institute или руководство Cloud Security Alliance. Третьи сосредоточены на отраслях промышленности, таких как здравоохранение или финансы.
Новая категория – требования к тем, кто создает (и, возможно, включает) код, например NIST Secure Software Development Framework. Иногда их называют «безопасностью цепочки поставок», и это может создать путаницу для тех, кто находится внутри цепочки поставок, и тех, кто находится на ее краях.
Поэтому я не собираюсь пытаться перечислить множество средств защиты, которые продаются сегодня для личной или деловой безопасности. (Если продавец, продающий вам их, не может четко объяснить, какую угрозу он рассматривает, невежливо укажите ему на дверь.) Я также не собираюсь пытаться каталогизировать каталоги, и опять же, каталог должен сам объяснять свои цели.
Многие из них не могут объяснить, какие угрозы их заботят, в ущерб себе и вашим затратам. (Я выступал с докладом Reverse Engineering Compliance («Соответствие требованиям обратного проектирования»), в котором подробно объяснял этот момент [Shostack, 2021].)
Заключение
Цепочки атак – это полезная структура, показывающая, как злоумышленники создают угрозы в реальных системах. Их операционная направленность объединяет множество угроз, которые вы теперь понимаете. Их повествовательная природа помогает почувствовать реальность угроз, и они могут помочь ответить на вечный вопрос защитника: «Зачем кому-то это делать?» Но угрозы меняются медленно, как и общие цепочки, которые их объединяют.
Цепочки, с помощью которых реализуются угрозы серверам, клиентам и сетям, медленно менялись на протяжении многих лет. Специфика, конечно, меняется из года в год, а цепочки – из десятилетия в десятилетие, но описанные структуры будут служить вам на протяжении всей вашей карьеры. Они являются основной частью того, что должен знать каждый инженер.
Эпилог
Угрозы в этой книге часто выглядят таинственными или призрачными, как ситхи. Слишком многие инженеры были обмануты, думая, что только полностью обученные джедаи на пике своего могущества могут справиться с этими угрозами. Вы многому научились, и еще бóльшему предстоит научиться. Излишняя самоуверенность – вот чего следует избегать.
То, что вы узнали из этой книги, – это конкретные угрозы и способы борьбы с ними. Эти угрозы становятся гораздо сильнее, если их игнорировать. Некоторые из них могут быть решены с помощью простой инженерии; другие требуют сложных компромиссов с нюансами и ловушками для беспечных. По мере продвижения вперед подумайте о том, как каждая из них может быть использована на ваших системах. В книге «Моделирование угроз: проектирование для обеспечения безопасности» я определил моделирование угроз как семейство методов, помогающих ответить на четыре ключевых вопроса:
1. Над чем мы работаем?
2. Что может пойти не так?
3. Что мы будем с этим делать?
4. Хорошо ли мы всё сделали?
По мере того как я преподавал, я понял, что многие студенты затрудняются ответить на вопрос, что может пойти не так. Это означает, что определение того, какие угрозы применимы к системе, может быть самой сложной задачей при моделировании угроз.
Большинству людей легко описать несколько вещей, которые могут пойти не так, и многим трудно определить технические механизмы, которые приводят к таким результатам. Некоторые даже как-то чувствуют безопасность, как Хан Соло чувствует Силу.
Хан. Шаманство и антикварное оружие ничто против бластера.
Люк. Ты что, не веришь в Силу?
Хан. Я облетел всю галактику из конца в конец и видел много странного, но не нашел ничего, что бы заставило меня поверить в Силу, которая всем управляет. Никакое мистическое поле не управляет моей судьбой! Все это фокусы и просто чепуха.
В скептицизме Хана есть доля мудрости. Некоторые угрозы действительно являются простыми уловками. Некоторые заявления об угрозах – чепуха. Конечно, стучать по шлему и пожимать плечами, изображая пантомимой, что радио не работает, – это тоже простой трюк. Мы можем выявлять угрозы из-за того, что они делают с нами, нашими продуктами или нашими клиентами. И когда мы это делаем, они теряют свою способность управлять нашей судьбой.
Угрозы, составляющие стержень этой книги, от STRIDE до предсказуемости и синтаксического анализа, связаны друг с другом цепочками атак. Знание угроз позволяет учитывать их при проектировании, создании, развертывании или эксплуатации технических систем. Теперь вы можете что-то сделать с каждой из них.
Компромиссы лежат в основе инженерии. Каждый инженер должен идти на компромисс между такими свойствами, как стоимость, качество и скорость. Великие инженеры находят элегантные, умные или вдохновляющие компромиссы. Часто наши компромиссы включают в себя то, что мы могли бы предвидеть: силовые блоки, который сильно греются и тратят электроэнергию, компоненты, которые не могут быть переработаны и разрушают окружающую среду, мост, прозванный «Галопирующей Герти» до его обрушения и который был построен с соотношением ширины к длине вдвое меньше, чем у современных ему мостов. Бывают и неожиданные сюрпризы. Волшебное свечение радиоактивности убивает часовщика? Один пакет может захватить базу данных?
Эта книга, «Чему „Звездные войны“ учат инженера по информационной безопасности», была задумана для того, чтобы привнести угрозы в это пространство компромиссов. От малых решений до больших, безопасность является свойством наших проектов.
Приквелы начинаются с истории Энакина Скайуокера, его деградации и падения. Основная трилогия состоит из двух взаимосвязанных историй роста. Первая о том, как страдания Дарта Вейдера из-за любви к сыну приводят его к искуплению. Вторая – это история взросления Люка, Хана и Леи.
Люк, Хан и Лея оказываются вместе в обстоятельствах за пределами их понимания и контроля. Каждый из них старается избежать своего героического пути. Тем не менее, сталкиваясь со многими проблемами и угрозами, каждый из них становится сильнее, и они становятся сильнее вместе.
Вы, ваши продукты и даже ваши команды можете пройти похожий, надеюсь, менее опасный путь. У всех нас есть страх перед неизвестным, и у нас есть смутное ощущение (или даже страшная уверенность), что наши продукты менее надежны, чем они могли бы быть. Но это в прошлом. Код в буквальном смысле фиксируется не только в системе управления версиями, но иногда он прожигается в кремнии и припаивается к платам. Мы можем контролировать только то, куда мы пойдем в будущем.
Когда Люк идет против Вейдера в конце «Возвращения джедая», он говорит Лее: «В нем есть что-то хорошее. Я почувствовал это». Даже если вы не чувствуете, что в этих угрозах есть что-то хорошее, противостояние им позволит вам найти и устранить их. Для обеспечения безопасности. Вы можете обнаружить их самостоятельно или в рамках программного обеспечения, которым пользуется ваша организация.
С этого момента вы можете продолжить путешествие длиною в жизнь в мир безопасности. Если вы это сделаете, вы можете выбрать светлую или темную сторону или даже решить, что вы избранный, который принесет баланс…
Но мы не джедаи, мы инженеры.
С самого начала и на каждом этапе реализации продукты и услуги, которые вы разрабатываете, теперь могут обеспечивать безопасность.
Это наша единственная надежда.
Глоссарий
Этот раздел в первую очередь предназначен для дополнения глоссария Ресурсного центра компьютерной безопасности NIST Computer Security Resource Center’s Glossary, доступного по адресу csrc.nist.gov/glossary/. Статьи ниже, не имеющие гнезда в глоссарии NIST, помечаются знаком (+). Там, где мои определения отличаются, запись помечается (*) и разъясняется разница.
Алгоритмы хэширования отображают произвольно длинные входные данные в выходные данные фиксированного размера, так что трудно (вычислительно недостижимо) найти два различных хэш-входа, которые дают один и тот же результат. Такие алгоритмы являются неотъемлемой частью процесса создания цифровых подписей фиксированного размера, которые могут как аутентифицировать подписывающую сторону, так и обеспечивать проверку целостности данных (обнаружение изменения ввода после подписи).
Агентство национальной безопасности Соединенных Штатов занимается электронной войной и сбором разведданных, в основном на стороне нападения, и отвечает за помощь в обороне Соединенных Штатов, особенно военным и разведывательным агентствам. В свое время крупнейший работодатель математиков в мире.