Una guía completa para mitigar el riesgo en la ingeniería de software

escritura-mano-hombre-tablero-tecnología-internet-710487-comprimido

Puede parecer imposible desarrollar software y mantener su seguridad integrada, ya que potencialmente está agregando nuevas vulnerabilidades al producto a medida que lo actualiza. Para reducir el riesgo durante el desarrollo del software y el proceso de ingeniería, debe incluir a los profesionales de la ciberseguridad a lo largo de su ciclo de vida de desarrollo de software ( SDLC ) para obtener un perfil de seguridad maduro.

Los Principios Rectores de la Mitigación de Riesgos de SDLC

En el desarrollo de software, la mitigación de riesgos es paralela a los procesos seguidos por las empresas tradicionales. El Proyecto de seguridad de aplicaciones web abiertas ( OWASP ) describe que el Modelo de madurez de Software Assurance (SAMM) debe centrarse en la evaluación, formulación e implementación de una estrategia de seguridad de software sólida que pueda integrarse fácilmente en el SDLC.
Por lo tanto, independientemente de la metodología de desarrollo de software que utilice, puede mitigar el riesgo siguiendo un proceso de administración de riesgos comprobado que le permite asegurar el software en el que está trabajando durante todo el proceso de desarrollo.

Cómo aborda SAMM la mitigación de riesgos

El Proyecto de software de aplicación web abierta (OWASP) incorpora la respuesta al riesgo y la mitigación a lo largo del ciclo de desarrollo del software. Funcionalmente, cada uno de los grupos dentro de la organización que trabajan en el proceso de desarrollo de software retiene la responsabilidad durante diferentes puntos de su ciclo.
Como resultado, OWASP descompone el proceso en funciones comerciales esenciales de la harina con cada función involucrada en una actividad diferente de administración de riesgos. Por lo tanto, las responsabilidades de mitigación de riesgos están integradas tanto en el SDLC como en los niveles de su organización. Esto garantiza que el software en el que está trabajando permanezca protegido durante su proceso de desarrollo y una vez finalizado.

1. Las responsabilidades de las funciones de gobierno

Según la definición de OWASP, la gobernanza se centra en los resultados comerciales y los entregables, que incluyen Estrategia y Métricas (SM), Política y Cumplimiento (PC) y Educación y Orientación (EG).
  • La práctica de estrategia y métricas (SM): se centra en establecer un marco para un programa de garantía de seguridad de software dentro de su organización para definir objetivos de seguridad mensurables en línea con su riesgo empresarial real.
  • La Práctica de Políticas y Cumplimiento (PC) : garantiza el cumplimiento no solo a través de los estándares de seguridad internos, sino que también se centra en el cumplimiento de los requisitos legales y reglamentarios externos. PC Practice crea auditorías para proporcionar la seguridad necesaria.
  • La práctica de educación y orientación (EG, por sus siglas en inglés): se enfoca en armar a todo el personal que trabaja en el ciclo de vida del software con los recursos y el conocimiento que necesita para desarrollar e implementar software seguro.

2. Las responsabilidades de las funciones de construcción.

La fase de construcción se centra en crear software y definir objetivos dentro de su proyecto. Por lo tanto, debe incluir a su equipo de gestión de proyectos en estos pasos.
  • La práctica de la evaluación de amenazas (TA): bajo la práctica de la AT, usted se enfoca en la identificación y análisis de riesgos. Esto le permite mantenerse alerta ante posibles amenazas, observar el impacto inminente que podría tener y la probabilidad de que ocurra. La evaluación de amenazas es el primer paso para mitigar el riesgo en la ingeniería de software.
  • La práctica de requisitos de seguridad (SR): La práctica de SR analiza primero todos los requisitos y protocolos de seguridad de alto nivel según la forma en que su organización pretende utilizar el software en desarrollo. La Práctica de SR luego revisa los nuevos riesgos y sus posibles estrategias de mitigación a medida que su software madura. Por lo tanto, debe considerar sus interacciones con los proveedores y seguir los estándares de auditoría de los Acuerdos de nivel de servicio (SLA).
  • La práctica de la arquitectura de seguridad (SA): la práctica de SA le permite crear seguridad de forma predeterminada en lugar de esperar hasta que complete su software. Esta práctica garantiza que su software se mantenga seguro durante su proceso de desarrollo, ya que es vulnerable a ataques incluso antes de que se complete. Por lo tanto, desea que sus equipos de proyecto se centren explícitamente en el diseño y la creación de software con un marco mental de funcionalidad de seguridad.

3. Las responsabilidades de las funciones de verificación.

La verificación se refiere al proceso de revisión, evaluación y prueba continua del software para detectar nuevos riesgos de seguridad.
  • La práctica de la revisión de diseño (DR): esta práctica evalúa el diseño y la arquitectura del software para detectar y abordar inmediatamente los problemas de manera temprana. Su objetivo principal es identificar, ubicar y abordar los riesgos de seguridad antes de que sean costosos.
  • La Práctica de Revisión de Implementación (IR) : La Práctica de IR le permite revisar el código fuente y otras configuraciones para detectar vulnerabilidades de seguridad. Durante las primeras etapas de desarrollo, puede utilizar listas de verificación simples. Sin embargo, las empresas maduras de desarrollo de software confían en la automatización para proporcionar una mayor cobertura.
  • La práctica de Pruebas de seguridad (ST): la práctica ST revisa la seguridad en el entorno de ejecución para verla funcionalmente como lo hará más adelante después de la implementación. Por lo tanto, esta práctica puede incorporar pruebas de penetración tradicionales para casos de alto nivel o evaluar otras configuraciones erróneas.

4. Las responsabilidades de las funciones de operaciones.

Las operaciones se refieren a todas las actividades que forman parte de la versión del software, incluidos el envío, el alojamiento, la operación y la implementación en el entorno de ejecución.
  • La práctica de gestión de problemas (IM): esta práctica esencialmente crea procesos para el manejo de incidentes operacionales y emite informes mediante la asignación de roles, el seguimiento de problemas y riesgos, y la organización de procesos formales de respuesta a la incidencia. Requiere además la comunicación entre las partes interesadas.
  • La práctica de protección del medio ambiente (EH) : esta práctica protege el software en desarrollo al garantizar que su infraestructura subyacente mantenga su postura de seguridad en lugar de socavarla. La implementación flexible de los parches de seguridad requiere que mantenga informado a su equipo de desarrollo y que encuentre maneras efectivas de revisar el entorno operativo.
  • La práctica de habilitación de operaciones (OE, por sus siglas en inglés): el enfoque aquí se centra en el monitoreo de riesgos para garantizar que los equipos de proyecto comuniquen todos los riesgos a los operadores y usuarios. Por lo tanto, debe crear la documentación detallada que los operadores y usuarios necesitan y compartirla con cada versión.

La importancia de integrar la seguridad en el desarrollo de software

seguridad
A medida que la demanda de usar plataformas de software como servicio se convierte en un furor generalizado con más compañías que implementan el servicio, se hace evidente que SaaS y otros servicios de software, los proveedores constituyen quizás los riesgos de violación de datos más significativos. Por lo tanto, se deduce que puede obtener una ventaja competitiva en el mercado al centrarse en la seguridad como su principal diferenciador como proveedor de servicios de software.
Sin embargo, dado que muchas plataformas SaaS también reconocen este problema emergente, muchos afirmarán ser seguros aunque no lo sean. En realidad, el entorno de datos del proveedor sigue siendo turbio. Por lo tanto, su gerente de proyecto debe estar enfocado en la administración y mitigación de riesgos del proyecto para asegurarse de que su producto de software esté realmente seguro.

Cómo las soluciones de gestión de GRC permiten la gestión de riesgos

OWASP SAMM requiere la documentación adecuada de varias partes interesadas a lo largo del ciclo de desarrollo de un producto de software. Si bien desde el principio es posible que le resulte suficiente usar una unidad compartida para administrar esta documentación, eventualmente necesitará un proceso automatizado para documentar y realizar un seguimiento de sus revisiones de seguridad si desea escalabilidad.
Aquí es donde entran las soluciones de gestión de Gobierno, Riesgo y Cumplimiento (GRC), ya que siempre le permiten administrar y priorizar sus tareas, permitiendo a todos los involucrados saber qué hacer. También puede utilizar las soluciones de administración de GRC para revisar sus tareas completadas y las listas de "tareas pendientes".
Las soluciones de gestión de GRC le permiten asignar tareas al equipo responsable del análisis de riesgos, la evaluación de riesgos y la mitigación de riesgos. Además, puede documentar las actividades de remediación que utiliza para proporcionar pruebas de que mantiene la disponibilidad, confidencialidad e integridad de los datos según lo exige la ley.
La administración de riesgos durante el desarrollo de software es una disciplina extensa, pero con las herramientas adecuadas, la información y el personal calificado, puede mitigar con éxito los riesgos en la ingeniería de software.

Acerca de: Programator

Somos Instinto Programador

0 comentarios:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

Con tecnología de Blogger.