{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Miedo y odio en DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ten\u00edamos 2 analizadores de c\u00f3digo, 4 herramientas de pruebas din\u00e1micas, nuestras propias creaciones y 250 scripts. No es que todo esto fuera necesario en el proceso actual, pero una vez que comenc\u00e9 a implementar DevSecOps, es necesario hacerlo bien.<\/p>\n

\"Miedo
\n
\nFuente<\/a><\/noindex>. Creadores de personajes: Justin Roiland y Dan Harmon.<\/i><\/p>\n

\u00bfQu\u00e9 es SecDevOps? \u00bfY DevSecOps? \u00bfEn qu\u00e9 se diferencian? \u00bfDe qu\u00e9 trata la Seguridad de Aplicaciones? \u00bfPor qu\u00e9 el enfoque cl\u00e1sico ya no funciona? Todas estas preguntas tienen respuestas. Yuri Shabalin<\/b> de\u00a0Swordfish Security. <\/b>Yuri responder\u00e1 a todo en detalle y abordar\u00e1 los problemas de la transici\u00f3n del modelo cl\u00e1sico de Seguridad de Aplicaciones al proceso DevSecOps: c\u00f3mo integrar adecuadamente el proceso de desarrollo seguro en el proceso de DevOps sin romper nada, c\u00f3mo pasar por las etapas principales de pruebas de seguridad, qu\u00e9 herramientas se pueden utilizar, en qu\u00e9 se diferencian y c\u00f3mo configurarlas correctamente para evitar trampas.
\n<\/a><\/noindex>
\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center>
\nSobre el ponente:<\/b> Yuri Shabalin\u00a0\u2014 <\/b>Arquitecto de Seguridad Jefe en la empresa Swordfish Security<\/b>. Es responsable de implementar SSDL, de la integraci\u00f3n general de herramientas de an\u00e1lisis de aplicaciones en un ecosistema unificado de desarrollo y pruebas. 7 a\u00f1os de experiencia en seguridad de la informaci\u00f3n. Ha trabajado en Alfa-Bank, Sberbank y Positive Technologies, que desarrolla software y ofrece servicios. Ponente en conferencias internacionales como ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Seguridad de Aplicaciones: \u00bfde qu\u00e9 trata?<\/h2>\n

\nSeguridad de Aplicaciones<\/b>\u00a0\u2014 es una rama de la seguridad que se encarga de la seguridad de las aplicaciones. No se relaciona con la infraestructura o la seguridad de la red, sino espec\u00edficamente con lo que escribimos y en lo que trabajan los desarrolladores: son las vulnerabilidades y defectos de la propia aplicaci\u00f3n.<\/p>\n

Direcci\u00f3n SDL o SDLC<\/a><\/noindex>\u00a0\u2014 Ciclo de vida del desarrollo de seguridad<\/b>\u00a0\u2014 fue desarrollado por Microsoft. En el diagrama est\u00e1 el modelo can\u00f3nico de SDLC, cuyo objetivo principal es la participaci\u00f3n de la seguridad en cada etapa del desarrollo, desde los requisitos hasta el lanzamiento y la producci\u00f3n. Microsoft se dio cuenta de que hab\u00eda demasiados errores en producci\u00f3n, que estaban aumentando y hab\u00eda que hacer algo al respecto, y propuso este enfoque que se ha vuelto can\u00f3nico.<\/p>\n

\"Miedo
\n
\nLa Seguridad de Aplicaciones y SSDL no est\u00e1n destinadas a detectar vulnerabilidades, como com\u00fanmente se cree, sino a prevenir su aparici\u00f3n. Con el tiempo, el enfoque can\u00f3nico de Microsoft fue mejorado y desarrollado, y se profundiz\u00f3 en detalle.<\/p>\n

\"Miedo
\n
\nEl SDLC can\u00f3nico est\u00e1 muy detallado en diversas metodolog\u00edas como OpenSAMM, BSIMM y OWASP. Las metodolog\u00edas son diferentes, pero en general son similares.<\/p>\n

Modelo de Madurez para la Construcci\u00f3n de Seguridad<\/h3>\n

\nMe agrada m\u00e1s BSIMM<\/b>\u00a0\u2014 Modelo de Madurez para la Construcci\u00f3n de Seguridad<\/a><\/noindex>. La base de la metodolog\u00eda es la divisi\u00f3n del proceso de Seguridad de Aplicaciones en 4 dominios: Gobernanza, Inteligencia, Puntos de Contacto SSDL y Despliegue. En cada dominio hay 12 pr\u00e1cticas, que se presentan en forma de 112 actividades.<\/p>\n

\"Miedo
\n
\nCada una de las 112 actividades tiene 3 niveles de madurez<\/b>: inicial, intermedio y avanzado. Todas las 12 pr\u00e1cticas se pueden estudiar por secciones, seleccionar lo que sea importante para usted, entender c\u00f3mo implementarlas y agregar elementos gradualmente, como an\u00e1lisis est\u00e1tico y din\u00e1mico de c\u00f3digo o revisi\u00f3n de c\u00f3digo. Elabore un plan y, a partir de \u00e9l, trabaje sin prisa en la implementaci\u00f3n de las actividades seleccionadas.<\/p>\n

Por qu\u00e9 DevSecOps<\/h2>\n

<\/p>\n

DevOps es un gran proceso en el que se debe cuidar la seguridad.<\/p><\/blockquote>\n

\nInicialmente DevOps<\/b><\/a><\/noindex> se asumieron auditor\u00edas de seguridad. En la pr\u00e1ctica, el n\u00famero de equipos de seguridad era mucho menor que ahora, y actuaban no como participantes en el proceso, sino como un organismo de control y supervisi\u00f3n que impone requisitos y verifica la calidad del producto al final del lanzamiento. Este es el enfoque cl\u00e1sico, donde los equipos de seguridad estaban separados del desarrollo y no participaban en el proceso.<\/p>\n

\"Miedo
\n
\nEl principal problema es que la seguridad de la informaci\u00f3n est\u00e1 separada del desarrollo. Generalmente, hay un contorno de seguridad de la informaci\u00f3n y en \u00e9l hay 2-3 grandes y costosas herramientas. Una vez cada seis meses, se recibe c\u00f3digo fuente o una aplicaci\u00f3n que necesita ser revisada, y una vez al a\u00f1o se realizan pruebas de penetraci\u00f3n<\/a><\/noindex>. Todo esto lleva a que los plazos de lanzamiento se retrasen, y el desarrollador se enfrenta a una gran cantidad de vulnerabilidades de herramientas automatizadas. Todo esto es imposible de resolver y reparar, porque a\u00fan no se han analizado los resultados de los seis meses anteriores, y ya hay un nuevo lote.<\/p>\n

En el proceso de trabajo de nuestra empresa, vemos que la seguridad en todas las \u00e1reas e industrias reconoce que es hora de alinearse y trabajar con el desarrollo en un mismo camino: en\u00a0Agile<\/b><\/a><\/noindex>. La paradigma DevSecOps encaja perfectamente en la metodolog\u00eda de desarrollo \u00e1gil, en la implementaci\u00f3n, apoyo y participaci\u00f3n en cada lanzamiento e iteraci\u00f3n.<\/p>\n

\"Miedo
\n<\/p>\n

Transici\u00f3n a DevSecOps<\/h2>\n

\nLa palabra m\u00e1s importante en el Ciclo de Vida del Desarrollo de Seguridad es \"proceso\"<\/b>Debes entender esto antes de pensar en comprar herramientas.<\/p>\n

Simplemente incluir herramientas en el proceso de DevOps no es suficiente; es importante la interacci\u00f3n y comprensi\u00f3n entre los participantes del proceso.<\/p><\/blockquote>\n

<\/p>\n

Lo m\u00e1s importante son las personas, no las herramientas.<\/h3>\n

\nA menudo, la planificaci\u00f3n de un proceso de desarrollo seguro comienza con la elecci\u00f3n y compra de una herramienta, y termina con intentos de integrar la herramienta en el proceso actual, que quedan como intentos. Esto lleva a consecuencias desafortunadas, porque cada herramienta tiene sus propias caracter\u00edsticas y limitaciones.<\/p>\n

Un caso com\u00fan es cuando el departamento de seguridad elige una buena, costosa herramienta, con amplias capacidades, y llega a los desarrolladores para integrarla en el proceso. Pero no funciona: el proceso est\u00e1 dise\u00f1ado de tal manera que las limitaciones de la herramienta ya comprada no encajan en la actual paradigma.<\/p>\n

Primero describe qu\u00e9 resultado deseas y c\u00f3mo ser\u00e1 el proceso. Esto ayudar\u00e1 a comprender los roles de la herramienta y la seguridad en el proceso.<\/p><\/blockquote>\n

<\/p>\n

Comienza con lo que ya se utiliza.<\/h3>\n

\nAntes de comprar herramientas costosas, observa lo que ya tienes. Cada empresa tiene requisitos de seguridad que se imponen al desarrollo, hay auditor\u00edas, pruebas de penetraci\u00f3n; \u00bfpor qu\u00e9 no transformar todo esto en una forma clara y conveniente para todos?<\/p>\n

Normalmente, los requisitos son un documento en papel que se encuentra en una estanter\u00eda. Hubo un caso en el que llegamos a una empresa para revisar los procesos y pedimos ver los requisitos de seguridad para el software. El especialista que se encargaba de eso busc\u00f3 por mucho tiempo:<\/p>\n

\u2014 Ahora, en alg\u00fan lugar en las notas hab\u00eda un camino donde se encontraba este documento.<\/i><\/p>\n

Al final, obtuvimos el documento una semana despu\u00e9s.<\/p>\n

Para requisitos, auditor\u00edas y dem\u00e1s, crea una p\u00e1gina, por ejemplo, en\u00a0Confluence<\/b>\u00a0\u2014 es conveniente para todos.<\/p>\n

Es m\u00e1s f\u00e1cil reformatear lo que ya existe y usarlo como punto de partida.<\/p><\/blockquote>\n

<\/p>\n

Usa los Security Champions. <\/h3>\n

\nNormalmente, en una empresa promedio con 100-200 desarrolladores trabaja un experto en seguridad, que desempe\u00f1a varias funciones y no puede revisar todo f\u00edsicamente. Incluso si se esfuerza al m\u00e1ximo, no podr\u00e1 revisar todo el c\u00f3digo que genera el desarrollo. Para tales casos, se desarroll\u00f3 el concepto de Security Champions.<\/b><\/a><\/noindex>.<\/p>\n

Los Campeones de Seguridad son personas dentro del equipo de desarrollo que est\u00e1n interesadas en la seguridad de su producto.<\/p><\/blockquote>\n

\"Miedo
\n
\nEl Campe\u00f3n de Seguridad es el punto de entrada al equipo de desarrollo y un evangelista de la seguridad en una sola persona.<\/p>\n

Normalmente, cuando un experto en seguridad se une al equipo de desarrollo y se\u00f1ala un error en el c\u00f3digo, suele recibir una respuesta sorprendida:<\/p>\n

\u2014 \u00bfY usted qui\u00e9n es? Es la primera vez que lo veo. Todo est\u00e1 bien para m\u00ed: un compa\u00f1ero senior en la revisi\u00f3n de c\u00f3digo me dijo \"aplicar\", \u00a1sigamos adelante!<\/i><\/p>\n

Esta es una situaci\u00f3n t\u00edpica, porque hay mucha m\u00e1s confianza hacia los compa\u00f1eros senior o simplemente a los colegas del equipo con los que el desarrollador interact\u00faa constantemente en el trabajo y en las revisiones de c\u00f3digo. Si en lugar de un experto en seguridad, es un Campe\u00f3n de Seguridad quien se\u00f1ala el error y sus consecuencias, su palabra tendr\u00e1 m\u00e1s peso.<\/p>\n

Adem\u00e1s, los desarrolladores conocen su c\u00f3digo mejor que cualquier experto en seguridad. Para alguien que tiene al menos 5 proyectos en la herramienta de an\u00e1lisis est\u00e1tico, suele ser complicado recordar todos los matices. Los Campeones de Seguridad conocen su producto: con qu\u00e9 interact\u00faa y qu\u00e9 mirar primero, son m\u00e1s efectivos.<\/p>\n

As\u00ed que reflexione sobre la posibilidad de implementar Campeones de Seguridad y ampliar la influencia del equipo de seguridad. Para el propio campe\u00f3n, tambi\u00e9n es \u00fatil: desarrollo profesional en un nuevo campo, ampliaci\u00f3n de la perspectiva t\u00e9cnica, mejora de habilidades t\u00e9cnicas, de gesti\u00f3n y de liderazgo, aumento en el valor en el mercado. Es un cierto elemento de ingenier\u00eda social, sus \"ojos\" en el equipo de desarrollo.<\/p>\n

Etapas de prueba<\/h2>\n

\nLa par\u00e1bola 20 a 80<\/a><\/noindex>\u00a0indica que el 20% de los esfuerzos generan el 80% del resultado. Estos 20% son pr\u00e1cticas de an\u00e1lisis de aplicaciones que se pueden y deben automatizar. Ejemplos de tales actividades son el an\u00e1lisis est\u00e1tico, SAST<\/b>, el an\u00e1lisis din\u00e1mico, DAST,<\/b> y\u00a0control de c\u00f3digo abierto<\/b>. Hablar\u00e9 en detalle sobre las actividades, as\u00ed como sobre las herramientas, con qu\u00e9 peculiaridades nos encontramos normalmente al implementarlas en el proceso y c\u00f3mo hacerlo correctamente.<\/p>\n

\"Miedo
\n<\/p>\n

Problemas principales de las herramientas<\/h3>\n

\nResaltar\u00e9 los problemas actuales que requieren atenci\u00f3n en todas las herramientas. Los analizar\u00e9 m\u00e1s a fondo para no repetir m\u00e1s adelante.<\/p>\n

An\u00e1lisis prolongado. <\/b>Si desde el commit hasta la producci\u00f3n se tardan 30 minutos en todas las pruebas y la compilaci\u00f3n, las verificaciones de seguridad llevar\u00e1n un d\u00eda. Nadie va a frenar el proceso por eso. Tengan en cuenta esta particularidad y saquen conclusiones.<\/p>\n

Alto nivel de False Negative o False Positive. <\/b>Todos los productos son diferentes, todos utilizan diferentes frameworks y su propio estilo de codificaci\u00f3n. En diferentes bases de c\u00f3digo y tecnolog\u00edas, las herramientas pueden mostrar diferentes niveles de False Negative y False Positive. Por lo tanto, presten atenci\u00f3n a lo que exactamente en\u00a0su<\/b> empresa y para sus<\/b> aplicaciones mostrar\u00e1 un resultado bueno y confiable.<\/p>\n

No hay integraciones con las herramientas existentes<\/b>. Mire las herramientas desde el punto de vista de las integraciones, con lo que ya est\u00e1 utilizando. Por ejemplo, si tiene Jenkins o TeamCity, verifique la integraci\u00f3n de las herramientas precisamente con este software, y no con GitLab CI, que usted no utiliza.<\/p>\n

Falta o excesiva complejidad en la personalizaci\u00f3n. <\/b>Si la herramienta no tiene API, \u00bfpara qu\u00e9 sirve? Todo lo que se puede hacer en la interfaz debe estar disponible a trav\u00e9s de la API. Idealmente, la herramienta debe tener la capacidad de personalizar las verificaciones.<\/p>\n

No hay hoja de ruta para el desarrollo del producto. <\/b>El desarrollo no se detiene, siempre estamos utilizando nuevos frameworks y funciones, reescribiendo c\u00f3digo antiguo en nuevos lenguajes. Queremos estar seguros de que la herramienta que compremos seguir\u00e1 soportando nuevos frameworks y tecnolog\u00edas. Por eso, es importante saber que el producto tiene una real y correcta Hoja de ruta<\/a><\/noindex> hoja de ruta.<\/p>\n

Particularidades del proceso<\/h3>\n

\nAdem\u00e1s de las particularidades de las herramientas, tengan en cuenta las particularidades del proceso de desarrollo. Por ejemplo, interferir en el desarrollo es un error t\u00edpico. Veamos qu\u00e9 otras caracter\u00edsticas deben ser consideradas y en qu\u00e9 debe prestar atenci\u00f3n el equipo de seguridad.<\/p>\n

Para no retrasar los plazos de desarrollo y lanzamiento, cree diferentes reglas<\/b> y diferentes show stoppers\u00a0<\/b>\u2014 criterios para detener el proceso de compilaci\u00f3n en caso de vulnerabilidades \u2014 para diferentes entornos<\/b>. Por ejemplo, entendemos que la rama actual va a un entorno de desarrollo o UAT, por lo que no detenemos ni decimos:<\/p>\n

\u2014 \u00a1Usted tiene vulnerabilidades aqu\u00ed, no puede continuar!<\/i><\/p>\n

En esta etapa, es importante informar a los desarrolladores que hay problemas de seguridad a los que deben prestar atenci\u00f3n.<\/p>\n

La existencia de vulnerabilidades no es un obst\u00e1culo para continuar con las pruebas.<\/b>: manual, de integraci\u00f3n o manual. Por otro lado, necesitamos de alguna manera aumentar la seguridad del producto, para que los desarrolladores no ignoren lo que encuentra la seguridad. As\u00ed que a veces actuamos de esta manera: en el entorno de desarrollo, cuando se lanza al entorno de desarrollo, simplemente notificamos a los desarrolladores:<\/p>\n

\u2014 Chicos, tienen problemas, por favor presten atenci\u00f3n a ellos.<\/i><\/p>\n

En la etapa de UAT, mostramos nuevamente advertencias sobre vulnerabilidades, y en la etapa de salida al entorno de producci\u00f3n decimos:<\/p>\n

\u2014 Chicos, les hemos advertido varias veces, no han hecho nada: no los dejaremos salir con esto.<\/i><\/p>\n

Si hablamos del c\u00f3digo y la din\u00e1mica, solo debemos mostrar y advertir sobre las vulnerabilidades de aquellas funciones y c\u00f3digos que se han escrito recientemente en esta funci\u00f3n. Si un desarrollador ha movido un bot\u00f3n 3 p\u00edxeles y le decimos que tiene una inyecci\u00f3n SQL y que necesita corregirlo urgentemente, eso es incorrecto. Solo mire lo que se ha escrito ahora y los cambios que est\u00e1n llegando a la aplicaci\u00f3n.<\/p>\n

Supongamos que tenemos un defecto funcional: c\u00f3mo no deber\u00eda funcionar la aplicaci\u00f3n: el dinero no se transfiere, al hacer clic en el bot\u00f3n no hay una transici\u00f3n a la siguiente p\u00e1gina o no se carga el producto. Los defectos de seguridad<\/b>\u00a0son defectos similares, pero no en t\u00e9rminos del funcionamiento de la aplicaci\u00f3n, sino de la seguridad. <\/p>\n

No todos los problemas de calidad del software son problemas de seguridad. Pero todos los problemas de seguridad est\u00e1n relacionados con la calidad del software. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nDado que todas las vulnerabilidades son defectos similares, deben estar donde est\u00e1n todos los defectos de desarrollo. As\u00ed que olv\u00eddense de los informes y los terror\u00edficos PDF que nadie lee.<\/p>\n

\"Miedo
\n
\nCuando trabajaba en una empresa de desarrollo, recib\u00ed un informe de herramientas de an\u00e1lisis est\u00e1tico. Lo abr\u00ed, me asust\u00e9, prepar\u00e9 un caf\u00e9, hoje\u00e9 350 p\u00e1ginas, lo cerr\u00e9 y volv\u00ed a trabajar. Los grandes informes son informes muertos.<\/b>. Por lo general, no llevan a ninguna parte, los correos se eliminan, se olvidan, se pierden o el negocio dice que asume los riesgos.<\/p>\n

\u00bfQu\u00e9 hacer? Los defectos confirmados que encontr\u00e9 los transformamos en un formato amigable para el desarrollo, por ejemplo, los agrupamos en el backlog en Jira. Priorizamos los defectos y los solucionamos en orden de prioridad junto con los defectos funcionales y de pruebas.<\/p>\n

An\u00e1lisis est\u00e1tico - SAST<\/h2>\n

\nEs un an\u00e1lisis de c\u00f3digo en busca de vulnerabilidades<\/b>, pero esto no es lo mismo que SonarQube. No solo verificamos patrones o estilo. Utilizamos varios enfoques para el an\u00e1lisis: basado en el \u00e1rbol de vulnerabilidades, por\u00a0DataFlow<\/a><\/noindex>, por an\u00e1lisis de archivos de configuraci\u00f3n. Esto se refiere estrictamente al c\u00f3digo.<\/p>\n

Ventajas del enfoque<\/b>: identificaci\u00f3n de vulnerabilidades en el c\u00f3digo en una etapa temprana del desarrollo<\/b>, cuando a\u00fan no hay entornos y herramientas listos, y\u00a0posibilidad de escaneo incremental<\/b>: escaneo de la secci\u00f3n de c\u00f3digo que ha cambiado, y solo de la funcionalidad que estamos implementando, lo que reduce el tiempo de escaneo.<\/p>\n

Desventajas<\/b>\u00a0\u2014 la falta de soporte para los lenguajes necesarios.<\/p>\n

Integraciones necesarias, <\/b>que deber\u00edan estar presentes en las herramientas, en mi opini\u00f3n subjetiva:<\/p>\n