Sueño cumplido, profesor en Máster de Seguridad

Corría el año 2.007 cuando participé como ponente en el evento CodeCamp de Microsoft como reciente ganador del premio Imagine Cup (también de la compañía de Bill Gates). Allí tuve el placer de asistir a una charla de un chaval con gorro a rayas que salió disfrazado de rock star (con la guitarra de Guitar Hero) y que encendió mi curiosidad por la Seguridad de la Información.

Sí, era Chema Alonso antes de ser estrella del rock

Desde ese momento empecé a leer blogs, a practicar cosillas por mi cuenta y a buscar la forma en la que poder formarme o incluso orientar mi vida laboral hacia ese mundo tan interesante que me habían mostrado.

Finalmente me decidí por realizar un Máster de Seguridad con el que me metí de lleno en ese campo, lo que me abrió las puertas a poder trabajar en el sector para ir creciendo y aprendiendo hasta llegar a ser el Responsable de Seguridad de una startup que será bombazo a corto/medio plazo.

Sin embargo, la lista de deseos para una vida no se queda sólo en trabajar en aquello que realmente te apasiona. Tambien fui tachando los deseos cumplidos relaticos a escribir un libro, grabar un disco, tener hijas, ver en directo “The Wall” de Pink Floyd, tener una banda de R&R, … pero faltaba algo importante para mi: Ser profesor de un Máster. Y ahora lo he conseguido, ¿te lo vendo? A ver qué tal se me da…

¿Eres un apasionado de la seguridad? ¿Trabajas en el sector tecnológico? ¿Quieres seguir formándote? Es probable que, en algún momento, te hagas una pregunta importante…

¿Debería hacer un Máster en Seguridad de la Información?

En este campo, toda la formación que recibas es una inversión de futuro. El sector IT forma parte cada vez más de nuestras vidas y su avance nos obliga a mantener un estado de formación continua si no queremos quedarnos obsoletos en unos meses.

Por suerte o desgracia, la seguridad toma un papel vital en todo esto y tener una formación especializada es un elemento diferenciador ahora, pero puede que obligatorio en un futuro cercano.

Hacer un Máster en Seguridad de la Información es un paso muy importante en tu carrera profesional, deja que te de tres motivos que influyeron positivamente en mi decisión para hacerlo:

  • Obtendrás conocimientos de primera mano gracias a los profesionales que lo imparten: los profesores suelen ser personas destacadas del sector, con amplia experiencia en aquello que te van a contar. No sólo aprenderás la teoría, también recibirás un valioso conocimiento de su experiencia práctica que te servirá para estar preparado para lo que te puedes encontrar.
  • Te centrarás en aquello que realmente te interesa: en la Universidad estudiamos un abanico de opciones relacionadas con nuestra carrera, algunas de ellas nos gustan y otras nos resultan irrelevantes. En un Máster, todo lo que ves está relacionado con tu pasión.
  • Forjarás nuevos y duraderos contactos: las personas que te encontrarás en el camino tienen tus mismos intereses y es muy habitual que surjan grandes amistades y hasta proyectos profesionales.

Como te digo, en mi caso particular, la elección fue afirmativa. No hay un día en el que no me alegre de aquella decisión. Desde entonces, he orientado mi vida laboral y continúo formándome para estar preparado ante los nuevos retos de seguridad que aparecen casi a diario.

Ojo, no lo hagas si …

Si tu única motivación es encontrar trabajo porque has leído que se necesitan cientos de miles de millones de especialistas por todo el mundo, no lo hagas. Si, he dicho no lo hagas. Un Máster es una especialización que necesita pasión, si no te resulta atractivo lo que vas a aprender, te aburrirás, nuncas serás un buen profesional y terminarás cambiando de campo habiendo tirado tu tiempo y dinero a la basura.

Echa un ojo a los perfiles más demandados

Dentro del mundo de la seguridad, hay diferentes caminos que puedes seguir:

  • Operación.
  • Hacking ético.
  • Arquitectura de seguridad.
  • Desarrollo de seguridad.
  • Auditor 27.001, LOPD, …
  • Continuidad de negocio.
  • Gestión de incidentes.

De todos estos campos, tienes formación dentro del Máster de Seguridad de la Información y Continuidad de Negocio de Eadic, título propio de la Universidad Rey Juan Carlos.

Partiendo de esta base, he tratado de reunir todo mi conocimiento y experiencia en los dos temas relativos a la auditoría de la norma ISO 27.001 de la que espero ser tu profesor si te animas a participar.

Durante dos semanas, te contaré todo lo que necesitas saber para afrontar como auditor un proceso completo de auditoría. Recuerda que estoy cumpliendo un sueño, así que te aseguro que voy a dar lo mejor de mi para que te resulte interesante y útil todo lo que te cuente.

¿He conseguido llamar tu atención?

Si es así, no dudes en ampliar información en la web de Eadic. ¡Espero verte pronto!

¿Para qué sirve un CISO (aka responsable de seguridad)?

Cuando me preguntan en qué trabajo y contesto que soy responsable de seguridad, lo habitual es que me imaginen organizando a personas que controlan puertas y pasean por pasillos en busca de ladronzuelos.

Cuando digo que soy responsable de seguridad en una empresa de tecnología, lo habitual es que me imaginen evitando que nos roben los móviles, los portátiles o las teles.

Cuando digo que soy responsable de seguridad de la información, lo habitual es que no tengan ni idea de qué les hablo. Entonces les explico que mi tarea es proteger la información valiosa de la compañía contra ataques informáticos de gente mala, fugas de información, malware, … Es entonces cuando me miran con cara de asombro y me dicen “ah, que eres un hacker!!”.

Pues no, no me considero un hacker y hago un inciso para explicar lo que yo entiendo por hacker. Me basaré en la definición dada por “The Internet Engineering Task Force (IETF®)”, muy del gusto de la comunidad de seguridad:

hacker –  A person who delights in having an intimate understanding of the  internal workings of a system, computers and computer networks in particular. The term is often misused in a pejorative context, where “cracker” would be the correct term.

Partiendo de la base de que considero un hacker a una persona apasionada de la tecnología que aprende constantemente con el objetivo de llevarla hasta el límite para poder mejorarla, no me considero hacker ya que no entro en la parte final de la definición. Quizás si un half-hacker, pero para mí los hackers de verdad son gente tan top como los ponentes habituales de los congresos de seguridad, los creadores de tecnología, los que sin formación académica terminan siendo muy importantes dentro de grandes empresas, …

Pero volviendo a lo del principio, al final siempre surgen dudas sobre las tareas que realiza un CISO o responsable de seguridad así que te voy a hacer un pequeño resumen.

El CISO o responsable de seguridad en la norma ISO 27.001

Ahora que estoy trabajando en el contenido del Máster de seguridad y continuidad de negocio del que voy a ser docente, concretamente en la parte relacionada con auditoría 27.001, estoy describiendo cómo no se da como obligatorio el nombramiento de un responsable de seguridad. El motivo es sencillo, la norma se puede ajustar a compañías de cualquier tamaño y las pequeñas normalmente no tendrán recursos para mantener una persona que se encargue únicamente de esas tareas.

Sin embargo, en empresas de más tamaño, es importante que exista esa figura para que pueda realizar las siguientes tareas:

  • Conformidad:
    • Desarrollar la lista de partes interesadas relacionadas con la seguridad de la información.
    • Desarrollar la lista de requisitos de las partes interesadas.
    • Permanecer en contacto continuo con autoridades y grupos de intereses especiales.
    • Coordinar todos los esfuerzos relacionados con la protección de datos personales.
  •  Documentación:
    • Proponer el borrador de los principales documentos de seguridad de la información, por ejemplo, Política de seguridad de la información, Política de clasificación, Política de control de acceso, Uso aceptable de activos, Evaluación del riesgo y metodología de tratamiento de riesgos, Declaración de aplicabilidad, Plan de tratamiento de riesgos, etc.
    • Ser responsable de revisar y actualizar los documentos principales.
  • Gestión de riesgos:
    • Enseñar a los empleados cómo realizar la evaluación de riesgos.
    • Coordinar todo el proceso de evaluación de riesgos.
    • Proponer la selección de salvaguardas.
    • Proponer los plazos para la implementación de salvaguardas.
  • Administración de recursos humanos:
    • Realizar comprobaciones de verificación de antecedentes de candidatos de trabajo.
    • Preparar el plan de capacitación y concientización para la seguridad de la información.
    • Realizar actividades continuas relacionadas con la sensibilización.
    • Realización de capacitación de inducción sobre temas de seguridad para nuevos empleados.
    • Proponer acciones disciplinarias contra empleados que realizaron la infracción de seguridad.
  • Relación con la alta dirección:
    • Comunicar los beneficios de la seguridad de la información.
    • Proponer objetivos de seguridad de información.
    • Informar sobre los resultados de la medición.
    • Proponer mejoras de seguridad y acciones correctivas.
    • Proponer presupuesto y otros recursos requeridos para proteger la información.
    • Informar requisitos importantes de las partes interesadas.
    • Notificar a la alta dirección sobre los principales riesgos.
    • Informar sobre la implementación de salvaguardas.
    • Asesorar a los principales ejecutivos en todos los asuntos de seguridad.
  • Mejoras:
    • Asegurarse de que se realizan todas las acciones correctivas.
    • Verificar si las acciones correctivas han eliminado la causa de las no conformidades.
  • Gestión de activos:
    • Mantener un inventario de todos los activos de información importantes.
    • Eliminar los registros que ya no se necesitan.
    • Desechar los medios y equipos que ya no se usan de forma segura.
  • Terceros:
    • Realizar la evaluación de riesgos para las actividades a subcontratar.
    • Realizar verificación de antecedentes para los candidatos de outsourcing.
    • Definir cláusulas de seguridad que deben formar parte de un acuerdo.
  • Comunicación:
    • Definir qué tipo de canales de comunicación son aceptables y cuáles no.
    • Preparar el equipo de comunicación para ser utilizado en caso de una emergencia o desastre.
  • Gestión de incidentes:
    • Recibir información sobre incidentes de seguridad.
    • Coordinar la respuesta a incidentes de seguridad.
    • Preparar evidencia para la acción legal después de un incidente.
    • Analizar incidentes para evitar su recurrencia.
  • Continuidad del negocio:
    • Coordinar el proceso de análisis del impacto comercial y la creación de planes de respuesta.
    • Coordinar el ejercicio y la prueba.
    • Realizar una revisión posterior al incidente de los planes de recuperación.
  • Técnico:
    • Aprobar los métodos apropiados para la protección de dispositivos móviles, redes de computadoras y otros canales de comunicación.
    • Proponer métodos de autenticación, política de contraseñas, métodos de cifrado, etc.
    • Proponer reglas para el teletrabajo seguro.
    • Definir las características de seguridad requeridas de los servicios de Internet.
    • Definir principios para el desarrollo seguro de los sistemas de información.
    • Revisar los registros de las actividades del usuario para reconocer el comportamiento sospechoso.

Básicamente, en esto consiste mi día a día. Pero no te voy a engañar, también me preocupa la gente que entra por la puerta o anda por los pasillos, sobre todo cuando vienen de visita…

Cuando tomas la decisión de convertirte en un profesional de la seguridad, como es mi caso, te das cuenta de que tienes que vivir en continua semi-paranoia para que no se te escape nada. Aunque mi visión de todo esto es siempre intentar que la seguridad sea lo primero, pero seguido muy de cerca por la usabilidad, ya que si les hago a mis compañeros el trabajo imposible, entonces mal vamos. En este sentido te recomiendo que le eches un vistazo a la entrada en la que cuento cómo ofrezco la seguridad a los departamentos vía API.

Espero haberte ayudado a comprender un poco mejor lo que hace un responsable de seguridad.

¡Hasta la próxima!

SecurityInside Live: Check Point Cyber Day 2017

La omnipresente transformación digital y el Internet de las Cosas piden cambios fundamentales en el presente y futuro de la ciberseguridad. Los últimos ataques ocurridos a nivel mundial demuestran la necesidad de implementar estrategias innovadoras para securizar las empresas.

Hoy asistimos al Check Point Cyber Day 2017, una jornada dedicada a los CIOs, CISOs, IT Security Managers y todos los interesados en conocer el futuro de la ciberseguridad de la mano de expertos nacionales e internacionales en esta materia.

Leer más

pruebas-de-seguridad

App terminada: ¿la subo a producción o hago pruebas de seguridad?

Hace dos días me tocó ir a la ventanilla de Alsa para cerrar un billete de vuelta. Sí, a la ventanilla. Mis argumentos sobre que puedo comprar hamburguesas del mercado con Amazon Prime, la comida del mes en Carrefour, pantalones vaqueros con Vibbo, pedir “taxi” con Uber o “conocer amigas” con Tinder… todo desde mi móvil, no fueron suficientes para convencer a la simpática persona que me atendía de que no tenía sentido que no pudiera hacerlo por internet a estas alturas de siglo.

Hoy en día todas las empresas que quieren estar “a mano” de sus usuarios invierten en apps móviles o web (responsive). Es imprescindible que sean sencillas,  rápidas y con un diseño fabuloso.

Seguro que alguno ya lo ve venir… ¿reconocéis lo que falta?

Seguridad. Cerca del 70% de las vulnerabilidades se encuentran en la capa de aplicación y apenas el 10% de los desarrolladores reconocen haber realizado pruebas de seguridad antes, durante y tras el lanzamiento de las apps [1].

Tampoco es para tanto…?

Quizás parezca que no, pero un error en una aplicación puede derivar en graves violaciones de seguridad. Lo que para un desarrollador puede ser un pequeño fallo, puede ser la entrada a la red interna de la organización y convertirse en el principio de una serie de escalados en horizontal y vertical que terminen con un magnífico acceso de administrador.

Una aplicación que no ha pasado las necesarias pruebas de seguridad puede terminar costando millones al negocio. Todavía me acuerdo de aquella charla de Antonio Ramos (www.leetsecurity.com) en la RootedCON titulada ¿Y si la seguridad afectara al valor contable de la empresa?. Que le pregunten a Yahoo si afecta a las cuentas o no un fallo de seguridad…

Si no te preocupas por la seguridad, quizás deberías preocuparte por la tesorería… ¿Qué tal unas recomendaciones mínimas?

Versiones cerradas, no metas parches de última hora

A veces, con las prisas, metemos características que no están del todo maduras. Tienen que estar aunque no estén demasiado finas, que “ya lo iremos arreglando”. La realidad es que se suele dejar como está, ya que tras la release, una lista de nuevas features está en tu nuevo sprint y no tienes tiempo para arreglar cosas.

Si algo no está pulido, probado y validado, no debería ponerse en producción, a la larga lo agradecerás.

Pruebas de todo tipo (sí, de seguridad también)

Una batería de pruebas es esencial en el desarrollo, pero no hablo de las pruebas funcionales mínimas que realiza el desarrollador conforme escribe código. Haz todo tipo de pruebas, automatiza, audita tu código, incluso busca expertos en QA testing que te enseñen cómo hacerlo.

Nunca dejes de revisar

Las pruebas no deben terminar una vez se publica una versión. Si tienes algo en producción durante mucho tiempo, ponlo a prueba, “putéalo” para que seas tú el primero en encontrar una vulnerabilidad y no el primero en sufrirla.

 

No es tan complicado, no te olvides las pruebas y tus usuarios, tu negocio y tu tesorería te lo agradecerán.

[1] https://www.sans.org/reading-room/whitepapers/analyst/2015-state-application-security-closing-gap-35942

primer_ataque_dos

¿El primer ataque DoS de la historia?

Estamos en 2017, lo que implica que el ataque DoS (Denegación de Servicio – Denial of Service) cumple 43 años. Lo que nació como la obra de un geek (o friki como decimos por aquí) se ha ido convirtiendo en algo muy elaborado que afecta a multitud de sistemas. Además, gracias a Internet, su variante DDoS (Distributed DoS) es sin duda uno de los quebraderos de cabeza de los que trabajamos en esto.

Un poco de historia

Cuenta la leyenda que el primer ataque DoS ocurrió en 1974 gracias a la curiosidad de David Dennis, un estudiante de 13 años de la Universidad de Illinois. David se percató de la existencia de un comando en los terminales PLATO (uno de los primeros sistemas computerizdos de aprendizaje compartido, antecesor de los sistemas multiusuario) llamado “ext”.

Este comando permitía conectar dispositivos externos y suponía que cuando se lanzaba, el dispositivo estaría presente, avisando de que únicamente era útil usarlo en ese caso.

Sin embargo, no avisaba de lo que ocurriría si no había dispositivos conectados. Cuando el comando se ejecutaba en un terminal así, se bloqueaba requiriendo un reinicio para volver a funcionar.

En este escenario, David tuvo la curiosidad de comprobar si era capaz de bloquear a todos los usuarios a la vez, de forma que el laboratorio quedase colapsado. Con esto en mente, desarrolló un programa que enviaba el comando “ext” a todos los terminales PLATO al mismo tiempo.

Como podéis imaginar, la ejecución fue un éxito rotundo, ya que bloqueó los terminales de más de 30 usuarios ante el asombro general. Este movimiento terminó con el bloqueo de la ejecución del comando “ext” de forma remota.

Os dejo la historia contada por David Dennis:

As far as I know, I’m the first person to have created a DoS of a room full of PLATO terminals deliberately. Systems people could of course kick anyone out they wanted, and “operator wars” had existed for years, but those tended to be consensual attacks on each other. What I did was I heard about a new command called the “external” command in TUTOR, or ‘ext’. Specifically, one of the music kids was saying how if you didn’t have a device attached, an ext command would cause your terminal to lock up and have to be powered off. Remember that powering off was discouraged, due to always-concern over flaky power to the plasma panels.

The other piece of this was they had rolled out the external command for everyone in the fall of 1974, after it having been only in use by the Music project. This meant that every user account on PLATO was set to defalt “can accept ext commands.” Default on.

If you recognize default enabled from any firewall work you’ll immediately recognize the trouble…

Anyway, I heard this and immediately thought of how a room full of annoying users could be locked up at once. My little 13 year old brain wanted to see a room full of users all be locked up at once.

So, I wrote a little program that sent exts to everyone within a range of site numbers, waited til I was over at CERL one morning, and let er rip.

It worked as advertised, 31 users all had to power off at once, great mayhem in the classroom, site monitors notified. No logging of course, I was never detected. Quietly left the room, went back over to uni.

Accessed the site displays I knew of from author mode, and looked up other sites around town or the country, and tried sending them some ext’s too. Was delighted to see mass posting on notesfiles about a locking out they were experiencing.

Soon some systems guys figured it out, probably a combination of common sense and maybe looking in some sort of logs, though I was never prosecuted or even approached, so I have to think to this day it was undetected. A few weeks later the ext command was withdrawn from ‘open all’ and a while after that was redeployed, this time with the default set to OFF. As it should have been all along. 🙂

So was there ever a DoS on a networked system prior to 1974 ? Im sure there had to be, but at least for the moment I’m claiming it !

David DennisPlatohistory.com

Y la moraleja es…

Al final, es la historia de siempre. Si hacemos algo pensando en que la situación perfecta es la única, lo más probable es que alguien se de cuenta de que, si esa situación no se da, ocurre algo indeterminado. A partir de ahí, encontrada la vulnerabilidad, lo demás es jugar y eso es precisamente lo que hizo David.

Como dijo Chema en alguno de sus posts:

Entendemos como Software Fiable aquel que hace lo que tiene que hacer y como Software Seguro aquel que hace lo que tiene que hacer y nada más. Ese algo más entre el software fiable y el software seguro son los bugs.

En este blog puedes encontrar algunas entradas que te pueden ayudar a desarrollar software seguro como las de las contraseñas (esta o esta) o las de auditoría de código (esta, esta o esta). Con estos consejos podrás lidiar en la medida de lo posible contra ataques DoS como el que hizo David. En cuanto a los DDoS, eso es otra historia…