Piensa, haz y fluye - LIBRO
SRE, Security Requirement Engineering, desarrollo seguro
Auditoría de código,  Ciberseguridad,  Desarrollo seguro

Requisitos de seguridad en software: Security Requirement Engineering (SRE)

En el desarrollo de software es un habitual la especificación de requisitos, para describir como debe comportarse el software. Dentro de esta descripción donde se pueden distinguir dos niveles: el funcional y el organico, también deben estar disponibles los requisitos que concretamente atienden a la seguridad. Estos requisitos son similares a los tradicionales pero tienen algunas diferencias a causa de que surgen puramente desde el punto de vista y la práctica de la ciberseguridad.

Verónica Hontecillas Mentor - Coach Experta en inteligencia emocional

¿Qué es el desarrollo seguro?

Los requisitos de seguridad pueden atender a un contexto de componentes software ya desarrollados, por ejemplo durante la instalación, despliegue, etc… En cambio aquí vamos a tratar los requisitos de seguridad enmarcados dentro del desarrollo de un componente software, cuando este se esta construyendo.


SRE, Security Requirement Engineering, desarrollo seguro, 2
SRE, Security Requirement Engineering, desarrollo seguro

En este sentido la ingeniería de requisitos de seguridad: Security Requirement Engineering (SRE), es una aproximación sistemática para identificar, analizar, obtener y especificar estos requisitos. Esta practica juega un papel fundamental en el desarrollo seguro, ya que mediante esta se integra la seguridad en el proceso de desarrollo de software y es la primera tarea de seguridad a realizar dentro del proyecto de desarrollo.

En este punto se puede trabajar mediante varias técnicas: cumplimentación de fichas y cuestionarios, entrevistas con los diferentes stakeholders, lluvias de ideas, descripción mediante una pizarra, dibujos, etc… Y puede recogerse la información en muchos formatos: formato simple del requisito, casos de uso orientados a un usuario, casos de abuso orientados a una explotación del sistema, historias de usuario, maquetación y ejemplos, etc… No hay ningún formato o herramienta acertada que nos garantice un trabajo de calidad y completo, se trata de un arte en manos del analista.


caso de abuso, Security Quality Requirements Engineering (SQUARE)
Interrelación entre casos de abuso y requisitos de seguridad, desarrollo seguro

Como guía para revisar que los requisitos, tanto de seguridad como los tradicionales de desarrollo, tienen una calidad y una completitud, puede enfrentarse estos al criterio de objetivos SMART:

  • Specific – target a specific area for improvement.
  • Measurable – quantify or at least suggest an indicator of progress.
  • Assignable – specify who will do it.
  • Realistic – state what results can realistically be achieved, given available resources.
  • Time-related – specify when the result(s) can be achieved.

El ámbito de la ciberseguridad abre un interesante marco que siempre es olvidado en un desarrollo de software: el ataque y la defensa del sistema, el punto de vista desde la mala intención y explotación de vulnerabilidades. Es por esta razón que los requisitos específicos de seguridad pueden tener un formato y motivación diferentes a los habituales. Mientras que los requisitos de desarrollo de software habitualmente se trabajan desde la positividad, desde satisfacer al negocio a los usuarios y enunciando en positivo cualidades del sistema; los requisitos de seguridad muchas veces requieren de negatividad, en cuanto a pensar en el peor escenario posible, uso malicioso de recursos, y enuncian en negativo, que no debe de poder ocurrirle al software.

Este punto de vista nos obliga a ponernos en el lugar del atacante, lo que nos ayuda a identificar las amenazas sobre los diferentes activos y recursos del sistema, entender que requerimos para que una explotación no pueda llegar a tener lugar y relacionar todo esto con los controles de seguridad que hemos de disponer. A continuación se expone un ejemplo de caso de abuso para ilustrarlo:


Requisito de seguridad – Caso de abuso 053
TítuloComo agente de amenaza interno, se intenta introducir en el sistema archivos XML maliciosos, entonces se controla validación de entrada de datos y se produce una devolución de error.
¿Quien?Agente de amenaza con posibilidad de uso de la funcionalidad de ingesta de datos.
¿Cuándo?Durante el uso de la funcionalidad de ingesta de datos.
¿Donde?http://www.contoso.com/es/Ingesta_XML.jsp
Objetivo inmediatoConseguir introducir datos maliciosos al sistema.
Objetivo final Producir un ataque de inyección. Por ejemplo un ataque de tipo inyección SQL que permita leer y modificar los datos de la base de datos del entorno de producción.
Contexto/precondicionesSe presupone que el agente de amenaza ya ha comprometido el sistema, hasta el punto de que puede realizar uso de la funcionalidad de ingesta de datos (en este caso de abuso se abstrae del control de autenticación).
Respuesta/postcondicionesEsta entrada de datos es validada en cuanto a tamaño y forma. Impidiendo en este control de forma, conjuntos de caracteres especiales que puedan causar un incidente de seguridad.
Resultado esperadoMensaje de error descriptivo sobre el campo invalido. Valorar el registro de esta actividad como evento de seguridad en determinados casos.
ComentariosCriminal de la computación. – Alteración no autorizada de los datos – Acto fraudulento (por ejemplo, repetición, personificación, interceptación).
Elementos relacionados Historia de usuario 048 HU – Ingesta de datos en formato XMLStride – Tampering o manipulación no autorizada
Cumple resultado esperado: [  ] Sí – [  ] No

Otro formato podría ser la redacción más simple en forma de requisito de cumplimiento, como por ejemplo los usados en las guías del CCN:


Nombre:037 – Revisión y eliminación de usuarios no necesarios
Descripción:Como se ha comentado anteriormente, por defecto el sistema operativo, crea configuraciones para facilitar el uso del mismo, una de esas configuraciones, son los usuarios predefinidos como ftp, games, etc. Estos usuarios tienen permisos y configuraciones para ciertas partes del sistema operativo.  El  tener  usuarios  predefinidos  en  el  S.O  puede  ser motivo  de  posibles  brechas  de seguridad. Por  esto,  los  usuarios  de  un  sistema  operativo tienen  que  ser  los  mínimos  necesarios  e indispensables, eliminando los que no sean necesarios y restringiendo ciertos permisos a los que por necesidad deban mantenerse.
Referencia:Guía del CCN-STIC-619 Seguridad sobre CentOS 7 (Cliente Independiente) v1.0: https://www.ccn-cert.cni.es/pdf/guias/series-ccn-stic/guias-de-acceso-publico-ccn-stic/3674-ccn-stic-619-implementacion-de-seguridad-sobre-centos7/file.html
Cumple:[  ] Sí – [  ] No
Observaciones: 

¿Qué es una auditoría de código?


Pasos de una static application security testing (SAST), desarrollo seguro, AuditoriaDeCodigo.com
Pasos de una static application security testing (SAST), desarrollo seguro, AuditoriaDeCodigo.com

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

error

Enjoy this blog? Please spread the word :)

error: