WhatsApp Facebook Twitter LinkedIn Mail

Seguridad por diseño (Security by Design, SbD)

Índice:

  1. ¿Qué es la SbD?
    1. Importancia del SbD
  2. Principios de seguridad

¿Qué es la seguridad por diseño?

La seguridad por diseño, Security by Design (SbD) en inglés, es un enfoque de seguridad tecnológica empresarial que se centra en automatizar los controles de seguridad de los datos y en el diseño de su infraestructura para garantizar la seguridad. Es decir, la seguridad por diseño está pensada para prevenir cualquier fallo de seguridad tecnológica para no tener que ir reparando los problemas después. Como dice el dicho: “Más vale prevenir que curar”.

Este enfoque se debe realizar al principio de un proyecto tecnológico (ya sea de hardware o de software). Pensar en seguridad por diseño cuando ya está todo implementado no tiene sentido porque no se puede modificar el diseño de la infraestructura. Algunos servicios tecnológicos ofrecen este compromiso de seguridad por defecto. Por ejemplo, Amazon Web Services tiene dentro de su sección de compliance un apartado dedicado al SbD. En él indican que garantizan el enfoque a la seguridad por diseño, una automatización de los controles de seguridad y que facilita las auditorías.

“El problema es que el 95% de los ataques que tienen éxito se deben a un software mal programado, mal mantenido o mal configurado. Sin embargo, este problema podría resolverse si se tuviera en cuenta la seguridad directamente desde el principio, en lugar de poner una tirita al producto sólo cuando ya está montado” – Thomas Tschersich, jefe del departamento de Seguridad Interna & Protección frente a los ciberataques en Deutsche Telekom (traducción propia)

¿Por qué es importante la seguridad por diseño?

Los sistemas que están diseñados desde el punto de vista de seguridad tienen como objetivo prevenir la aparición de vulnerabilidades. Por ello, estos diseños se centran en establecer medidas y poner controles que eviten que surjan problemas. Por ejemplo, porque un usuario abra un enlace que desencadene un ataque ransomware sin querer o porque un usuario sin derecho a acceder al sistema de nóminas pueda meterse y hacer cambios. La mayoría de las acciones que se realizan en el enfoque de seguridad por diseño está enfocado al usuario. Esto se debe a que el usuario es el eslabón más débil de la seguridad TIC.

Interesante: el derivado de seguridad por diseño, privacidad por diseño (privacy by design), es una estrategia que puede evitar muchos problemas en cuanto al no cumplimiento de la ley de protección de datos (GDPR). Esta ley obliga a las empresas de software a diseñar sus sistemas para que los usuarios no puedan ejecutar tareas que no son conformes a la GDPR, y que no se piden más datos personales de lo estrictamente necesario.

No obstante, la programación del sistema también es tomada muy en serio a la hora de hacer el diseño. Para ello, se le puede dar una serie de pautas a los programadores que están desarrollando un sistema para asegurar que siguen prácticas seguras y uniformes. Asimismo, también es muy útil el uso de monitorizaciones del desempeño del sistema, autenticaciones, controles y auditorías. De esta forma, es menos probable que algo ocurra, y, si ocurre, se detecta fácilmente.

Principios de seguridad

La organización sin ánimo de lucro OWASP (Open Web Application Security Project, proyecto abierto de seguridad de aplicaciones web) ha establecido 10 principios de seguridad. Estos principios son:

  1. Minimizar la superficie de ataque: cada elemento que se le añade a una tecnología supone un potencial riesgo para la tecnología en general. Por ejemplo, si se le añade a un software un plug-in para categorizar el inventario. Algunos plug-ins tienen ciertas zonas que por su desarrollo son más susceptibles a ataques. Entonces, es necesario hacer lo posible para minimizar ese riesgo. Para ello se puede establecer que sólo tengan acceso a esa función ciertas personas autorizadas o, incluso mejor, eliminar esa función si no es del todo imprescindible.
  2. Establecer valores seguros por defecto: este principio consiste en ofrecer el entorno más seguro por defecto al usuario. Ya si el usuario decide reducir esa seguridad (si es que le está permitido), que sea elección suya. Por ejemplo, estableciendo una capa de conexión segura (SSL) en el servidor web. Ya si el usuario quiere acceder a otra web que no lo tenga, es su propia elección.
  3. Privilegio mínimo: consiste en otorgar la menor cantidad de privilegios posible a los usuarios para desempeñar los procesos empresariales. Esto se debe a, cuanto menos funciones tengan en las que confundir o cometer errores, mejor seguridad habrá. Este privilegio mínimo no sólo se aplica a los derechos de los usuarios, sino también a los de: middlewares; CPUs, memorias, redes y sistemas de archivos.
  4. Defensa en profundidad: cuantos más controles se pongan, mejor. Es mejor tener varios controles a que haya un posible riesgo de ataque. Los controles dificultan que haya vulnerabilidades. Estos controles pueden ser: auditorías centralizadas, validación por niveles, entre otros. Sin embargo, hay que guardar cierto balance en el número de controles. Esto se debe a que por cada control que se realiza se pierde rapidez y facilidad de uso. Por ejemplo, una empresa puede poner muchos controles en la gestión de las facturas electrónicas. Esto puede sonar muy útil, pero si debido a esos controles un administrativo va a tardar 10 minutos más, entonces es posible que busque una forma alternativa de gestionarla. Resultando esa forma alternativa en una brecha de seguridad.
  5. Fallar de forma segura: los fallos en los procesos de las aplicaciones pueden suceder por muchos motivos distintos. Lo importante es ver cuál ha sido la forma en la que fallan, ya que eso determina si la aplicación es segura. Esto quiere decir que, por ejemplo, cuando haya un fallo, se deniegue el acceso al sistema por defecto. De esta forma, el fallo acaba en bloqueo del acceso y los hackers no pueden entrar.
  6. No confiar en los servicios: muchas empresas usan capacidades de procesamiento de terceros. Las políticas y posturas de seguridad de terceros muy probablemente sean diferentes a las de la empresa contratante y, además, normalmente no se tiene control sobre ellas. Por tanto, no se puede confiar de forma implícita en los sistemas externos. En este caso, lo que se puede hacer es que los partners firmen un contrato en el que aseguran que van a cumplir con protocolos de seguridad de la empresa.
    Atención: este tipo de contratos son muy comunes en el mundo de software. Por ello, TIC Portal ha creado el Premium digiBook Asuntos legales de una contratación TIC. En este digiBook se encuentran todos los aspectos legales que hace falta saber para que una contratación de software vaya bien.
  7. Separación de funciones: un control clave del fraude es la separación de funciones. El objetivo es eliminar la posibilidad de que un solo usuario realice y oculte una acción prohibida. Por ejemplo, que un administrador pueda meterse en el usuario de algún usuario para inculparle de algo por motivos personales.
  8. Evitar la seguridad por oscuridad: el método de seguridad por oscuridad o por ocultación consiste en mantener en secreto el código fuente del software, ocultar los algoritmos y protocolos utilizados. Este método por sí solo no es suficiente ya que sólo oculta el código, pero si es descubierto no detiene el ataque. La seguridad debe basarse en muchos otros factores, como políticas de contraseñas razonables, controles profundos (al igual que de fraude y de auditoría), limitaciones en las transacciones y una arquitectura de red sólida.
  9. Mantener simple la seguridad: algunas empresas siguen una tendencia de utilizar enfoques complejos. Por ejemplo, hay empresas que usan arquitecturas complejas en su desarrollo del software. Esta forma de complicar contribuye a que sea más difícil para los programadores, facilitando la aparición de fallos y vulnerabilidades. Por tanto, a veces la forma más segura es utilizando una programación sencilla que evite errores.
  10. Arreglar los problemas de seguridad de forma correcta: cuando se ha detectado un problema de seguridad, es importante hacer pruebas para identificar la raíz del problema. Además, si se utiliza un patrón de diseño, es muy probable que este patrón se encuentre en otras partes. Por tanto, es crucial que, una vez se sepa cómo resolverlo de forma correcta, se analice si este patrón se encuentra repetido en otras partes para corregirlo.

¿Quieres usar este artículo como fuente? Haz clic para copiar:

European Knowledge Center for Information Technology. (2022, 26 septiembre). Seguridad por diseño (Security by Design, SbD). TIC Portal. https://www.ticportal.es/glosario-tic/seguridad-diseno-sbd