Pues sí, parece ser que el DNS es un bicho raro que nadie quiere y seguro que algunos se preguntarán qué es eso del DNS. Pues el DNS es un servicio encargado de resolver los nombres de las direcciones de Internet, es decir, que si usted pone en su navegador web www.google.es, él se encarga de decirle a su navegador que donde quiere usted ir es a la IP 1.2.3.4.

Como ven bajo esas tres letritas tan raras se esconde uno de los servicios más críticos para la infraestructura de su empresa. ¿Por qué? Pues porque es el encargado de que si un cliente pone www.suempresa.es vaya a su empresa y no a la de la competencia, porque también es el encargado de que si su servidor requiere una actualización la obtenga del sitio correcto y no de “pedazo-rootkit-te-voy-a-meter” y, como no, de que cuando un usuario se conecte a Facebook el lunes para comprobar qué planes hay para el sábado vaya realmente a Facebook y no a un falsa web que robe las credenciales del usuario (tenga en cuenta que quien dice Facebook puede decir su entidad bancaria).

Una de las características que ofrece la versión ProfessionalFeed (la de pago, vamos: $1200 al año cada licencia) de Nessus —entre otras— es la posibilidad de realizar auditorías de cumplimiento a sistemas Unix y Windows, aplicaciones o bases de datos SQL basadas en estándares ya predefinidos.

Así pues, podremos realizar auditorías de cumplimiento basándonos en las recomendaciones CERT, guías de buenas prácticas CIS o NSA, requerimientos de configuración PCI , e incluso Bandolier (proyecto de Digital Bond) proporciona políticas de cumplimiento (a través de ficheros .audit de los cuales hablaremos a continuación) para auditar sistemas SCADA, DCS y otras aplicaciones de sistemas de control industrial, entre otros.

Hace un par de semanas definimos cuales eran las principales limitaciones que presentan los IDS/IPS actuales y como era necesario aportar algo más de conocimiento para poder detectar amenazas y riesgos en la infraestructura.

Como ejemplo de requisito adicional se desarrolló un preprocesador dinámico de geolocalización para Snort que permitía poder generar alertas en función del origen o destino de la IP de un paquete de red. El concepto era totalmente distinto a lo que se había desarrollado actualmente con la geolocalización, puesto que nuestro objetivo no era, una vez generada una alerta obtener la procedencia o destinatario con fines únicamente estadístico, sino ser capaces de generar la alerta por la procedencia o el destino de un paquete de red.

En los últimos días venimos escuchando en prensa y televisión que el gobierno ha decidido restaurar la velocidad límite en las autopistas y autovías españolas a 120 Km/h, después de haber estado restringida a 110 km/h durante los últimos 4 meses. Como con casi todo en esta vida, y más con las decisiones políticas, nos encontramos con opiniones encontradas al respecto, unos hubieran mantenido el límite en 110 km/h, para mejorar el medioambiente otros lo prefieren en 120km/h e incluso algunos piden ahora su subida a 130km/h.

¿Cuál es la velocidad límite más adecuada? Sinceramente, ni idea.

La visualización de la información es tan importante como la información en sí misma. Demasiada información, sin la posibilidad de analizarla correctamente, no sirve de mucho. Por esto, quería dedicar esta entrada a mi chica unas herramientas que muestran, de una forma visualmente atractiva, alertas de seguridad generadas por Snort. No esperéis potentes interfaces gráficas haciendo data mining, agregando información, categorizándola, procesándola, correlándola y alertando de lo más importante que está ocurriendo en nuestra red. Para eso hay que recurrir a soluciones profesionales que conllevan un coste más o menos considerable.

En esta ocasión os voy a mostrar una herramienta de código libre que nos ofrece una interfaz visualmente atractiva, aprovechando la potencia de una herramienta del omnipresente Google. Esta herramienta se llama SnoGE y está desarrollada por Leon Ward, un ingeniero de seguridad que trabaja en Sourcefire, empresa que está detrás del proyecto Snort. Este script procesa las alertas generadas por Snort en formato Unified2 y genera un fichero KML. ¿Qué es un fichero KML? Para quien no lo sepa, se trata de un fichero XML especialmente diseñado por Google para representar objetos en su GoogleEarth. Y es ahí donde está la gracia del proyecto SnoGE: con un sencillo script escrito en Perl, es posible montar una interfaz gráfica muy atractiva que nos permite ver desde dónde nos están atacando; ideal para cuando vengan periodistas ávidos de ver ataques informáticos en tiempo real u otra fauna no técnica, al estilo de la película “Juegos de Guerra” o las diseñadas por Mark Coleran.

Saben ustedes que es norma habitual NO utilizar este blog para hablar de S2 Grupo como empresa, sino de seguridad en el sentido más amplio de la palabra, pero nos van a permitir que esta vez hagamos una pequeña excepción a este hábito a raíz de un proyecto concreto que acabamos de cerrar. Y es que creemos que la ocasión vale la pena, juzguen ustedes…

Si algo caracteriza a la Autoridad Portuaria de Valencia (APV) es el hecho de ser una organización pionera en su sector, en continua innovación, y dando respuesta a los retos que exige un mercado tan competitivo como en el que se mueve la APV. Intentar ir un paso por delante del resto ha sido siempre una de sus señas de identidad, ofreciendo servicios punteros a la comunidad portuaria nacional e internacional, y ejerciendo de locomotora del desarrollo económico de la Comunidad Valenciana.

Estimados lectores, a raíz de un reciente proyecto, he podido conocer el significado de la palabra Exitus. Probablemente muchos de ustedes conocerán el significado de esta palabra, pero para los no estén familiarizados con el término éste se emplea en el ámbito medico para hacer referencia a historias clínicas de pacientes que han terminado en la muerte de un individuo.

Este post trata de desarrollar este escatológico término en el ámbito de las TI; es decir, que sucede con la información de un individuo tras su defunción.

Con independencia de las calificaciones morales o éticas que tenga el uso indebido de la información relacionada con un difunto, desde un punto de vista actual con respecto al tratamiento de esos datos por parte de la LOPD, en el informe 61/2008, Aplicación de la normas de protección de datos a los datos de personas fallecidas, de la AEPD, se indica

Las organizaciones cambian constantemente; es posible que algunas cambien por capricho pero la gran mayoría cambian para subsistir. El origen de los cambios es diverso: algunos tienen que ver con iniciativas internas de la empresa, otros están condicionados por la relación con terceras partes (clientes, proveedores, socios, etc.) y, por supuesto, hay cambios que vienen forzados por el entorno. Por ejemplo, un cambio en el marco legislativo puede forzar a la organización a modificar sus procesos a fin de cumplir los nuevos requisitos regulatorios.

Todos tenemos claro que los cambios, sea cual sea su origen u objetivo, tienen lugar y por lo tanto, se deben gestionar adecuadamente para evitar que éstos repercutan negativamente en la seguridad de la organización.

Desde hace un tiempo, cuando realizamos compras con nuestra tarjeta de crédito o débito, hemos dejado de firmar un recibo y ahora debemos introducir el número PIN de nuestra tarjeta en el TPV del comercio. Supongo que las entidades bancarias habrán introducido este cambio en la forma de pago por motivos de seguridad (digo yo), pero no estoy del todo segura de que con este nuevo método la seguridad se vea incrementada, dado que ahora tenemos que introducir el PIN de nuestra tarjeta delante de otros clientes, personal de los comercios, y cualquiera que esté próximo al TPV.

Con la firma, si alguien sustraía tu tarjeta, no podía ir al cajero y retirar efectivo de tu cuenta. Sin embargo, ahora no sólo puede hacerlo sino que muchos comercios asumen que al conocer el PIN tú eres el legítimo propietario de la tarjeta, y han dejado de pedir el DNI. Además, el hecho de haberse fijado en el PIN que ha tecleado otra persona puede “motivar” a algún desalmado a robar la tarjeta de alguien con quien ha coincidido en un comercio, ya que una vez se haga con ella, los obstáculos para acceder a sus ahorros han desaparecido.

¿Consideras que la sustitución de la firma por la introducción del PIN al pagar en los comercios incrementa la seguridad?

• No, porque expongo más el PIN de mi tarjeta (54%, 80 Votos)
• Sí, porque sólo yo sé mi PIN y la firma es fácil de imitar (24%, 36 Votos)
• Creo que es similar (22%, 31 Votos)

Votantes: 147

 Loading ...

El pasado martes estuvimos analizando algunos aspectos del ENS y de la Ley de PIC en una sesión de trabajo junto a amigos y compañeros del mundillo de la seguridad; al hablar de Protección de Infraestructuras Críticas, uno de los puntos de debate fue la obligatoriedad de que el Responsable de Seguridad y Enlace disponga de la habilitación de Director de Seguridad expedida por el Ministerio del Interior, según lo previsto en la normativa de Seguridad Privada, marcada explícitamente en el artículo 16 -si no me equivoco-. Por supuesto, esta obligación generó algo de polémica, ya que el planteamiento es que si buena parte de los riesgos provienen del ámbito tecnológico debería o bien indicarse como requisito algún título, certificación, habilitación… adicional al anterior (o incluso que lo sustituya) o bien dejarse abierto, sin definir ninguna restricción en la Ley en cuanto a requisitos para el Responsable de Seguridad y Enlace. Evidentemente, el foro incitaba al debate porque todos los que participábamos proveníamos del ámbito de las TIC; si la reunión la hubiera organizado AVADISE, por poner un ejemplo, ni siquiera se habría comentado este punto, ya que lo consideraríamos algo normal… ¿verdad? :)

Mis argumentos en este caso fueron de apoyo total a la Ley y a la restricción que impone. Nos guste o no, las figuras definidas en la LSP son las únicas existentes en materia de seguridad -ámbito privado, por supuesto- en España, con lo que si tenemos que definir algún rol “reconocido”, debe ceñirse a estas figuras (y por supuesto, a la hora de hablar del Responsable de Seguridad y Enlace, la figura adecuada es la de Director de Seguridad, ¿verdad?). A partir de ahí, algunas consideraciones: