¿Sueñan los robots con la seguridad y privacidad por diseño? (I)

lunes, 2 de octubre de 2017

Bob es un apasionado de la construcción de hogares de madera. Sus reputadas edificaciones no tienen comparación: son bellas, funcionales y resistentes. El único detalle que podríamos achacarle a Bob es que nunca construye casas con cimientos, y nunca le dio importancia a ese detalle hasta que la mansión de Alice despegó del suelo durante la primera tormenta, produciéndole cierto resquemor. Bob corrigió el problema fácilmente, reconstruyó la casa y esta vez por sólo la mitad del precio inicial… aunque por si acaso esta vez ató la casa al suelo con cuerdas de alta resistencia.


Como ocurre en la construcción, el desarrollo software no debe concebirse si no incorpora una serie de medidas de seguridad y privacidad adecuadas al entorno donde será ejecutado. El desarrollo y diseño software se aleja ya de un trabajo de artesanos, más cuando el sector de las TIC es extremadamente complejo por la multitud de lenguajes de programación que intervienen, tecnologías interoperables, metodologías de desarrollo, coordinación de equipos de desarrollo… pero, por si fuera poco, hay que cumplir también con los costes y plazos. Un escenario óptimo y un caldo de cultivo para errores y carencias, que en el ámbito de la ciberseguridad se convertirán en fallos de seguridad y en vulnerabilidades. Atrás quedó la construcción reactiva perimetral, donde el propio desarrollador ejecutaba el código y si la casa volaba por los aires volvía atrás a corregir los fallos detectados, en muchos casos añadiendo nuevos.

No solo existen infinidad de amenazas e intereses para vulnerar los sistemas, sino que además existen riesgos añadidos que parten de los propios equipos de desarrollo que (por acción u omisión) introducen una serie de anomalías que pueden ser críticas en los sistemas.

¿En qué consiste?

La Seguridad y Privacidad por Diseño (SPD, o Security and Privacy by design) no es un paradigma reciente, sino que simplemente le pone nombre a una necesidad. Existen dos acepciones más o menos extendidas, la primera algo simplista que consiste en la introducción de medidas de seguridad en etapas tempranas del proceso de diseño del sistema. Pero un significado amplio mucho más preciso sobre la SPD la define como el establecimiento de un marco de trabajo que de manera sistémica, metódica y formal introduzca medidas de seguridad y privacidad a lo largo de todo el ciclo de vida del desarrollo software.

Por tanto, el SPD está ligado al ciclo de vida del desarrollo de un sistema software. Dotando cada fase de una serie de características exclusivas del ámbito de la seguridad que envuelven las fases habituales de este ciclo:
  1. Análisis de Requisitos. Se extenderán a la obtención de requisitos de seguridad y privacidad del sistema. La correcta detección y enumeración de estos requisitos es esencial para el proceso ya que solo podrán integrarse, validarse y comprobarse aquellos aspectos que hayan sido correctamente identificados. Ejemplos: El sistema de pago mediante tarjeta de crédito debe cumplir con la PCI DSS; debe existir funciones de auditoría que recojan cualquier modificación de datos, cambios del estado del sistema, intentos de autenticación, etc.

  2. ¡No es mi culpa! No puedo introducir algo si no sé que hace falta. (Fdo: Arquitecto software)

  3. Diseño. Todos los componentes, módulos, dependencias, controles y mecanismos que garanticen el cumplimiento de los requisitos de seguridad y privacidad son incorporados al diseño. Esta fase integrará una serie de factores funcionales y estructurales derivados de los requisitos de seguridad y privacidad recogidos en la fase anterior. Ejemplos: Incorporación al sistema de un sistema centralizado para el control de logs; añdir controles en todos los componentes de comunicación para garantizar aspectos como la confidencialidad en tránsito; etc.

  4. ¡No es mi culpa! No puedo desarrollar algo si no se encuentra en el diseño (Fdo: Desarrollador)

  5. Implementación y desarrollo. Se da forma a los controles de seguridad embebidos en el sistema, usando IDEs, técnicas y lenguajes de programación orientados a la seguridad, o que hagan un uso seguro de los recursos. Además, los modelos de gobernanza y responsabilidad de unos sistemas con otros deben integrarse y satisfacer la especificación.

  6. ¡No es mi culpa! No había ticket ni prueba unitaria para esto. (Fdo: QA)

  7. Testing y verificación. La automatización de las baterías de pruebas debe incorporar la validación de los requisitos de seguridad y privacidad, garantizando que se cumple su comportamiento y especificación formal. A este nivel se deben introducir aspectos de monitorización sobre el flujo de desarrollo, que compruebe que las soluciones cumplen con las restricciones de seguridad y privacidad a medida que sus distintos módulos operan entre sí.

  8. ¡No es mi culpa! Nadie me avisó sobre no usar contraseñas en ruso (Fdo: Venta especialista)

  9. Producción y Release. Aún en la fase de despliegue existen requisitos de seguridad y privacidad que deben salvaguardarse y que no han podido verificarse hasta esta fase. Amparados por un plan de remediación y respuesta ante incidentes que debería garantizar no solo los aspectos de seguridad y privacidad integrados, sino aquellas consideraciones que podrían emerger. Por ejemplo, un servicio online prestado a millones de personas testado y validado aún es susceptible a riesgos externos de diversa naturaleza que podría afectar a este servicio, y debe existir un plan de contingencia activo.

  10. No es mi culpa que pudiese bajarme los perfiles de todos los usuarios... y lo hiciese (Fdo: cliente de sombrero blanco)

  11. Respuesta y Feedback. Tras el lanzamiento la integridad y resistencia del sistema debe garantizarse periódicamente a través de revisiones constantes de seguridad tanto desatendidas como supervisadas. Diversos mecanismos de auditoria miden además la evolución de los sistemas de cara a la mejora constante de los mecanismos integrados, que gracias a cómo han sido introducidos pueden beneficiarse de un flujo constante de mejoras y actualizaciones.

¿Cómo ha llegado este producto a funcionar? (Fdo: Analista de sistema)

A efectos prácticos esta intervención en el ciclo aporta una serie de controles de seguridad y privacidad que establecen los cimientos y los pilares del proceso. Mejorando las futuras fases de evolución del software en cada una de las futuras iteraciones del proceso.

Objetivos

Por tanto, ya sabemos que Bob tendría que haber considerado los cimientos como parte fundamental del proceso, y si lo hubiera hecho además hubiese percibido una serie de objetivos subyacentes que proporciona la "intervención" del proceso como son:
  • Estandarización controlada. El ciclo de vida es acelerado gracias a un proceso estandarizado en la construcción, ya que los requisitos de seguridad y sus mecanismos de resolución son encapsulados como piezas reutilizables, tanto en el proceso de integración como de actualización a través de los procesos de ingeniería.
  • Plantillas. El enfoque SPD facilita la creación de plantillas a partir de modelos de seguridad que se generan para resolver los requisitos de seguridad. Optimizando los procesos de reutilización de conocimiento y soluciones a casos comunes. Esta reutilización mejora enormemente la optimización de recursos a nivel interno en las empresas.
  • Automatismos de verificación. La estructuración de la arquitectura y del código conforme a metodologías seguras, garantiza la creación de mecanismos reproducibles y extrapolables de verificación, entre sistemas o entre componentes del propio producto.
  • Granularidad. Las medidas de seguridad y privacidad se incrustan en el sistema a nivel sistémico por lo que necesidades de cumplimiento como las garantías normativas y regulatorias son abordadas con mayor efectividad en tiempo de diseño. Y de manera supervisada por controles predefinidos que son verificados de forma automática mediante scripts de control.
  • Trazabilidad y confianza. No todas las soluciones existentes resuelven de manera fiable los requisitos de seguridad y deben estar firmemente verificados y validados. Es por ello que los procesos de desarrollo no deben integrar fuentes externas de dudosa confianza en fases críticas como el diseño o la implementación. Gracias a procesos de trazabilidad las empresas establecen repositorios de componentes y servicios fiables, en los que pueden apoyar sus soluciones con plenas garantías.




Hemos comprobado que la SPD aborda el ciclo de vida de manera activa para incorporar una serie de complementos, de forma automatizada, que garanticen un producto con garantías de seguridad y privacidad validadas en cada caso. Existen distintas metodologías conceptuales y tecnológicas, más o menos consolidadas, que abordan este tipo de desarrollo y que estudiaremos en sucesivas entradas sobre este tema, así como las dificultades que ha encontrado la SPD para su expansión debido a las grandes diferencias entre la vertiente industrial con la académica.

Marcos Arjona
Innovación y laboratorio
marcos.arjona@11paths.com

No hay comentarios:

Publicar un comentario