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