Page 2 - Secure Software Development Life Cycle
P. 2
Laboratorio de Ciberseguridad
La revisión de código es una práctica 6. Requerimientos de seguridad
necesaria pero no suficiente que pretende Al igual que los requerimientos
evitar las vulnerabilidades originadas funcionales, los requerimientos de
producto de los errores producidos por seguridad deben incluirse desde las etapas
los programadores y que son introducidos iniciales del diseño del sistema. Deben
de forma accidental o no, como puede ser: incluirse tanto requerimientos de
Buffer OverFlow, Race Condition, etc. seguridad funcionales como también
comportamiento o posibles patrones de
2. Análisis de riesgos arquitectónicos ataque. Un ejemplo de riesgo es: la
Al momento de analizar y diseñar el inexistencia de especificación de acceso a
sistema, se debe identificar y documentar datos.
los posibles vectores de ataque y
asunciones según la arquitectura elegida. 7. Operaciones de seguridad
Toda arquitectura tiene sus puntos Consisten en monitorear los sistemas en
débiles, por lo que considerarlos y búsqueda de irregularidades. Esta
minimizarlos es crucial. Un ejemplo de actividad asume que los ataques van a
riesgo es: Falla en autenticación y ocurrir y determina mecanismos de
decisiones de control de acceso. monitoreo y registro con la finalidad de
evaluar y comprender los patrones de
3. Pruebas de penetración ataque para diseñar estrategias de defensa
Las pruebas de penetración son una efectivas. Un ejemplo de riesgo es:
herramienta útil para evaluar la seguridad Auditoría o log de sistema insuficiente.
de un sistema en un entorno equivalente
al entorno real. El objetivo es descubrir las En el proceso de desarrollo de software es
vulnerabilidades existentes como ser el importante tener en consideración estos
mal manejo del estado de la interfaz Web, conceptos de seguridad ya que la
sin embargo, esta actividad se encuentra funcionalidad de un sistema no significa nada
estrechamente ligada a las habilidades de si cuando la aplicación está siendo utilizada
las personas que la llevan adelante. tiene vulnerabilidades que no solo afectan al
sistema, sino que pueden escalar y
4. Pruebas de seguridad basadas en comprometer otros aspectos. Los riesgos de
riesgos seguridad no solo afectan a los usuarios en
Las pruebas de este tipo consisten en todas sus dimensiones, sino que también
evaluar el sistema desde el punto de vista afectan al proveedor y su imagen.
funcional (usuario interno) y desde el
punto de vista externo y los patrones de Referencias
ataque que podría utilizar un ciber
delincuente. El objetivo de esta actividad
es evaluar la seguridad basándose en los McGraw, G. (2006). Software security:
riesgos identificados. Un ejemplo de Building Security in. Addison-Wesley
riesgo es: Filtración de datos. Professional.
5. Casos de abuso
Los casos de abuso consisten en pensar Paul, M. (2013). Official (ISC)2 Guide to the
como los atacantes. Formalmente son CSSLP CBK. CRC Press.
similares a los casos de uso, pero en los
casos de abuso el objetivo es describir el Viega, J., & McGraw, G. (2002). Building
comportamiento del sistema ante un secure software: How to Avoid Security
ataque. Dentro de los riesgos que se Problems the Right Way. Addison-Wesley
pueden detectar se encuentra los ataques Professional.
de manipulación.