Los clientes nos exigen productos cada vez m\u00e1s seguros y que est\u00e9n listos para trabajar con ellos, por lo que la seguridad es una de las principales prioridades de todos. Pero sin un enfoque est\u00e1ndar de seguridad, es casi imposible cumplir con las expectativas de los clientes.<\/p>\n
Ah\u00ed es donde entra en juego el ciclo de vida de desarrollo seguro (SDL).<\/p>\n
SDL es un proceso. Si observa los muchos de los SDL que existen en todas las industrias, encontrar\u00e1 que la mayor\u00eda incluye las mismas fases y actividades de seguridad b\u00e1sicas. Pueden tener diferentes nombres para cada fase, pero todas las industrias siguen b\u00e1sicamente el mismo proceso.<\/p>\n
Aqu\u00ed exponemos la gu\u00eda que sigue BLMovil\u00a0 para colocar la seguridad al frente de nuestros desarrollo y al centro de nuestra metodolog\u00eda.<\/p>\n
En su forma m\u00e1s simple, el SDL es un proceso que estandariza las mejores pr\u00e1cticas de seguridad en una variedad de productos y \/ o aplicaciones. Captura las actividades de seguridad est\u00e1ndar de la industria y las empaqueta para que puedan implementarse f\u00e1cilmente. El ciclo de vida del desarrollo de software consta de varias fases, que explicamos con m\u00e1s detalle a continuaci\u00f3n.<\/p>\n
El SDL se desarroll\u00f3 por parte de Microsoft, como respuesta al famoso memorando de Bill Gates de enero de 2002. En \u00e9l, Gates estableci\u00f3 el requisito de incorporar seguridad en los productos de Microsoft. Admiti\u00f3 que debido a varios brotes de virus y malware, Microsoft ten\u00eda que incorporar la seguridad si quer\u00eda ser tomado en serio en el mercado.<\/p>\n
Esto dio como resultado el esfuerzo de Microsoft Trustworthy Computing, del cual naci\u00f3 la idea de SDL. Microsoft hizo obligatorio el SDL en 2004 y se desat\u00f3 una industria artesanal. Muchas otras empresas, incluidas Cisco, Adobe y Aetna, han adoptado desde entonces los procesos SDL de Microsoft o han creado los suyos propios. Y Microsoft ha compartido sus \u00e9xitos y experiencias sobre el SDL con otras empresas y publicado muchos de sus materiales y herramientas como c\u00f3digo abierto.<\/p>\n
La falta de un enfoque est\u00e1ndar para desarrollar productos seguros termina causando problemas. Por un lado, las vulnerabilidades van creciendo en los productos desarrollados. La tipificaci\u00f3n de los mismos y la respuesta\u00a0 que tiene que dar el equipo de desarrollo para hacer frente a estas vulnerabilidades son grandes consumidores de recursos. Como resultado, los programadores pasan demasiado tiempo arreglando el c\u00f3digo que escribieron en el pasado y no pueden enfocarse en los desarrollos futuros.<\/p>\n
El segundo problema es que los programadores tienden a repetir los mismos errores de seguridad, esperando cada vez una respuesta diferente. El tercer problema viene de que los problemas se encuentran en el lanzamiento o despu\u00e9s de la implementaci\u00f3n, cuando si se hubieran solucionado antes, los problemas se podr\u00edan haber solucionado de una forma m\u00e1s econ\u00f3mica.<\/p>\n
Finalmente, sin un est\u00e1ndar de seguridad, los clientes no tienen garant\u00eda de que un producto determinado sea seguro. Un producto puesto a la venta puede ser perfecto o puede ser terrible desde el punto de vista de la seguridad. Sin SDL, no existe paridad de seguridad de producto a lo largo de la producci\u00f3n dentro de la empresa. Y sin un proceso est\u00e1ndar, algunos equipos de desarrollo ignoran la seguridad por completo.<\/p>\n
El SDL es un proceso con diferentes fases que contiene actividades de seguridad que se encuentra dentro del cl\u00e1sico tri\u00e1ngulo personas-proceso-tecnolog\u00eda. El SDL forma la parte del proceso.<\/p>\n
Incluye tanto al equipo de seguridad central que gestiona el proceso y lo actualiza, como a los equipos de producto o desarrollo que realizan actividades de seguridad. La parte de la tecnolog\u00eda se basa en herramientas que ayudan a encontrar vulnerabilidades en el c\u00f3digo fuente o descubrir vulnerabilidades en una instancia en ejecuci\u00f3n del producto o aplicaci\u00f3n.<\/p>\n
El SDL tiene que ser neutral a la metodolog\u00eda utilizada. Las actividades de seguridad encajan dentro de cualquier metodolog\u00eda de desarrollo de productos, ya sea en cascada, \u00e1gil o DevOps. Las diferencias metodol\u00f3gicas se manifiestan en la cadencia de las actividades de seguridad.<\/p>\n
El SDL se desarroll\u00f3 durante el tiempo en el que predominaba la metodolog\u00eda en cascada, por lo que generalmente se describe como un proceso lineal que comienza con los requisitos y termina con el lanzamiento. Cuando el SDL se ampl\u00eda a \u00e1gil, algunas actividades de seguridad se integran en el cronograma de sprint normal, mientras que otras se realizan en procesos aparte. Con DevOps, las actividades se integran en el proceso de compilaci\u00f3n mediante la automatizaci\u00f3n, mientras que las actividades adicionales ocurren fuera del workflow.<\/p>\n
Un SDL se divide en fases que se relacionan estrechamente con el enfoque en cascada. El enfoque est\u00e1ndar de SDL incluye requisitos, dise\u00f1o, implementaci\u00f3n, prueba y lanzamiento \/ respuesta.<\/p>\n
En la fase de requisitos, se integran las mejores pr\u00e1cticas de seguridad para el desarrollo de un producto. Estas pr\u00e1cticas pueden venir de los est\u00e1ndares de la industria o estar basadas en respuestas a problemas que han ocurrido en el pasado.<\/p>\n
Existen requisitos predefinidos para ayudar definir los requisitos de seguridad funcional implementados en el producto e incluir todas las actividades del SDL. Se utilizan como punto de reforzamiento para garantizar que todas las piezas se consideren correctamente.<\/p>\n
Los requisitos de seguridad pueden adoptar la forma cl\u00e1sica, indicando que el producto o la aplicaci\u00f3n debe, puede o debe hacer algo. Un ejemplo podr\u00eda ser que el producto deba exigir una longitud m\u00ednima de contrase\u00f1a de ocho caracteres.<\/p>\n
En el mundo \u00e1gil, los requisitos se expresan como historias de usuarios. Estas historias contienen la misma informaci\u00f3n que los requisitos, pero la funcionalidad de seguridad est\u00e1 escrita desde la perspectiva del usuario.<\/p>\n
La fase de dise\u00f1o dentro del SDL consiste en actividades que deben ocurrir antes de escribir el c\u00f3digo. El dise\u00f1o seguro consiste en cuantificar una arquitectura (para una sola caracter\u00edstica o para todo el producto) y luego buscar problemas. El dise\u00f1o seguro se debe realizar en documento formal para que quede documentado todo el proceso realziado.<\/p>\n
En el desarrollo de muchos sistemas, el avi\u00f3n est\u00e1 en el aire mientras se dise\u00f1an las alas, pero el SDL puede sobrevivir incluso a esta locura. La clave es utilizar el modelado de amenazas.<\/p>\n
El modelado de amenazas es el proceso de pensar en c\u00f3mo se atacar\u00e1 una caracter\u00edstica o sistema y luego mitigar esos ataques futuros en el dise\u00f1o antes de escribir el c\u00f3digo. El modelado de amenazas es similar a percibir los delitos antes de que ocurran, como en la pel\u00edcula Minority Report de 2002.<\/p>\n
Un modelo de amenazas s\u00f3lido identifica la zona de ataque de una caracter\u00edstica o producto y luego define los ataques m\u00e1s probables que podr\u00edan ocurrir en esas interfaces. Un modelo de amenaza es tan bueno como las mitigaciones que contiene para solucionar los problemas. Pero es fundamental identificar los problemas de seguridad en las primeras etapas del proceso.<\/p>\n
La siguiente fase es la implementaci\u00f3n o escritura de c\u00f3digo seguro. El SDL contiene un listado de elementos que deben contemplar los programadores para asegurarse de que su c\u00f3digo tenga la mayor probabilidad de ser seguro. Este proceso involucra una mezcla de est\u00e1ndares y herramientas automatizadas.<\/p>\n
Un SDL s\u00f3lido define una gu\u00eda de codificaci\u00f3n segura (como las publicadas por SEI CERT para C, C ++ y Java), que define lo que se espera durante el desarrrollo y proporciona una gu\u00eda para ayudar a los desarrolladores cuando identifican un problema espec\u00edfico y necesitan informaci\u00f3n para solucionarlo.<\/p>\n
Las herramientas de implementaci\u00f3n incluyen software de pruebas de seguridad de aplicaciones est\u00e1ticas (SAST) y pruebas de seguridad de aplicaciones din\u00e1micas (DAST). SAST es como un corrector ortogr\u00e1fico de c\u00f3digo que identifica vulnerabilidades potenciales en el c\u00f3digo fuente. SAST se ejecuta en una compilaci\u00f3n nocturna o puede integrarse en su IDE. Puede encontrar y abrir nuevos errores en el sistema de administraci\u00f3n de errores todas las noches (en nuestro caso se generan en Polarion) o pedirle al desarrollador que haga una pausa mientras codifica para solucionar un problema en tiempo real.<\/p>\n
El DAST comprueba la instanciaci\u00f3n en tiempo de ejecuci\u00f3n de la aplicaci\u00f3n. Rastrea una aplicaci\u00f3n completamente para identificar todas las interfaces posibles y luego intenta explotar las vulnerabilidades comunes de dichos interfaces en la aplicaci\u00f3n.<\/p>\n
Las actividades de prueba formales dentro del SDL tienen que incluir planes de prueba funcional de seguridad, escaneo de vulnerabilidades y pruebas de penetraci\u00f3n. El an\u00e1lisis de vulnerabilidades utiliza herramientas est\u00e1ndar de la industria para determinar si existe alguna vulnerabilidad a nivel del sistema con la aplicaci\u00f3n o el producto.<\/p>\n
Las pruebas de penetraci\u00f3n en las que los testers intentan evitar las protecciones de seguridad en una aplicaci\u00f3n determinada y explotarlas. El Pen Testing extiende el producto y lo expone a escenarios de prueba que las herramientas automatizadas no pueden replicar. El Pen Testing requiere muchos recursos, por lo que generalmente no se realiza en cada versi\u00f3n.<\/p>\n
El lanzamiento ocurre cuando todas las actividades de seguridad se validan contra la compilaci\u00f3n final y es en ese momento cuando el software se env\u00eda a los clientes (o se pone a disposici\u00f3n para su descarga).<\/p>\n
La respuesta es la interfaz que generamos para que los clientes externos y nuestrosexpertos de seguridad puedan informar sobre problemas de seguridad en los productos.<\/p>\n
Parte de la respuesta incluye un equipo de respuesta a incidentes de seguridad del producto que se centra en clasificar y comunicar las vulnerabilidades del producto, tanto errores individuales como aquellos que requerir\u00e1n la colaboraci\u00f3n de toda la industria para informar si hiciera falta a terceros de problemas de seguridad en sus productos como Frameworks, plugins, etc, para que los puedan solucionar para poder seguir utiliz\u00e1ndolos con seguridad en nuestros desarrollos.<\/p>\n
Hay otras actividades de seguridad que son cruciales para el \u00e9xito de un SDL. Como pueden ser recompensas por errores, educaci\u00f3n y capacitaci\u00f3n.<\/p>\n
El ciclo de vida de desarrollo seguro es una forma diferente de crear productos; coloca la seguridad al frente y al centro durante el proceso de desarrollo de productos o aplicaciones.<\/p>\n
Desde los requisitos hasta el dise\u00f1o, desde la codificaci\u00f3n hasta las pruebas, SDL nos esforzamos por incorporar seguridad en nuestros productos o aplicaciones en cada paso del proceso de desarrollo. Una software factory moderna no puede sobrevivir sin tomarse en serio la seguridad, y la forma de hacerlo es integrando un SDL en nuestro trabajo diario.<\/p>\n