Las amenazas informáticas del 2007

noviembre 30, 2006 § Deja un comentario

En el año 2007 se harán más evidentes una mayor cantidad de ataques para capturar la ID y contraseña de los usuarios al mostrar una página falsa de inicio de sesión y un aumento de los ataques dirigidos a servicios populares en línea como eBay. Como lo demostraron los ataques de fraude electrónico que siguieron al huracán Katrina, McAfee Avert Labs también espera más ataques que aprovechen la buena disposición de las personas para ayudar a quienes lo necesitan. Por el contrario, se espera que disminuyan los ataques a los Proveedores de servicios de Internet (ISP), mientras que los orientados al sector financiero se mantendrán estables.

Leer artículo completo
___

Anuncios

Las amenazas informáticas del 2007

noviembre 30, 2006 § Deja un comentario

En el año 2007 se harán más evidentes una mayor cantidad de ataques para capturar la ID y contraseña de los usuarios al mostrar una página falsa de inicio de sesión y un aumento de los ataques dirigidos a servicios populares en línea como eBay. Como lo demostraron los ataques de fraude electrónico que siguieron al huracán Katrina, McAfee Avert Labs también espera más ataques que aprovechen la buena disposición de las personas para ayudar a quienes lo necesitan. Por el contrario, se espera que disminuyan los ataques a los Proveedores de servicios de Internet (ISP), mientras que los orientados al sector financiero se mantendrán estables.

Leer artículo completo
___

¿Es realmente Oracle tan inseguro como nos cuentan?

noviembre 30, 2006 § Deja un comentario

Las voces que se alzaron recientemente contra Oracle empiezan a tambalearse. Y si no, véase lo que le ha pasado a Argeniss, que muy recientemente anunció una iniciativa a bombo y platillo, en la que planeaban imitar el Month of Browser Bugs y el Month of Kernel Bugs.

Finalmente, rebajaron sus pretensiones mensuales para plantear la semana de los bugs de Oracle (se ve que el mes les venía grande). Pues al final, ni eso: No habrá The Week of Oracle Database Bugs. Lo más gracioso es leer en su texto original:

Why not the Month of Oracle Database Bugs?

We could do the Year of Oracle Database Bugs but we think a week is enough to show how flawed Oracle software is, also we don’t want to give away all our 0days:), anyways if you want to contribute send your Oracle 0days so this can be extended for another week or more.

Yo no sé vosotros, pero al leer eso creo que la razón para que se cancele la semana de Oracle no es otra que la incapacidad para generar ni un sólo 0day para Oracle. Y es que abrir la boca es fácil, pero mantenerla abierta, cuesta más trabajo. Quizás otros investigadores sí sean capaces de hacerlo, pero éstos han pinchando en su primera tentativa.

Sobre las críticas a Oracle que se están viendo últimamente, y me refiero especialmente al informe de David Litchfield, yo tengo mi punto de vista al respecto, y ayer lo dejaba entrever en los comentarios que intercambiaba con Sergio de los Santos, donde comento que medir la seguridad de un producto exclusivamente por el número de vulnerabilidades es muchas veces irreal, especialmente cuando el producto analizado requiere de un deployment medianamente serio, más allá de una instalación rápida como la que podemos hacer para cualquier aplicación doméstica.

Admito que el número de vulnerabilidades es un rasero adecuado si pretendemos comparar la seguridad de dos aplicativos que están listos para ser usados tal y como los entrega el fabricante. Ese estado de entrega es el estado de arranque para la seguridad, ya que usaremos el producto nada más abrir la caja e instalarlo.

Pero ese razonamiento hace aguas cuando el producto requiere un proceso de implementación multivariable, en el que se transforman las cualidades del producto que sale de la caja, ya que la personalización mitiga muchas veces riesgos y vulnerabilidades. Es el caso de Oracle, es el caso de SQL Server, es el caso de Sybase, es el caso de DB2, y en general, es el caso de los motores que están pensados para ser desplegados tras un proceso consultivo y de adecuación a las necesidades del despliegue.

Os pongo un ejemplo. Según el estudio de Litchfield, Oracle es menos seguro porque sufre más vulnerabilidades que SQL Server. La pregunta que me hago yo es muy sencilla. ¿Qué pasa si ese Oracle no está expuesto a tráfico remoto? ¿Qué pasa si ese Oracle está encapsulado en una red aislada de producción que en ningún caso tiene trato directo ni con el exterior, ni tan siquiera con los usuarios de esa red interna? ¿Qué pasa si tengo una versión de Oracle con 200 vulnerabilidades pero NINGUNA puede ser explotada porque los únicos usuarios que pueden tocar la BBDD son operadores y administradores sujetos a normativa de seguridad corporativa y/o a directiva de auditoría del propio motor de la BBDD? El ejemplo me vale para cualquier gestor profesional de los que he citado antes, incluído SQL Server. No hay distinciones.

En definitiva, soy de los que opina que ese informe está sesgado y que no representa ni tan siquiera la realidad, ya que se está dando por supuesto que Oracle está siempre expuesto a la explotación de vulnerabilidades, y eso no siempre es así. Como tampoco está siempre expuesto SQL Server. Para mí, en un SQL Server sin parchear 5 años, que no tiene trato con usuarios (un agregador de información, una interfase de un aplicativo corporativo, etc.) y que no es manipulable ni por sus inputs ni sus outputs, no es prioritaria la política de parcheado, y sin embargo sí lo es la política de funcionalidad. Yo consideraré ese SQL Server como seguro frente a explotación de vulnerabilidades, y centraré mis esfuerzos en verificar que no cumplir con la política de parcheado no está generado problemas de funcionalidad colaterales.

Oracle no hace las cosas a la perfección. Su ciclo de parches podría ser más rápido, pero no menos cierto es que parchear Oracle tiene su miga, y que muchas veces ni en un trimestre entero se puede gestionar, repito, gestionar la seguridad de un motor de BBDD del que pende un negocio. Y es que gestionar y planificar la seguridad no significa lo mismo que parchear.

También podemos ciriticar a Oracle, y en general a la mayoría de fabricantes, por otras causas, ya que sus esfuerzos en investigación proactiva de seguridad podrían ser más concienzudos, y no dar lugar a la aparición de tantos problemas de seguridad que sí pueden ser críticos en ciertos despliegues. Pero tenemos que huír de la crítica sesgada, porque esa ni es constructiva, ni aporta nada.

A NGSS hay que entenderlos, ya que venden productos de seguridad para SQL Server, y venden productos de seguridad para Oracle. Para ellos la seguridad sólo va a girar en torno a la seguridad desde el punto de vista técnico, y no van a mirar mucho más allá. Sobre el hecho de que entre sus clientes destacados esté Microsoft y no esté Oracle no comentaré nada, pero no ayuda mucho a valorar como plenamente neutral el informe de Litchfield.

Hay un ejemplo muy espartano que ilustra claramente que la seguridad no depende de un sólo parámetro. Volvo es, según dicen muchos expertos, uno de los fabricantes de vehículos más seguros que hay. ¿Es más seguro un Volvo que un Seat Panda? Mal haríamos en decir rápidamente que sí, porque la seguridad de un vehículo no depende sólamente de las propiedades de ese vehículo tal y como sale de la cadena de montaje. ¿O es que siempre es más seguro un Volvo con las ruedas desgastadas sin líquido de frenos, con las pastillas cristalizadas y en mal estado de amortiguación que un Seat Panda en perfecto estado de mantenimiento? ¿Es más seguro ese Volvo con las cerraduras abiertas aparcado en un descampado que el Panda aparcado en un garage, con las cerraduras cerradas?

Moralejas:

* Gestionar la seguridad no equivale a parchear.
* De lo anterior se deduce que evaluar la seguridad no equivale a evaluar el estado de explotación de vulnerabilidades.
* En productos complejos, la seguridad es una cualidad que depende de muchas variables y no sólo de la cantidad de vulnerabilidades conocidas.
* Los productos que requieren personalización no presentan las mismas cualidades de seguridad que el producto que nos facilita el fabricante. Existe una transformación.
* Durante el funcionamiento y la progresiva parametrización de un gestor de base de datos, se transforman muchas de las cualidades y comportamientos del mismo, modificándose su seguridad.
* Es un error considerar a la seguridad como la única cualidad determinante para optar por una solución u otra.
* Las comparativas en rara ocasión recogen todas las casuísticas posibles, y por tanto, en rara ocasión son aconsejables para evaluar la seguridad de un producto.
* De lo anterior se deduce que las únicas comparativas válidas son aquellas en las que se comparan dos o más productos operando en las mismas condiciones y en el mismo ámbito. Comparar productos complejos en distintos ámbitos, o lo que es peor, sin estar en operación, es algo total y absolutamente carente de utilidad.
* Si te vas a comprar un coche, no hagas caso de mi ejemplo del Volvo y el Panda

Fuente: http://www.sahw.com/wp/archivos/2006/11/29/es-realmente-oracle-tan-inseguro-como-nos-cuentan/
___

¿Es realmente Oracle tan inseguro como nos cuentan?

noviembre 30, 2006 § Deja un comentario

Las voces que se alzaron recientemente contra Oracle empiezan a tambalearse. Y si no, véase lo que le ha pasado a Argeniss, que muy recientemente anunció una iniciativa a bombo y platillo, en la que planeaban imitar el Month of Browser Bugs y el Month of Kernel Bugs.

Finalmente, rebajaron sus pretensiones mensuales para plantear la semana de los bugs de Oracle (se ve que el mes les venía grande). Pues al final, ni eso: No habrá The Week of Oracle Database Bugs. Lo más gracioso es leer en su texto original:

Why not the Month of Oracle Database Bugs?

We could do the Year of Oracle Database Bugs but we think a week is enough to show how flawed Oracle software is, also we don’t want to give away all our 0days:), anyways if you want to contribute send your Oracle 0days so this can be extended for another week or more.

Yo no sé vosotros, pero al leer eso creo que la razón para que se cancele la semana de Oracle no es otra que la incapacidad para generar ni un sólo 0day para Oracle. Y es que abrir la boca es fácil, pero mantenerla abierta, cuesta más trabajo. Quizás otros investigadores sí sean capaces de hacerlo, pero éstos han pinchando en su primera tentativa.

Sobre las críticas a Oracle que se están viendo últimamente, y me refiero especialmente al informe de David Litchfield, yo tengo mi punto de vista al respecto, y ayer lo dejaba entrever en los comentarios que intercambiaba con Sergio de los Santos, donde comento que medir la seguridad de un producto exclusivamente por el número de vulnerabilidades es muchas veces irreal, especialmente cuando el producto analizado requiere de un deployment medianamente serio, más allá de una instalación rápida como la que podemos hacer para cualquier aplicación doméstica.

Admito que el número de vulnerabilidades es un rasero adecuado si pretendemos comparar la seguridad de dos aplicativos que están listos para ser usados tal y como los entrega el fabricante. Ese estado de entrega es el estado de arranque para la seguridad, ya que usaremos el producto nada más abrir la caja e instalarlo.

Pero ese razonamiento hace aguas cuando el producto requiere un proceso de implementación multivariable, en el que se transforman las cualidades del producto que sale de la caja, ya que la personalización mitiga muchas veces riesgos y vulnerabilidades. Es el caso de Oracle, es el caso de SQL Server, es el caso de Sybase, es el caso de DB2, y en general, es el caso de los motores que están pensados para ser desplegados tras un proceso consultivo y de adecuación a las necesidades del despliegue.

Os pongo un ejemplo. Según el estudio de Litchfield, Oracle es menos seguro porque sufre más vulnerabilidades que SQL Server. La pregunta que me hago yo es muy sencilla. ¿Qué pasa si ese Oracle no está expuesto a tráfico remoto? ¿Qué pasa si ese Oracle está encapsulado en una red aislada de producción que en ningún caso tiene trato directo ni con el exterior, ni tan siquiera con los usuarios de esa red interna? ¿Qué pasa si tengo una versión de Oracle con 200 vulnerabilidades pero NINGUNA puede ser explotada porque los únicos usuarios que pueden tocar la BBDD son operadores y administradores sujetos a normativa de seguridad corporativa y/o a directiva de auditoría del propio motor de la BBDD? El ejemplo me vale para cualquier gestor profesional de los que he citado antes, incluído SQL Server. No hay distinciones.

En definitiva, soy de los que opina que ese informe está sesgado y que no representa ni tan siquiera la realidad, ya que se está dando por supuesto que Oracle está siempre expuesto a la explotación de vulnerabilidades, y eso no siempre es así. Como tampoco está siempre expuesto SQL Server. Para mí, en un SQL Server sin parchear 5 años, que no tiene trato con usuarios (un agregador de información, una interfase de un aplicativo corporativo, etc.) y que no es manipulable ni por sus inputs ni sus outputs, no es prioritaria la política de parcheado, y sin embargo sí lo es la política de funcionalidad. Yo consideraré ese SQL Server como seguro frente a explotación de vulnerabilidades, y centraré mis esfuerzos en verificar que no cumplir con la política de parcheado no está generado problemas de funcionalidad colaterales.

Oracle no hace las cosas a la perfección. Su ciclo de parches podría ser más rápido, pero no menos cierto es que parchear Oracle tiene su miga, y que muchas veces ni en un trimestre entero se puede gestionar, repito, gestionar la seguridad de un motor de BBDD del que pende un negocio. Y es que gestionar y planificar la seguridad no significa lo mismo que parchear.

También podemos ciriticar a Oracle, y en general a la mayoría de fabricantes, por otras causas, ya que sus esfuerzos en investigación proactiva de seguridad podrían ser más concienzudos, y no dar lugar a la aparición de tantos problemas de seguridad que sí pueden ser críticos en ciertos despliegues. Pero tenemos que huír de la crítica sesgada, porque esa ni es constructiva, ni aporta nada.

A NGSS hay que entenderlos, ya que venden productos de seguridad para SQL Server, y venden productos de seguridad para Oracle. Para ellos la seguridad sólo va a girar en torno a la seguridad desde el punto de vista técnico, y no van a mirar mucho más allá. Sobre el hecho de que entre sus clientes destacados esté Microsoft y no esté Oracle no comentaré nada, pero no ayuda mucho a valorar como plenamente neutral el informe de Litchfield.

Hay un ejemplo muy espartano que ilustra claramente que la seguridad no depende de un sólo parámetro. Volvo es, según dicen muchos expertos, uno de los fabricantes de vehículos más seguros que hay. ¿Es más seguro un Volvo que un Seat Panda? Mal haríamos en decir rápidamente que sí, porque la seguridad de un vehículo no depende sólamente de las propiedades de ese vehículo tal y como sale de la cadena de montaje. ¿O es que siempre es más seguro un Volvo con las ruedas desgastadas sin líquido de frenos, con las pastillas cristalizadas y en mal estado de amortiguación que un Seat Panda en perfecto estado de mantenimiento? ¿Es más seguro ese Volvo con las cerraduras abiertas aparcado en un descampado que el Panda aparcado en un garage, con las cerraduras cerradas?

Moralejas:

* Gestionar la seguridad no equivale a parchear.
* De lo anterior se deduce que evaluar la seguridad no equivale a evaluar el estado de explotación de vulnerabilidades.
* En productos complejos, la seguridad es una cualidad que depende de muchas variables y no sólo de la cantidad de vulnerabilidades conocidas.
* Los productos que requieren personalización no presentan las mismas cualidades de seguridad que el producto que nos facilita el fabricante. Existe una transformación.
* Durante el funcionamiento y la progresiva parametrización de un gestor de base de datos, se transforman muchas de las cualidades y comportamientos del mismo, modificándose su seguridad.
* Es un error considerar a la seguridad como la única cualidad determinante para optar por una solución u otra.
* Las comparativas en rara ocasión recogen todas las casuísticas posibles, y por tanto, en rara ocasión son aconsejables para evaluar la seguridad de un producto.
* De lo anterior se deduce que las únicas comparativas válidas son aquellas en las que se comparan dos o más productos operando en las mismas condiciones y en el mismo ámbito. Comparar productos complejos en distintos ámbitos, o lo que es peor, sin estar en operación, es algo total y absolutamente carente de utilidad.
* Si te vas a comprar un coche, no hagas caso de mi ejemplo del Volvo y el Panda

Fuente: http://www.sahw.com/wp/archivos/2006/11/29/es-realmente-oracle-tan-inseguro-como-nos-cuentan/
___

Protección corporativa contra estafas

noviembre 30, 2006 § Deja un comentario

Pongámonos en la siguiente situación: un amigo nos dice que en mitad del mar está a punto de emerger una nueva isla.

Nuestro amigo nos da todo lujo de detalles sobre la noticia, y al final, nos dice muy serio: “Lo han dicho por televisión”. Si es así, todo debería ser cierto, si lo ha dicho la televisión…

Generalmente esas afirmaciones pueden tener visos de ser ciertas, y en función del amigo que nos la cuente deberemos tener muchas reservas a la hora de afirmar que son ciertas. Puede que haya visto un episodio de ciencia ficción, o que haya visto una información sobre la isla Graham, Ferdinandea o Giulia (según la fuente cambia el nombre). Puede que no tenga ninguna base, o puede ser completamente cierto.

En muchas ocasiones, demasiada gente lo considerará cierto “si lo ha dicho la televisión”, como cuando hace unos 20 años alguien me dijo que habían descubierto una bacteria de destruía los ordenadores (de esa noticia al primer virus informático hay un largo trecho). Afortunadamente otro grupo numeroso de personas pone en la zona de “dudoso” determinadas afirmaciones hasta que pueden verificarlas por algún medio.

Pero estamos en la puerta del año 2007, la experiencia de los rumores ha cambiado. Aunque dudemos de algunas cosas, “lo he visto en Internet” es la nueva frase de moda. Todo aquello que se vea a través de una pantalla y muestre alguna información, es cierto. Aunque lo que me haya llegado por correo sea descabellado, como ha llegado “por Internet”, es válido. Esta manera de pensar va a provocar numerosos problemas a los usuarios de los ordenadores, y muchos más a los administradores de red en el año 2007.

Para los usuarios, el problema más importante en el año 2007 va a ser el de las estafas a través de Internet. La más conocida es el ya clásico “phishing”. Si un usuario crédulo recibe un correo de su banco, sin dudarlo accede allí donde le digan y dejará datos personales suficientes como para que su cuenta corriente se vea seriamente comprometida. Pero usuarios de este tipo quedan cada vez menos, la información va calando, lentamente, entre los internautas. E incluso los bancos son conscientes de estos problemas y en algunos casos (dignos de elogio) avisan a los usuarios de una posible estafa en sus cuentas bancarias.

Por otro lado, los administradores de red se van a encontrar con el mismo problema de estas estafas, pero en dos vertientes muy distintas. Por un lado, tienen que evitar que estos robos se produzcan a nivel corporativo, de manera que el robo de dinero no se produzca en las cuentas de la empresa, sin duda mucho más jugosas que en las de los usuarios (por lo menos en su término medio).

Pero indirectamente también deberá proteger a los usuarios crédulos de su red. Ellos son los responsables de que los contenidos que penetran en la red no sean peligrosos no solo para la información (los virus, gusanos, etc), sino para los usuarios de la red. La protección no es directamente empresarial, sino que se están protegiendo los bienes de los empleados. Un valor añadido de lo que muchas veces no se percatan los administradores corporativos.

Pero a pesar de eso, siempre puede haber un código malicioso dentro de nuestros sistemas que esté causando problemas. Ese vídeo humorístico descargado por un usuario puede necesitar algún códec ubicado en alguna página maliciosa, de manera que al descargarse e instalarse esté también instalando un troyano. Pero no uno conocido, sino uno exclusivo, del cual se hayan distribuido muy pocos ejemplares en Internet. De esta manera, su detección se volverá muy complicada para los sistemas clásicos. Si la red en cuestión está equipada con sistemas de detección proactiva, estas amenazas de difícil detección podrán ser detectadas.

En un sistema personal, no es excesivamente difícil tener un sistema de protección más o menos adecuado. Todo depende de los conocimientos del usuario: si es consciente de los riesgos que corre, podrá instalar una solución para cada uno de los problemas, incluido el de la detección de códigos desconocidos.

Sin embargo, la instalación de sistemas de protección en un entorno corporativo supone un problema: ¿hasta qué punto está la red en peligro? ¿Estoy evitando las amenazas que puedan llegar a mis usuarios de una manera correcta? Si un usuario no tiene una protección correcta, puede que sufra algún tipo de problema “clásico”, como la desaparición de archivos o la imposibilidad de arrancar un sistema (que a día de hoy es un problema casi menor). Pero si el fallo en la instalación de seguridad supone que pueda entrar en el sistema un mensaje de correo electrónico que intente estafar a un usuario de la red, el problema es mayor. Y muchísimo mayor si ese posible usuario estafado es el responsable de las cuentas corrientes de la empresa.

A la hora de proteger toda una red, no solo hay que pensar en instalar un antivirus y listos. La protección, de manera global, debe considerarse también para las posibles estafas y timos, todo de manera centralizada y con claros sistemas de gestión del riesgo.

Fernando de la Cuadra
Editor Técnico Internacional
Panda Software (http://www.pandasoftware.com)

Fuente: http://www.antivirusgratis.com.ar/noticias/display.php?ID=4306
___

Protección corporativa contra estafas

noviembre 30, 2006 § Deja un comentario

Pongámonos en la siguiente situación: un amigo nos dice que en mitad del mar está a punto de emerger una nueva isla.

Nuestro amigo nos da todo lujo de detalles sobre la noticia, y al final, nos dice muy serio: “Lo han dicho por televisión”. Si es así, todo debería ser cierto, si lo ha dicho la televisión…

Generalmente esas afirmaciones pueden tener visos de ser ciertas, y en función del amigo que nos la cuente deberemos tener muchas reservas a la hora de afirmar que son ciertas. Puede que haya visto un episodio de ciencia ficción, o que haya visto una información sobre la isla Graham, Ferdinandea o Giulia (según la fuente cambia el nombre). Puede que no tenga ninguna base, o puede ser completamente cierto.

En muchas ocasiones, demasiada gente lo considerará cierto “si lo ha dicho la televisión”, como cuando hace unos 20 años alguien me dijo que habían descubierto una bacteria de destruía los ordenadores (de esa noticia al primer virus informático hay un largo trecho). Afortunadamente otro grupo numeroso de personas pone en la zona de “dudoso” determinadas afirmaciones hasta que pueden verificarlas por algún medio.

Pero estamos en la puerta del año 2007, la experiencia de los rumores ha cambiado. Aunque dudemos de algunas cosas, “lo he visto en Internet” es la nueva frase de moda. Todo aquello que se vea a través de una pantalla y muestre alguna información, es cierto. Aunque lo que me haya llegado por correo sea descabellado, como ha llegado “por Internet”, es válido. Esta manera de pensar va a provocar numerosos problemas a los usuarios de los ordenadores, y muchos más a los administradores de red en el año 2007.

Para los usuarios, el problema más importante en el año 2007 va a ser el de las estafas a través de Internet. La más conocida es el ya clásico “phishing”. Si un usuario crédulo recibe un correo de su banco, sin dudarlo accede allí donde le digan y dejará datos personales suficientes como para que su cuenta corriente se vea seriamente comprometida. Pero usuarios de este tipo quedan cada vez menos, la información va calando, lentamente, entre los internautas. E incluso los bancos son conscientes de estos problemas y en algunos casos (dignos de elogio) avisan a los usuarios de una posible estafa en sus cuentas bancarias.

Por otro lado, los administradores de red se van a encontrar con el mismo problema de estas estafas, pero en dos vertientes muy distintas. Por un lado, tienen que evitar que estos robos se produzcan a nivel corporativo, de manera que el robo de dinero no se produzca en las cuentas de la empresa, sin duda mucho más jugosas que en las de los usuarios (por lo menos en su término medio).

Pero indirectamente también deberá proteger a los usuarios crédulos de su red. Ellos son los responsables de que los contenidos que penetran en la red no sean peligrosos no solo para la información (los virus, gusanos, etc), sino para los usuarios de la red. La protección no es directamente empresarial, sino que se están protegiendo los bienes de los empleados. Un valor añadido de lo que muchas veces no se percatan los administradores corporativos.

Pero a pesar de eso, siempre puede haber un código malicioso dentro de nuestros sistemas que esté causando problemas. Ese vídeo humorístico descargado por un usuario puede necesitar algún códec ubicado en alguna página maliciosa, de manera que al descargarse e instalarse esté también instalando un troyano. Pero no uno conocido, sino uno exclusivo, del cual se hayan distribuido muy pocos ejemplares en Internet. De esta manera, su detección se volverá muy complicada para los sistemas clásicos. Si la red en cuestión está equipada con sistemas de detección proactiva, estas amenazas de difícil detección podrán ser detectadas.

En un sistema personal, no es excesivamente difícil tener un sistema de protección más o menos adecuado. Todo depende de los conocimientos del usuario: si es consciente de los riesgos que corre, podrá instalar una solución para cada uno de los problemas, incluido el de la detección de códigos desconocidos.

Sin embargo, la instalación de sistemas de protección en un entorno corporativo supone un problema: ¿hasta qué punto está la red en peligro? ¿Estoy evitando las amenazas que puedan llegar a mis usuarios de una manera correcta? Si un usuario no tiene una protección correcta, puede que sufra algún tipo de problema “clásico”, como la desaparición de archivos o la imposibilidad de arrancar un sistema (que a día de hoy es un problema casi menor). Pero si el fallo en la instalación de seguridad supone que pueda entrar en el sistema un mensaje de correo electrónico que intente estafar a un usuario de la red, el problema es mayor. Y muchísimo mayor si ese posible usuario estafado es el responsable de las cuentas corrientes de la empresa.

A la hora de proteger toda una red, no solo hay que pensar en instalar un antivirus y listos. La protección, de manera global, debe considerarse también para las posibles estafas y timos, todo de manera centralizada y con claros sistemas de gestión del riesgo.

Fernando de la Cuadra
Editor Técnico Internacional
Panda Software (http://www.pandasoftware.com)

Fuente: http://www.antivirusgratis.com.ar/noticias/display.php?ID=4306
___

Cómo es la tecnología que suplantará al código de barras

noviembre 30, 2006 § Deja un comentario

Nota de Segu-Info: Si bien la información de este artículo es real, la misma es parcial. RFID es vulnerable a ataques de diversa índole que lo hacen inseguro.

La Identificación a través de Radio Frecuencia, RFID por sus siglas en inglés, empieza a generar una nueva revolución tecnológica. Usos y aplicaciones

RFID

Durante muchos años, la captura de datos en la cadena de suministro se ha realizado por medio de la lectura de código de barras, requiriendo una línea de visión directa con el producto para su lectura.

Actualmente, la tecnología de Identificación a través de Radio Frecuencia (RFID) viene complementado los códigos de barras. Esta tecnología no requiere de una línea de visión directa para capturar la información, puesto que utiliza ondas radioeléctricas para la transmisión de datos. Ahora, los artículos pueden leerse a distancia durante todo el proceso de fabricación y distribución, hasta el punto de venta; ya que no es necesario alinear los productos para poder leerlos.

La tecnología RFID

La Identificación a través de Radio Frecuencia (RFID) es hoy una de las aplicaciones de mayor crecimiento en la industria de captura automática de datos. Con el desarrollo de etiquetas especiales para este sistema, se está optimizando la forma de tomar inventarios, distribuir y comercializar productos.

La tecnología RFID está basada en un microchip incorporado a una etiqueta que puede adherirse a cualquier tipo de producto. Este dispositivo almacena un número de identificación (como un código único) que por medio de un lector permite rastrear, ubicar y contabilizar exactamente los artículos.

La distancia de rastreo varía dependiendo del tamaño y tipo de antena y si el chip es pasivo o activo: puede ser desde dos centímetros, hasta trece metros o incluso varios kilómetros, en casos más complejos.

Una buena ubicación y orientación de la etiqueta en el producto final juega un papel significativo en la codificación, pues se deben tener en cuenta todos los factores, incluyendo el ambiental, con el fin de seleccionar las etiquetas apropiadas.

Etiquetas inteligentes

Gran parte del crecimiento de la tecnología RFID se debe a la innovación en el diseño de las “etiquetas inteligentes”, que combinan los beneficios de la codificación de barras con la funcionalidad de RFID.

Actualmente, existen impresoras que incorporan las capacidades de impresión de códigos de barras, textos legibles y gráficos sobre la superficie de la “etiqueta inteligente”, al mismo tiempo que codifican la información sobre el chip RFID incrustado en la misma.

De esta forma, hay compañías que diseñan impresoras que integran estas dos funciones (como Zebra en sus modelos R110Xi y R170Xi). Este tipo de equipos de impresión funcionan como los modelos de impresión térmica tradicionales para crear códigos de barras, gráficos o texto pero incluyendo el sistema de codificación para RFID.

Antes de imprimir la “etiqueta inteligente”, los datos de RFID se codifican en la etiqueta (los datos para la codificación son seleccionados por el diseño de la aplicación y administrados automáticamente por el software del sistema). Después de la codificación, la etiqueta es leída para asegurar la exactitud de los datos y luego es impresa sobre su superficie.

Para evitar errores durante la codificación de etiquetas, las impresoras imprimen un mensaje de error sobre estas si los datos están mal codificados, invalidándolas para su uso. La velocidad en el proceso de codificación y verificación depende de la cantidad de datos RFID y del tipo de etiqueta.

Así como las impresoras, el material de las etiquetas varía. De hecho, muchas de estas cintas, según su clase, pueden llegar a optimizar el desempeño en la impresión de códigos de barras, siendo totalmente compatibles con distintos ambientes extremos; por ejemplo, se producen adhesivos especiales para soportar frío extremo o exposición química.

Ventajas de la tecnología RFID

Algunas de las ventajas que ofrece la tecnología RFID, además de la facilidad en la codificación e impresión de etiquetas, tienen que ver con la eficiencia en la manipulación de los productos durante su distribución. Es decir, se puede supervisar el inventario en cada uno de los puntos de la cadena de suministros.

Esto también es posible, debido a que las etiquetas son resistentes y permiten su lectura en cualquier tipo de entorno (superficies con pintura, suciedad, hielo, etc.).

Lo anterior permite la reducción de errores en la información de los productos, el control sobre la calidad de los mismos y sobre el stock almacenado, son beneficios que se obtienen cuando se aplica RFID a este tipo de actividades.

Acerca del RFID

La tecnología de identificación por radiofrecuencia (RFID) fue utilizada modestamente durante los últimos 30 años. En la actualidad, sus costos comenzaron a reducirse y los estándares ya se encuentran disponibles. De esta forma, la implementación de la tecnología de RFID a nivel de consumo masivo y en la cadena de abastecimiento empieza a generar una nueva revolución tecnológica que, sin dudas, afectará la forma en que las compañías desarrollan sus negocios.

Información en tiempo real acerca de la ubicación de los productos a lo largo de la cadena de abastecimiento, optimización de la disponibilidad del producto en góndola a nivel de consumo masivo, visibilidad absoluta y precisa acerca de los inventarios y mayor eficiencia en la manipulación de materiales son algunos de los principales beneficios que se desprenden del uso de esta tecnología.

Acerca de la las Impresoras y lectores RFID

Un sistema típico de RFID está constituido por cuatro componentes principales: tags, lectores, antenas y un host (computadora central). Un tag RFID está compuesto por un microchip y una antena flexible instalada sobre una superficie plástica. El lector es utilizado para leer y escribir información en el tag. Actualmente, el formato más común para tags es una etiqueta adhesiva de identificación. Las etiquetas inteligentes pueden ser impresas y aplicadas en cada caja o pallet. Para obtener una respuesta de una etiqueta RFID, el lector emite una onda de radio, cuando el tag se encuentra dentro del rango del lector, le responde identificándose a si mismo. Las etiquetas pueden leerse a distancia sin contacto físico o línea de vista con el lector.

Las etiquetas pasivas programables no tienen previsto almacenar información desde su origen, sino que requieren del proceso de codificación para ser utilizadas. Las impresoras de etiquetas inteligentes de Zebra Technologies proveen la plataforma ideal para la codificación de tags.

Por su parte, el lector utiliza su antena para enviar información digital codificada a través de ondas de radiofrecuencia. Un circuito receptor en la etiqueta es capaz de detectar el campo modulado, decodificar la información y usar su propia antena para enviar una señal más débil a modo de respuesta.

José Cornelio, gerente de Desarrollo de Negocios de Zebra Technologies (JCornelio@zebra.com)

Fuente: http://www.infobae.com/notas/nota.php?IdxSeccion=1&Idx=288897
___

¿Dónde estoy?

Actualmente estás viendo los archivos para noviembre, 2006 en Seguridad Informática.