Bueno y creo que no podríamos dejar por fuera cuando estamos hablando de software de algunas pruebas
o de algunas Haussman que tendríamos que hacer contra contra el software.
Si bien DevOps eso es lo que busca integrar las pruebas o la calidad el aseguramiento de la calidad
del software entre el mismo ciclo de vida de desarrollo del software lo que hacemos acá es lo que quiero
en este video es explicarles algunos algunos ataques que existen verdad y lo hago hasta ahora hasta
en el desarrollo de software porque la mayoría de estos ataques vienen derivados de malas prácticas
de desarrollo de software.
En este caso por ejemplo buffer overflow que es el buffer overflow el buffer overflow lo que busca es
valga la redundancia llenar el buffer que se le asignó o el espacio de memoria que se le asignó a alguna
aplicación para poder 2 2 metas.
La primera escrachar la aplicación es decir que la aplicación falle porque ya no tiene espacio y memoria
donde donde donde ejecutarse y la más maliciosa es llegar a un puntero específico dentro del buffer
overflow para poder saltarse ese espacio de memoria saltarse a otro espacio en memoria y ya correr algún
comando malicioso por ejemplo un rootkit alguna señal reversa una reversals.
Pero si el buffer overflow es un ataque que valga la redundancia ataca las vulnerabilidades en el desarrollo
que se dejaron ahí verdad en las variables especialmente de entrada.
Luego tenemos el Crosa scriptum también que es otro tipo de ataque que también otra vez valga la redundancia
ataca las vulnerabilidades que se dejaron por que dejaron los programadores a la hora de desarrollar
el código y así puedo mencionar muchas esquiado Injection que por lo que busca escríbalo injection es
pues como su nombre lo dice inyectar código o Keres de SQL en la ejecución por ejemplo si nosotros tenemos
una variable de lo bien dónde está enviando el usuario y la contraseña a la base de datos para ver si
hay un match y si la comparación es correcta y luego puedes desbloquear o dar los accesos necesarios
que se tenga en este caso SQL injection lo que busca es meterse en medio de ese Cuadri para hacer otras
tareas.
Puede ser traer información o hacer un select o eliminar información en casos más maliciosos verdad.
El cruce de scripting como lo toque o lo comenté en videos anteriores es un ataque a que afecta a los
clientes.
Si bien el vulnerable es el servidor en este caso el servidor guarda los scripts que el ataque el atacante
está inyectando en la página web.
El afectado es el cliente porque al final el cliente pues utilizando un browser está ejecutando sus
scripts entonces puede ser que el script esté hecho para redireccionar al cliente de alguna página maliciosa
para robar cookies para robar credenciales etcétera etcétera.
Luego tenemos request fail incluyeron el local fallo inclusión y también Directory Traverso.
Estos tres ataques lo que buscan es aprovecharse de una vulnerabilidad en la llamada a las variables
es decir cuando tenemos páginas dinámicas por ejemplo donde yo digo Bueno si da clic en este botón página
que cargue esta otra página que se encuentra en un directorio local o se encuentra en alguna librería
local.
Lo que yo hago es cuando no se sanity bien las variables es meterme en medio de esa llamada dinámica
y decirle bueno esta página que estás tratando de cargar realmente no está aquí en el directorio local
sino que está en otro directorio puede ser otra vez local faul incluyen en un directorio local y remota
de inclusión en un directorio remoto y el directorio Traverso de decirle básicamente utilizar la misma
variable de entrada y decirle bueno sabes que no cargues ninguna ninguna página o nada dinámico sino
que simplemente ándate al directorio raíz y mostrarme algún archivo por ejemplo el archivo password
hollado o si estamos hablando de un sistema Linux verdad y bueno hay muchas variables de este tipo.
Realmente mi meta tampoco es entrar en mucho detalle aquí o ponerme muy técnico con los tipos de ataques
como se haya comentado ya en videos anteriores tenemos un curso de esto de pruebas de penetración por
si su intereses va por S por S.
Por ese camino pero lo que sí quiero que entiendan es que muchas de éstas de todos los ataques que acabo
de mencionar son por malas prácticas de programación es decir no se analizaron las variables en el caso
de buffer overflow nunca chequeó qué cantidad de caracteres podría recibir la variable de password nunca
chequeo qué cantidad de caracteres podría recibir la variable login dada como tal.
Entonces el atacante pudo meter 10000 caracteres que entonces la pila donde yo estaba o el espacio memoria
donde yo estaba se llenó y mi aplicación se murió.
En el caso de Cross-Save scripting nunca nunca CH:Qué por por caracteres especiales por ejemplo qué
hace alguien introduciendo algún carácter especial que no tendría que ir en el campo de usuario por
ejemplo si mi usuario consiste de un correo electrónico apóstrofe no tendría que ir ahí.
Por ejemplo en ese Colin Jackson es lo mismo si yo estoy utilizando usuarios y mi y mi variable es marchar.
Es decir solo recibo caracteres y números o simplemente un integer verdad que sólo recibo números que
hace alguien poniendo un apóstrofe.
Entonces este tipo de cosas al final las aniquilación de las variables o el chequeo de las variables
como tal pues creo que sería nuestra primera línea de defensa contra muchos ataques incluyendo los que
les acabo de mencionar verdad.
Y otro otro no quiero decir ataque pero otro error muy común son los ganchos de mantenimiento o los
mantenciones que ya los hayamos tocado anteriormente pero en este caso en su manifestación más común
que es las credenciales que se quedan grabadas en el propio código como tal en el propio código fuente
algunos programadores hacen esto para fácil Fats facilitarse la vida a la hora de hacer pruebas con
el código ya sea la interfaz gráfica el backend etcétera etcétera.
Pero cuando ya hacen la producción pues no quitan estas credenciales que se quedan ahí en el código
y lo peor de todo es que muchas veces es código por ejemplo PHP o incluso en el mismo HTML.
He visto credenciales que se quedan ahí entonces yo sólo veo el código fuente de la página y bien puedo
hacer con un par de credenciales que si bien no es un ataque como tal sí que sí que es un error de programación
que nos afecta de verdad como tal por ahí bueno lo que podríamos hacer y esto no es que de la noche
a la mañana se vaya a arreglar es que de la noche a la mañana yo les vaya a decir miren dejen de hacer
esto dejen de hacer lo otro hay que adoptar enbolsa hay que adoptar metodologías de desarrollo como
vimos por ejemplo un scrum un extreme programming o cualquier modelo ágil.
Podría ser verdad pero no sólo es el proceso o el modelo que debemos de seguir sino también llegar a
una a un estado de madurez donde un proceso sea repetible y optimizado.
Para esto tenemos el CMMI verdad que es el modelo de capacidades y madurez o el software que provee
Harima Chury Moro que al final es lo que como su nombre lo dice Nosotros tenemos que llegar a un nivel
de madurez tal que las pruebas de seguridad se vuelvan parte del día a día y que sean repetibles de
verdad en este caso como estamos hablando lo orientado al software.
Tenemos cinco etapas específicas o cinco niveles de madurez específicos con lo que al CMMI se refiere
verdad.
En este caso por ejemplo inicial repetible definido manejado y optimizado cada uno de estos tiene sus
particularidades de cuál es el Estado o que depende del proceso del Estado madurez pues puede caer en
alguno de estos ejemplos.
Por ejemplo en el estado inicial el proceso de software está caracterizado por ser como a lo que salga
verdad o sea lo hacemos con el cliente nos pidió esto hoy vamos a hacer vamos a ver qué hacemos para
hacerlo.
Puede ser un proceso muy caótico y no funciona así pero bueno es un proceso caótico no repetible que
sería el nivel número 2 de madurez que es hoy.
Hay un project management muy básico verdad no es que sea un project management pues avanzado para nada
más que todo lo que se utiliza para ver tiempos y costos no tanto procesos o funcionalidad sino tiempos
y costos como tal.
Luego tenemos el definido que ya hay un puesto como su nombre lo dice un proceso de desarrollo de software
definido tanto del lado management como del lado técnico y cuando se documenta está estandarizado o
está integrado de repente con algún proceso de negocio y la organización es un proceso que está aprobado
por la gerencia customizado para nuestras necesidades verdad.
Luego tenemos el manejado que es el nivel número 4 que entonces ahí entramos a medidas bien detalladas
del proceso de software de por ejemplo control de calidad análisis del performance por ejemplo del software
o análisis de vulnerabilidades del software análisis estático y dinámico del código.
Ya estamos en un proceso mucho más definido y manejado.
Y luego tenemos el optimizado que es básicamente una mejora continua del proceso de desarrollo de software.
De repente en la primera iteración no nos salió bien entonces tenemos un proceso optimizado para la
segunda iteración pues se corrige Varda es repetible es digamos que implementamos tecnología allá aquí
para para optimizar esto verdad.
Y bueno ese es en pocas palabras los cinco niveles de madurez según el CMMI.
Ahora bien hay algunos procesos que se pudieron dar cuenta de que no vamos a saber en dónde caen específicamente
yo a mí lo que me gusta recomendar en este caso es implementar Koblet verdad para el tema de gobierno
y gobernanza.
Creo que hace muy separación entre el tema de madurez y capacidad que si bien en muchos libros lo toquen
al mismo tiempo o que sean similares o que sean en este caso sinónimos verdad.
No creo que lo sean sino que hay algunas diferencias entonces es un proceso un poco más ordenado Kbit
que simplemente venir y decir bueno vamos a implementar CMMI que da un poquito más de visibilidad y
de mejora hacia los procesos y no sólo procesos sino a la organización como tal.
Y luego tenemos las pruebas las pruebas de aceptación como tal que no está de más decirlo pero pero
pero aquí donde el usuario final dice Bueno voy a certificar o aceptar que realmente esto funciona y
al final sí sin esa aceptación pues cualquier modelo de madurez va a ser gastar de más.
No vamos a poder llegar a ningún a ningún nivel.
Ahora bien qué niveles de aceptación hay acá.
Según el St QBE realmente detrás están un poco alargues pero bueno es de International Software Testing
califiqué Humboldt.
Tenemos cuatro niveles de aceptación muy marcados digámoslo así Primero tenemos la aceptación del usuario
que como su nombre lo dice el usuario acepta la funcionalidad baulera pero tan valida que realmente
cumpla las necesidades del usuario como tal.
Luego tenemos la aceptación operacional más que todo conocida como aceptación de producción que valida
que realmente el software en este caso la herramienta alcanza los requerimientos operacionales necesarios
es decir ya se desintegra de repente con alguna herramienta tiene backups tiene Encryption tiene algún
plan de mitigación de riesgos o un plan de mitigación de vulnerabilidades o tiene capacidad de reportería.
Todo lo tema operacional.
Luego tenemos el control Accept contesten que esto es digamos.
Se ve el contrato y dice bueno el contrato decía que esto y esto y estudiamos hacer el contrato y según
el contrato nosotros estamos cumpliendo con absolutamente todo y luego tenemos el complaints accept
them texting que esto es básicamente decir bueno.
Este software fue desarrollado por un banco y entonces vamos a ver si realmente este software cumple
con las necesidades de PCI por ejemplo o este software fue desarrollado para un hospital y vamos a ver
si software cumple con las con los requerimientos de Hipa por ejemplo guarda y estos son los cuatro
niveles que según el S The Cube The Cube Pradón son los aceptados o son los que realmente tendríamos
que pasar cada vez que vamos a entregar un software ya sea ingenuos o sea que esté Holder sea un cliente
interno o externo como tal verdad.
Y bueno los premios espero les haya gustado y muy pronto.