Hace unos días nos hacíamos eco de la publicación del “2009 Data Breach Investigations Report” a cargo del “Verizon Business RISK team”, y repasábamos algunos de los datos sobre el análisis de los incidentes de seguridad.
Pero el informe no sólo analiza la tipología y origen de los incidentes, si no que también ofrece pistas sobre cómo orientar los esfuerzos para mitigar los riesgos potenciales de sufrir uno de ellos. Las recomendaciones se resumen en cinco áreas:
- Asegurarse de que se han implantado y se mantienen vigentes un conjunto esencial de controles de seguridad.
- Encontrar, tracear y analizar los datos de que se dispone.
- Recopilar y analizar logs de actividad de sistemas y aplicaciones de forma continua.
- Auditar periódicamente las credenciales y privilegios de los usuarios.
- Auditar (analizar vulnerabilidades, tests de penetración, etc.) en servicios y aplicaciones Web de forma periódica.
En teoría, la mejor defensa contra las violaciones de datos es bastante simple: no conservar los datos. Dado que esta aproximación al problema no es realista para muchas organizaciones, lo mejor que puede hacerse es mantener sólo aquellos datos estrictamente necesarios para el negocio, requeridos por motivos legales o de compliance; y saber con precisión dónde se almacenan y cómo se mueven por la organización. Ahora bien, llevar esto a la práctica no es tarea trivial. He aquí algunos enlaces al respecto: Data Loss Prevention Best Practices, Understanding and Selecting a Data Loss Prevention Solution, etc.
La mayoría de los incidentes siguen produciéndose debido a que no se habían implantado ni siquiera los controles básicos de seguridad (e.g. parches de seguridad en sistemas operativos y servidores), y los que estaban implantados no lo estaban globalmente. Así pues, quedan expuestas algunas vulnerabilidades bien conocidas, es muy probable que un atacante las encuentre y las explote. Sin embargo, es mucho menos probable que un atacante gaste su tiempo en detectar vulnerabilidades no evidentes.
En este sentido el informe mantiene su recomendación de 2008 al respecto de la eliminación de credenciales por defecto y de compartir credenciales, de la revisión de cuentas en busca de signos de abuso o anomalías, etc. También se mantiene de incorporar la seguridad desde el propio ciclo de desarrollo de las aplicaciones, incluyendo auditorías de código, para evitar vulnerabilidades habituales como la inyección de SQL, el Cross Site Scripting (XSS), etc.
