"Confianza en el diseño seguro" vs. "Seguro, confiamos en el diseño" (Otra historia de Star Wars)
Volvemos a conectar con la entrada anterior sobre diseño seguro donde en esencia vimos que la técnica de penetración-parcheado-corrección supone un coste mucho mayor que la integración de robustos mecanismos de seguridad que prevengan las vulnerabilidades en una fase temprana. Basta con recordar el ejemplo del gasto no previsto que tuvo que financiar el canciller Darth Sidious para reconstruir la Estrella de la Muerte. Y en la mayoría de los casos no hablamos solo de gasto económico, sino también perjuicio de imagen, consideraciones legales, cuestiones de privacidad, daños a terceros, que te lancen por un pozo de ventilación mientras lanzas rayos, etc.
Veamos algunos métodos más para el desarrollo seguro, pero en este caso solo dos de los más importantes que afectan a cómo se desarrolla software seguro y privado, con independencia del resto del ciclo de vida.
Integración segura en fase de desarrollo
Por muy expertos que sean los desarrolladores y muy tipificados que estén los requisitos funcionales y de seguridad durante la etapa de desarrollo, la integración de componentes de seguridad en sistemas complejos modularizados no es una tarea sencilla. Además, requiere de una formación adecuada y en constante renovación a la hora de implementar las peculiaridades funcionales de seguridad. Para resolver estas cuestiones numerosas propuestas ofrecen a los desarrolladores un apoyo, que lejos de ser invasivo, permiten incorporar a sus frameworks de trabajo elementos que proporcionen ese conocimiento de seguridad necesario que eviten la introducción de defectos en el código.
Este método es menos formal que los que hemos visto hasta ahora y se compone de:
En Rogue One, Bodhi Rook consigue entrar en el planeta Scarif a través de la puerta del escudo, únicamente utilizando un código obsoleto de autenticación, alegando que les han desviado desde la estación Eadu. Este éxito en ingeniería social hubiese sido inútil si los desarrolladores hubiesen previsto las carencias del factor humano y hubiesen añadido controles de seguridad basados en otro tipo de parámetros, como identificadores y huellas biométricas de los ocupantes, verificación de la firma criptográfica que autoriza el desvío de la nave, privilegios concedidos a la nave para acceder al espacio protegido, etc. Los desarrolladores hubiesen recibido de antemano del patrón/modelo de seguridad, el conjunto de controles necesarios para implementar.
Métodos formales
Estos métodos se componen de una serie de técnicas y herramientas con base matemática utilizadas para la verificación del desarrollo y análisis de sistemas. Normalmente aplicables a distintas fases del ciclo de vida de la creación software, donde las más habituales y que más han asimilado el uso de métodos formales son:
Los métodos formales permiten recoger requisitos y decisiones de diseño utilizando un lenguaje preciso y común tanto para expresar el qué se quiere obtener, qué tests debe superar y en qué restricciones debe padecer. Estas tres estipulaciones definidas en lenguaje matemático son universales y verificables de forma inequívoca. En esencia, la especificación indica qué queremos y qué no queremos conseguir desde los requisitos, y esta expresión va redefiniéndose a través de las funciones y los componentes donde, una vez llegado a las decisiones de diseño, su forma está tan próxima a la programación que su conversión es casi inmediata.
Una vez obtenida la especificación y realizada la implementación, llega el proceso de la verificación formal, para ello gracias a la expresión matemática es posible comprobar la correctitud del sistema implementado. Durante el desarrollo la especificación se verifica a partir de pre y post condiciones que se cumplen en el código desarrollado. Es decir, de cada sentencia, función, clase, método y librería, se deben cumplir todas las precondiciones y postcondiciones que garantizan que se están cumpliendo con los formalismos matemáticos especificados, garantizando que al menos matemáticamente el programa/sistema cumple con su propósito esperado. Esto incluye que se cumplan las restricciones de seguridad y privacidad que fueron incluidas como requisitos funcionales.
El equipo de diseño de sistemas informáticos del Imperio Galáctico hubiera solventado algunos de los problemas de seguridad mediante una especificación matemática de ciertos requisitos:
El factor humano (de nuevo) como eslabón más débil
Hemos repasado y descrito varios enfoques usados en el ciclo de vida del desarrollo software seguro y privado. Y todos ellos defienden unos conceptos muy básicos como son:
Y es que la práctica ha demostrado que las principales vulnerabilidades encontradas en los sistemas son introducidas por errores humanos, y que hubiesen sido fácilmente detectables de forma anticipada. Pero queda demostrado que todos los errores introducidos por factores humanos son los más complejos de resolver y corregir, ya que la mayoría se deben a malas prácticas, ignorancia y falta del seguimiento de procedimientos estandarizados. Anecdóticamente Darth Vader mataba a todos los que le fallaban, suponemos que también a los CISOs, por lo que es difícil que de los fallos que hubiesen cometidos pudiesen adquirir lecciones aprendidas para corregirlas en el futuro.
En definitiva, cada vez más necesitamos acudir a enfoques y ciclos de desarrollo que integren SPD en su núcleo y que permitan gracias a su asistencia corregir todos los errores que por nuestra propia naturaleza humana pudiésemos introducir. La mejora y optimización de los procesos desatendidos y automatizados ayudan a prevenir fallos del diseño y a remediar con bastante antelación fallos de seguridad. Confiar en la Fuerza está bien, pero dejarse ayudar por R2-D2, K2SO o BB-8 garantizará que haremos la tarea con mayor seguridad y privacidad.
Veamos algunos métodos más para el desarrollo seguro, pero en este caso solo dos de los más importantes que afectan a cómo se desarrolla software seguro y privado, con independencia del resto del ciclo de vida.
Integración segura en fase de desarrollo
Por muy expertos que sean los desarrolladores y muy tipificados que estén los requisitos funcionales y de seguridad durante la etapa de desarrollo, la integración de componentes de seguridad en sistemas complejos modularizados no es una tarea sencilla. Además, requiere de una formación adecuada y en constante renovación a la hora de implementar las peculiaridades funcionales de seguridad. Para resolver estas cuestiones numerosas propuestas ofrecen a los desarrolladores un apoyo, que lejos de ser invasivo, permiten incorporar a sus frameworks de trabajo elementos que proporcionen ese conocimiento de seguridad necesario que eviten la introducción de defectos en el código.
Este método es menos formal que los que hemos visto hasta ahora y se compone de:
- Una gestión eficiente y autogestionada de los repositorios de software seguro, junto a...
- ...la utilización sostenible y supervisada de primitivas tanto de funciones criptográficas como protocolos. Gracias a la centralización de los componentes, funciones y librerías de seguridad utilizadas en la empresa, junto a un correcto conocimiento de las funciones criptográficas y protocolos, permitirán a los desarrolladores saber de antemano si un protocolo sufre de vulnerabilidades por overflow o si una función criptográfica de hasheo ha sido comprometida y se pueden provocar colisiones de forma intencionada.
En Rogue One, Bodhi Rook consigue entrar en el planeta Scarif a través de la puerta del escudo, únicamente utilizando un código obsoleto de autenticación, alegando que les han desviado desde la estación Eadu. Este éxito en ingeniería social hubiese sido inútil si los desarrolladores hubiesen previsto las carencias del factor humano y hubiesen añadido controles de seguridad basados en otro tipo de parámetros, como identificadores y huellas biométricas de los ocupantes, verificación de la firma criptográfica que autoriza el desvío de la nave, privilegios concedidos a la nave para acceder al espacio protegido, etc. Los desarrolladores hubiesen recibido de antemano del patrón/modelo de seguridad, el conjunto de controles necesarios para implementar.Métodos formales
Estos métodos se componen de una serie de técnicas y herramientas con base matemática utilizadas para la verificación del desarrollo y análisis de sistemas. Normalmente aplicables a distintas fases del ciclo de vida de la creación software, donde las más habituales y que más han asimilado el uso de métodos formales son:
- La especificación de requisitos funcionales e integración en la fase de diseño, y...
- ....en la validación y verificación en la fase de desarrollo. El objetivo de estos métodos persigue proporcionar mecanismos que pueden mejorar la corrección del sistema en desarrollo, en este caso comprobar que se consigue el mayor grado de seguridad y privacidad en el sistema.
Los métodos formales permiten recoger requisitos y decisiones de diseño utilizando un lenguaje preciso y común tanto para expresar el qué se quiere obtener, qué tests debe superar y en qué restricciones debe padecer. Estas tres estipulaciones definidas en lenguaje matemático son universales y verificables de forma inequívoca. En esencia, la especificación indica qué queremos y qué no queremos conseguir desde los requisitos, y esta expresión va redefiniéndose a través de las funciones y los componentes donde, una vez llegado a las decisiones de diseño, su forma está tan próxima a la programación que su conversión es casi inmediata.
Una vez obtenida la especificación y realizada la implementación, llega el proceso de la verificación formal, para ello gracias a la expresión matemática es posible comprobar la correctitud del sistema implementado. Durante el desarrollo la especificación se verifica a partir de pre y post condiciones que se cumplen en el código desarrollado. Es decir, de cada sentencia, función, clase, método y librería, se deben cumplir todas las precondiciones y postcondiciones que garantizan que se están cumpliendo con los formalismos matemáticos especificados, garantizando que al menos matemáticamente el programa/sistema cumple con su propósito esperado. Esto incluye que se cumplan las restricciones de seguridad y privacidad que fueron incluidas como requisitos funcionales.
El equipo de diseño de sistemas informáticos del Imperio Galáctico hubiera solventado algunos de los problemas de seguridad mediante una especificación matemática de ciertos requisitos:
El factor humano (de nuevo) como eslabón más débil
Hemos repasado y descrito varios enfoques usados en el ciclo de vida del desarrollo software seguro y privado. Y todos ellos defienden unos conceptos muy básicos como son:
- Reducir la superficie de exposición a los riesgos.
- Regular y establecer políticas de seguridad y privacidad que validen el ciclo de vida de desarrollo
- Automatizar la integración de los mecanismos de seguridad y
- Reducir el factor humano en la decisión de factores de seguridad a integrar/desplegar en el sistema.
 |
| Fuente: Wiki Star Wars |
Y es que la práctica ha demostrado que las principales vulnerabilidades encontradas en los sistemas son introducidas por errores humanos, y que hubiesen sido fácilmente detectables de forma anticipada. Pero queda demostrado que todos los errores introducidos por factores humanos son los más complejos de resolver y corregir, ya que la mayoría se deben a malas prácticas, ignorancia y falta del seguimiento de procedimientos estandarizados. Anecdóticamente Darth Vader mataba a todos los que le fallaban, suponemos que también a los CISOs, por lo que es difícil que de los fallos que hubiesen cometidos pudiesen adquirir lecciones aprendidas para corregirlas en el futuro.
En definitiva, cada vez más necesitamos acudir a enfoques y ciclos de desarrollo que integren SPD en su núcleo y que permitan gracias a su asistencia corregir todos los errores que por nuestra propia naturaleza humana pudiésemos introducir. La mejora y optimización de los procesos desatendidos y automatizados ayudan a prevenir fallos del diseño y a remediar con bastante antelación fallos de seguridad. Confiar en la Fuerza está bien, pero dejarse ayudar por R2-D2, K2SO o BB-8 garantizará que haremos la tarea con mayor seguridad y privacidad.
Marcos Arjona
Innovación y Laboratorio de ElevenPaths
marcos.arjona@11paths.com
Innovación y Laboratorio de ElevenPaths
marcos.arjona@11paths.com
Artículo publicado en el Blog de ElevenPaths - Sucríbete al RSS - Sigue ElevenPaths en Twitter - Sitio web oficial de ElevenPaths
Tags : ElectronicLab ElevenPaths Blog IFTTT Nicaragua
Carlos Gutierrez
Seo Construction
Me gusta hacer diseños frescos y creativos. Mi alijo de diseños siempre está lleno de ideas refrescantes. No dude en echar un vistazo a mi Vcard.
- Carlos Gutierrez
- Februari 24, 1989
- 1220 Manado Trans Sulawesi
- contact@example.com
- +123 456 789 111
Publicar un comentario
Nota: sólo los miembros de este blog pueden publicar comentarios.