Поделиться через

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Символы схемы потока данных, включая процесс, хранилище данных, поток данных и внешнюю сущность.

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

Пример схемы потока данных для гипотетического драйвера модели драйвера Windows (WDM) в режиме ядра.

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

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

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

  • Запросы на выполнение административных задач для драйвера и его устройства с помощью вызовов процедур 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)

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

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

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

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

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

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

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

  • IRP_MJ_XXX запросов, обрабатываемых драйвером
  • IoCTLs, определяемые или обрабатываемые драйвером
  • ИНТЕРФЕЙСЫ API, вызываемые драйвером
  • Процедуры обратного вызова
  • Любые другие интерфейсы, предоставляемые драйвером
  • Файлы, которые считывает или записывает драйвер, включая файлы, используемые во время установки
  • Разделы реестра, которые драйвер считывает или записывает
  • Страницы свойств конфигурации и любые другие сведения, предоставленные пользователем, которые использует драйвер

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

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

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

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

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

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

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

  • Spoofing
  • Амперирование
  • Epudiation R
  • РаскрытиеI nformation
  • Denial of service
  • Eналожение привилегий

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

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

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

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

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

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

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

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

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

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

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

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

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

Уязвимая точка Потенциальная угроза (STRIDE) Сценарий
запросы IRP_MJ_DEVICE_CONTROL

отказ в обслуживании;

повышение привилегий.

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

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

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

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

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

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

Структура просто перечисляет в иерархическом порядке шаги для атаки на определенную угрозу. Пример:

1.0. Заставить устройство перестать отвечать на запросы.

1.1 Выдача IOCTLS в последовательности сбоя.

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

1.1.2. Получение повышенных привилегий для выдачи внутренних ioCTL.

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

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

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

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

  • Запросы на выполнение административных задач для драйвера и его устройства с помощью вызовов процедур 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
  • Зараженныепользователи
  • Возможностьприкрытия D

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

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

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

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

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

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

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

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

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

Критерий DREAD Оценка Комментарии
Ущерб 8 Временно прерывает работу, но не приводит к постоянному повреждению или потере данных.
Воспроизводимость 10 Каждый раз вызывает сбой устройства.
Эксплойтируемость 7 Для определения последовательности команд требуются целенаправленные усилия.
Затронутые пользователи 10 Влияет на каждую модель этого устройства на рынке.
Возможность обнаружения 10 Предполагается, что будут обнаружены все потенциальные угрозы.
Общая: 9.0 Устранение этой проблемы имеет высокий приоритет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Книги

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

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

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

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

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

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

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

См. статью Методы программирования драйверов в архитектуре драйвера в режиме ядра.

Инструменты тестирования

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

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

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

См. также:

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