Microsoft SDL

Práctica # 1 - Proveer entrenamiento

La seguridad es trabajo de todos. Los desarrolladores, ingenieros de servicio y administradores de programas y
productos deben comprender los conceptos básicos de seguridad y saber cómo integrar la seguridad en el
software y los servicios para hacer que los productos sean más seguros al mismo tiempo que satisfacen las
necesidades comerciales y brindan valor al usuario.

La capacitación efectiva complementará y reforzará las políticas de seguridad, las prácticas de SDL, los
estándares y los requisitos de seguridad del software, y se guiará por los conocimientos derivados de los datos o
las nuevas capacidades técnicas disponibles.

Si bien la seguridad es tarea de todos, es importante recordar que no todos deben ser expertos en seguridad ni
esforzarse para convertirse en un probador de penetración competente. Sin embargo, asegurarse de que todos
entiendan la perspectiva del atacante, sus objetivos y el arte de lo posible ayudará a captar la atención de todos
y elevar la barra de conocimiento colectiva.

Práctica # 2 - Definir los requisitos de seguridad

La necesidad de considerar la seguridad y la privacidad es un aspecto fundamental del desarrollo de aplicaciones
y sistemas altamente seguros y, independientemente de la metodología de desarrollo utilizada, los requisitos de
seguridad deben actualizarse continuamente para reflejar los cambios en la funcionalidad requerida y los
cambios en el panorama de amenazas. Obviamente, el momento óptimo para definir los requisitos de seguridad
es durante las etapas iniciales de diseño y planificación, ya que esto permite que los equipos de desarrollo
integren la seguridad de manera que minimice las interrupciones. Los factores que influyen en los requisitos de
seguridad incluyen (pero no se limitan a) los requisitos legales y de la industria, los estándares internos y las
prácticas de codificación, la revisión de incidentes anteriores y las amenazas conocidas. Estos requisitos deben
ser rastreados a través de un sistema de seguimiento de trabajo o mediante telemetría derivada de la tubería de
ingeniería.

Enlaces utiles :
DevOps Azure / Azure Boards

Práctica # 3 - Definir informes de métricas y cumplimiento

Es esencial definir los niveles mínimos aceptables de calidad de seguridad y hacer que los equipos de ingeniería
sean responsables de cumplir con esos criterios. La definición de estos principios ayuda al equipo a comprender
los riesgos asociados con los problemas de seguridad, identificar y corregir los defectos de seguridad durante el
desarrollo y aplicar los estándares en todo el proyecto. Establecer una barra de errores significativa implica
definir claramente los umbrales de severidad de las vulnerabilidades de seguridad (por ejemplo, todas las
vulnerabilidades conocidas descubiertas con una clasificación de severidad "crítica" o "importante" se deben
corregir con un marco de tiempo específico) y nunca se debe relajar una vez que se haya establecido .

Para realizar un seguimiento de los indicadores clave de rendimiento (KPI) y garantizar que se completen las
tareas de seguridad, el seguimiento de errores y / o los mecanismos de seguimiento de trabajo utilizados por
una organización (como Azure DevOps) deben permitir que los defectos de seguridad y los elementos de trabajo
de seguridad se etiqueten claramente como Seguridad y marcado con su severidad de seguridad adecuada. Esto
permite un seguimiento preciso y el informe del trabajo de seguridad.
Enlaces utiles :
SDL Privacy Bug Bar muestra
Agregar o modificar un campo para rastrear los requisitos de datos en los Devops de Azure
Agregue una barra de errores de seguridad a Microsoft Team Foundation Server 2010 (recurso heredado)
Muestra de la barra de errores de seguridad de SDL

Práctica # 4 - Realizar modelado de amenazas

El modelado de amenazas se debe utilizar en entornos donde exista un riesgo de seguridad significativo. El
modelado de amenazas se puede aplicar a nivel de componente, aplicación o sistema. Es una práctica que
permite a los equipos de desarrollo considerar, documentar y (lo que es más importante) discutir las
implicaciones de seguridad de los diseños en el contexto de su entorno operativo planificado y de manera
estructurada.

La aplicación de un enfoque estructurado a los escenarios de amenazas ayuda a un equipo a identificar las
vulnerabilidades de seguridad de manera más efectiva y económica, a determinar los riesgos de esas amenazas
y luego a hacer selecciones de funciones de seguridad y establecer las mitigaciones adecuadas.

Enlaces utiles :
Modelado de amenazas

Práctica # 5 - Establecer requisitos de diseño

El SDL se suele considerar como una actividad de garantía que ayuda a los ingenieros a implementar
"características seguras", en el sentido de que las características están bien diseñadas con respecto a la
seguridad. Para lograr esto, los ingenieros normalmente confiarán en las características de seguridad, como la
criptografía, la autenticación, el registro y otros. En muchos casos, la selección o implementación de las
funciones de seguridad ha demostrado ser tan complicada que las opciones de diseño o implementación pueden
generar vulnerabilidades. Por lo tanto, es de vital importancia que estos se apliquen de manera coherente y con
una comprensión consistente de la protección que brindan.

Práctica # 6 - Definir y utilizar estándares de criptografía

Con el aumento de la computación móvil y en la nube, es de vital importancia garantizar que todos los datos,
incluidos los datos de seguridad y de gestión y control, estén protegidos contra la divulgación o alteración
involuntarias cuando se transmiten o almacenan. El cifrado se utiliza normalmente para lograr esto. Hacer una
elección incorrecta en el uso de cualquier aspecto de la criptografía puede ser catastrófico, y es mejor
desarrollar estándares de cifrado claros que proporcionen detalles sobre cada elemento de la implementación
del cifrado. Esto debe dejarse a los expertos. Una buena regla general es usar solo bibliotecas de cifrado
revisadas por la industria y asegurarse de que se implementen de una manera que les permita ser reemplazadas
fácilmente si es necesario.

Enlaces utiles :
Recomendaciones criptográficas de Microsoft SDL

Práctica # 7 - Administrar el riesgo de seguridad del uso de componentes de terceros

Hoy en día, la gran mayoría de los proyectos de software se crean utilizando componentes de terceros (tanto
comerciales como de código abierto). Al seleccionar componentes de terceros para usar, es importante
comprender el impacto que una vulnerabilidad de seguridad en ellos podría tener para la seguridad del sistema
más grande en el que están integrados. Tener un inventario preciso de componentes de terceros y un plan para
responder cuando se descubran nuevas vulnerabilidades contribuirá en gran medida a mitigar este riesgo, pero
se debe considerar una validación adicional, dependiendo del apetito de riesgo de su organización, el tipo de
componente utilizado y Impacto potencial de una vulnerabilidad de seguridad. Obtenga más información sobre
la administración de los riesgos de seguridad del uso de componentes de terceros, como el software de código
abierto.

Enlaces utiles :
La gestión de riesgos de seguridad inherente al uso de componentes de terceros
Gestión de riesgos de seguridad inherentes al uso de software de código abierto

Práctica # 8 - Usar herramientas aprobadas

Defina y publique una lista de herramientas aprobadas y sus comprobaciones de seguridad asociadas, como las
opciones y advertencias del compilador / vinculador. Los ingenieros deben esforzarse por usar la última versión
de las herramientas aprobadas, como las versiones del compilador, y aprovechar las nuevas funcionalidades y
protecciones de análisis de seguridad.

Enlaces utiles :
Herramientas, compiladores y opciones recomendadas para x86, x64 y ARM (herramientas heredadas)
Herramientas SDL

Práctica # 9 - Realizar pruebas de seguridad de análisis estático (SAST)

El análisis del código fuente antes de la compilación proporciona un método altamente escalable de revisión del
código de seguridad y ayuda a garantizar que se sigan las políticas de codificación seguras. SAST generalmente
se integra en la canalización de confirmación para identificar vulnerabilidades cada vez que se compila o
empaqueta el software. Sin embargo, algunas ofertas se integran en el entorno del desarrollador para detectar
ciertas fallas, como la existencia de funciones inseguras u otras prohibidas, y reemplazar aquellas con
alternativas más seguras, ya que el desarrollador está codificando activamente. No hay una solución única para
todos, y los equipos de desarrollo deben decidir la frecuencia óptima para realizar SAST y, tal vez, implementar
múltiples tácticas para equilibrar la productividad con una cobertura de seguridad adecuada.

Enlaces utiles :
Microsoft DevSkim
Reglas de Roslyn
Mercado de seguridad VSTS
Análisis de código para C / C ++
BinSkim
FxCop (herramienta heredada)
Lista de herramientas para el análisis de código estático (Wikipedia)

Práctica # 10 - Realizar pruebas de seguridad de análisis dinámico (DAST)

La verificación en tiempo de ejecución de su software completamente compilado o empaquetado comprueba la
funcionalidad que solo es evidente cuando todos los componentes están integrados y en ejecución. Esto se logra
normalmente utilizando una herramienta o conjunto de ataques precompilados o herramientas que monitorean
específicamente el comportamiento de la aplicación para detectar daños en la memoria, problemas de
privilegios de usuario y otros problemas críticos de seguridad. Al igual que SAST, no existe una solución única
para todos, y si bien algunas herramientas, como las herramientas de escaneo de aplicaciones web, pueden
integrarse más fácilmente en el proceso de integración continua / entrega continua, otras pruebas DAST, como
fuzzing, requieren una solución diferente. enfoque.

Enlaces utiles :
Mercado de seguridad VSTS
Pruebas automatizadas de penetración con difusor de caja blanca
Práctica # 11 - Realizar pruebas de penetración
Las pruebas de penetración son un análisis de seguridad de un sistema de software realizado por profesionales
de seguridad capacitados que simulan las acciones de un pirata informático. El objetivo de una prueba de
penetración es descubrir posibles vulnerabilidades resultantes de errores de codificación, fallas en la
configuración del sistema u otras debilidades de implementación operativa, y como tal, la prueba generalmente
encuentra la variedad más amplia de vulnerabilidades. Las pruebas de penetración a menudo se realizan junto
con revisiones de código manuales y automatizadas para proporcionar un mayor nivel de análisis de lo que
normalmente sería posible.

Enlaces utiles :
Analizador de superficie de ataque
Muestra de la barra de errores de seguridad de SDL

Práctica # 12 - Establecer un proceso estándar de respuesta a incidentes

La preparación de un plan de respuesta a incidentes es crucial para ayudar a enfrentar nuevas amenazas que
pueden surgir con el tiempo. Debe crearse en coordinación con el Equipo de respuesta a incidentes de seguridad
del producto (PSIRT) dedicado de su organización. El plan debe incluir a quién contactar en caso de una
emergencia de seguridad y establecer el protocolo para el servicio de seguridad, incluidos los planes para el
código heredado de otros grupos dentro de la organización y para el código de terceros. ¡El plan de respuesta a
incidentes se debe probar antes de que sea necesario!

Enlaces utiles :
Guía de referencia de respuesta a incidentes de Microsoft
Uso del Centro de seguridad de Azure para una respuesta a un incidente
Gestión de incidentes de seguridad de Office 365
Respuesta a incidentes de Microsoft y responsabilidad compartida por la computación en la nube
Centro de respuesta de seguridad de Microsoft

Garantía de seguridad operacional (OSA)

La seguridad operacional efectiva abarca muchos dominios, incluida la seguridad física, los controles de
personal, la gestión de activos y otros, que están documentados en numerosos estándares y marcos. OSA
describe las prácticas de ingeniería de seguridad que deben adoptar las organizaciones y es un marco utilizado
para mejorar los aspectos básicos de la seguridad operativa de los servicios en línea.

Seguridad Operacional A diferencia de la Seguridad Física ("Security" en inglés), la Seguridad Operacional o

"Safety" engloba los procesos y sistemas destinados a reducir el número de accidentes e incidentes derivados de
la operación.
La Seguridad Operacional aérea se basa en tres pilares fundamentales:
 La definición de niveles de seguridad aceptables, así como de indicadores de los mismos que permitan
detectar una desviación que llevase a la degradación o pérdida de dichos niveles.
 La notificación, investigación y análisis de incidencias de seguridad, así como la posterior difusión de las
lecciones derivadas de dichas incidencias, con el fin de aprender de errores pasados, aplicando las
medidas preventivas o correctivas adecuadas para que no vuelvan a producirse. Esta parte tiene un
carácter básicamente reactivo, es decir, se buscan soluciones a partir de lo que ya ha sucedido.
 La detección, evaluación y mitigación de riesgos, encaminada a la localización precoz de las posibles
amenazas sobre el Sistema de Navegación Aérea, y la aplicación de barreras y medidas mitigadoras
sobre el sistema con el fin de que el nivel de riesgo sea tolerable.

Así, la Seguridad Operacional debe ser básicamente proactiva y, más aún, predictiva, con el fin de identificar y
prevenir, con la suficiente antelación, y a partir de incidentes menores, las posibles amenazas sobre el sistema
para evitarlas o, en caso de ocurrir, mitigar sus efectos de forma que sean lo menos severos posibles.
Es importante no confundir la Seguridad Operacional (Safety) con la Seguridad Física (Security). Mientras la
primera trata de identificar y minimizar el riesgo de ocurrencia de accidentes e incidentes graves (prevención), la
segunda se centra en vigilar posibles incidentes derivados, no de la operación, sino de ataques producidos
intencionadamente por humanos contra bienes, infraestructuras y personas, como pueden ser actos de
terrorismo, secuestros o a actos de interferencia ilícitos, etc (protección).

Práctica # 1 - Proveer entrenamiento

La seguridad es trabajo de todos. Asegurarse de que todos entiendan la perspectiva del atacante, sus
objetivos y el arte de lo posible ayudará a captar la atención de todos y elevar la barra de conocimiento
colectiva. Los desarrolladores, los ingenieros de servicio y los gerentes de productos deben comprender
los conceptos básicos de seguridad y saber cómo incorporar la seguridad en el software y los servicios
para hacer que los productos sean más seguros al mismo tiempo que satisfacen las necesidades
comerciales y brindan valor al usuario.

La capacitación efectiva complementará y reforzará las políticas de seguridad, las prácticas de OSA, los
estándares y los requisitos de seguridad, y se guiará por los conocimientos derivados de los datos o las
nuevas capacidades técnicas disponibles.

Práctica # 2 - Usar autenticación de múltiples factores

Las contraseñas pueden ser robadas, y las identidades comprometidas. Requerir un segundo factor
además de una contraseña mejora inmediatamente la seguridad. Además, la autenticación de la
identidad de un usuario o administrador y la verificación de su autorización para realizar una acción son
controles fundamentales sobre los que se basan otros controles de seguridad. Es beneficioso
estandarizar un enfoque tanto de autenticación como de autorización.

Enlaces utiles :
Autenticación multifactorial de Azure

Práctica # 3 - Hacer cumplir el privilegio mínimo

Es importante restringir y minimizar el número de personas en roles privilegiados que tienen acceso a
información o recursos seguros. Esto reduce la posibilidad de que un usuario malintencionado obtenga
ese acceso o que un usuario autorizado comprometa inadvertidamente un recurso sensible. Sin
embargo, los usuarios aún necesitan realizar operaciones privilegiadas en un servicio y es necesario
comprender qué son esas operaciones y separar esas funciones de modo que no haya una oportunidad
fácil para la escalada de privilegios. El principio de "administración suficiente" debe adoptarse para
restringir el privilegio elevado solo a aquellas funciones que el administrador requiere para completar la
tarea en cuestión y solo en una base "justo a tiempo" (JIT) y solo para el mínimo práctico período.

El uso de estaciones de trabajo de acceso privilegiado (PAW, por sus siglas en inglés) también ayuda a
proteger a los usuarios privilegiados de los ataques de Internet y los vectores de amenazas al
proporcionar una máquina dedicada para tacks sensibles y separar estas tareas y cuentas confidenciales
de las estaciones de trabajo de uso diario.

Enlaces utiles :
Gestión de identidad privilegiada de Azure AD
Control de acceso basado en roles
Estaciones de trabajo de cuenta privilegiada
Sólo suficiente administración

Práctica # 4 - Proteger los secretos

Cifre y almacene los secretos de la aplicación y elimine la necesidad de incluir secretos y otra
información de configuración confidencial en el código o en los archivos de configuración del
código. Nunca almacene contraseñas u otros datos confidenciales en el código fuente o en los archivos
de configuración o en archivos de texto plano (documentos, hojas de cálculo) almacenados en
ubicaciones desprotegidas. Los secretos de producción no deben usarse para desarrollo o pruebas.

Enlaces utiles :
Bóveda de clave de Azure
Almacenamiento seguro de secretos de aplicaciones en desarrollo
Identidades gestionadas para Azure
Herramientas de entrega continua para Visual Studio (incluye vista previa del escáner de
credenciales)

Práctica # 5 - Minimizar la superficie de ataque

Minimice la cantidad de funciones que pueden ser atacadas por una parte maliciosa. Se debe adoptar
un enfoque de defensa en profundidad y la superficie de ataque debe minimizarse en cada nivel de la
pila, incluyendo la limitación y el bloqueo de los puertos de red disponibles, la implementación de
configuraciones de roles de servidor de línea de base y la restricción de las aplicaciones que un servidor
puede ejecutar. .

Enlaces utiles :
Applocker
Asegurando SQL Server
Líneas base de seguridad de Windows
Guía de seguridad de Windows Server 2016
Dispositivo de protección

Práctica # 6 - Cifrar datos en tránsito y en reposo

Con el aumento de la computación móvil y en la nube, es de vital importancia garantizar que todos los
datos, incluida la información sensible a la seguridad y los datos de gestión y control, estén protegidos
contra la divulgación o alteración involuntarias cuando se transmiten o almacenan. El cifrado se utiliza
normalmente para lograr esto. En el mundo operacional, solo use bibliotecas de cifrado revisadas por la
industria y solo use versiones sólidas del protocolo de cifrado. Además, asegúrese de comprender las
protecciones que proporciona una solución de cifrado, especialmente al cifrar los datos almacenados.

Enlaces utiles :
Microsoft SDL Recomendaciones criptográficas
Qualys SSL Labs

Práctica # 7 - Implementar monitoreo de seguridad

Es de vital importancia poder detectar, responder y recuperarse de los ataques. Las aplicaciones, el
sistema y los archivos de registro de seguridad bien diseñados son las fuentes de datos fundamentales
que informan las alertas automatizadas de los sistemas de gestión de eventos e información de
seguridad (SIEM) y que admiten el análisis forense en caso de un incidente.

Enlaces utiles :
Centro de seguridad de Azure

Práctica # 8 - Implementar una estrategia de actualización de seguridad

Los atacantes a menudo explotan las vulnerabilidades descubiertas previamente para las cuales se han
publicado actualizaciones, antes de que los sistemas a los que afectan sean parcheados. Para ayudar a
solucionar esto, todos los sistemas deben ser monitoreados y actualizados continuamente con las
últimas actualizaciones de seguridad. Para los paquetes de software y sistema operativo, solo use las
versiones de software actualmente compatibles e idealmente las últimas versiones. Además, para
ayudar a detectar y prevenir infecciones de malware, se debe requerir que los servidores ejecuten
software antimalware que bloqueará y remediará infecciones potenciales antes de que puedan causar
daños.

Enlaces utiles :
Cómo mantener tu computadora Windows al día.
Enterprise Mobility + Documentación de seguridad

Práctica # 9 - Proteger contra los ataques DDOS

Los ataques distribuidos de denegación de servicio (DDoS, por sus siglas en inglés) son algunos de los
mayores problemas de disponibilidad y seguridad que enfrentan las aplicaciones en la nube, ya que
cualquier punto final al que se pueda acceder públicamente a través de Internet puede ser
objetivo. Para solucionar esto, como mínimo, el tráfico debe ser monitoreado continuamente y deben
proporcionarse mitigaciones en tiempo real para ataques comunes a nivel de red. Sin embargo, a
medida que los ataques DDoS se vuelven más sofisticados y específicos, también puede ser necesario
proporcionar mitigaciones DDoS a los ataques de capa de protocolo y aplicación.

Enlaces utiles :
Descripción general de Azure DDoS Protection Standard

Práctica # 10 - Validar la configuración de aplicaciones web y sitios

El escaneo de aplicaciones y sitios web es una parte crítica del mantenimiento de un entorno de
operaciones altamente seguro para servicios en línea. Valide regularmente que los sitios web y las
aplicaciones web estén configurados de manera óptima para evitar ataques comunes a la web y para
usar versiones seguras de los protocolos de transporte, y han optado por opciones relevantes para la
seguridad. Los escaneos que usan credenciales autenticadas generalmente producirán resultados más
valiosos y cualquier problema que se encuentre debe ser remediado inmediatamente.

Enlaces utiles :
Escáneres de seguridad de aplicaciones web (Wikipedia)

Práctica # 11 - Realizar pruebas de penetración

El objetivo de la prueba de penetración es descubrir posibles vulnerabilidades resultantes de errores de
codificación, fallas en la configuración del sistema u otras debilidades de implementación operativa. Lo
realiza un dedicado "equipo rojo" de expertos en seguridad que simulan ataques de la vida real en la
red, la plataforma y las capas de aplicaciones, desafiando la capacidad de los servicios en la nube del
"equipo azul", un equipo dedicado de respondedores de seguridad, para detectar, Proteger contra, y
recuperarse de las brechas de seguridad. Cada incumplimiento del Equipo Rojo es seguido por una
divulgación completa entre el Equipo Rojo y el Equipo Azul para identificar brechas, abordar los
hallazgos y mejorar significativamente la respuesta de incumplimiento.

Enlaces utiles :
Analizador de superficie de ataque
Muestra de la barra de errores de seguridad de SDL
Aprenda más sobre las pruebas de penetración en el sitio en vivo
Rojo contra azul: pruebas internas de penetración de seguridad de Microsoft Azure

Integración de riesgos de TI y riesgos operacionales Cuando la operación de nuestro

negocio depende de cómo gestionamos la tecnología

Por definición, riesgo operacional es la suma de fallas o errores en los procesos, de las personas que los
ejecutan o de las tecnologías que los soportan, que pueden presentarse tanto desde un entorno externo
como interno y estar ocasionadas por actividades intencionales, procedimientos inadecuados o
defectuosos o por agentes contingentes como desastres naturales.

Entre estos escenarios pueden presentarse tanto amenazas, un potencial de riesgo,

como vulnerabilidades, que son brechas que quedan como puertas abiertas esperando a ser explotadas
en forma programada o fortuita. Lo que sí tienen en común es un escudo metodológico para mitigar los
riesgos a la operación: LA GESTIÓN. Entonces, evitar pérdidas financieras e incumplimiento legal
requiere establecer un entorno metodológico en nuestra operación, mediante la gestión relacionada con
la seguridad física y lógica, normativa interna para alinear las TI con el cumplimiento, proyectos de TI,
usuarios de la organización, y amenazas externas.

En la búsqueda de cómo resolver nuestra problemática sobre los riesgos operativos, observamos que
existe una relación lógica entre la definición del alcance del riesgo operacional y los factores de
producción determinados para el gobierno de la información (procesos–tecnologías–personas), lo cual
afirma la necesidad de establecer procesos adecuados para el cumplimiento de los objetivos de negocio,
operados por personal con las capacidades y conocimientos necesarios y acorde a sus funciones dentro
de los servicios, y el soporte de recursos tecnológicos e infraestructura de servicios a la medida de las
necesidades del negocio.

Por ello, es natural el empleo de estándares relacionados con el gobierno de TI y gobierno corporativo
(como ISO 20000 y 27001, ITIL, COBIT5, Normas NIST, etc.) para normalizar nuestros procesos y
ayudar a ordenar todas las actividades asociadas a la continuidad operativa, así como a la seguridad de la
información.

Minimizar el riesgo operativo requiere un conocimiento “relacionalista” de la organización. Pensar que

los procesos internos y los servicios de TI están disociados entre sí o que no hay nada más allá de la
organización que pueda afectarla, es acotarse a una sola dimensión de riesgos y perder la visión global y
multidisciplinaria que se requiere para la subsistencia de la operación de nuestro negocio. Las
necesidades de gobierno deben surgir a nivel corporativo, desde todas las áreas de la organización, y
apoyarse piramidalmente teniendo en cuenta que no se pueden establecer directrices que no se sustenten
inicialmente en procesos y procedimientos que vayan enmarcándola hacia un camino de madurez, que le
permita establecer un gobierno adecuado a su entorno, a su industria y, principalmente, a su cultura. Este
entendimiento nos brindará la objetividad necesaria para la adopción de los estándares adecuados.
DevOps

Desde el principio, el SDL de Microsoft identificó que la seguridad debía ser un trabajo de todos e incluyó
prácticas en el SDL para gerentes de programas, desarrolladores y evaluadores, todo orientado a mejorar la
seguridad. Además, al reconocer que un solo tamaño no se ajusta a todos los enfoques de desarrollo, describió
las prácticas flexibles y las actividades probadas para mejorar la seguridad de las aplicaciones de software en
cada etapa del desarrollo, ya sea utilizando la clásica metodología ágil o la más nueva. Sin embargo, aparte de
considerar el entorno de producción, el SDL no incluyó actividades para ingenieros de operaciones.

El enfoque de DevOps cambia eso. Ahora, el desarrollo y las operaciones están estrechamente integradas para
permitir la entrega rápida y continua de valor a los usuarios finales. DevOps ha reemplazado el desarrollo y las
operaciones aisladas para crear equipos multidisciplinarios que trabajan en conjunto con prácticas,
herramientas y KPI compartidos y eficientes. Para ofrecer software y servicios altamente seguros en este
entorno de rápido movimiento, es fundamental para la seguridad moverse a la misma velocidad. Una forma de
lograrlo es crear seguridad en los procesos de desarrollo (SDL) y operaciones (OSA).

Práctica # 1 — Proporcionar entrenamiento

La formación es fundamental para el éxito. Asegurarse de que todos entiendan la perspectiva del atacante, sus
objetivos y cómo explotan los errores de codificación y configuración o las debilidades arquitectónicas ayudarán
a captar la atención de todos y elevar la barra de conocimiento colectiva.
Práctica # 2 — Definir requisitos
Establezca una línea de base de seguridad mínima que tenga en cuenta los controles de seguridad y de
cumplimiento. Asegúrese de que estén incorporados en el proceso y la tubería de DevOps. Como mínimo,
asegúrese de que la línea de base tenga en cuenta las amenazas del mundo real, como el Top 10 de OWASP o
el Top 25 de SANS , y los requisitos reglamentarios o de la industria y los problemas conocidos o que podrían
introducirse por un error humano en la pila de tecnología que seleccione. .
Práctica # 3 — Definir métricas y reportes de cumplimiento
Maneje el comportamiento que desea con los ingenieros al definir métricas específicas que impulsan la acción y
apoyan los objetivos de cumplimiento.

Práctica # 4 — Uso de análisis de composición de software (SCA) y gobernabilidad

Al seleccionar componentes de terceros (tanto comerciales como de código abierto), es importante comprender
el impacto que podría tener una vulnerabilidad en el componente en la seguridad general del sistema. Las
herramientas de SCA pueden ayudar con la exposición de licencias, proporcionar un inventario preciso de
componentes y reportar cualquier vulnerabilidad con los componentes a los que se hace referencia. También
debe ser más selectivo al usar componentes de terceros de alto riesgo y considerar realizar una evaluación más
exhaustiva antes de usarlos.

Obtenga más información sobre el uso de componentes de terceros seguros>

Enlaces utiles :
Fuente Blanca
Práctica # 5: Realizar el modelado de amenazas
Aunque el modelado de amenazas puede ser desafiante en DevOps debido a su lentitud percibida, es un
componente crítico de cualquier proceso de desarrollo seguro. En la mayoría de las situaciones, la aplicación de
un enfoque estructurado a los escenarios de amenazas ayuda a un equipo a identificar las vulnerabilidades de
seguridad de manera más efectiva y económica, a determinar los riesgos de esas amenazas y luego a hacer
selecciones de características de seguridad y establecer las mitigaciones adecuadas. Como mínimo, el modelado
de amenazas debe utilizarse en entornos donde exista un riesgo de seguridad significativo.
Práctica # 6 — Usar herramientas y automatización
Use herramientas cuidadosamente seleccionadas y una automatización inteligente que esté integrada en el
mundo del ingeniero (como un entorno de desarrollo integrado). En el mundo de la ingeniería moderna, es fácil
suponer que la automatización es la solución y es correcto que la automatización es crítica, pero es importante
ser selectivo al elegir herramientas y tener cuidado al implementarlas. El objetivo es solucionar los problemas y
no sobrecargar a los ingenieros con demasiadas herramientas o procesos ajenos a la experiencia diaria de
ingeniería. Las herramientas utilizadas como parte de un flujo de trabajo seguro de DevOps deben cumplir con
los siguientes principios:
 Las herramientas deben estar integradas en la tubería de CI / CD.
 Las herramientas no deben requerir experiencia en seguridad.
 Las herramientas deben evitar una alta tasa de falsos positivos de problemas de informes.
La integración de las Pruebas de seguridad de análisis estático (SAST) en su IDE (entorno de desarrollo integrado)
puede proporcionar una visión analítica profunda de la sintaxis, la semántica y proporcionar un aprendizaje justo
a tiempo, evitando la introducción de vulnerabilidades de seguridad antes de que el código de la aplicación se
comprometa con su repositorio de código. De manera similar, la integración de las herramientas de Pruebas de
seguridad de análisis dinámico (DAST) en el proceso de integración continua / entrega continua ayudará a
descubrir rápidamente los problemas que solo aparecen cuando todos los componentes están integrados y en
ejecución.

Enlaces utiles :
Detección de riesgos de seguridad de Microsoft (MSRD)
Microsoft DevSkim
Mercado de seguridad VSTS
Escaneo de codigo de seguridad
Analizadores de seguridad Roslyn Diagnostics
Microsoft BinSkim
Pruebas automatizadas de penetración con difusor de caja blanca
Análisis de código de seguridad de Microsoft (en vista previa privada)

Si está utilizando Azure, el Kit de DevOps seguro se puede descargar desde Visual Studio Marketplace .
Práctica # 7: mantener las credenciales seguras
La búsqueda de credenciales y otro contenido confidencial en los archivos de origen es necesario durante la
confirmación previa, ya que reduce el riesgo de propagar la información confidencial al proceso de CI / CD de su
equipo. En lugar de almacenar claves confidenciales en el código, considere usar una solución de traer su propia
clave (BYOK) que genere claves con un módulo de seguridad de hardware (HSM).

Enlaces utiles :
Analizador de Código CredScan
Utilice el servicio conectado de Key Vault
Práctica # 8 — Usar aprendizaje y monitoreo continuo
La supervisión de sus aplicaciones, infraestructura y red con análisis avanzados puede ayudar a descubrir
problemas de seguridad y rendimiento. Al utilizar prácticas de integración continua / implementación continua
(CI / CD) combinadas con herramientas de monitoreo, podrá obtener una mejor visibilidad del estado de su
aplicación e identificar y mitigar los riesgos para reducir la exposición a los ataques. El monitoreo también es una
parte esencial de apoyar una estrategia de defensa en profundidad y puede reducir el tiempo promedio de su
organización para identificar (MTTI) y el tiempo promedio para contener (MTTC) las métricas.

Enlaces utiles :
Monitor azul
Detección avanzada de amenazas