Моделирование угроз для драйверов

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

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

Проектирование безопасного драйвера включает в себя:

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

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

Модель угроз отвечает на следующие вопросы:

• Какие ресурсы требуют защиты?
• Каким угрозам подвержены активы?
• Насколько важно или вероятно, каждая угроза?
• Как устранить угрозы?

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

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

• Веб-сайт Microsoft SDL:

  https://www.microsoft.com/sdl

• Упрощенная реализация Microsoft SDL:

  Скачивание Белого документа

• В этой записи блога описывается, как скачать бесплатную копию жизненного цикла разработки безопасности: SDL, Майкл Ховард и Стив Липнер:

  https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

Создание моделей угроз для драйверов

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

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

Одним из способов организации усилий по моделированию угроз является выполнение следующих действий.

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

Создание схемы потока данных

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

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

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

Информация поступает в драйвер вследствие запросов от операционной системы, пользовательского процесса или запросов от устройства (обычно прерываний).

Драйвер на предыдущем рисунке получает данные из операционной системы в нескольких типах запросов:

• Запросы на выполнение административных задач для драйвера и его устройства с помощью вызовов к подпрограммам DriverEntry, DriverUnload и AddDevice
• Запросы Plug and Play (IRP_MJ_PNP)
• Запросы на управление питанием (IRP_MJ_POWER)
• Запросы на внутреннее управление I/O устройств (IRP_MJ_INTERNAL_DEVICE_CONTROL)

В ответ на эти запросы данные передаются из драйвера обратно в операционную систему в виде сведений о состоянии. Драйвер на рисунке получает данные из процесса пользователя в следующих типах запросов:

• Создание, чтение и запись запросов (IRP_MJ_CREATE, IRP_MJ_READ или IRP_MJ_WRITE)
• Запросы управления вводом/выводом общедоступных устройств (IRP_MJ_DEVICE_CONTROL)

В ответ на эти запросы выходные данные и информация о состоянии возвращаются от драйвера к процессу пользователя.

Наконец, драйвер получает данные от устройства в результате операций ввода-вывода или действий пользователя (таких как открытие лотка на CD-приводе), которые изменяют состояние устройства. Аналогичным образом данные от драйвера передаются на устройство во время операций ввода-вывода и изменения состояния устройства.

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

На второй схеме показаны отдельные задачи для каждого типа запроса ввода-вывода на первой схеме. (Для простоты пути данных к устройству были опущены.)

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

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

• IRP_MJ_XXX запрашивает обработку драйвером
• IOCTLs, которые определяются или обрабатываются драйвером
• API, вызываемые драйвером
• Подпрограммы обратного вызова
• Любые другие интерфейсы, предоставляемые драйвером
• Файлы, которые драйвер считывает или записывает, включая те, которые используются во время установки
• Ключи реестра, которые драйвер считывает или записывает
• Страницы свойств конфигурации и другие сведения, предоставленные пользователем, которые использует драйвер.

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

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

Анализ потенциальных угроз

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

• Какие механизмы безопасности существуют для защиты каждого ресурса?
• Защищены ли все переходы и интерфейсы должным образом?
• Может ли неправильное использование функции непреднамеренно поставить под угрозу безопасность?
• Может ли злонамеренное использование функции компрометировать безопасность?
• Обеспечивают ли параметры по умолчанию достаточную безопасность?

Подход STRIDE к классификации угроз

Акроним STRIDE описывает шесть категорий угроз программному обеспечению. Это акроним является производным от:

• Спуфинг
• Амперирование
• Отказ
• Раскрытие информации
• Oтказ в обслуживании
• Елевация привилегий

Используя STRIDE в качестве руководства, вы можете задать подробные вопросы о типах атак, которые могут быть нацелены на водителя. Цель состоит в том, чтобы определить типы атак, которые могут быть возможны в каждой уязвимой точке в драйвере, а затем создать сценарий для каждой возможной атаки.

• Спуфинг — это использование учетных данных другого пользователя для получения доступа к недоступным ресурсам. Процесс осуществляет атаку спуфинга путем передачи поддельных или украденных учетных данных.

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

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

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

• Атаки типа "отказ в обслуживании" угрожают возможности допустимых пользователей получать доступ к ресурсам. Ресурсы могут быть дисковое пространство, сетевые подключения или физическое устройство. Атаки, которые замедляют работу системы до неприемлемых показателей, также считаются атаками типа "отказ в обслуживании". Драйвер, позволяющий пользователю монополизировать системный ресурс ненужным образом, может быть подвержен атаке типа "отказ в обслуживании", если потребление ресурсов препятствует возможности других допустимых пользователей выполнять свои задачи.

  Например, драйвер может использовать семафор для защиты структуры данных при выполнении в IRQL = PASSIVE_LEVEL. Однако драйвер должен получить и освободить семафор в паре KeEnterCriticalRegion/KeLeaveCriticalRegion , которая отключает и повторно включает доставку асинхронных вызовов процедур (APCs). Если драйвер не сможет использовать эти процедуры, APC может привести к приостановке потока, удерживающего семафор. В результате другие процессы (включая созданные администратором) не смогут получить доступ к структуре.

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

  Атаки с повышением привилегий также могут возникать, если драйвер в режиме ядра использует значение RequestorMode в заголовке IRP, чтобы определить, поступает ли запрос ввода-вывода из вызывающего объекта в режиме ядра или в пользовательском режиме. В irPs, поступающих из сети или службы сервера (SRVSVC), значение RequestorMode — KernelMode независимо от источника запроса. Чтобы избежать таких атак, драйверы должны выполнять проверки доступа для таких запросов, а не просто использовать значение RequestorMode.

Методы анализа драйверов

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

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

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

Деревья угроз и контуры могут быть полезны в моделировании таких сложных сценариев.

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

Дерево угроз показывает необходимые шаги для осуществления определённой атаки и взаимоотношения между шагами. План является альтернативой дереву угроз.

Структура просто перечисляет в иерархическом порядке шаги по атаке определенной угрозы. Рассмотрим пример.

1.0 Причина прекращения реагирования устройства.

1.1 Проблема IOCTLS в последовательности сбоев.

1.1.1. Определите последовательность, которая приводит к сбою устройства.

1.1.2 Получить повышенные привилегии для отправки внутренних команд ввода-вывода.

Любой метод поможет вам понять, какие угрозы являются наиболее опасными и какие уязвимости в проектировании наиболее важны.

Моделирование угроз по ускоренному методу

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

Драйвер получает данные из операционной системы в нескольких типах запросов:

• Запросы на выполнение административных задач для драйвера и его устройства с помощью вызовов к подпрограммам DriverEntry, DriverUnload и AddDevice
• Запросы Plug and Play (IRP_MJ_PNP)
• Запросы на управление питанием (IRP_MJ_POWER)
• Внутренние запросы подсистемы управления вводом-выводом устройства (IRP_MJ_INTERNAL_DEVICE_CONTROL)

В ответ на эти запросы данные передаются из драйвера обратно в операционную систему в виде сведений о состоянии. Драйвер получает данные от процесса пользователя в следующих типах запросов:

• Создание, чтение и запись запросов (IRP_MJ_CREATE, IRP_MJ_READ или IRP_MJ_WRITE)
• Запросы на управление общедоступными устройствами (IRP_MJ_DEVICE_ CONTROL)

В ответ на эти запросы от драйвера к процессу пользователя поступают выходные данные и сведения о состоянии.

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

Подход DREAD к оценке угроз

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

DREAD — это акроним, описывающий пять критериев оценки угроз программному обеспечению. DREAD означает:

• Damage
• Reproducibility
• Exploitability
• Инфицированныепользователи
• Обнаруживаемость

Чтобы определить приоритеты угроз для драйвера, ранжируйте каждую угрозу от 1 до 10 по всем 5 критериям оценки DREAD, а затем добавьте оценки и разделите на 5 (количество критериев). Результатом является числовая оценка от 1 до 10 для каждой угрозы. Высокие оценки указывают на серьезные угрозы.

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

• Воспроизводимость — это мера частоты успешного выполнения указанного типа атаки. Легко воспроизводимая угроза, скорее всего, будет использоваться, чем уязвимость, которая возникает редко или непредсказуемой. Например, угрозы для компонентов, которые установлены по умолчанию или используются по каждому возможному пути выполнения кода, являются очень воспроизводимыми.

• Эксплуатируемость оценивает усилия и знания, необходимые для осуществления атаки. Угроза, которая может быть атакована относительно неопытным студентом колледжа, является легко эксплуатируемой. Атака, требующая высококвалифицированного персонала и дорогостоящая для выполнения, является менее уязвимой.

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

• Затронутые пользователи. Число пользователей, которые могут быть затронуты атакой, является еще одним важным фактором в оценке угрозы. Атака, которая может повлиять не более чем на одного или двух пользователей, будет иметь относительно низкий рейтинг по этой шкале. И наоборот, атака типа "отказ в обслуживании", которая вызывает сбой сетевого сервера, может повлиять на тысячи пользователей и, следовательно, оценивалась значительно выше.

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

Пример. Оценка угроз с помощью DREAD

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

Устранение угроз

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

Включение моделирования угроз в более широкий жизненный цикл разработки безопасности

Рассмотрите возможность включения процесса моделирования угроз в более широкий жизненный цикл безопасной разработки — SDL.

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

Дополнительные сведения см. в разделе "Жизненный цикл разработки безопасности Майкрософт" (SDL) — руководство по процессу.

Учебные курсы и организационные возможности . Обучение безопасности программного обеспечения для расширения возможностей распознавания и устранения уязвимостей программного обеспечения.

Корпорация Майкрософт предоставляет четыре основных класса обучения SDL для скачивания. Классы обучения жизненного цикла разработки безопасности Майкрософт

Дополнительные сведения об обучении SDL см. в этом техническом документе. Основные учебные материалы по безопасности программного обеспечения для Microsoft SDL

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

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

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

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

Проверка . Проверка — это точка, в которой программное обеспечение функционально завершено и проверяется в соответствии с целями безопасности, описанными в соответствии с требованиями и этапом разработки.

Дополнительные средства, такие как Binscope и фаззеры, можно использовать для проверки того, выполнены ли цели безопасности в проектировании, и код готов к выпуску.

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

Дополнительные сведения о процессе SDL см. в следующих дополнительных ресурсах:

• Это основной сайт Microsoft SDL и предоставляет обзор SDL. https://www.microsoft.com/sdl

• В этом блоге описывается, как скачать бесплатную копию жизненного цикла разработки безопасности: SDL, Майкл Ховард и Стив Липнер. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/

• Эта страница содержит ссылки на дополнительные публикации SDL. https://www.microsoft.com/SDL/Resources/publications.aspx

Призыв к действию

Для разработчиков драйверов:

• Сделайте часть моделирования угроз частью проектирования драйверов.
• Выполните действия по эффективному устранению угроз в коде драйвера.
• Ознакомьтесь с проблемами безопасности и надежности, которые применяются к типу драйвера и устройства. Дополнительные сведения см. в разделах, относящихся к устройству, в комплекте драйверов устройств Windows (WDK).
• Узнайте, какие проверки операционной системы, диспетчер ввода-вывода и все драйверы более высокого уровня выполняются до того, как запросы пользователей достигают вашего драйвера, и какие проверки они не выполняют.
• Используйте средства из WDK, например средство проверки драйверов для тестирования и проверки драйвера.
• Просмотрите общедоступные базы данных известных угроз и уязвимостей программного обеспечения.

Дополнительные ресурсы безопасности драйверов см. в списке контрольных списков безопасности драйверов.

Ресурсы безопасности программного обеспечения

Книги

Написание защищенного кода, второй выпуск Майкл Говард и Дэвид ЛеБланк

24 Смертельных грехов безопасности программного обеспечения: ошибки программирования и как их исправить, Первое издание Майкл Говард, Дэвид Лебланк и Джон Вьега

Искусство оценки безопасности программного обеспечения: выявление и предотвращение уязвимостей программного обеспечения, Марк Доуд, Джон Макдональд и Джастин Шух

Сведения о разработчике оборудования и драйвера Майкрософт

Отмена логики в техническом документе драйверов Windows

Модель безопасности Windows: что должен знать каждый разработчик драйверов

Пакет средств разработки драйверов Microsoft Windows (DDK)

См. Методы программирования драйверов в Архитектуре драйвераKernel-Mode

Средства тестирования

См. комплект лабораторий оборудования Windows в тестовом режиме для обеспечения производительности и совместимости

Общедоступные базы данных известных угроз и уязвимостей программного обеспечения

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

• Распространенные уязвимости и экспозиции (CVE): https://cve.mitre.org/
• Общее перечисление слабых мест: https://cwe.mitre.org/
• Общее перечисление и классификация шаблонов атак: https://capec.mitre.org/index.html
• NIST поддерживает сайт, описывающий каталог уязвимостей: https://samate.nist.gov/BF/

См. также

Контрольный список безопасности водителя