Как моделирование угроз и уход влево помогают создать прочную основу для безопасного программного обеспечения

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

Конечно, для вашего приложения также может не понадобиться тратить ненужные часы на создание серверной части, такой как Fort Knox. Быть сторонником безопасности не означает всегда носить шляпу из фольги (хотя вы действительно выглядите в ней лихо), но это означает, что необходимо обеспечить надлежащий уровень безопасности.

Насколько подходит безопасность? К сожалению, ответ таков: зависит от обстоятельств.

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

Моделирование угроз: что самое худшее могло случиться

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

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

В мире программного обеспечения можно найти несколько различных методологий оценки рисков приложений, в том числе подробную Специальную публикацию NIST 800–30.

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

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

  • Какой злоумышленник захочет взломать мое приложение? Что они будут после?
  • Если контроль над x попадет в чужие руки, что злоумышленник сможет с этим делать?
  • Где в моем приложении могла возникнуть уязвимость x?

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

  • Уязвимости или компоненты, которые могут вызвать риск
  • Влияние успешного выполнения риска на приложение
  • Последствия для пользователей или организации приложения

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

Обычно риски сортируются по иерархии рисков от наихудшего до самого умеренного. Наихудшие риски имеют самые негативные последствия, и от них наиболее важно защититься. Самые легкие риски являются наиболее приемлемыми - хотя они все еще являются нежелательным результатом, они оказывают наименьшее негативное влияние на приложение и пользователей.

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

Нажатие влево

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

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

Чем дальше вы продвигаетесь в процессе сборки, тем сложнее и дороже становится вносить изменения в уже установленный вами компонент. Если вы обнаружите проблему со стенами только после того, как крыша будет установлена ​​на место, вам может потребоваться изменить или снять крышу, чтобы исправить ее. Аналогичные параллели можно провести и для программных компонентов, только без такой легкости распутывания присоединенных частей.

В случае с домиком на дереве практически невозможно начать с украшений или даже с крыши, потому что вы не можете повесить их в воздухе.

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

Строительство снизу вверх

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

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