Seguridad en desarrollos ágiles

seguridad

(Constanza Pizarro) #1

Estimados,

Por los acontecimientos ocurridos recientemente con el Banco de Chile, muchas de las empresas que conozco tomaron la acción reactiva de incluir normas de seguridad, en el caso de la empresa donde presto servicios, hicimos una investigación de las normas, metodologías, leyes, estándares, frameworks y todo aquello relacionado con seguridad en ambiente TI, dónde OWASP es una de las opciones que se quieren implementar, adicionalmente están en proceso de la famosa Transformación digital y adicionalmente tienen células trabajando en proyectos casi “ágiles”…

y me pregunto… en un ambiente así… ¿Qué técnicas o métodos sean apropiados para introducir estos temas de seguridad (que antes estaban olvidados) en un ambiente dónde ya se están introduciendo grandes cambios?

Dejo un documento de los top 10 problemas de seguridad de OWASP:


(RIcardo M.) #2

Hola,
los temas de seguridad deben ser parte del Definition of Done de cada historia de usuario que se implemente. Si hay “deuda tecnica” de seguridad, simplemente crear historias de usuario para irlo resolviendo.

Saludos,

Ricardo


(Bryan Jimenez Franco) #3

Buen tema Constanza.
Personalmente me gusta como lo ve ThoughtWorks, un enfoque continuo y desde el inicio al fin, inclusive en el diseño, y tambien incluyen OWASP.

Saludos,
Bryan


(Manuel Enrique Grandón Troncoso) #4

Cualquier acción de seguridad “puede” entorpecer la agilidad y es un tema a considerar en las acciones a tomar en la búsqueda del cumplimiento de la actividad ágil , por lo que , si debemos acotar en la implementación de cualquier proyecto el área de seguridad de una empresa , ya en otro correo expondré más sobre el tema , sólo como ejemplo puedo dar el siguiente :

Un profesional da los primeros pasos en la implementación de un proyecto y dentro del bosquejo o análisis preliminar debe incluir las normas de seguridad que su proyecto identifica y además de identificarlas debe estar en su plan los recursos o acciones a seguir.

Esto a modo de resumen si entiendo bien lo que plantea , yendo a un tema más superficial y también de seguridad , quien trabaja en un proyecto debe conocer las normas de seguridad que el área implementa y volviendo al tema que llamó superficial , cuando hace la presentación de su proyecto debe tener y conocer todas las normas de seguridad implementadas por la empresa para hacer ágil el proyecto , ejemplo : como lleva su presentación a una reunión ? Lo lleva en su notebook el cual tiene acceso a la WiFi de la empresa o se puede conectar a la red en una oficina o cualquier punto de trabajo ? Lo lleva en un pendrive ? Hoy las normas de seguridad deben considerar en casos el bloqueo de los puestos USB , como expongo son todas cosas que pueden afectar la agilidad de un proyecto.

Las excusas si entendí mal lo que realmente se pretendía en este correo , pero quería plantear la agilidad y las normas de seguridad como consideraciones .

Saludos


(Manuel Enrique Grandón Troncoso) #5

Se entiende dama , ya hicieron la definición , gracias , algunas respuestas quizá por error fueron explicativas del concepto .


(Sandro Gomez) #6

En SF en el area Digital donde trabajo, hemos implementado recientemente un modelo donde los aspectos de seguridad son incorporados en el D.o.D.
Para poder hacerlo contamos con un “ethical hacker” que sigue los lineamientos OWASP. En primera instancia nuestro modelo era que nuestro “ethical hacker” probaba los incrementos una vez que estos se encontraban en “entregados” (staging o pre-producción) o incluso algunas células pasaban el incremento directamente a producción lo que acumulaba esta “deuda técnica consciente” y la “inconsciente”. Pero las necesidades del negocio son cambiantes entonces muchas veces en lugar de “pagar la deuda” se piorisaban otros features.
Finalmente hemos llegado a un modelo donde nuestro “ethical hacker” ha definido el set de vulnerabilidades y su mitigación que más se repiten y las hemos incorporado en el D.o.D de las células. Con esto aspiramos mitigar el 80% (aprox) de las vulnerabilidades conocidas antes de salir a producción el 20% restante hemos aplicado y acordado en conjunto con la compañía que una vez que el incremento se encuentre desplegado en pre-produccion, staging o producción y se detecta una vulnerabilidad CRITICA y ALTA cualquier desarrollo es detenido y el equipo se enfoca total y únicamente a resolver el problema de seguridad. Sobre ese 20% aspiramos llegar a un numero aún inferior implementando una serie de pruebas de seguridad automatizadas (DevSecOps) directamente en el pipeline (seguridad de contenedores, imagenes, secretos, etc).
Todo esto lo hemos hecho en conjunto con las células (Scrum Teams) y para nuestra sorpresa los últimos “eventos” han sensibilizado a los equipos en la importancia de la seguridad de nuestros productos. Finalmente las compañias u organizaciones pueden poner todos los controles y “burocracia” que consideren pertinente para “asegurar” sus productos, PERO finalmente son los desarrolladores los máximos responsables de sus artefactos y desde las diferentes áreas que interactuamos con los Devs Teams debemos apoyarlos constantemente para que se hagan cargo y nuestra deuda técnica de seguridad tienda a cero.


(Constanza Pizarro) #7

le daré una midara :slight_smile:
Gracias!

@mrsangrin, interesante la forma de exponer el caso y con esto me asalta una nueva pregunta…
¿Quien se encarga de validar las normas y leyes propias del país donde será utilizado el sistema, es igualmente parte del D.o.D?


(Constanza Pizarro) #8

No esperaba este enfoque en la respuesta, supongo que es un tema que solemos olvidar… aunque no importa si es ágil o no jejeje


(Ana Luz Valencia Plata) #9

buen aporte lo de OWASP

Saludos.


(Rafael Avaria Gutierrez) #10

OWASP es una recomendación incluyen una seria de medidas que se deven implementar en servidores y el código base para los vectores más comunes de ataque.

Es algo que todo desarrollador debe saber y preocuparse de entender.

Depende mucho del tipo servidor, lenguaje o framework usado.
la forma de implementar OWASP en .Net con IIS es totalmente diferente que en apache con PHP o con frameworks como angular y React.

Aquí esta la guia de configuración para servidores y frameworks más comunes
https://www.owasp.org/index.php/Secure_Configuration_Guide

Una guia para javascript
https://www.owasp.org/index.php/3rd_Party_Javascript_Management_Cheat_Sheet


(Rafael Avaria Gutierrez) #11

Hay que saber implementar OWASP afecta la velocidad de desarrollo y puede tener un impacto negativo se implementa de la noche a la mañana.

Muchos scripts fallan, uno de los casos mas frecuentes es mod_security un plugin que previenen muchos ataques y se instala en apache, nginx e iiis. (https://github.com/SpiderLabs/ModSecurity/wiki)

generalmente muchos devs se llevan la sorpresa que no les funciona muchas librerías que están acostumbrados a usar.


(Manuel Enrique Grandón Troncoso) #12

Están bien todos los puntos expuestos , incluidos los OWAS (Top), pero dentro de una empresa hay más que métodos y procedimientos , hay entidades que estan fuera del paraguas de IT y que hay que identificar en el proceso de agilidad .
No sólo la teoría , de la práctica hay que llevar esto a un documento o ampliar el OWAS(framework ágil) o cualquier herramienta ágil.


(Manuel Enrique Grandón Troncoso) #13

Buen aporte Rafael. Constaza , quizá me salí del tema ,pero hay buenos temas a debatir en pos de la agilidad ya que después quizá toda la metodología se transforma en algo no ágil y ahí me acuerdo de las primeras experiencias en Jira donde por no ser exhaustivo en como dominar y aplicar la herramienta (incluyendo quien saca las estadísticas ) el tema deja de ser deficiente por ende se pierde agilidad…


(Ana Luz Valencia Plata) #14

Se debe hacer gestión del cambio en todos los aspectos que involucra el desarrollo software, es un cambio cultural, se debe capacitar, educar a todos los actores involucrados, éste es un tema sensible para las organizaciones, transversal , se debe revisar todos los procesos de negocio de la empresa, para tener una visión integral y holistica de éste tema y tomar acciones preventivas, una vez analizadas las vulnerabilidades detectadas.

Saludos.


(Rafael Avaria Gutierrez) #15

Ten en mente que la mayoría de ataques son por ingeniería social, hay mucho que capacitar a las personas en temas de seguridad.

Desde un punto de vistas de desarrollador el riesgo es siempre que pueden inyectar código a tu sitio, algo tan simple como un comentario se puede volver una pesadilla si ejecuta un script que te lleva a un sitio identico al tuyo que capture tarjetas de crédito.

Pienso que nadie le toma el peso hasta que es hackeado y puede significar la perdida de un cliente hasta perjudicar la imagen de una empresa.

Hoy con internet of thing, donde se controlan dispositivos físicos como ampolletas inteligentes, actuadores el tema se vuelve mucho más sensible, estas hablando que un hacker puede alterar a los dispositivos de tu casa o peor aún de una empresa y afectar a miles de usuarios.


(Lindsay Iturra ) #16

Sin duda un tema muy interesante! :smiley:
Desde mi punto de vista la seguridad se debiese abordar desde un inicio en las Historias de Usuario como parte del desarrollo (análisis de las vulnerabilidades del SW), pero también es importante contar con procesos continuos que velen por la seguridad (Ethical Hacking).

Para los puntos mencionados, he visto que lo más utilizado es OWASP, sin embargo también hay otro sitio que categoriza los tipos de vulnerabilidades y pueden ser complementarios el NVD (NATIONAL VULNERABILITY DATABASE) https://nvd.nist.gov/

Y para finalizar, no se debe olvidar la Seguridad en la Infraestructura que ahí también existe mucho por explorar y abordar.

Slds! :v:


(Juan Francisco Maureira) #17

Mientras “seguridad” no sea parte de los procesos standar de desarrollo (así como CI/CD, TDD o cualquier otra herramienta que uses) en las personas comprometidas con el desarrollo del SW y tus stakeholders estén concientes del valor/impacto de esos items. “Seguridad” va a morderte los talones.

Pon como meta el llegar a ese punto, mientras no estés ahí sólo te queda mitigar y parchar.