Prefacio al artículo
Una vez desarrollado el producto de software, no solo es necesario realizar pruebas funcionales de las funciones comerciales para juzgar si satisfacen las necesidades reales del solicitante, sino que también es necesario realizar pruebas de seguridad del producto para detectar la seguridad general del producto. En el proceso de SDL, si el producto va a lograr el desarrollo, los estándares de versión no solo deben cumplir con los objetivos comerciales funcionales esperados establecidos por los gerentes de producto y los gerentes de proyecto, sino que también deben cumplir con los estándares de seguridad y calidad.
Objeto de medición
Los productos de software se pueden dividir ampliamente en las siguientes categorías:
Sistema interno: el sistema desarrollado por la empresa para uso interno, como por ejemplo: software de comunicación interna, sistema de base de datos interno, etc.
Sistema externo: el sistema desarrollado por la empresa y lanzado al mundo exterior, como: el sitio web oficial externo de la empresa, el sistema de oficina extranet de la empresa
Compra de productos: productos de seguridad, productos de oficina colaborativa y otros sistemas de software desarrollados por terceros que las empresas eligen comprar después de evaluar productos en la industria.
Métrica
También existen diferentes métricas de calidad de seguridad del software para diferentes tipos de productos de software:
Sistema interno: el sistema interno desarrollado por la empresa solo necesita cumplir con los requisitos de que no haya vulnerabilidades de alto y alto riesgo en la máquina host y que no haya vulnerabilidades de alto y alto riesgo en el escaneo web.
Sistema externo: el sistema desarrollado por la empresa y lanzado al mundo exterior debe cumplir con los requisitos de escaneo de fugas web, penetración manual y auditoría de seguridad del código, no debe tener vulnerabilidades de riesgo medio y cumplir con los estándares de la lista de verificación de diseño de seguridad.
Compra de productos: el tercero debe proporcionar materiales de certificación de seguridad del producto y debe incluir un acuerdo de responsabilidad de seguridad y un servicio posventa de parada de emergencia al firmar un contrato. Los materiales de certificación de seguridad aquí generalmente se refieren a informes emitidos por empresas de seguridad de terceros. , incluidos informes de auditoría de código, escaneos fallidos del escáner principal, informe de prueba de penetración, lista de componentes de código abierto (tipo de componente de código abierto dependiente e información de versión)
Calificación de vulnerabilidad
Las empresas pueden clasificar las vulnerabilidades según la importancia de su propio negocio, los estándares de la industria y las leyes y regulaciones. El siguiente es un ejemplo simple:
calificación |
Descripción de los criterios de evaluación (cumple una de las siguientes condiciones) |
||||||||||
Bajo |
1) No se encontraron problemas de seguridad obvios |
||||||||||
2) No se desvía de los estándares y especificaciones relevantes de la industria nacional. |
|||||||||||
3) La explotación de agujeros de seguridad no causará riesgos de seguridad obvios para el sistema (por ejemplo, la explotación de agujeros de seguridad solo obtendrá cierta información de los componentes del sistema) |
|||||||||||
4) Otras vulnerabilidades de seguridad con el mismo grado de daño que el anterior |
|||||||||||
medio |
1) La desviación de los estándares y especificaciones relevantes de la industria nacional causará problemas como la exposición parcial de la información, pero no causará directamente problemas graves (como la lectura de la base de datos backend). |
||||||||||
2) La explotación de agujeros de seguridad tendrá un cierto impacto en el sistema (como la obtención de información no confidencial en el proceso de comunicación) |
|||||||||||
3) Aunque la explotación de vulnerabilidades de seguridad tendrá un impacto grave en el sistema, no es fácil de explotar. |
|||||||||||
4) Otras vulnerabilidades de seguridad con el mismo grado de daño que el anterior |
|||||||||||
alto |
1) La desviación de los estándares y especificaciones relevantes de la industria nacional y la desviación causarán directamente problemas graves (por ejemplo: obtener el código fuente del programa, poder leer y escribir archivos del sistema de forma remota o manipular datos en segundo plano, poder ejecutar comandos de forma remota como un comando normal). usuario o realizar ataques de denegación de servicio), puede ejecutar comandos de forma remota como usuario administrativo, etc.) |
||||||||||
2) La explotación de vulnerabilidades de seguridad tendrá un impacto grave en el sistema y es fácil de explotar (por ejemplo: obtener el código fuente del programa, leer y escribir archivos del sistema de forma remota o manipular datos en segundo plano, ejecutar comandos de forma remota como un usuario normal o realizar denegaciones de ataques al servicio, ejecutar comandos de forma remota como usuario administrativo, etc.) |
|||||||||||
3) Otras vulnerabilidades de seguridad comparables a las anteriores |
|||||||||||
Resumen al final del artículo.
La seguridad y la calidad del producto determinan si el producto puede cumplir con los requisitos de lanzamiento y si se puede lanzar a tiempo. Por lo tanto, cuanto antes se implementen y publiquen los estándares de medición de seguridad y calidad del producto y las regulaciones de lanzamiento de productos de SDL, mejor. Al mismo tiempo Al mismo tiempo, los gerentes de productos, gerentes de proyectos y personal de I + D prestan más atención a los problemas de seguridad durante el ciclo de desarrollo de software para evitar fallas al conectarse debido a problemas de seguridad o refactorización de las funciones del producto en la etapa posterior.