¿Cuál es el proceso de creación de una barra de errores?

En mi empresa, estamos trabajando para adoptar el ciclo de vida de desarrollo seguro de Microsoft, y parte del proceso de MSDL implica establecer barras de errores de seguridad y privacidad desde el inicio de un proyecto. Escuché el concepto de una barra de errores antes de MSDL, y entiendo que es esencialmente una definición de qué nivel / cantidad de errores está dispuesto a aceptar en un producto final, pero he nunca entendí cómo crear una barra de errores para un proyecto. ¿Hay algún proceso bien documentado para establecer barras de errores del que pueda aprender?

He intentado buscar en Google ejemplos o escenarios de proyectos del mundo real definir barras de errores al inicio de un proyecto, pero parece que no puedo obtener buenos resultados o consejos sobre el proceso de establecimiento de una barra de errores. Hay ejemplos de MSDL de lo que parecen ser barras de errores completadas, pero estoy interesado en aprender sobre el proceso de definir algo como esto. Por ejemplo, para aquellos que han hecho algo como esto antes, ¿ha definido barras de errores de una manera muy específica (por ejemplo, diciendo " No debe haber acceso no autorizado al sistema de archivos: leyendo desde el "), o ha adoptado un enfoque diferido de decir que cuando encontremos errores los calificaremos en una escala de 1 a 5 (siendo 5 el más grave), establezca ahora que no se enviarán errores por encima de un 3 y dejará su clasificación de errores hasta que se descubran? Siento que intentar hacer lo primero es una actividad tonta e imposible, pero lo último tiende a inclinarse hacia la indulgencia cuando un proyecto está llegando al final.

De nuevo, para terminar con todo eso en una pregunta sucinta, ¿alguien puede proporcionarme un enfoque bien documentado para definir / crear barras de errores?

Responder

Let » s comienzan con una definición básica para Bug Bar:

Las puertas de calidad y las barras de errores se utilizan para establecer niveles mínimos aceptables de seguridad y calidad de privacidad. Un equipo de proyecto debe negociar puertas de calidad (por ejemplo, todas las advertencias del compilador deben ser evaluadas y corregidas antes del registro del código) para cada fase de desarrollo. Una barra de errores es una puerta de calidad que se utiliza para definir los umbrales de gravedad de las vulnerabilidades de seguridad, por ejemplo no hay vulnerabilidades conocidas en la aplicación con una calificación de «crítica» o «importante» en el momento del lanzamiento. La barra de errores, una vez configurada, nunca debe relajarse.

Cuando un usuario de software presenta un informe de error, debe asignar una categoría STRIDE al error, si el error es un error del cliente o del servidor, y el alcance que afecta el error. Los usuarios pueden ser desarrolladores de software y personal de control de calidad. STRIDE significa:

  • Spoofing
  • Manipulación
  • Repudio
  • Divulgación de información
  • Denegación de servicio (DoS)
  • Elevación de privilegios (EoP)

Los valores de «alcance» relevantes son

  • Cliente: IU de confianza falsificada en escenario común / predeterminado
  • Cliente: interfaz de usuario de confianza falsificada en otro escenario específico
  • Cliente: interfaz de usuario falsificada como parte de un escenario de ataque mayor
  • Servidor: usuario específico falsificado o computadora sobre protocolo seguro
  • Servidor: usuario aleatorio falsificado o computadora sobre protocolo seguro
  • Cliente: datos confiables alterados que persisten después del reinicio
  • Cliente: datos alterados que no persiste después de reiniciar

A partir de ahí, se crea una matriz que asigna un nivel de severidad a cada combinación. Los valores posibles para el nivel de gravedad son:

  1. Crítico
  2. Importante
  3. Moderado
  4. Bajo
  5. Ninguno

Ejemplo de entrada en la matriz (puede haber varias de estas entradas):

STRIDE Categoría: Spoofing
Alcance: Cliente: IU de confianza falsificada en un escenario común / predeterminado

Descripción: Capacidad del atacante para presentar una interfaz de usuario que es diferente pero visualmente idéntica a la interfaz de usuario en la que los usuarios deben confiar para tomar decisiones de confianza válidas en un escenario predeterminado / común. Una decisión de confianza se define como cualquier momento en que el usuario realiza una acción creyendo que una entidad en particular presenta cierta información, ya sea el sistema o alguna fuente local o remota específica.

Nivel de gravedad: Importante

Microsoft afirma que corrige todos los errores que tienen una importancia superior a «baja» antes de la implementación.

Lectura adicional
Agregar una barra de errores de seguridad a Microsoft Team Foundation Server 2010
Nuevo SDLC: ciclo de vida del desarrollo de la seguridad

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *