Los expertos convienen que aunque la seguridad absoluta de la aplicación es casi imposible, hay medidas dominantes que usted debe tomar para atenuar riesgo.
Paso de progresión 1: Defina el proceso
El primer paso de progresión es definir el proceso que usted va a utilizar para desarrollar y para medir la seguridad de su software.
El desarrollo del software tiene muchas fases, de los requisitos que recolectan con diseño, el desarrollo, la prueba y el despliegue. Usted debe considerar cómo sus procesos existentes se deben aumentar en cada fase del desarrollo para incluir seguridad, dijo a Ben Chelf, principal oficial en Coverity, fabricante de la tecnología de las herramientas estáticas del análisis del código de fuente.
“Definir el proceso incluye el pensamiento de los estándares de la codificación para que sus reveladores eviten construcciones potencialmente peligrosas del código; pensando de cómo diseñar el sistema de una manera segura de modo que no haya acceso involuntario, incluso en el caso donde está a prueba de balas el código sí mismo; y así sucesivamente,” Chelf dijo.
La seguridad no es justa algo que usted puede dar una palmada encendido en el final del proceso después de que se junte el sistema, Chelf agregado. Eso es demasiado atrasado. Con un buen proceso en el lugar que atraviesa el ciclo vital entero del desarrollo del software, usted puede instalar puntos de verificación a la medida y verificar que la seguridad se está tratando apropiadamente.
Sin embargo, no hay proceso que trabaja para todas las organizaciones.
“Las compañías a que he visto como el más acertado puesto junto un equipo de los expertos de la seguridad para ayudar a definir los procesos y los estándares para el desarrollo del software que ocurre dentro de la entidad,” Chelf dijeron. “Este grupo debe ser considerado como enabler, no una palmada del ‘ en el wrist a la organización del desarrollo del software.”
El encargado de programa del grupo de Eric Bidstrup, de Microsoft para la ingeniería de la seguridad y la comunidad, el computar digno de confianza, dicho le es importantes conseguir la ayuda de la gerencia para el — seguro del desarrollo no importa qué.
“Asegure que usted tenga ayuda absoluta de la gerencia para el software seguro del edificio, incluyendo la capacidad de parar el envío de un producto si no resuelve sus especificaciones predefinidas, aprobadas y documentadas para el desarrollo seguro del software,” de Bidstrup dicho.
De hecho, la responsabilidad, prioridades y compra necesidad de ser establecido antes de que el progreso se pueda hacer en seguridad de la aplicación.
La “seguridad de la aplicación requiere una sociedad entre los equipos de la seguridad y sus contrapartes del desarrollo,” dijo a Mike Weider, director de las soluciones de la seguridad en la IBM racional. Las “organizaciones necesitan poner una prioridad en este las nuevas características al costado constructivas y los plazos el satisfacer. Esto solicita las aplicaciones internamente o externamente desarrolladas.
Los progresos de tercera persona y las compañías costa afuera necesitan ser celebrados responsables de entregar código seguro construyendo esto en los contratos legales. “
Sebastian Holst, vice presidente mayor de ventas y de la comercialización en las soluciones con derecho preferente, también recomienda un inventario detallado de existir ÉL ambiente.
“Una organización debe tener un inventario exacto qué ha desarrollado y desplegado y donde esas aplicaciones están siendo utilizadas, para qué propósitos y por quién,” de Holst dijo.
Los problemas más grandes vienen cuando las organizaciones esperan hasta el final del desarrollo para pensar de seguridad, Weider agregado.
“Apenas como [es más eficaz fijar] calidad durante la codificación que una vez en la producción, igual es verdad para la seguridad,” Weider dicho. “Es una rotación del mindset que necesita ser — creado cocer al horno-en seguridad. La prueba para la calidad necesita ir de común acuerdo con la prueba para la seguridad. El proceso del desarrollo necesita ser adaptado en un cierto plazo de modo que las organizaciones estén pensando del — durante requisitos, diseño, desarrollo de la seguridad de la aplicación enseguida y estén probando.”
Adán Kolawa, co-fundador y CEO de Parasoft, un fabricante de las herramientas automatizadas de la calidad del software, los reveladores dichos debe “realizar allí no es ningún punto negro de plata para la seguridad y esa seguridad es realmente una edición infinita.”
Kolawa agregó que es importante conseguir lejos del pensamiento de seguridad en términos de fallos de funcionamiento que fijan y en lugar de otro mirarla como cerciorándose de que los errores de la seguridad no existen en el código en el primer lugar. Los “errores de la seguridad no se pueden tratar como fallos de funcionamiento,” él dijo. “Usted puede o no puede encontrar fallos de funcionamiento, pero usted debe prevenir errores de la seguridad. Es decir usted necesita garantizar que ciertas clases de los errores de la seguridad no existan en el código.”
Paso de progresión 2: Eduque a jugadores.
El segundo paso de progresión en desarrollar software seguro es educar a los jugadores en su organización del desarrollo del software.
La seguridad del software no ha estado exactamente en la vanguardia del ingeniero informático, así que las ocasiones son sus reveladores, arquitectos, encargados de producto, no entrenan a los ingenieros del QA (garantía de calidad) y así sucesivamente correctamente en lo que significa diseñar y poner software en ejecución seguro, Chelf de Coverity dicho.
“No es apenas una cuestión de programación con seguridad,” Chelf dicho. “Si usted tiene un sistema que se ponga en ejecución perfectamente de una perspectiva de la codificación pero permite el acceso debido a las opciones pobres de la palabra de paso para los utilizadores, el sistema sigue siendo inseguro. Realmente comienza tan en la parte anterior muy del ciclo vital del desarrollo del software.”
Chelf dijo una variedad de buenos recursos, incluyendo los libros y los cursos en línea, están disponibles para los reveladores del entrenamiento en cómo los sistemas pueden ser comprometidos.
Pero además de smarts del libro, él dijo, los reveladores necesitan smarts de la calle.
“Usted puede instalar un laboratorio verdadero, con un sistema verdadero, y después explota el sistema con una hazaña anterior y sabida,” Chelf dicho. “Dé a sus equipos de reveladores la experiencia de primera mano de poner a punto el sistema explotado, de rastrear el incidente a su causa de la raíz y de ver de primera mano no sólo cómo es difícil puede ser seguir abajo el problema en un sistema explotado pero también cómo es sutil el error está probablemente que fue aprovechado. La meta de este tipo de ejercicio es conseguir a sus reveladores sentir el impacto verdadero de las vulnerabilidades de la seguridad en el sistema.”
Como un adjunto a un laboratorio, Bidstrup de Microsoft sugerido, instaló un proceso de la respuesta de la seguridad. “Y esté preparado para poner al día su ciclo vital del desarrollo de la seguridad basado en lo que usted aprende de su raíz-causa el análisis de vulnerabilidades descubiertas,” Bidstrup dicho.
La IBM Weider racional fue en cuanto decir eso que educa los reveladores es crítico a ganar la guerra en — de la seguridad y que las organizaciones necesitan adquirir la responsabilidad de esa educación. Los “reveladores consiguen raramente el entrenamiento de la seguridad durante escuela, así que ésta necesita suceder en el trabajo,” él dijo.
Paso de progresión 3: Equipe a equipo.
El tercer paso de progresión para asegurar el desarrollo es equipa a miembros del equipo de las herramientas y de las tecnologías que les ayudarán a construir aplicaciones en una manera segura desde el principio.
Chelf advirtió, sin embargo, que algunas de estas herramientas puedan retardar el — de proceso algo que molesta a encargados y a reveladores de negocio igualmente.
“No incurra en ninguna equivocación, agregando seguridad a su proceso del desarrollo del software puede potencialmente retrasar sus esfuerzos del desbloquear,” Chelf dicho. “Y no sólo está el tiempo al mercado absolutamente crítico a su negocio, sus reveladores también no goza cualquier cosa que se agrega a su proceso que los retarde abajo.”
Afortunadamente, las herramientas están disponibles que puede ayudar a los reveladores a ser más seguros y más eficientes, Chelf dicho. El análisis estático del código es una gran manera de contrariar el proceso si no-oneroso manualmente de repasar una base entera del código para el — de las vulnerabilidades de la seguridad una tarea que nadie realmente desea emprender, él dijo.
Las herramientas y las tecnologías están disponibles ayudar a organizaciones con la verificación, la validación y la seguridad y para ayudar a realzar integridad de software a través del sistema.
“Las ventajas ganadas descubriendo desertan anterior en el contrapeso del proceso del desarrollo del software el tiempo adicional que usted está pidiendo que sus reveladores pasaran en desarrollar código seguro,” Chelf dicho. “Recomiendo las herramientas de la cosecha que se diseñan para el revelador.
Usted puede escoger los analizadores que se hacen para el equipo de la intervención de la seguridad, o el QA, pero el grupo de gente más influyente como pertenece a la seguridad del software es sus reveladores del software. “
Bidstrup de Microsoft produjo eco la importancia de reducir al mínimo riesgo de vulnerabilidades de la puesta en práctica usando las herramientas estáticas del análisis del código. Él también dijo organizaciones si “utilice las mitigaciones de la defensa-en-profundidad aplicando las mejores opciones disponibles de compiladores y construya las herramientas.”
Mientras tanto, las organizaciones dichas Holst con derecho preferente “seleccionan a prácticas, a armazones, a tecnologías, a configuraciones y a surtidores comunes de asegurar estado coherente y un principio del ‘ de menos surprise a través de la empresa.”
Paso de progresión 4: Prueba y prueba otra vez.
El cuarto paso de progresión en convertirse para la seguridad es emplear técnicas seguridad-de prueba.
En el pasado, el — de la verificación que aseguraba un programa no falló el — y el — de la validación que aseguraba un programa hizo lo que fue supuesto para hacer el — era las tareas primarias a la organización del desarrollo del software necesitada para tratar antes de desbloquear, Chelf dicho.
“[Sin embargo,] la diferencia entre la verificación/la validación y la seguridad es que es mucho más difícil probar para la seguridad,” él dijo. La “prueba para cerciorarse de el programa se ejecuta correctamente y no falla es algo observable. La prueba para considerar si cierto incidente podría ser explotado es mucho más difícil de observar.”
La parte de esto proviene el hecho que, cuando el software que se convierte con seguridad en mente, usted se está convirtiendo contra un adversario, Chelf dicho.
“Esto es un paradigma mucho diverso que simplemente intentando hacer a sus clientes felices con las características que trabajan,” él dijo. “Y al trabajar contra un adversario, usted debe referirse a no sólo si un sistema falla, pero cómo falla exactamente, porque ese hacker intentará cada modo del incidente él o ella poder de intentar destapar la debilidad en su sistema.
“La realidad es que aunque su aplicación falla 99.9999 por ciento del tiempo en una manera segura, algún hacker hacia fuera allí destapará probablemente eso uno-en-uno-millón modo de fallo para explotar su aplicación,” él dijo. “Y eso es muy difícil de probar para.”
Sin embargo, la prueba vigorosa se debe hacer no obstante, los expertos de la opinión.
Los “componentes de una aplicación necesitan ser probados por separado y también otra vez junto,” Weider dicho. “Una parte de una aplicación podría ser segura en sus la propia, pero cuando el código creado por otra persona [se introduce], una nueva vulnerabilidad de la seguridad podría ser creado. La seguridad se puede nunca tomar para concedido.”
Por otra parte, Weider dicho, allí ha sido algunos adelantos increíbles en la calidad de herramientas seguridad-de prueba en el último varios años. “Utilizó conjuntamente con buenos proceso y entrenamiento, las herramientas pueden reducir perceptiblemente el coste y tiempo requerido para la seguridad que probaba,” él dijo.
Paso de progresión 5: Vigile el proceso.
Pasado, la conformidad con políticas de la seguridad se debe vigilar sobre una base en curso.
“Vigile la conformidad a las políticas de la seguridad usando una infraestructura automatizada,” Kolawa de Parasoft dicho. “En un rato programar cada noche, la infraestructura automatizada debe extraer las modificaciones más últimas del código de control de la fuente y determinarse si ese código se conforma con la política de la seguridad. Si se encuentra un problema, el revelador que lo introdujo debe ser notificado dentro de su IDE [ambiente integrado del desarrollo] para promover la remediación rápida.”
Este paso de progresión también incluye revisiones de código de seguridad y vigilancia de la seguridad que mantiene mientras que las aplicaciones se mueven en la producción.
“Ningún proyecto del desarrollo, no importa cómo está bien diseñado o ejecutado, seguirá siendo 100 por ciento asegura 100 por ciento del tiempo si está ido a sus propios dispositivos,” dijo a Andrew Zaikin, experto de la seguridad y director del proyecto en los servicios de Exigen del especialista del outsourcing.
“Mire la producción, leen registros de la producción como se están desarrollando, y permanecen implicado sobre una base constante y continua,” Zaikin dicho.
Autor original: Darryl K. Taft
Publicación original: http://www.eweek.com/index2.php?option=content&task=view&id=46989&pop=1&hide_ads=1&page=0&hide_js=1
Traducción por: Ing. David Ordinola Guevara
1.- aj
Martes 01 de julio de 2008 a las 12:04
me gusto mucho tu tema es algo muy interesante y delicado a la hora de desarrollar, aunqe comun mente no se piense en ello
Invertir[Expandir/Contraer]