Gestión de riesgos de software
El requisito más importante para la administración de riesgos de software es adoptar
una metodología de ingeniería de software de alta calidad que permita buenas
prácticas de gestión de riesgos, la metodología principal es el modelo espiral, el
modelo espiral postula que el desarrollo es el mejor realizado haciendo el mismo tipo
de cosas. Una vez más, en lugar de correr en círculos. Sin embargo, la idea es ir en
espiral hacia el objetivo final, que generalmente es un producto completo y sólido.
Gran parte de la repetición en el modelo espiral a menudo se reduce a refinar su
producto en base a nuevas experiencias.
En el modelo en espiral, la primera actividad es derivar un conjunto de requisitos.
Los requisitos son esenciales. Desde el punto de vista de la seguridad, debe
asegurarse de considerar la seguridad cuando se derivan los requisitos.
Recomendamos dedicar algo de tiempo a hablar sobre la seguridad como su propio
tema, para que se cumpla.
La segunda actividad es identificar su mayor riesgo y evaluar estrategias para
resolver esos riesgos. La identificación del riesgo se logra mediante el análisis de
riesgos. Claramente, los profesionales lo harán mucho mejor en términos de
seguridad si tienen en cuenta los requisitos de seguridad al realizar un análisis de
riesgos. En esta etapa, así como durante la fase de requisitos. Consideramos que es
bueno realizar un análisis de seguridad completo para garantizar que se aborde la
seguridad.
Un ejercicio de gestión de riesgos puede comenzar en cualquier momento durante el
ciclo de vida general del software, aunque se aplica lo más pronto posible, para
cualquier proyecto dado, es probable que haya algo de contaminación en el ciclo de
vida más allá del cual la administración de riesgos del software sea muy costosa. Sin
embargo, nunca es demasiado tarde.
En la pinta del ciclo de vida en que comienza la administración del riesgo del
software, todos los artefactos existentes y las partes interesadas involucradas se
pueden usar como recursos para identificar el riesgo del software. Documentos de
requisitos Los documentos de arquitectura y diseño, los modelos, cualquier código
existente e incluso los casos de prueba son artefactos útiles.
A continuación, se abordan los riesgos, a menudo a través de la creación de
prototipos, y se puede realizar cierta validación para garantizar que una posible
solución gestione los riesgos de forma apropiada, dado el contexto comercial.
Cualquier solución de este tipo se integra en el estado actual de las cosas; quizás el
código será modificado. Quizás el diseño y los requisitos se actualizarán también.
Finalmente, el próximo está planeado.
La clave del modelo espiral es que se aplica en iteraciones locales en cada hito
durante las fases del ciclo de vida del software. Cada ciclo de gestión de riesgos de
software local implica la aplicación de la misma serie de pasos, iteraciones locales
del riesgo de gestión del ciclo en un nivel más refinado, y se aplica específicamente
al ciclo de vida fase durante la cual se realizan. Como resultado, los proyectos se
vuelven más resistentes a cualquier problema que surja en el camino.
Este modelo contrasta fuertemente con el modelo de cascada más antiguo, que
tiene todo el desarrollo en orden, sin mirar atrás ni retroceder para abordar las
preocupaciones recientemente identificadas. La ingeniería de software se basa en
un intento de formalizar el desarrollo de software, inyectando cierta cordura en lo
que a menudo se percibe como un esfuerzo demasiado creativo.
La creación de software seguro se basa en gran medida en la disciplina de la
ingeniería de software, tomando prestados libremente métodos que funcionan y
haciendo uso de artefactos de ingeniería críticos. Tenga en cuenta, sin embargo,
que algunos profesionales de la ingeniería de software exageran el proceso en
detrimento de la comprensión y adaptación del comportamiento del software.
Creemos que el proceso es algo relacionado con los alimentos, pero el análisis del
producto final (el software mismo) es una práctica esencial.
El rol del personal de seguridad
Acercarse a la seguridad como la gestión del riesgo puede no ser fácil para algunas
organizaciones. Uno de los problemas que se encuentran en el mundo real es la
desconexión entre lo que llamamos "bandas errantes de desarrolladores" y el
departamento de seguridad del departamento de tecnología de la información.
Aunque hemos dicho que la seguridad se integra de manera directa en las
metodologías de ingeniería de software, aún requiere tiempo y experiencia. Un
enfoque factible para cerrar la brecha es hacer que la seguridad del software sea el
trabajo de alguien. El truco es encontrar a la persona correcta.
Se requieren dos calificaciones principales para un líder de seguridad de software:
(1) una comprensión profunda del desarrollo de software y (2) una comprensión de
la seguridad. De estos dos, la primera calificación es probablemente la más
importante.
La declaración anterior puede sonar extraña proveniente de un par de personas de
seguridad. Baste decir que ambos fuimos desarrolladores (y conocedores del
lenguaje de programación) antes de ingresar a la seguridad. Los desarrolladores
tienen un radar altamente sincronizado. Nada molesta a un desarrollador más que
una reunión inútil con personas que aparentemente no "entienden". Los
desarrolladores quieren hacer las cosas, no preocuparse por las casillas de
verificación y pasar las revisiones.
Desafortunadamente, la mayoría de los desarrolladores ven a las personas de
seguridad como obstáculos a superar, principalmente debido al enfoque basado en
la "revisión" del ciclo de vida tardío que muchas organizaciones parecen usar.
Este factor se puede convertir en una ventaja para la seguridad del software. A los
desarrolladores les gusta escuchar a personas que pueden ayudar a que su trabajo
sea mejor. Esta es una razón por la cual la experiencia de desarrollo real es un
requisito crítico para una persona de seguridad de software exitosa. Un especialista
en seguridad de software debe actuar como recurso para el desarrollo
personal en lugar de un obstáculo. Esto significa que los desarrolladores y
arquitectos deben tener motivos para respetar el cuerpo de conocimientos que la
persona aporta al trabajo. Es más probable que se consulte un recurso útil al
principio de un proyecto (durante las fases de diseño y arquitectura), cuando se
puede lograr lo mejor.
Con demasiada frecuencia, el personal de seguridad asignado para revisar la
seguridad de las aplicaciones no son desarrolladores. Esto les hace hacer preguntas
que nadie con experiencia en desarrollo podría hacer. Y hace que los
desarrolladores y arquitectos pongan los ojos en blanco y se burlen. Por eso es
fundamental que la persona a cargo de la seguridad del software realmente conozca
el desarrollo.
Saber todo lo que no se sabe sobre el desarrollo de software es, en sí mismo,
insuficiente. Un profesional de seguridad de software también necesita saber sobre
seguridad. En este momento, no hay sustituto para la experiencia directa.
Una vez que se identifica un líder de seguridad del software, él o ella debe ser el
recurso principal para desarrolladores y arquitectos o, preferiblemente, debe
construir un recurso de primer nivel para otros desarrolladores y arquitectos o,
preferiblemente, debe construir un recurso de primer nivel para otros desarrolladores
. Por ejemplo, es una buena práctica proporcionar un conjunto de pautas de
implementación para que los desarrolladores las tengan en cuenta cuando la ventaja
de seguridad no esté comenzando por encima de sus hombros (generalmente esta
es una mala idea, por supuesto). Crear un recurso de este tipo al que los
desarrolladores y arquitectos puedan acudir en busca de ayuda y asesoramiento
durante todo el ciclo de vida del software requiere algo de esfuerzo. Un factor crítico
es comprender y desarrollar el conocimiento de los conceptos de desarrollo
avanzado y su impacto en la seguridad.
En muchos proyectos, tener un grupo de ingenieros de seguridad puede ser
rentable. Los desarrolladores y arquitectos quieren fabricar productos sólidos. Cada
vez que el personal de seguridad ayuda a las personas en un proyecto a cumplir
este objetivo sin ser visto como un impuesto u obstáculo, el proceso puede hacer
maravillas.
Personal de seguridad de software en el ciclo de vida.
Otro trabajo para el software es que él o ella debe ser responsable de asegurarse de
que la seguridad esté representada de manera justa durante cada fase del ciclo de
vida del software. Este ingeniero podría ser líder o podría ser otro individuo. Durante
cada fase, debe ser la mejor persona (o personas) disponible para el trabajo.
Evaluación de riesgos
Un enfoque eficaz basado en el riesgo requiere un conocimiento experto de la
seguridad. El administrador de riesgos debe ser capaz de identificar situaciones en
las que los ataques conocidos podrían aplicarse potencialmente al sistema, ya que
pocos ataques totalmente únicos se le ocurren. Desafortunadamente, se sabe que
se obtiene ese conocimiento experto.
La identificación del riesgo funciona mejor cuando se tiene una especificación
detallada del trabajo de un sistema. Es invaluable tener un recurso definitivo para
responder preguntas sobre cómo se espera que el sistema actúe en circunstancias
particulares. Cuando las especificaciones están en el centro de desarrollo, y no en
papel, todo el proceso se vuelve mucho más borroso. Es muy fácil consultar sus
requisitos mentales dos veces y obtener información contradictoria sin darse cuenta.
Una vez que se han identificado los riesgos, el próximo paso es clasificar los riesgos
en orden de gravedad.
Cualquier clasificación de este tipo es una tarea sensible al contexto que depende
de las necesidades y los objetivos del sistema.
Algunos riesgos pueden no valer la pena mitigar. La clasificación de los riesgos es
esencial para asignar los recursos de prueba y análisis más adelante, porque la
asignación de recursos es un problema comercial, por lo que las buenas decisiones
comerciales con respecto a dicha asignación requieren datos sólidos.
