Históricamente, la seguridad computacional ha estado basada en el uso de un conjunto de herramientas genéricas y soluciones que proporcionan una fortificación o defensa perimetral para las aplicaciones que están siendo protegidas. En la mayoría de los casos, estas soluciones de seguridad fueron agregadas o ideas tardías. Más aún, el ambiente abierto, ilimitado, altamen- te vulnerable y altamente colaborativo que presenta la Internet vuelve altamente inefectivos estos modelos de fortaleza. La supervivencia puede ser pensada como una solución de inge- niería de software que integra la seguridad computacional dentro del proceso de diseño y desarrollo de software desde su inicio. Protege la misión específica de la misión, proporciona el reconocimiento de los problemas que no pueden ser evitados totalmente, y provee esquemas de recuperación cuando los ataques (o los accidentes o las fallas de componentes) no pueden ser completamente evitados. El equilibrio entre gestión de riesgo e ingeniería son parte in- herente del proceso de desarrollo para los sistemas con capacidad de supervivencia.
Por lo tanto, las estrategias de supervivencia deben estar integradas a todo el ciclo de vida del desarrollo del software. Esto impone un reto particularmente fuerte al desarrollo de software basado en COTS, ya que las implicancias del desarrollo de este tipo de sistemas basado en COTS (COTS-Based System -CBS-) son desalentadoras. Con el modelo de fortaleza o basado en el perímetro, un CBS se debería desarrollar con poca o ninguna atención de la seguridad compu- tacional, y al que luego se le debería agregar una defensa perimetral basada en COTS (por ejemplo, un firewall comercial más un paquete de encriptación, etc.) para mejorar la seguridad. Sin embargo, la capacidad de supervivencia es una propiedad global que emerge de las interac- ciones entre los componentes del sistema y resulta dificultoso discernir cuándo las cualidades intrínsecas son completamente conocidas. Con los COTS, muchos de los atributos de calidad de software son desconocidos y difíciles de analizar sin tener acceso al código fuente u otros arte- factos del proceso de ingeniería de software.
Metas a largo plazo exigen de la creación de metodologías prácticas de desarrollo de software para la construcción de CBSs seguros y con capacidad de supervivencia. Se prevé trabajar en dos áreas complementarias de investigación de ingeniería de software: (1) la supervivencia para las actividades de desarrollo de software tradicional (es decir, a medida), y (2) actividades del ciclo de vida del CBS.
Al principio del presente trabajo se analizó la investigación sobre las metodologías de desarrollo de sistemas con supervivencia focalizado en el ciclo de vida de desarrollo de software tradicio-
nal, y asociado con las actividades de supervivencia. Desafortunadamente, estas actividades del ciclo de vida tradicional (enriquecido con los elementos de supervivencia) no puede ser aplica- do directamente al desarrollo de sistemas basados en COTS. Como ya se planteara, los CBSs imponen desafíos especiales y severos a cualquier equipo de desarrollo de software. El mayor desafío es el de lidiar con información extremadamente limitadas acerca de los atributos de cali- dad del software de los productos COTS que se encuentran bajo consideración para ser utiliza- dos como componentes del sistema. Generalmente, ninguno de los artefactos del proceso de ingeniería de software tradicional (código fuente, lógica de diseño, ambientes de testeo y resul- tados de testeo, etc.) son fáciles de obtener; para el caso de un típico producto COTS resulta casi imposible discernir qué criterios se aplicaron (explícita o implícitamente) a nivel de ingeniería del software sobre los diferentes componentes de la calidad (desempeño, seguridad, disponibili- dad, mantenibilidad, usabilidad, etc.). Resulta innecesario decir que ésta es una desventaja seve- ra para un equipo de desarrollo que está tratando de construir un sistema con capacidad de su- pervivencia a partir de componentes COTS.
Un paso importante es una extensión del modelo de ciclo de vida en espiral para incorporar las actividades de supervivencia. Esto se muestra en la Figura 14.
Figura 14. Modelo de ciclo de vida en espiral con actividades de supervivencia.
Imponerle al desarrollo de CBSs un proceso de ingeniería de software basado en principios ha sido el centro de la investigación inicial en las actividades del ciclo de vida de sistemas basados
Implementación Integración Arquitectura
Valorización de la competencia del fabri- cante y de la calidad del
producto
Análisis de la vulnerabilidad
Análisis del impacto
Refinamiento del diseño del sistema
Verificación y validación del diseño Valorización del asegu-
ramiento del diseño Plan de refinamiento del sistema Alternativas de diseño Alternativas de fabricante Restricciones de asegura- miento I Objetivos, Alternativas, Restricciones IV Planificación II Análisis de Riesgo y Mitigación III Desarrollo del Producto Ambiente de intrusión Servicios esenciales Necesidades mínimas Ciclo de vida de la supervivencia y planificación del asegura- miento Requerimientos de superviven- cia Relevameinto de tecnología COTS relevan- te Valorización de la propia experticia en la gestión de COTS Adversarios principales
en COTS [Brownsword 00, Oberndorf 00]. Si bien los aspectos relativos con la seguridad y la supervivencia no fueron tratados explícitamente en los primeros trabajos referidos, dicha inves- tigación sirve como un basamento (junto con la investigación actual sobre la supervivencia para las actividades del ciclo de vida tradicional) en el desarrollo de una metodología para la cons- trucción de CBSs con capacidad supervivencia.
El ciclo de vida de los CBSs incluye cuatro áreas de actividad, cada una de las cuales tiene varias áreas [Oberndorf 00]:
1. Área de Actividad de Ingeniería
Contexto del Sistema, Arquitectura y Diseño, Mercado, Construcción, Gestión de la Configuración, Implantación y Soporte, Evaluación.
2. Área de Actividad del Negocio
Caso del Negocio del COTS, Estimación del Costo del COTS, Relaciones con el Pro- veedor Interno, Relaciones con el Fabricante.
3. Área de Actividad de Alcance del Proyecto
Estrategia CBS, Gestión del Riesgo del COTS, Balanceo CBS, Compartición de Infor- mación, Transición Cultural.
4. Área de Actividad del Contrato
Requerimientos del Contrato, Seguimiento y Supervisión del Contrato, Solicitud, Nego- ciación del Licenciamiento.
A su vez, cada sub-área incluye un conjunto de actividades. El conjunto completo de activida- des se muestra en la Tabla 8. (Observar que las actividades dentro del área de actividad no son secuenciales excepto cuando se lo indique).