¿Construimos Software Seguro?
¿Por qué encontramos tantos fallos de seguridad en los desarrollos una vez éstos han subido a producción? Pensemos por un momento en las aplicaciones de Internet y en la cantidad de veces que se han reportado vulnerabilidades que permitían acceder a las bases de datos de los clientes por culpa de fallos en los desarrollos. La seguridad juega un papel muy importante en estos productos y no se le presta la atención que merece.
Conozco casos donde los desarrolladores reportan la ausencia de requisitos de seguridad a sus responsables y las excusas por parte del equipo de diseño siempre suelen ser las mismas: no hay tiempo, los plazos son escasos, no hay presupuesto. Pero luego a quienes se apunta con el dedo cuando empiezan a aparecer los bugs, es a los desarrolladores.
En el inicio, durante la fase de análisis se debe realizar un análisis de impacto y pensar en las amenazas y vulnerabilidades a las que puede verse afectado nuestro producto, para ello debemos incorporar modelos de amenazas. Además todo arquitecto debe recoger: las políticas, los riesgos y las normas jurídicas.
En la fase de diseño se debe realizar un análisis de riesgos, el cual debe ser realizado por expertos en seguridad quienes son capaces de reconocer en que situaciones se producen los ataques más comunes. Durante la fase de implementación, si los programadores necesitan formación en seguridad, se les debe de proporcionar dicha formación.
En definitiva, se recomienda establecer los controles desde que se establecen los requisitos. Os recomiendo la lectura de Systems Security Engineering Capability Maturity Model (SSE-CMM) y dar un paseo por OWASP.
Fuente: Security By Default
Conozco casos donde los desarrolladores reportan la ausencia de requisitos de seguridad a sus responsables y las excusas por parte del equipo de diseño siempre suelen ser las mismas: no hay tiempo, los plazos son escasos, no hay presupuesto. Pero luego a quienes se apunta con el dedo cuando empiezan a aparecer los bugs, es a los desarrolladores.
¿No sería mejor empezar a pensar en seguridad desde que comienza el ciclo de vida del software y no después de subir el producto a producción, cuando los costes se vean aumentados por la necesidad de tener que aplicar parches y más parches?.
Las organizaciones deben definir una serie de prioridades y la mayoría de las veces la seguridad no suele ser de alta prioridad. A menudo, no es rentable hacer un sistema tan seguro como sea posible, ya que el riesgo es bajo y el coste es alto.
Las organizaciones deben definir una serie de prioridades y la mayoría de las veces la seguridad no suele ser de alta prioridad. A menudo, no es rentable hacer un sistema tan seguro como sea posible, ya que el riesgo es bajo y el coste es alto.
Cuando recibimos los estudios de viabilidad de los clientes, revisamos en busca de requisitos de seguridad pero éstos son escasos y en muchas ocasiones inexistentes. Si los analistas son buenos éstos se encargan de incluir algunos, pero como las estimaciones de los proyectos suelen ser en la mayoría de los casos muy ajustadas, tienden a omitirlos.
El software está en la raíz de la mayoría de los problemas de seguridad informática, si éste no se comporta de forma adecuada surgirán problemas de integridad, disponibilidad, confidencialidad... Los bugs y vulnerabilidades son la causa de un mal diseño y una mala implementación. Debemos empezar a concienciarnos: la seguridad debe estar presente en todas las fases del ciclo de vida de un producto.
En el inicio, durante la fase de análisis se debe realizar un análisis de impacto y pensar en las amenazas y vulnerabilidades a las que puede verse afectado nuestro producto, para ello debemos incorporar modelos de amenazas. Además todo arquitecto debe recoger: las políticas, los riesgos y las normas jurídicas.
En la fase de diseño se debe realizar un análisis de riesgos, el cual debe ser realizado por expertos en seguridad quienes son capaces de reconocer en que situaciones se producen los ataques más comunes. Durante la fase de implementación, si los programadores necesitan formación en seguridad, se les debe de proporcionar dicha formación.
En el plan de pruebas funcionales, también debe estar presente la seguridad ya que pueden surgir nuevas salvaguardas a incluir. Se deben incluir pruebas de seguridad, test de intrusión, pruebas de carga, pruebas de denegación de servicio y planes de mitigación de riesgos. En estos casos podemos utilizar herramientas para el análisis de vulnerabilidades como:
Además debemos incluir una buena auditoría, ya que es una parte esencial en la seguridad del software.
Pero todas estas medidas no se harán efectivas si no están incluidas en el Gobierno de TI, es decir, si no hay concienciación en materias de seguridad desde las altas esferas.
Pero todas estas medidas no se harán efectivas si no están incluidas en el Gobierno de TI, es decir, si no hay concienciación en materias de seguridad desde las altas esferas.
Es extraordinariamente rentable invertir en seguridad en las etapas iniciales del proyecto, podemos hablar de ahorros del 20% (Secure Business Quarterly)
En definitiva, se recomienda establecer los controles desde que se establecen los requisitos. Os recomiendo la lectura de Systems Security Engineering Capability Maturity Model (SSE-CMM) y dar un paseo por OWASP.
Fuente: Security By Default
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!