Gestión de riesgos con análisis de código de software

3

Soy programador por día y estoy trabajando en un proyecto que se centra en la gestión de riesgos basada en los controles PCI-DSS dentro de una organización.

Últimamente he pensado que muchos controles PCI-DSS se centran en parches de software, diagramas de red y fechas de finalización de la vida útil, etc. pero si la organización crea su propio software, deberíamos agregar análisis de código de software en esta área para encontrar ¿Posibles vulnerabilidades y exploits antes de que salga a la luz?

Sé que se debe probar todo el código y puede hacer que los examinadores de pruebas verifiquen el software, pero ¿por qué no debe pasar el código a través de un kit de herramientas de análisis antes de que se publique para ofrecerle un posible nivel de amenaza?

    
pregunta OliverBS 20.02.2014 - 13:45
fuente

4 respuestas

3

Su referencia a los parches de software, los diagramas de red y las fechas de finalización de la vida útil es cierta con respecto a las PCI DSS en su conjunto, pero existen requisitos muy específicos y relevantes con respecto a su pregunta:

  • 6.3.2: Revisión del código personalizado antes del lanzamiento a producción ... para identificar cualquier vulnerabilidad potencial de codificación
  • 6.4: Siga los procesos de control de cambios
  • 6.5: Desarrollar aplicaciones basadas en pautas de codificación seguras. Prevenir vulnerabilidades comunes de codificación ...

La Sección 6 de las PCI DSS se centra mucho en la seguridad del proceso de codificación, pero tiene razón en que no requiere una implementación específica. Un kit de herramientas de análisis se incluiría en 6.3.2 que requiere la revisión del código, ya sea a través de medios manuales o automáticos. Además, debe tener implementado un proceso para evitar todas las clases de vulnerabilidades según se hace referencia entre los requisitos 6.5.1 y 6.5.9.

Hay muchos procesos superpuestos que deben usarse para mitigar las vulnerabilidades y garantizar que no ingresen al código de producción. Si aborda seriamente la sección 6 de las PCI DSS y cumple todos los requisitos con procesos que funcionan para su organización y tiene sentido para la seguridad, estará en un buen lugar.

    
respondido por el freb 22.02.2014 - 01:06
fuente
3

No hay ninguna razón por la que no deba, de hecho, es una excelente manera de hacer una comprobación inicial. La razón por la que no se menciona específicamente es porque la prueba del lápiz y el análisis manual deberían hacer un trabajo mucho mejor que un análisis automatizado (y puede incluir uno como parte de la revisión). El punto es que las pruebas automatizadas por sí solas no son suficientes .

    
respondido por el AJ Henderson 20.02.2014 - 15:40
fuente
2

Ignorar PCI DSS. Es inútil (ver también: BlackPOS).

Lo importante es la administración de procesos de negocios y un profundo conocimiento de sus cadenas de producción de alto valor. El problema de la seguridad de la información / datos / aplicaciones es que las cadenas de entrada de bajo valor pueden permitir a los adversarios abrirse camino en las cadenas de salida de alto valor. Cubra sus cadenas rastreando el flujo de datos a través de su organización.

Identifique los elementos críticos y construya un aparato para asegurar todas sus cadenas de entrada apropiadas. Compre un seguro cibernético que sea igual a su sistema BPM. Haga una apelación ante sus equipos de auditoría, asesores regulatorios, abogados de distrito y la FTC (o donde sea que se encuentren sus jurisdicciones) para autoevaluarse mediante marcos alternativos. Si desea mi sugerencia sobre un marco, recomendaría VisibleOpsSec sobre, digamos, ISO 27001/27002, PCI DSS, IT COBIT, FISAP, CIP, et al.

Appsec es muerto simple. Usted integra Microsoft TFS (o Atlassian JIRA / Confluence) con plantillas de proceso que se asignan a las necesidades de la organización (aproximadamente) y que funcionan con plantillas de proceso existentes como EssUP, Agile, Scrum, Waterfall o cualquier pequeña plantilla de proceso que su equipo de administración de productos coordine. con sus dueños de negocios / org. Si tiene un tercero que realiza cualquier parte de su producto de software, los incluye (obviamente) y los mantiene en los mismos estándares.

Luego, realiza la simulación y el análisis del equipo rojo, así como algunos análisis del método Delphi para recopilar opiniones y comprender los resultados antes de que se realicen en la vida real. Usted integra estos conceptos en su Application Lifecycle Management (ALM) a través de bdd-sec y la búsqueda de errores. Muchas tareas de búsqueda de errores y bdd-sec se basan en Burp Suite Professional, por lo que se asegura de que todos tengan una copia, pero también los arman con IronWASP y OWASP ZAP. Si ejecuta una tienda JEE (probablemente Atlassian para ALM), entonces querrá un buen arnés de prueba automatizado WebDriver (u O2) combinado con Contrast Security. Si tiene una tienda de Microsoft, consulte muchas de las herramientas estándar de VisualStudio (o O2), tal vez agregando Fortify o Checkmarx en proyectos al contado que requieren mitigación intermedia o continua. Otros marcos requieren algunos ajustes inusuales, pero nada demasiado sofisticado o "por ahí". Si está ejecutando proyectos móviles, los arneses de Appium combinados con Clang asan (para iOS) o Coverity (para Android) más un control de terreno de Appthority probablemente funcionarán bien.

Es importante que esto esté respaldado por los programas de respuesta y manejo de incidentes de calidad ENISA y US-CERT. La dotación de personal o la retención de personal talentoso de DFIR es siempre su mayor problema de infosec. Agregar el proceso y las herramientas a ese programa es su segundo mayor problema de información. Después de eso, appsec, datasec, "netsec" (jaja, ¡como si incluso existiera!), Y la gestión de riesgos será un paseo por el parque.

    
respondido por el atdre 20.02.2014 - 18:52
fuente
1

Como se mencionó, no hay razón para que no deba. Una de las razones por las que no lo es es la falta de madurez de las prácticas de la industria con respecto a la revisión / auditoría del código, no solo en un contexto de PCI. No existe un estándar bien establecido para qué y cómo debe verificar si existen vulnerabilidades en el código fuente del software, no hay una forma formalizada de realizar dichas evaluaciones y, a partir de hoy, las soluciones existentes para realizarlas son inmaduras y el mercado no está claro para los clientes. . Agregue una falta constante de ingenieros especializados que entiendan cómo funciona esto y aquí están.

    
respondido por el ack__ 20.02.2014 - 22:16
fuente

Lea otras preguntas en las etiquetas