Категоризация и приоритизация угроз

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

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

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

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

Модель оценки риска DREAD

DREAD — это мнемонический чеклист для приоритизации угроз по их серьезности. Он расшифровывается как Damage, Reproducibility, Exploitability, Affected Users и Discoverability; смысл этих категорий достаточно очевиден. Обычно для каждой категории используется шкала от 0 до 10. Итоговую оценку риска можно вычислить как среднее значение: Risk = (D + R + E + A + D) / 5.

Однако некоторые оценки DREAD могут быть спорными. Например, воспроизводимость не очень полезна в случаях, когда атака удаляет таблицу и повторно на той же таблице уже не сработает. Это даст низкую оценку, поскольку действие можно выполнить только один раз, хотя последствия все равно будут серьезными. Сложно оценивать и обнаруживаемость: для этого нужно знать, что известно атакующему. Поэтому эту оценку часто выставляют равной 10, исходя из предположения, что любая угроза рано или поздно будет обнаружена, а умный атакующий существует. Вокруг обнаруживаемости было много обсуждений, включая вопрос о том, не поощряет ли стремление специалистов по безопасности снижать обнаруживаемость устаревший подход "безопасность через сокрытие" (security through obscurity).

Модель угроз STRIDE

Модель угроз STRIDE — это полезный чеклист вопросов, который помогает при моделировании угроз приложения. "STRIDE" — акроним для следующих категорий угроз: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service и Elevation of Privilege.

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

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

Чем опытнее команда, тем меньше ей нужны такие мнемоники. Тем не менее кратко рассмотрим, что означает STRIDE:

Spoofing охватывает случаи, когда кто-то незаконно получает доступ к системе, используя аутентификационные данные другого пользователя. Главный вопрос здесь в том, как компоненты могут убедиться, что другая сторона потока данных является "правильной" стороной, или как понять, откуда эта сторона получила данные. Например, веб-сайты редко думают о пользователе, но для пользователя может быть важно, что веб-сайт является "правильным", а не поддельным.

Tampering охватывает такие случаи, как несанкционированные изменения постоянных данных, как внутри машины, так и при передаче. Например, важно ли, что данные приходят не по порядку или в неполном виде?

Repudiation имеет две стороны. Первая — угрозы, связанные с пользователями, которые отрицают свои действия. Например, пользователь выполняет незаконную операцию в системе, где нет возможности отследить запрещенные действия. Иногда такая возможность желательна: вспомните возможность правдоподобного отрицания для сохранения приватности. Вторая сторона — non-repudiation, то есть способность системы противостоять отрицанию действий пользователями. Например, клиент может купить товар, а затем утверждать, что покупки не было. Поэтому пользователю может потребоваться подписать квитанцию при получении товара, а продавец сможет использовать подписанную квитанцию как доказательство сделки. Чтобы это работало, система должна вести журналы аудита, и нужно убедиться, что они хранятся так, чтобы их нельзя было изменить.

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

Denial of Service относится ко всем случаям, когда сервер или сервис становится недоступным для авторизованных пользователей. От некоторых типов DoS угроз нужно защищаться хотя бы для повышения доступности и надежности системы.

Наконец, Elevation of Privilege — это тип угрозы, при котором непривилегированный пользователь находит способ получить достаточные привилегии для компрометации системы. Угрозы повышения привилегий включают ситуации, когда атакующий фактически прошел все защиты системы и стал частью самой доверенной системы; это действительно опасная ситуация.

Применение STRIDE

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

• Злоумышленник использует атаку man-in-the-middle, чтобы просматривать и/или изменять данные профиля на пути между клиентом и сервером или между компонентами системы.
• Злоумышленник получает доступ к данным профиля напрямую в базе данных или изменяет их.
• Злоумышленник узнает, как действовать "от имени" пользователя, имитируя определенное поведение Lightweight Directory Access Protocol (LDAP).
• Злоумышленник изменяет данные на сайте.
• Злоумышленник запускает DoS-атаку против части системы и делает систему неработоспособной, например блокируя доступ к базе данных с профилями пользователей.
• Злоумышленник удаляет или изменяет журналы аудита.
• Злоумышленник запускает DoS-атаку на цель, выводит ее из строя и занимает ее место.

Геймификация анализа безопасности

Анализ может быть утомительной работой, но не обязан быть таким. Что если превратить его в игру, где участниками будут разработчики, архитекторы, тестировщики и другие сотрудники компании? Зарезервируйте комнату, организуйте угощение и подготовьте призы. И не забывайте получать удовольствие от анализа. В этой области есть как минимум два заметных варианта, и оба являются карточными играми. Эти игры поощряют участников творчески и нестандартно думать об угрозах. Во-первых, это карточная игра Microsoft Elevation of Privilege (EoP), основанная на STRIDE. Во-вторых, карточная игра OWASP Cornucopia, которая в основном основана на OWASP Secure Coding Practices — Quick Reference Guide (SCP). Cornucopia более релевантна веб-приложениям, чем EoP.

Зачем расставлять приоритеты

Теперь у нас есть набор угроз, но что с ними делать? Эту часть можно назвать анализом риска, поскольку нужно решить, какой риск они создают. Не все угрозы имеют одинаковый уровень риска.

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

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

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

В этой первой части курса Advanced Topics мы сделали следующий шаг к пониманию архитектурного анализа. В следующей части мы рассмотрим назначение лог-файлов и управление ими.

Не забудьте проверить свои баллы в индикаторе в правом нижнем углу материала!