Categorías
Uncategorized

Protege información y activos tecnológicos con las Pruebas de Penetración

En LITHEN operamos con diferentes metodologías para evaluar riesgos y vulnerabilidades de seguridad en el desarrollo de infraestructura, de esta manera generamos estrategias integrales vinculadas a los objetivos de tu organización.

Una de estas metodologías son las pruebas de penetración, estás evalúan la seguridad de las organizaciones desde un punto de vista digital. Se utilizan para identificar fallos y mitigarlos antes de que se materialicen y causen un daño a la organización.

Las pruebas van más allá del análisis del código, se enfocan en el hackeo de la aplicación y/o la infraestructura digital. De esta manera se amplía la superficie de análisis para detectar mayor número de vulnerabilidades.

Las pruebas de penetración además permiten clasificar las vulnerabilidades de acuerdo con su tipo: aplicación o infraestructura y nivel de riesgo (Crítico, Alto, Medio, Bajo, Informativo). Proporcionan evidencias de la explotación y el impacto que genera en la organización. Brindan lo necesario para recomendar los controles que fortalezcan la defensa en el entorno digital con un enfoque de gestión de riesgos.

Para definir este servicio, en LITHEN operamos con distintas metodologías avaladas por distintos organismos, entre las más importantes destacan:

Pentesting de caja blanca

En una prueba de caja blanca se conoce la composición interna y se tiene acceso total al software para detectar vulnerabilidades, es decir, tienen pleno acceso al código fuente, a la documentación de la arquitectura y a las credenciales de usuario. Por eso se conoce como caja blanca, porque hay claridad total sobre la estructura que se quiere trabajar. A partir de esta prueba, puedes obtener una evaluación completa de las vulnerabilidades tanto internas como externas de la infraestructura TI.

Pentesting de caja gris

La prueba de penetración de caja gris, tiene una pequeña diferencia con la anterior, ya que solo se tiene acceso a las credenciales y no al código de fuente ni a la documentación de la arquitectura. En este caso, se realizan ataques desde la perspectiva de los usuarios para determinar el impacto que podría tener una persona malintencionada.

Pentesting de caja negra

En un pentesting de caja negra, no posee más información de la que ya es conocida por cualquier persona, poniéndose desde la perspectiva de un hacker externo. No tiene credenciales ni acceso a ninguna información privada.

El objetivo principal de todas estas es conocer si un atacante externo sin información previa podría obtener acceso al sistema, a la aplicación o a los datos de la organización.

Es necesario identificar qué tipo de prueba se realizará, si se trata de un aplicativo o su infraestructura de nube. Estas dos opciones contemplan alcances y metodologías distintas, por lo que es recomendable definirlas. 

El tipo de prueba define la manera cómo se realizará la evaluación de seguridad con respecto al punto donde el atacante está situado.

Pruebas internas

Son pruebas que se hacen dentro del ambiente en el que la aplicación converge con infraestructura de nube y en algunos casos en sitio. Generalmente evalúan servicios que no se encuentran publicados en internet. Se pueden realizar en aplicaciones, servidores, bases de datos o la red corporativa.

Pruebas externas

Se realizan sobre los servicios accesibles sólo desde internet, tal y como lo haría un atacante ajeno a la organización. Generalmente no se evalúan algunos servicios de la infraestructura, que solo están disponible si la prueba fuera interna.

El tipo de caja definirá el contexto de la prueba, estipulando si se realizarán pruebas estáticas, dinámicas, con credenciales de acceso al aplicativo o servidor.

En LITHEN te platicamos algunos beneficios de contar con estas Pruebas 

  • Identificar las vulnerabilidades técnicas que no puedan ser detectadas por un análisis de vulnerabilidad organizacional.
  • Identificar y clasificar los hallazgos de acuerdo con estándares internacionales de gestión de riesgos como lo es CVSSv3.1
  • Realizar un plan de solución a los hallazgos y de mejora continua.

Categorías
Seguridad en Desarrollo de Software

Desarrollo de Software Seguro

Es un modelo de trabajo que se basa en la realización de exploraciones de seguridad continuas dentro de la construcción de un proyecto, es decir desde sus fases iniciales y antes de que se escriba una sola línea de código. Estas pruebas se centran en descubrir y corregir cualquier error en una etapa temprana y comprenden tests de autenticación, autorización, confidencialidad, integridad, estabilidad, no repudio, disponibilidad o resiliencia.

El objetivo es asegurarnos de que impediremos el acceso al programa y a los datos almacenados por parte de los usuarios.

Ciclo de vida de desarrollo de seguridad 

El seguimiento de procedimientos recomendados para el desarrollo de software seguro requiere la integración de seguridad en cada fase del ciclo de vida de desarrollo, del análisis de requisitos al mantenimiento, independientemente de la metodología de proyecto.

Como resultado de infracciones de datos de alto perfil y el aprovechamiento de brechas de seguridad operativa, cada vez más desarrolladores comprenden que la seguridad se debe abordar a lo largo de todo el proceso de desarrollo.

Las fases para el desarrollo de Software seguro son las siguientes

  • Capacitación
  • Requerimientos
  • Diseño
  • Implementación
  • Comprobación
  • Resultados
  • Lanzamiento

Metodologías 

Las metodologías de desarrollo seguro de software sitúan a la seguridad en el centro del proceso.

Existen distintos modelos, concebidos por grandes compañías, organizaciones nacionales y bajo paradigmas de código abierto.

  • S-SDLC (Secure Software Development Life Cycle). Se basa en verificar los requisitos de seguridad a lo largo de las distintas fases de construcción del software: análisis, diseño, desarrollo, pruebas y mantenimiento. Sobre todo, durante las dos primeras, ya que gran parte de las debilidades de los sistemas se generan incluso antes de comenzar las tareas de programación. Las claves del S-SDLC son la atención al detalle, para favorecer la identificación inmediata de las vulnerabilidades; y la mejora continua.
  • CLASP (Comprehensive Lightweight Application Security Process): Proyecto del OWASP que establece una serie de actividades, roles y buenas prácticas dirigidas a coordinar los procesos de desarrollo seguro de software. La organización OWASP CLASP se asienta en cinco perspectivas o vistas que abordan los conceptos generales de esta metodología, la distribución de funciones, la valoración de las actividades aplicables, la implementación de estas actividades, y el listado de problemas que pueden dar lugar a la aparición de vulnerabilidades.
  • SSDF (Secure Software Development Framework): Iniciativa del NIST (National Institute of Standards and Technology de Estados Unidos), provee indicaciones para evangelizar a la organización acerca de la importancia de la seguridad informática; proteger el software de uso habitual ante hipotéticos ataques; orquestar un desarrollo seguro de software; y detectar y solucionar con rapidez cualquier vulnerabilidad.
  • Pushing Left, Like a Boss: Serie de artículos en línea donde se describen los distintos tipos de actividades de seguridad de aplicaciones que los desarrolladores deben seguir para crear código más seguro.
  • Plataforma de identidad de Microsoft: Se trata de una plataforma completa que consiste en un servicio de autenticación, bibliotecas de código abierto, registro y configuración de aplicaciones, documentación completa para desarrolladores, ejemplos de código y otro contenido. La plataforma de identidad de Microsoft admite protocolos estándar del sector tales como OAuth 2.0 y OpenID Connect.

Cualquier paso en falso puede develar datos personales o dejar un software a merced de mentes malintencionadas. Por ello, es imprescindible tener presentes las técnicas de desarrollo seguro de software en todo momento y en proyectos de todo tipo.

 

Fuente: Microsoft Documentación