Ciberseguridad

Casos reales de incidentes de ciberseguridad

Aunque no seamos conscientes de ellos, existen multitud de casos y brechas reales de incidentes de seguridad que han ocurrido en empresas que pensamos que son invulnerables. En esta imagen se muestran algunos de los casos más importantes ocurridos a empresas muy conocidas.

Por ejemplo, podemos ver casos famosos como el de Sony con PlayStation, o el caso de eBay o el de Ashley Madison, aquella web de citas de la que se filtraron datos de más de 40 millones de usuarios, con todo el impacto que puede suponer eso, ya que había personas bastante famosas dadas de alta en la web con sus datos reales. También aparecen los distintos escándalos de Facebook con un montón de brechas de seguridad y una bastante reciente, o de British Airways con datos filtrados de cientos de miles de tarjetas.

En este enlace de Wikipedia podéis ver muchos más casos de incidentes de seguridad, donde podéis analizar y ver la gran cantidad de casos reales que ocurren. Todos los días hay nuevos casos y cada vez son más frecuentes, y es así porque es muy complicado monitorizar y detectar cualquier agujero de seguridad o cualquier brecha justo en el momento.

Elementos en monitorización de seguridad

Si queremos detectar lo antes posible pues esos ataques o incidentes de seguridad, que empiezan por aprovechar una vulnerabilidad o por algún usuario que ha tomado algún privilegio que no debía.

El elemento base que nos va a permitir monitorizar todas esas cosas es un correlador o SIEM, que, aunque necesiten de más piezas, debe ser el núcleo. Este SIEM debe nutrirse de diferentes fuentes de datos mediante una o varias sondas, que se irán desplegando para recoger los logs de los distintos dispositivos. Estas sondas recolectarán estas fuentes de datos, los van a procesar en un proceso que se denomina normalización, y los envían al SIEM.

El SIEM tiene dos partes, una parte para tiempo real y otra para el cumplimiento, que en algunos sistemas esta parte para cumplimiento sería otro dispositivo adicional destinado a la retención a largo plazo. En la parte de tiempo real lo que va a hacer es aplicar una serie de casos de uso que van a detectar comportamientos anómalos, y cuando algún patrón coincida con ese caso de uso, saltará una alerta o ejecutará una determinada acción.

Respecto a las distintas fuentes de datos o distingos logs que puede ingestar un SIEM, podemos destacar algunos como:

• Sistema operativo
• Firewall
• Proxy web
• IDS/IPS
• Antivirus
• AntiSpam
• VPN
• O365

Estos elementos lo que nos permiten, cuantos más elementos tengamos, es construir esa traza que nos permita verificar cuál es el paciente cero desde dónde se ha generado esa brecha de seguridad o desde dónde se ha materializado esa amenaza.

No solo con un SIEM podemos hacer todo esto, sino que necesitamos otros elementos adicionales, porque el fin es detectar lo que se denomina el Cyber Kill Chain, que son las fases que sigue un atacante para entrar dentro de una casa o dentro de una organización y crear persistencia, conectarse con su centro de control y comando, conseguir permisos de administrador y, haciendo movimientos laterales, descifrar información, bloquear sistemas, cifrar el servidor de ficheros o lo que quiera, porque tiene permisos suficientes.

Esto ha dado pie a que una organización como Mitre, haya desarrollado un lenguaje común de casos de uso que va analizando estas tácticas, técnicas y procedimientos y las va mapeando en una tabla, donde están los casos de uso.

Si vistáis la página web de Mitre podréis ver esa matriz de casos de uso, donde podéis ver cómo mapea las distintas fases, que podéis ver de forma resumida en la imagen anterior, con casos de uso que se pueden implementar en los distintos correladores.

Aparte de eso tenemos otros elementos no menos importantes que el SIEM, entre los que tenemos por un lado la parte de enriquecimiento y mejora el ratio de detección, cómo pueden ser las plataformas de inteligencia de amenaza, que lo que hacen es ingestar por un lado y suministrar por otro.

Ingestan esos indicadores de compromiso, que pueden ser URL maliciosas, hashes de ficheros, etcétera, que están verificadas que son maliciosas, y lo interesante de esos indicadores es que cuanto antes los tengamos, mucho mejor, porque además duran desde segundos a días o semanas, porque van cambiando o bien la IP del servidor remoto o cualquier otro dato, y entonces pierden su validez.

Por otro lado, tenemos la parte de orquestación y respuesta, que es muy importante para complementar el otro lado del SIEM, justo por encima. Cuando salta una alerta tendremos lo que se denomina un playbook, que son una serie de pasos que configuran unas acciones a realizar en función de la acción que se ha disparado.

Soluciones de monitorización de seguridad

Por último, vamos a resaltar algunos fabricantes que ofrecen sus soluciones en versiones gratis, pruebas de X días o versiones reducidas, como son:

• Alien Vault
• McAfee
• IBM Security
• Splunk
• Elasticsearch en su parte de SIEM

Os animamos a montar un laboratorio para hacer pruebas, que es como mejor se aprende.