This post is also available in: Português Español
Existe una comunidad virtual que crea herramientas, documentación, artículos y tecnologías gratuitos para ayudar a las personas a proteger sus sitios web, aplicaciones y recursos de red. Se llama OWASP, un acrónimo de Open Web Application Security Project, que se traduce como Open Web Application Security Project.
Esta entidad trata directamente el concepto de security by design, que es un enfoque de desarrollo de software que se centra en la seguridad desde las primeras etapas de creación. Ayudando a dedicarse a las mejores prácticas de programación, mejorando el entorno de seguridad en su conjunto, ya que evita la existencia de varias vulnerabilidades en el software.
Es vital en un contexto donde se llevan a cabo numerosos ataques para explotar tales fallas. Las vulnerabilidades de software a menudo son los descuidos de programación que dejan las aplicaciones, servidores o sitios web menos seguros.
Entonces depende de los desarrolladores crear software con un alto estándar de seguridad, para descartar la posibilidad de tales ataques. Sin embargo, se sabe que proteger un sitio web o un recurso de red puede ser difícil. Sin embargo, OWASP puede facilitar el proceso. Esta institución proporciona una lista completa de principios de diseño de seguridad que los programadores pueden seguir. Seguir estos principios garantizará que la aplicación sea segura, lo que reducirá en gran medida el riesgo de un ataque cibernético.
Principios OWASP
- 1) Definición de activos:
- 2) Comprender quiénes son los atacantes:
- 3) Pilares principales:
Antes de desarrollar cualquier estrategia de seguridad, es fundamental identificar y clasificar los datos que manejará la aplicación.
OWASP sugiere que los programadores creen controles de seguridad apropiados para el tipo de datos que se gestionan. Por ejemplo, un software que procesa información financiera debe tener restricciones mucho más estrictas que un blog o un foro web, cuyo propósito es bien diferente.
Los programadores deben diseñar controles que eviten el uso indebido de la aplicación por parte de diferentes tipos de actores maliciosos, lo que incluye empleados y programadores descontentos o descontentos: algunos los consideran el tipo de amenaza más peligroso del security by design.
La lista continúa con los ataques drive-by, que liberan virus o troyanos en el sistema, así como organizaciones criminales virtuales e incluso Script Kiddies, un término utilizado para definir a los adolescentes que intentan practicar actividades similares a los crackers, que ocasionalmente logran algún éxito.
OWASP recomienda que todos los controles de seguridad se diseñen teniendo en cuenta los pilares fundamentales de la seguridad de la información:
- Confidencialidad:
- Integridad:
- Disponibilidad:
los datos se liberan según los permisos para el usuario
asegurarse de que los datos no sean alterados por usuarios no autorizados.
Asegúrese de que los sistemas y los datos estén disponibles para los usuarios autorizados cuando los necesiten.
Arquitectura de seguridad
OWASP recomienda que cada software tenga medidas de seguridad de aplicación diseñadas para cubrir todo tipo de riesgos. Esto va desde los riesgos de uso típicos (borrar algo por accidente) hasta ataques extremos (ataques de fuerza bruta, ataques de inyección, etc.).
Debido a esto, se recomienda que los desarrolladores consideren cada función de la aplicación que están diseñando y hagan preguntas sobre si el proceso en torno a cada función es lo más seguro posible o no. Todo el mundo puede hacer un ejercicio de imaginación y pensar: si yo fuera un ciberdelincuente, ¿cómo explotaría este recurso? ¿qué sería útil para reducir el riesgo de esta característica?
OWASP también sugiere que los desarrolladores sigan la técnica de modelado de riesgos de amenazas STRIDE/DREAD utilizada por muchas empresas. STRIDE ayuda a los programadores a identificar amenazas, mientras que DREAD les permite clasificarlas.
Principios de seguridad
1. Minimice el área de superficie de ataque
Cada vez que un programador agrega una función a su aplicación, aumenta el riesgo de tener una vulnerabilidad de seguridad. El principio de minimizar el área de superficie de ataque restringe las funciones a las que pueden acceder los usuarios, para reducir las posibles debilidades.
Es posible, por ejemplo, codificar una función de búsqueda en una aplicación. Tal característica es potencialmente vulnerable a ataques de inclusión de archivos y ataques de inyección SQL.
El desarrollador podrá limitar el acceso a la función de búsqueda para que solo los usuarios registrados puedan usarla, lo que reduce la superficie de ataque y el riesgo de que se produzca una intrusión.
2. Establecer estándares seguros
Este principio establece que la aplicación debe ser segura por defecto. Esto significa que cada nuevo usuario debe tomar medidas para obtener mayores privilegios y eliminar medidas de seguridad adicionales.
Establecer estándares seguros significa que debe haber reglas de seguridad estrictas sobre cómo se manejan los registros de usuario, con qué frecuencia se deben cambiar las contraseñas, qué tan complejas deben ser, etc.
Los usuarios de software pueden desactivar algunas de estas funciones, pero deben configurarse en un nivel de seguridad alto de forma predeterminada.
3. El principio del mínimo privilegio
El principio de privilegios mínimos (POLP) establece que un usuario debe tener el conjunto mínimo de privilegios necesarios para realizar una tarea específica.
POLP se puede aplicar a todos los aspectos de una aplicación web, incluidos los derechos de usuario y el acceso a los recursos. Por ejemplo, un usuario suscrito a una aplicación de blog como autor no debe tener privilegios de administrador que le permitan agregar o quitar usuarios. A los autores solo se les debe permitir publicar artículos, limitándose a tal función.
4. El principio de la Defensa en Profundidad
La idea aquí es: varios controles de seguridad que abordan los riesgos de diferentes maneras son la mejor opción para proteger una aplicación.
Entonces, en lugar de tener un control de seguridad para el acceso de los usuarios, que tenga varias capas de validación, herramientas adicionales de auditoría de seguridad y herramientas de registro.
En lugar de permitir que alguien inicie sesión con solo un nombre de usuario y contraseña, se usaría una verificación de IP, un sistema Captcha, registro de intentos de inicio de sesión, detección de fuerza bruta, etc.
5. Fallar pero con seguridad
Hay muchas razones por las que una aplicación web no puede procesar una transacción. Tal vez haya fallado una conexión a la base de datos, o los datos ingresados por un usuario pueden ser incorrectos.
Este principio establece que las aplicaciones deben fallar de forma segura. La falla no debe otorgar privilegios adicionales al usuario y no debe mostrar información confidencial del usuario, como consultas o registros de la base de datos.
6. Cuidado con terceros
Muchas aplicaciones web utilizan servicios de terceros para acceder a funciones adicionales u obtener datos adicionales. Este principio establece que uno nunca debe confiar ciegamente en estos servicios.
La aplicación siempre debe verificar la validez de los datos que envían los servicios de terceros, sin otorgar permisos de alto nivel a esos servicios.
7. Separación de funciones
Es algo que puede usarse para evitar que las personas actúen de manera fraudulenta. Por ejemplo, un usuario de un sitio de comercio electrónico no debe ser promovido a administrador, ya que podría cambiar pedidos y otorgar descuentos inesperados.
Lo contrario también es cierto, ya que un administrador no debe tener la capacidad de realizar funciones que realizan los clientes, como ordenar artículos desde el front-end del sitio web.
8. Evita la seguridad por oscuridad
Este principio OWASP establece que la seguridad por oscuridad nunca debe habilitarse. Si la aplicación requiere que la URL de administración esté oculta para que pueda permanecer segura, entonces no es segura.
Debe haber suficientes controles de seguridad para mantener la aplicación segura sin ocultar la funcionalidad principal o el código fuente.
9. Seguridad simple y eficaz
Los desarrolladores deben evitar el uso de arquitecturas demasiado sofisticadas al desarrollar controles de seguridad para sus aplicaciones. Tener mecanismos muy complejos puede aumentar el riesgo de errores.
10. Solucionar problemas de seguridad correctamente
Si se ha identificado un problema de seguridad en una aplicación, los desarrolladores deben determinar su causa raíz.
Ellos necesitan arreglarlo y probar las reparaciones a fondo. Si el sistema utiliza patrones de diseño, es probable que el error esté presente en varios sistemas. Los programadores deben tener cuidado de identificar a todos los afectados.
This post is also available in: Português Español
