Las empresas necesitan un programa de seguridad de software

Puede hacer algunos entrenamientos y pruebas, dotar a los desarrolladores con herramientas de seguridad gratuitas y seguir viendo los mismos defectos de seguridad una y otra vez. Si comienza con una iniciativa de seguridad de software inmadura (SSI o programa de seguridad de aplicaciones, programa de seguridad del producto), entonces Agile, DevOps y CI-CD son solo formas de acelerar el mismo software con errores. Se necesita un esfuerzo real a nivel empresarial para unir todo.

El esfuerzo a nivel de negocios, el SSI, debe garantizar que algunos problemas importantes se aborden explícitamente:

- La empresa debe decidir qué nivel de riesgo es aceptable y qué no. Existe el riesgo en todas partes: programar el riesgo, el riesgo de cumplimiento, el riesgo presupuestario y mucho más. En otras palabras, las cosas no siempre suceden de la manera que queremos. Eso significa que la empresa puede gastar en exceso, terminar fuera de cumplimiento o producir lo correcto demasiado tarde para que a nadie le importe. Incluso si todo eso funciona a la perfección, ¿qué defectos de seguridad se permitirán en los entornos de producción y cuáles se deben remediar de inmediato? Sin reglas claras para tales decisiones, los propietarios de aplicaciones individuales u otros aceptores de riesgos pueden terminar poniendo a la empresa en riesgo, o incluso fuera del negocio.

- La cultura tiene que aceptar que hay momentos en que la seguridad ganará las funciones y el cronograma. Debe haber una protección de gobierno que claramente delimita cuando la seguridad tiene prioridad. ¿Un parche de seguridad de middleware rompe la aplicación? Arregla la aplicación ¿El código abierto tiene una licencia no deseada? Está prohibido. ¿Una vulnerabilidad "alta" para la que se conocen los ataques automatizados? Arréglalo; nadie puede "aceptar el riesgo". La cadena de herramientas de CI / CD solo funciona si colocamos el nombre de usuario / contraseña de texto claro en el script de automatización. 

- La automatización de desarrollo y operaciones debe permitir la integración de elementos de seguridad que permitan cumplir los objetivos de seguridad empresarial. DevOps y CI / CD pueden ser una gran mejora con respecto a los procesos de desarrollo actuales. Sin embargo, la gente de seguridad del software también debe estar en la mezcla. ¿De qué sirve hacer que el software sea más rápido si aún tiene que esperar las pruebas de seguridad antes de pasar a la producción? El grupo de seguridad de software (SSG) que lidera el SSI debe garantizar que todas las cadenas de herramientas de desarrollo y operaciones tengan los ganchos donde las herramientas de seguridad pueden ejecutarse en línea y ejecutarse según la cadencia que el desarrollo espera.

- Los arquitectos y desarrolladores deben saber cómo es el código de seguridad. Todos estamos familiarizados con las diferencias entre educación y capacitación, y sabemos que el "entrenamiento de conciencia" no mejora el código. La capacitación ciertamente ayuda, pero entrenar solo no va a marcar la gran diferencia. Nadie ha nacido como arquitecto de seguridad de aplicaciones y se necesitan muchos años de experiencia con los requisitos de seguridad y las pilas de tecnología para hacerlo bien. Casi todos los arquitectos necesitan estándares preaprobados para cosas como cifrado, flujos de datos y administración de secretos en código; necesitan asistencia con modelos de amenazas y casos de abuso y abuso; y necesitan un aprendizaje manual específico, adaptado y repetido para una revisión segura del diseño. Además de la capacitación, los desarrolladores necesitan cosas como estándares de codificación segura, bibliotecas de seguridad por diseño para requisitos de seguridad no funcionales y características de seguridad aprobadas previamente.

- Todos los interesados ​​deben conocer sus roles y responsabilidades. Esto no es difícil Cualquiera que no conozca sus responsabilidades no las está cumpliendo.

- La compañía necesita una buena historia de software (y ciberseguridad) para contarle al público, a los accionistas, a los reguladores y a todos los demás. ¿Quieres el beneficio de la duda cuando algo malo sucede? Tener un SSI real que la gente pueda entender y en la que pueda creer. No solo eso, sino que realmente se lo cuente. Entonces, es más probable que crean que lo que sucedió fue un error que puede estudiarse y luego evitarse, en lugar de ser un indicador de inmadurez sistémica.

- La empresa necesita ahorrar dinero asegurando que los diversos componentes de su iniciativa de seguridad de software realmente funcionen en conjunto en lugar de causar fricción. ¿Por qué rastrear todos los ataques contra la empresa y no utilizar ese conocimiento para conducir estándares de codificación, capacitación y modelado de amenazas? ¿Por qué todos sus resultados de prueba SAST, DAST y fuzzing se obtienen en una sola base de datos y nunca realizan ningún análisis? ¿Por qué los desarrolladores corrigen defectos de seguridad "altos" en 3 días, pero dejan que los parches "altos" languidezcan durante semanas?

- Ninguna compañía puede permitirse ir a sentarse ante la autoridad después de una violación y hablar sobre cómo van a construir una iniciativa de seguridad de software el próximo año. 2002 llamó y quiere sus excusas. En 2018, ninguna empresa puede estar "a punto de comenzar con un SSI". Incluso si su empresa no crea software, igual necesita una historia sobre COTS, código abierto, software a medida u otro tipo de software que ponga en producción. . Incluso si solo tiene un montón de datos confidenciales procesados ​​por completo en los entornos de SaaS de otras compañías, aún necesita una historia de seguridad del software.

- Las compañías de seguros de ciberseguridad se están volviendo mucho más exigentes con las políticas y los pagos para las empresas que no pueden demostrar una verdadera capacidad de seguridad de software. Consulte a un abogado; por favor, no busque ni infiera consejos sobre este tema de un artículo que algún día adornará el fondo de una jaula de loros.

- El software y los adquirentes de SaaS están incrementando enormemente las actividades de administración de proveedores y el escrutinio de las prácticas de seguridad del proveedor, incluidas las actividades seguras de SDLC del proveedor. Todos entienden la gran cantidad de empresas de confianza que ofrecen los proveedores SaaS y en la nube, las empresas de desarrollo de software fuera de la fuente, los proveedores de herramientas de seguridad y una variedad de otros de los que depende el éxito de las empresas. Y todos sabemos que incluso si es el socio el que no cumple con las expectativas, es el nombre de su empresa el que aparecerá en la prensa y que causará furor entre los reguladores, los accionistas y el público.

- Ninguna empresa puede mantenerse al día con el cambio de ritmo en los métodos de ataque y la tenacidad si sus únicas armas son más SAST, DAST y Pen Testing. Toda empresa necesita un SSI completo que responda a las necesidades relacionadas con la gestión de proveedores, gestión de código abierto, gestión de competencias, puntos de control SDLC seguros, privacidad y cumplimiento, políticas y estándares, gestión de defectos y un satélite saludable integrado en los equipos de ingeniería. Incluso esas cosas requieren un fuerte inventario de software y un seguimiento efectivo de los proyectos de software. También dependen de buenas elecciones y mantenimiento rápido por parte de los grupos de IT Security y Enterprise Architecture. Luego, tiene una inteligencia de ataque confiable para saber qué están haciendo los chicos malos y alguna orientación sobre lo que están haciendo los SSI maduros (consulte, por ejemplo, www.bsimm.com). Todo eso ayuda a decidir qué tipo de prueba (descubrimiento de defectos de seguridad) es necesaria para cada pieza de software en la cartera de la empresa. ¿Revisión manual del código? SAST? DAST? ¿Pruebas de penetración? IAST? ¿RASPAR? ¿Fuzzing? ¿Modelado de amenazas? ¿Revisión segura del diseño? Análisis de riesgo de arquitectura? ¿Que profundo? ¿Con qué frecuencia? ¿A dónde van todos los errores? ¿Qué se soluciona? ¿Cuan rápido? ¿Quién puede aceptar el riesgo? Hay un hilo de gobernanza que debe ejecutarse a través de todo el SSI que hace la mayor prevención posible, y proporciona la detección y reacción necesarias para garantizar que la cartera de software esté protegida adecuadamente. Luego, usa métricas para asegurarte de que todo se mueve en la dirección correcta.

Por supuesto, habrá otras razones particulares para su empresa. ¿Eres un fabricante de automóviles? Se necesitará un SSI real para tomar nuevos componentes de docenas de proveedores que comprenden millones de líneas de código y convertirlos en un automóvil que satisfaga la percepción de privacidad y seguridad del público.

Descubre la innovación

Para asegurar el éxito empresarial, ahora y a futuro, es imprescindible maximizar el retorno de la inversión existente en software, a la vez que innovar y adoptar nuevas tecnologías. Los retos que hay abordar para competir en un mundo de TI Híbrida incluyen DevOps, Seguridad, Gestión de riesgos y Análisis predictivo. Puedes obtener más información sobre cómo abordar estos retos e innovar en este enlace.