Modelado de amenazas para controladores
Los escritores y arquitectos de controladores deben hacer que el modelado de amenazas forme parte integral del proceso de diseño para cualquier controlador. En este tema se proporcionan instrucciones para crear modelos de amenazas para controladores de Windows.
La seguridad debe ser un punto de diseño fundamental para cualquier controlador. Cualquier producto correcto es un destino. Si está escribiendo un controlador para Windows, debe asumir que algún momento, en algún lugar, alguien intentará usar el controlador para poner en peligro la seguridad del sistema.
El diseño de un controlador seguro implica:
- Identificar los puntos en los que el conductor podría ser vulnerable a un ataque.
- Analizar los tipos de ataques que se pueden montar en cada punto de este tipo.
- Asegurarse de que el controlador está diseñado de tal manera como para frustrar tales ataques.
El modelado de amenazas es un enfoque estructurado para estas tareas de diseño importantes. Un modelo de amenazas es una manera de clasificar y analizar las amenazas a un recurso. Desde la perspectiva de un escritor de controladores, los recursos son el hardware, el software y los datos en el equipo o la red.
Un modelo de amenazas responde a las preguntas siguientes:
- ¿Qué recursos necesitan protección?
- ¿A qué amenazas son vulnerables los activos?
- ¿Qué importancia o probabilidad tiene cada amenaza?
- ¿Cómo puede mitigar las amenazas?
El modelado de amenazas es una parte importante del diseño de software, ya que garantiza que la seguridad está integrada en el producto, en lugar de abordarse como una idea posterior. Un buen modelo de amenazas puede ayudar a encontrar y evitar errores durante el proceso de diseño, lo que elimina revisiones potencialmente costosas más adelante y posibles daños de reputación a su organización.
En esta sección se aplican los principios del modelado de amenazas al diseño de controladores y se proporcionan ejemplos de amenazas a las que un controlador podría ser susceptible. Para obtener una descripción más completa del modelado de amenazas para el diseño de software, consulte estos recursos.
Sitio web de Microsoft SDL:
Implementación simplificada del SDL de Microsoft:
En esta entrada de blog se describe cómo descargar una copia gratuita del ciclo de vida de desarrollo de seguridad: SDL, de Michael Howard y Steve Lipner:
Creación de modelos de amenazas para controladores
La creación de un modelo de amenazas requiere un conocimiento exhaustivo del diseño del controlador, los tipos de amenazas a las que se puede exponer el controlador y las consecuencias de un ataque de seguridad que aprovecha una amenaza determinada. Después de crear el modelo de amenazas para un controlador, puede determinar cómo mitigar las posibles amenazas.
El modelado de amenazas es más eficaz cuando se realiza en una forma organizada y estructurada durante el diseño del controlador, en lugar de enfazardly durante la codificación. Un enfoque estructurado aumenta la probabilidad de que detecte vulnerabilidades en el diseño, lo que ayuda a garantizar que el modelo sea completo.
Una manera de organizar un esfuerzo de modelado de amenazas es seguir estos pasos:
- Cree un diagrama estructurado que muestre el flujo de datos a través del controlador. Incluya todas las tareas posibles que realiza el controlador y el origen y el destino de todas las entradas y salidas del controlador. Un diagrama de flujo de datos formal, o un diagrama estructurado similar, puede ayudarle a analizar la ruta de acceso de los datos a través del controlador e identificar las interfaces externas, los límites y las interacciones del controlador.
- Analice las posibles amenazas de seguridad, en función del diagrama de flujo de datos.
- Evalúe las amenazas que identificó en el paso anterior y determine cómo mitigarlas.
Creación de un diagrama de flujo de datos
Un diagrama de flujo de datos muestra en forma conceptual el flujo de datos entre el controlador y las entidades externas con las que interactúa, normalmente el sistema operativo, un proceso de usuario y el dispositivo. Un diagrama de flujo de datos formal usa los símbolos siguientes:
En la ilustración siguiente se muestra un diagrama de flujo de datos de ejemplo para un controlador hipotético del modelo de controlador de Windows (WDM) en modo kernel. Independientemente de la arquitectura de su tipo determinado de controlador, el modelo conceptual es el mismo: mostrar todas las rutas de acceso de datos e identificar cada origen de datos que entra o sale del controlador.
Nota En la ilustración anterior se muestran los datos que fluyen directamente entre un proceso de usuario y el controlador y se omiten los controladores intermedios. Sin embargo, en realidad, todas las solicitudes pasan por el administrador de E/S y pueden atravesar uno o varios controladores de nivel superior antes de llegar a un controlador determinado. La ilustración omite estos pasos intermedios para resaltar la importancia del origen original de los datos y el contexto del subproceso que proporcionó los datos. Los controladores en modo kernel deben validar los datos que se originan en modo de usuario.
La información entra en el controlador debido a las solicitudes del sistema operativo, las solicitudes de un proceso de usuario o las solicitudes (normalmente interrumpe) desde el dispositivo.
El controlador de la ilustración anterior recibe datos del sistema operativo en varios tipos de solicitudes:
- Solicitudes para realizar tareas administrativas para el controlador y su dispositivo, a través de llamadas a las rutinas DriverEntry, DriverUnload y AddDevice
- solicitudes de Plug and Play (IRP_MJ_PNP)
- Solicitudes de administración de energía (IRP_MJ_POWER)
- Solicitudes de control de E/S de dispositivo interno (IRP_MJ_INTERNAL_DEVICE_CONTROL)
En respuesta a estas solicitudes, los datos fluyen del controlador de nuevo al sistema operativo como información de estado. El controlador de la ilustración recibe datos de un proceso de usuario en los siguientes tipos de solicitudes:
- Crear, leer y escribir solicitudes (IRP_MJ_CREATE, IRP_MJ_READ o IRP_MJ_WRITE)
- Solicitudes de control de E/S de dispositivo público (IRP_MJ_DEVICE_ CONTROL)
En respuesta a estas solicitudes, los datos de salida y la información de estado fluyen del controlador de nuevo al proceso de usuario.
Por último, el controlador recibe datos del dispositivo debido a operaciones de E/S del dispositivo o acciones de usuario (como abrir la bandeja en una unidad de CD) que cambian el estado del dispositivo. Del mismo modo, los datos del controlador fluyen al dispositivo durante las operaciones de E/S y cambian en el estado del dispositivo.
En la ilustración anterior se muestra el flujo de datos del controlador en un nivel conceptual amplio. Cada círculo representa una tarea relativamente grande y carece de detalles. En algunos casos, un diagrama de un solo nivel, como el ejemplo, es adecuado para comprender los orígenes de datos y las rutas de acceso. Si el controlador controla muchos tipos diferentes de solicitudes de E/S de distintos orígenes, es posible que tenga que crear uno o varios diagramas adicionales que muestren más detalles. Por ejemplo, el círculo con la etiqueta "Controlar solicitudes de E/S" podría expandirse en un diagrama independiente, similar a la ilustración siguiente.
En el segundo diagrama se muestran tareas independientes para cada tipo de solicitud de E/S en el primer diagrama. (Por motivos de simplicidad, se han omitido las rutas de acceso de datos al dispositivo).
Las entidades externas y los tipos de entrada y salida que se muestran en el diagrama pueden variar, en función del tipo de dispositivo. Por ejemplo, Windows proporciona controladores de clase para muchos tipos de dispositivos comunes. Un controlador de clase proporcionado por el sistema funciona con un minidriver proporcionado por el proveedor, que normalmente es una biblioteca de vínculos dinámicos (DLL) que contiene un conjunto de rutinas de devolución de llamada. Las solicitudes de E/S de usuario se dirigen al controlador de clase, que a continuación llama a las rutinas del minidriver para realizar tareas específicas. Normalmente, el minidriver no recibe todo el paquete de solicitud de E/S como entrada; en su lugar, cada rutina de devolución de llamada recibe solo los datos necesarios para su tarea específica.
Al crear los diagramas de flujo de datos, recuerde la variedad de orígenes para las solicitudes de controladores. Cualquier código que se ejecute en el equipo de un usuario podría generar una solicitud de E/S a un controlador, desde aplicaciones conocidas como Microsoft Office para freeware, shareware y descargas web de origen potencialmente dudoso. En función de su dispositivo específico, es posible que también tenga que tener en cuenta códecs multimedia o filtros de terceros que su empresa distribuye para admitir su dispositivo. Entre los posibles orígenes de datos, se incluyen los siguientes:
- IRP_MJ_XXX solicitudes que controla el controlador
- ICTLs que el controlador define o controla
- API a las que llama el controlador
- Rutinas de devolución de llamada
- Cualquier otra interfaz que el controlador exponga
- Archivos que el controlador lee o escribe, incluidos los usados durante la instalación
- Claves del Registro que el controlador lee o escribe
- Páginas de propiedades de configuración y cualquier otra información proporcionada por el usuario que consume el controlador
El modelo también debe cubrir los procedimientos de instalación y actualización del controlador. Incluya todos los archivos, directorios y entradas del Registro que se leen o escriben durante la instalación del controlador. Tenga en cuenta también las interfaces expuestas en instaladores de dispositivos, co-instaladores y páginas de propiedades.
Cualquier punto en el que el controlador intercambia datos con una entidad externa es potencialmente vulnerable al ataque.
Análisis de posibles amenazas
Después de identificar los puntos en los que un controlador podría ser vulnerable, puede determinar qué tipos de amenazas podrían producirse en cada punto. Tenga en cuenta los siguientes tipos de preguntas:
- ¿Qué mecanismos de seguridad se aplican para proteger cada recurso?
- ¿Todas las transiciones e interfaces están protegidas correctamente?
- ¿Podría un uso incorrecto de una característica poner en peligro involuntariamente la seguridad?
- ¿Podría usarse malintencionado una característica en peligro la seguridad?
- ¿La configuración predeterminada proporciona una seguridad adecuada?
El enfoque STRIDE para la categorización de amenazas
El acrónimo STRIDE describe seis categorías de amenazas para el software. Este acrónimo se deriva de:
- Suplantación deidentidad
- Amperamiento de T
- Repudiation
- Divulgación denformation
- Denial of service (D enial of service)
- Elevaciónde privilegios
Con STRIDE como guía, puede plantear preguntas detalladas sobre los tipos de ataques que podrían dirigirse a un conductor. El objetivo es determinar los tipos de ataques que podrían ser posibles en cada punto vulnerable del controlador y, a continuación, crear un escenario para cada posible ataque.
La suplantación de identidad usa las credenciales de otra persona para obtener acceso a recursos inaccesibles de otro modo. Un proceso monta un ataque de suplantación de identidad pasando credenciales falsificadas o robadas.
La manipulación está cambiando los datos para montar un ataque. Por ejemplo, un controlador podría ser susceptible a alteraciones si los archivos de controlador necesarios no están adecuadamente protegidos por la firma de controladores y las listas de control de acceso (ACL). En esta situación, un usuario malintencionado podría modificar los archivos, lo que vulnera la seguridad del sistema.
El rechazo se produce cuando un usuario deniega la realización de una acción, pero el destino de la acción no tiene ninguna manera de demostrar lo contrario. Un controlador podría ser susceptible a una amenaza de rechazo si no registra acciones que podrían poner en peligro la seguridad. Por ejemplo, un controlador para un dispositivo de vídeo podría ser susceptible a rechazo si no registra solicitudes para cambiar las características de su dispositivo, como el foco, el área escaneada, la frecuencia de captura de imágenes, la ubicación de destino de las imágenes capturadas, etc. Las imágenes resultantes podrían estar dañadas, pero los administradores del sistema no tendría ninguna manera de determinar qué usuario causó el problema.
Las amenazas de divulgación de información son exactamente como el nombre implica: la divulgación de información a un usuario que no tiene permiso para verlo. Cualquier controlador que pase información a o desde un búfer de usuario es susceptible a amenazas de divulgación de información. Para evitar amenazas de divulgación de información, los controladores deben validar la longitud de cada búfer de usuario y inicializar los búferes sin inicializarlos antes de escribir datos.
Los ataques por denegación de servicio amenazan la capacidad de los usuarios válidos para acceder a los recursos. Los recursos pueden ser espacio en disco, conexiones de red o un dispositivo físico. Los ataques que ralentizan el rendimiento en niveles inaceptables también se consideran ataques de denegación de servicio. Un controlador que permite a un proceso de usuario monopolizar innecesariamente un recurso del sistema podría ser susceptible a un ataque por denegación de servicio si el consumo de recursos dificulta la capacidad de otros usuarios válidos para realizar sus tareas.
Por ejemplo, un controlador podría usar un semáforo para proteger una estructura de datos mientras se ejecuta en IRQL = PASSIVE_LEVEL. Sin embargo, el controlador debe adquirir y liberar el semáforo dentro de un par KeEnterCriticalRegion/KeLeaveCriticalRegion , que deshabilita y vuelve a habilitar la entrega de llamadas a procedimientos asincrónicos (APCs). Si el controlador no puede usar estas rutinas, un APC podría hacer que el sistema operativo suspenda el subproceso que contiene el semáforo. Como resultado, otros procesos (incluidos los creados por un administrador) no podrían obtener acceso a la estructura.
Un ataque de elevación de privilegios puede producirse si un usuario sin privilegios obtiene el estado con privilegios. Un controlador en modo kernel que pasa un identificador de modo de usuario a una rutina ZwXxx es vulnerable a ataques de elevación de privilegios porque las rutinas ZwXxx omiten las comprobaciones de seguridad. Los controladores en modo kernel deben validar todos los identificadores que reciben de los autores de llamadas en modo de usuario.
Los ataques de elevación de privilegios también pueden producirse si un controlador en modo kernel se basa en el valor RequestorMode del encabezado IRP para determinar si una solicitud de E/S procede de un llamador en modo kernel o en modo de usuario. En IRP que llegan desde la red o el servicio server (SRVSVC), el valor de RequestorMode es KernelMode, independientemente del origen de la solicitud. Para evitar estos ataques, los controladores deben realizar comprobaciones de control de acceso para dichas solicitudes en lugar de simplemente usar el valor de RequestorMode.
Técnicas de análisis de controladores
Una manera sencilla de organizar el análisis es enumerar las áreas vulnerables junto con las posibles amenazas y uno o varios escenarios para cada tipo de amenaza.
Para realizar un análisis exhaustivo, debe explorar la posibilidad de amenazas en cada punto potencialmente vulnerable del controlador. En cada punto vulnerable, determine cada categoría de amenaza (suplantación de identidad, manipulación, rechazo, divulgación de información, denegación de servicio y elevación de privilegios) que podría ser posible. A continuación, cree uno o varios escenarios de ataque para cada amenaza viable.
Por ejemplo, considere el flujo de datos para las solicitudes de IRP_MJ_DEVICE_CONTROL como se muestra en la ilustración anterior. En la tabla siguiente se muestran dos tipos de amenazas que un controlador podría encontrar al procesar estas solicitudes:
| Punto vulnerable | Amenaza potencial (STRIDE) | Escenario |
|---|---|---|
| solicitudes de IRP_MJ_DEVICE_CONTROL | Denegación de servicio Elevación de privilegios |
El proceso de usuario emite una secuencia de ICTLs que hace que se produzca un error en el dispositivo. El proceso de usuario emite un IOCTL que permite FILE_ANY_ACCESS. |
Los árboles de amenazas y los esquemas pueden ser útiles para modelar estos escenarios complejos.
Un árbol de amenazas es un diagrama que muestra una jerarquía de amenazas o vulnerabilidades; en esencia, un árbol de amenazas imita los pasos del usuario malintencionado para montar un ataque. El objetivo final del ataque es en la parte superior del árbol. Cada nivel subordinado muestra los pasos necesarios para llevar a cabo el ataque. La ilustración siguiente es un árbol de amenazas simple para el escenario de denegación de servicio en el ejemplo anterior.
El árbol de amenazas muestra los pasos necesarios para montar un ataque determinado y las relaciones entre los pasos. Un esquema es una alternativa a un árbol de amenazas.
Un esquema simplemente muestra en orden jerárquico los pasos para atacar una amenaza determinada. Por ejemplo:
1.0 Hace que el dispositivo deje de responder.
1.1 Problema IOCTLS en secuencia de error.
1.1.1 Determine la secuencia que hace que se produzca un error en el dispositivo.
1.1.2 Obtenga privilegios elevados para emitir IOPS internos.
Cualquiera de las técnicas puede ayudarle a comprender qué amenazas son más peligrosas y qué vulnerabilidades del diseño son más críticas.
Modelado rápido de amenazas de ruta de acceso rápido
Si los recursos son limitados, en lugar de crear un diagrama completo del modelo de amenazas, se puede crear un esquema de resumen para ayudar a evaluar los riesgos de seguridad para el controlador. Por ejemplo, en el texto siguiente se describen algunas de las áreas expuestas en el controlador de ejemplo descrito en el ejemplo anterior.
El controlador recibe datos del sistema operativo en varios tipos de solicitudes:
- Solicitudes para realizar tareas administrativas para el controlador y su dispositivo, a través de llamadas a las rutinas DriverEntry, DriverUnload y AddDevice
- solicitudes de Plug and Play (IRP_MJ_PNP)
- Solicitudes de administración de energía (IRP_MJ_POWER)
- Solicitudes de control de E/S de dispositivo interno (IRP_MJ_INTERNAL_DEVICE_CONTROL)
En respuesta a estas solicitudes, los datos fluyen del controlador de nuevo al sistema operativo como información de estado. El controlador recibe datos de un proceso de usuario en los siguientes tipos de solicitudes:
- Crear, leer y escribir solicitudes (IRP_MJ_CREATE, IRP_MJ_READ o IRP_MJ_WRITE)
- Solicitudes de control de E/S de dispositivo público (IRP_MJ_DEVICE_ CONTROL)
En respuesta a estas solicitudes, los datos de salida y la información de estado fluyen del controlador de nuevo al proceso de usuario.
Con este conocimiento básico del flujo de datos al controlador, puede examinar cada área de entrada y salida para detectar posibles amenazas.
El enfoque DREAD para la evaluación de amenazas
Determinar cómo y dónde podría ser atacado un controlador no es suficiente. A continuación, debe evaluar estas posibles amenazas, determinar sus prioridades relativas y diseñar una estrategia de mitigación.
DREAD es un acrónimo que describe cinco criterios para evaluar las amenazas en el software. DREAD significa:
- Damage
- Eproducibilidad de R
- Exploitability
- Usuariosinfectados
- Discoverability
Para priorizar las amenazas al controlador, clasifique cada amenaza de 1 a 10 en los 5 de los criterios de evaluación DE TERROR y, a continuación, agregue las puntuaciones y divida en 5 (el número de criterios). El resultado es una puntuación numérica entre 1 y 10 para cada amenaza. Las puntuaciones altas indican amenazas graves.
Daño. Evaluar el daño que podría resultar de un ataque de seguridad es obviamente una parte fundamental del modelado de amenazas. Los daños pueden incluir pérdida de datos, errores de hardware o multimedia, rendimiento estándar o cualquier medida similar que se aplique al dispositivo y a su entorno operativo.
La reproducibilidad es una medida de la frecuencia con la que un tipo de ataque especificado se realizará correctamente. Es más probable que se aproveche una amenaza reproducible fácilmente que una vulnerabilidad que se produce rara vez o imprevisible. Por ejemplo, las amenazas a las características instaladas de forma predeterminada o que se usan en cada ruta de acceso de código potencial son altamente reproducibles.
La vulnerabilidad de seguridad evalúa el esfuerzo y la experiencia necesarios para montar un ataque. Una amenaza que puede ser atacado por un estudiante universitario relativamente inexperto es altamente explotable. Un ataque que requiere personal altamente cualificado y es costoso de llevar a cabo es menos explotable.
Para evaluar la vulnerabilidad de seguridad, considere también el número de posibles atacantes. Una amenaza que puede ser aprovechada por cualquier usuario remoto y anónimo es más aprovechable que uno que requiere un usuario local y altamente autorizado.
Usuarios afectados. El número de usuarios que podrían verse afectados por un ataque es otro factor importante para evaluar una amenaza. Un ataque que podría afectar a la mayoría de uno o dos usuarios valoraría relativamente bajo en esta medida. Por el contrario, un ataque por denegación de servicio que bloquea un servidor de red podría afectar a miles de usuarios y, por lo tanto, podría valorar mucho más.
La detectabilidad es la probabilidad de que se aproveche una amenaza. La detectabilidad es difícil de calcular con precisión. El enfoque más seguro consiste en suponer que cualquier vulnerabilidad se aprovechará finalmente y, por consiguiente, confiar en las demás medidas para establecer la clasificación relativa de la amenaza.
Ejemplo: Evaluación de amenazas mediante DREAD
Siguiendo con el ejemplo descrito anteriormente, en la tabla siguiente se muestra cómo un diseñador podría evaluar el ataque hipotético de denegación de servicio:
| Criterio DE TERROR | Puntuación | Comentarios |
|---|---|---|
| Daños | 8 | Interrumpe el trabajo temporalmente, pero no provoca daños permanentes ni pérdida de datos. |
| Posibilidad de reproducir la amenaza | 10 | Hace que el dispositivo produzca un error cada vez. |
| Posibilidad de que se aproveche | 7 | Requiere un esfuerzo centrado para determinar la secuencia de comandos. |
| Usuarios afectados | 10 | Afecta a todos los modelos de este dispositivo en el mercado. |
| Detectabilidad | 10 | Supone que se detectarán todas las posibles amenazas. |
| Total: | 9.0 | La mitigación de este problema es de alta prioridad. |
Mitigación de amenazas
El diseño del controlador debe mitigar todas las amenazas que expone el modelo. Sin embargo, en algunos casos, es posible que la mitigación no sea práctica. Por ejemplo, considere un ataque que potencialmente afecta a muy pocos usuarios y es poco probable que produzca la pérdida de datos o facilidad de uso del sistema. Si la mitigación de esta amenaza requiere varios meses de esfuerzo adicional, puede optar por dedicar razonablemente tiempo adicional a probar el controlador en su lugar. Sin embargo, recuerde que es probable que un usuario malintencionado encuentre la vulnerabilidad y monte un ataque y, a continuación, el controlador requerirá una revisión para el problema.
Incluir el modelado de amenazas en un proceso más amplio del ciclo de vida de desarrollo de seguridad
Considere la posibilidad de incluir el proceso de modelado de amenazas en un ciclo de vida de desarrollo seguro más amplio: SDL.
El proceso de SDL de Microsoft proporciona una serie de procesos de desarrollo de software recomendados que se pueden modificar para ajustarse a cualquier tamaño de organización, incluido un único desarrollador. Considere la posibilidad de agregar componentes de las recomendaciones de SDL al proceso de desarrollo de software.
Para obtener más información, consulte Ciclo de vida de desarrollo de seguridad de Microsoft (SDL): guía de proceso.
Entrenamiento y funcionalidades organizativas : persigue el entrenamiento de seguridad de desarrollo de software para ampliar la capacidad de reconocer y corregir las vulnerabilidades de software.
Microsoft hace que sus cuatro clases básicas de aprendizaje de SDL estén disponibles para su descarga. Clases de aprendizaje básico del ciclo de vida de desarrollo de seguridad de Microsoft
Para obtener información más detallada sobre el entrenamiento de SDL, consulte este documento técnico. Entrenamiento de seguridad de software esencial para el SDL de Microsoft
Requisitos y diseño : la mejor oportunidad para crear software de confianza es durante las fases de planeamiento iniciales de una nueva versión o una nueva versión, ya que los equipos de desarrollo pueden identificar objetos clave e integrar la seguridad y la privacidad, lo que minimiza la interrupción de los planes y las programaciones.
Una salida clave en esta fase es establecer objetivos de seguridad específicos. Por ejemplo, decidir que todo el código debe pasar el análisis de código de Visual Studio "Todas las reglas" con cero advertencias.
Implementación: todos los equipos de desarrollo deben definir y publicar una lista de herramientas aprobadas y sus comprobaciones de seguridad asociadas, como las opciones y advertencias del compilador o vinculador.
Para un desarrollador de controladores, la mayor parte del trabajo útil se realiza en esta fase. A medida que se escribe código, se revisa para detectar posibles puntos débiles. Las herramientas como el análisis de código y el comprobador de controladores se usan para buscar áreas en el código que se pueden proteger.
Comprobación : la verificación es el punto en el que el software está funcionalmente completo y se prueba con los objetivos de seguridad descritos en los requisitos y la fase de diseño.
Se pueden usar herramientas adicionales como binscope y fuzz testers para validar que se han cumplido los objetivos de diseño de seguridad y que el código está listo para enviarse.
Versión y respuesta : como preparación para publicar un producto, es conveniente crear un plan de respuesta a incidentes que describa lo que hará para responder a nuevas amenazas y cómo atenderá al controlador después de que se haya enviado. Realizar este trabajo con antelación significará que podrá responder más rápido si se identifican problemas de seguridad en el código que se ha enviado.
Para obtener más información sobre el proceso de SDL, consulte estos recursos adicionales:
Este es el sitio principal de Microsoft SDL y proporciona información general sobre SDL. https://www.microsoft.com/sdl
En este blog se describe cómo descargar una copia gratuita de The Security Development Lifecycle: SDL, de Michael Howard y Steve Lipner. https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/
En esta página se proporcionan vínculos a publicaciones de SDL adicionales. https://www.microsoft.com/SDL/Resources/publications.aspx
Llamada a la acción
Para desarrolladores de controladores:
- Hacer que el modelado de amenazas forme parte del diseño del controlador.
- Siga los pasos para mitigar eficazmente las amenazas en el código del controlador.
- Familiarícese con los problemas de seguridad y confiabilidad que se aplican al tipo de controlador y dispositivo. Para obtener más información, consulte las secciones específicas del dispositivo del Kit de controladores de dispositivos Windows (WDK).
- Comprenda qué comprobaciones realizan el sistema operativo, el administrador de E/S y los controladores de nivel superior antes de que las solicitudes de usuario lleguen al controlador y qué comprobaciones no realizan.
- Use herramientas del WDK, como el comprobador de controladores para probar y comprobar el controlador.
- Revise las bases de datos públicas de amenazas conocidas y vulnerabilidades de software.
Para obtener más recursos de seguridad de controladores, consulte Lista de comprobación de seguridad del controlador.
Recursos de seguridad de software
Libros
Escribir código seguro, segunda edición de Michael Howard y David LeBlanc
24 Pecados mortales de seguridad de software: Errores de programación y Cómo corregirlos, Primera edición de Michael Howard, David LeBlanc y John Viega
El arte de la evaluación de seguridad de software: identificación y prevención de vulnerabilidades de software, por Mark Dowd, John McDonald y Justin Schuh
Información para desarrolladores de hardware y controladores de Microsoft
Notas del producto Cancelar lógica en controladores de Windows
Modelo de seguridad de Windows: qué necesita saber cada escritor de controladores
Kit de desarrollo de controladores de Microsoft Windows (DDK)
Consulte Técnicas de programación de controladores en la arquitectura del controlador en modo kernel.
Herramientas de prueba
Consulte Kit de laboratorio de hardware de Windows en Prueba para obtener rendimiento y compatibilidad.
Bases de datos públicas de amenazas conocidas y vulnerabilidades de software
Para ampliar sus conocimientos sobre amenazas de software, revise las bases de datos públicas disponibles de amenazas conocidas y vulnerabilidades de software.
- Vulnerabilidades y exposiciones comunes (CVE): https://cve.mitre.org/
- Enumeración de puntos débiles comunes: https://cwe.mitre.org/
- Enumeración y clasificación de patrones de ataque comunes: https://capec.mitre.org/index.html
- NIST mantiene un sitio que describe cómo se catalogan las vulnerabilidades: https://samate.nist.gov/BF/
Consulte también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de