Hackear una compañía antes de adquirirla

February 11th, 2014

¿Deberían añadirse labores de Ethical Hacking y de Incident Detection al Due-Diligence, durante el proceso de adquisición de una compañía?

Sí.

Un asesor de negocios, sí debería sugerir un “ethical hacking & incident detection”, como parte del due-diligence.

¿Pero es acaso eso ético?
Siendo que no hay nada de antiético en un due-diligence, y desde que los frameworks de due-diligence contemplan el identificar el riesgo del negocio desde la perspectiva de la seguridad de la información, por el contrario a lo que podamos concebir en primera instancia, un ejercicio de ethical hacking & incident detection es más que razonable, pues nos permitirá identificar los riesgos reales, así como los incidentes (riesgos más reales aún) que ya vienen produciéndose en esa compañía. Sin duda eso, ayudará a tener una mejor decisión a la hora de comprarla, y saber qué riesgos para los bolsillos del inversionista eso significa.

Como empresa en soluciones de análisis y detección de brechas e incidentes, JACKSECURITY ha visto importantes casos, donde la incómoda situación futura de la adquisición podría haberse mitigado, si la diligencia debida hubiera sido dirigida con igual atención sobre la seguridad de la información de la compañía adquirida, desde el enfoque real “hacking & incidentes”.

Citando un caso público, en el años 2011, la compañía VASCO tuvo que perder los €10 millones que había empleado para adquirir la compañía DIGINOTAR, además de otras tantos a sólo un par de meses de su operación de compra, luego que se descubriese que su adquirida había sido víctima de una brecha de seguridad informática importante, hecho que además sacó a la subsidiaria del negocio de los certificados digitales. Aún, los mismos oficiales de VASCO fueron los primeros en hacer saber a todos los medios de la puesta en bancarota en la que se hallaba DigiNotar.

Vea en la gráfica siguiente la importante caída estacionaria en las acciones del ejemplo descrito, luego que VASCO hiciera público los hechos, y a pesar de que los negocios de VASCO poco o nada tuvieran que ver con la tecnología de su recién subsidiada DIGINOTAR (2011)



Recomendación JaCkSecurity:
Si Ud. es un ejecutivo en esta misión escríbanos para presentarles una solución de análisis y detección de brechas e incidentes de seguridad real y en producción de su prospectada actual.

JACKSECURITY
JACK INCIDENTS NOW!

Armas para un CISO: El caso Heckenkamp (1999)

November 27th, 2013

runner

En diciembre 1999, Scott Kennedy, administrador de sistemas de Qualcomm Corp. San Diego, California, descubrió que alguien había hackeado la red de su compañía, por lo que contactó a Terry Rankhorn del FBI.

Su rastreo de la intrusión apuntaba a una computadora en la red de la Universidad de Wisconsin en Madison. Jeffrey Savoy, investigador de la red informática, respondió al contacto de Kennedy, al examinar inmediatamente los sistemas de su universidad.

Savoy determinó que en efecto alguien había empleado una computadora en la red de la universidad para hackear los sistemas de Qualcomm, y que la misma computadora había sido usada para hackear uno de los sistemas más importantes de la universidad, el servidor de correos (Mail2) con 60,000 cuentas de correo y con una carga diaria de 250,000 correos, lo que lo convertía de valor crítico, sobre todo porque era temporada de exámenes finales.

La computadora empleada pertenecía al área de hospedaje estudiantil, y su dirección IP terminaba en .117 (en adelante “x.x.x.117″). El acceso ganado contaba con los privilegios de un administrador (root), y ninguno de los administradores había estado trabajando desde los dormitorios del campus.

Fijando la dirección IP como referencia inicial, y comparándolo con los tiempos del acceso del hacking y los ingresos normales al servicio de correos, Savoy determinó que el estudiante de ciencias informáticas Jerome Heckenkamp podría estar relacionado, además de su resquemor por los antecedentes laborales de Heckenkamp en el departamento de TI, donde fuere despedido por actos similares.

Sin embargo, debido a que los registros (escritos) de asignación de direcciones IP del hospedaje estudiantil no eran precisos y hasta eran incongruentes con la persona de Jerome Heckenkamp, Savoy sólo procedió a bloquear en su firewall la computadora registrada con la dirección IP x.x.x.117.

Rankhorn (FBI) enterado de los hallazgos de Savoy, le pidió a Savoy esperar a tener la orden judicial para hacer el cateo de la computadora en cuestión.

A pesar de ello, Savoy -preocupado- decidió más tarde -en la noche- verificar si el intruso había vuelto a conectarse a Mail2, quizás al alterar su dirección IP, lo cual en efecto así comprobó. Esta vez conectado con la dirección IP x.x.x.120, Savoy elevó su nivel de preocupación, toda vez que el intruso ya sabía que estaba siendo investigado (producto del bloqueo del firewall) y que en cualquier momento podría tomar represalias contra el sistema y echarlo abajo.

El sysadmin concluyó que debía tomarse acción esa noche y no esperar al labor del FBI de la mañana siguiente, porque temía sería demasiado tarde.

Al emplear las mismas credenciales que previamente había conseguido para acceder al computador con x.x.x.117, Savoy ingreso al computador con la nueva dirección IP x.x.x.120, para verificar si se trataba del mismo. A pesar, de ello, y sin tomar borrar o alterar o destruir algún archivo en el computador, Savoy decidió ejecutar una serie de comandos que le permitiesen verificar si el computador x.x.x.120 y el x.x.x.117 eran el mismo.

Savoy concluyó que la máquina x.x.x.120 debía ser sacada de línea inmediatamente para proteger los intereses y seguridad de la universidad, a pesar de que el FBI no tenía aún su orden judicial. Para ello contactó nuevamente al detective Scheller, miembro de la policía universitaria, con quienes desconectaron la computadora en cuestión desde el mismo cuarto de habitación de Heckenkamp, el cuál -además- estaba entreabierto, y sin Heckenkamp dentro.

Al siguiente día, el FBI consiguió su orden de allanamiento, por lo que confiscaron la computadora e inspeccionaron la habitación. Heckenkamp fue acusado de múltiples delitos por acceso intencional a computadoras protegidas sin autorización (18 U.S.C. §,1030(a)(5)(B).

En amparo a la 4ta Enmienda, Keckenkamp solicitó suprimir la evidencia -que él consideraba ilegal- obtenida por:
1) la inspección remota de su computadora,
2) la imagen del disco duro tomada de su computadora la noche del hallazgo (la que había sido de su consentimiento original),
3) la confiscación realizada en consecuencia a la orden de allanamiento del FBI,

Aunque los jueces no negaron su derecho a la expectativa de privacidad razonable de la 4ta. Enmienda, el tribunal de apelaciones finalmente desestimó su pedido, por dos razones esenciales:

1) Porque Savoy no hackeó la computadora de Heckenkamp para sostener evidencias a favor de la investigación federal (FBI) de Qualcoom Corp., Savoy hackeó la computadora de Heckenkamp únicamente para proteger el servidor de correos de su universidad en un momento del negocio que él consideró de alto riesgo el no tomar acciones inmediatas para determinar el equipo real, bloquearlo y entregarlo a las autoridades.

2) Los términos de servicio (TOS/TOU) de la universidad autorizaban el hacking de Savoy. Al respecto, la corte señaló: “Bajo las políticas de la universidad, las cuales consintió Heckenkamp cuando conectó su computadora a la red de la universidad, Savoy estaba autorizado a rectificar situaciones de emergencias que amenacen la integridad de los sistemas informáticos y de comunicaciones del campus… además señaló que… Savoy descubrió a través de su inspección de los registros de la red, sobre los que Heckenkamp no tenía por qué tener alguna expectativa de privacidad razonable, que la computadora que él había bloqueado previamente de la red estaba ahora operando desde un dirección IP diferente, lo cuál en sí mismo era ya una violación a otra política de la red de la universidad”

Resumido de http://cdn.ca9.uscourts.gov/datastore/opinions/2007/04/04/0510322.pdf

J A C K S E C U R I T Y
- JaCk Incidents Now! -

Ética

November 15th, 2013

Recientemente estuvimos hablando de ética en un repaso interno del CBK. Y nos quedó claro que este tema casi hasta parece tierra virgen en la actualidad en las conferencias de seguridad, especialmente en las que se habla de hacking.

Con la finalidad de demostrar quién es mejor, o cuán grande es su kung fu, muchos hackers deben hacer uso de la irreverencia para venderse bien.

Sin embargo, ese (halo o transpiración real de) arrogancia que le distingue a la mayoría de los que se hacen llamar hackers, a veces les lleva a salirse del libreto de lo que le llamamos “hacking o hacker ético”.

¿Por qué deberíamos salirnos del libreto? ¿Cuándo deberíamos salirnos del libreto?

En JaCkSecurity empresa, tenemos un “código de ética”, y guardamos un capítulo con muchas reglas para dicho fin, pues puede ser extremadamente “bajo de ética” el no controlar el espíritu hacker.

Aunque, la habilidad parece darte el poder para hacer o gozar de algo que el resto no puede o no tiene (acceso), eso no significa que tienes licencia para hacerlo, sobre todo si ostentas una certificación de hackeo ético. Eso sería contradictorio.

Un individuo contradictorio o con doble libreto, no puede ser un individuo de fiar. Y con las disculpas del resto de colegas, no debe ser aceptado en una comunidad (seguridad) donde nos queremos hacer notar por la “confianza”.

En JaCkSecurity creemos que sin confianza en la gente de seguridad, no hay mercado de seguridad legítimo, sino mas bien un mercado sobre el que no podemos construir “buenos” negocios. Por eso, es importante para nosotros la ética.

Escribimos este post, para aquellos colegas y competidores que aún se mantienen en la brecha, luchando contra la falsa ética hacker, contra los irreverentes que patean el tablero, contra los que hackean a sus propias instituciones “éticas” y/o superiores.

A todos aquellos que procuran guardar la ética, los felicitamos.

Debemos redoblar esfuerzos en alzar nuestra ética aún más, para que aquellos que ostentan el título de ética y aún no comprenden su verdadero significado puedan madurar pronto.

Sigamos siendo éticos, y en el largo plazo cocecharemos resultados beneficiosos para todos en esta fascinante industria.

Javier Romero
Chief Technology Officer
JaCkSecurity

Ingeniero social, ¡ya te ví!

September 12th, 2013

2012-12-14 19.31.02-400

Fueron las palabras que nuestro falso mensajero leyó de los ojos de una de las ejecutivas que lo vió descender del ascensor común de la torre que minutos antes había burlado satisfactoriamente.

Hoy en día es común las solicitudes de pruebas de ingeniería social física y lógica, para probar la propensibilidad de todos los usuarios y agentes de la seguridad de una compañía. Sin embargo, de qué sirve encrespar la suspicia de un usuario, si previamente no se le ha “entrenado” para responder a incidentes de este tipo. (¿No es mas bien hasta cierto punto injusto? Si su política no lo detalla así)

La ejecutiva que vio a nuestro falso mensajero, de haber sido entrenada, hubiera tomado acciones, y no sólo nos habría observado con ojos de:

“¡ya te ví! si algo sucede no me olvidaré tu rostro, mensajero con ese pingüino navideño”

Eso es sin duda, una buena medida del usuario aislado (se llama juicio y criterio: muchas mujeres lo tienen más desarrollado que los hombres), pero no es una componenda eficaz en un paquete de respuesta a incidentes “entrenado” de los usuarios de una compañía a la que se le prueba con este tipo de ataques de ingeniería social. Es decir, de qué sirve que haya un usuario alerta, si no sabe a quién reportar la misma.

Si Ud. piensa contratarnos para ataques de ingeniería social, primero verifique si su SGSI, y/o su personal entienden y sabe cómo reaccionar a ellos, de otro modo, es como llamábamos a nuestra antigua versión de nuestra familia de pentest (penetration testing):

“un deja vu“. Sí, un deja vu, es decir, un servicio que demostrará algo que prácticamente “ya lo he visto”, o que al menos tenía certero que “podía suceder”.

¿Para qué contratar una empresa que te demuestre lo que ya sabías que iba a suceder? Alguna ideas para no dejar de lado esta pruebas sólo porque si SGSI no lo contemplen, podrían ser:
1) Usar la explotación como un ejemplo para entrenamiento futuro
2) Filmarlo, documentarlo
3) Usar el material videográfico para desarrollar con todos su staff de colaboradores (en su charlas mensuales de concientización) un plan consenzuado para “responder a incidentes” por ataques de ingeniería social.

JaCkSecurity
+51-651-0222

Su SGSI (sistema de gestión de seguridad de la información) debería contar con un plan para esos eventos de interés. Sólo en Perú, la SBS (Superintendencia de Banca y Seguros) exige en su circular desarrollar procedimientos específicos para incidentes específicos, si la ingeniería social le preocupa, y su sector es regulado por SBS, entonces “debe desarrollarlo“. Asi, el próximo “ya te ví” activará la alarma, y el show se acabará antes que nuestro falso mensajero salga de su edificio.

Sembrado de evidencia, una estrategia de detección

July 17th, 2013

 

 

Sembrar evidencia puede ser muy mal visto, y de hecho si lo pretendemos usar en un litigio, hasta podríamos terminar siendo incriminados. Pero, en la práctica muchas empresas lo usan, para detectar agentes del mal, ante incidentes no controlables.

 

En la calle, hay unos dispositivos que no sobrevivirían financieramente si no fueran protegidos por esa técnica de detección efectiva. Aquí un ejemplo menos virtual.

Cuando la privacidad protegió a la música compartida (Verizon, 2003)

July 12th, 2013

 

En enero del 2003, una corte de distrito de los EE.UU. en District of Columbia ordenó que Verizon (un proveedor de servicio de Internet o ISP) debía sujetarse a las disposiciones del citatorio de RIAA, Recording Industry Association of America, una organización que representa los intereses de la industria de la grabación.

 

La RIAA, en un esfuerzo por detener la música compartida no autorizada en-línea, solicitó a Verizon los nombres de 2 de sus suscriptores quienes supuestamente hicieron disponible en el Internet más de 600 archivos de música protegidos por copyright. Aunque muchos ISPs, como Comcast, y otras universidades cumplían con similares citatorios solicitados por RIAA, Verizon rehusó a liberar los nombres de cualquier de sus suscriptores.

 

 

Verizon argumentó que al hacer eso violaría los derechos de privacidad de sus suscriptores y violarían artículos específicos de la Constitución de los EE.UU. Así, Verizon apeló la decisión de la corte de distrito. El 19 de diciembre del 2003, la Corte de Apelaciones del District of Columbia anuló la decisión de corte inferior, al fallar a favor de Verizon. [Extraído de Ethics & Technology de Herman T. Tavani]

¿Quiénes son más propensos a recibir un DDoS?

June 11th, 2013

[Anonimizado] Era una compañía de e-commerce que a juzgar de algunos andaba al margen de la bahía (Ud. entiende). Cierto día su sitio web fue agredido por un DDoS. Hasta varios días después de sufrir por pérdidas de ventas en línea, el agresor se dio a revelar. El atacante indicó ser del otro latitud, y le solicitó a la empresa de e-commerce $9K por detener los ataques. Estos ataques eran esporádicos y astutamente breves, y se repitieron luego de recibir esta oferta de salvataje. El empresario fue reacio a seder esa suma. Al ver que nadie lo ayudaba, decidió salir del país donde alojaba su sitio de e-commerce. Esta decisión no duró ni 4 semanas desde el inicio de los hechos. ¿Sabría el atacante al tipo de negocio que atacaba?

Era un sitio de venta de medios digitales ilegal. Otros sitios propensos a DDoS:
- Sitios de pedófilos o pedofilia
- Sitios de ideas políticas no aceptadas
- Sitios ilegales o prohibidos
- Sitios que hacen dinero ilegal
- Sitios de e-commerce en general (con algún transfondo de revanchismo)
- Sitios de streaming
- En incluso sitios legales, pero vulnerables a race-conditions o de propensos a venganzas (¿sitios de gaming?)

YES!, la realidad supera al cine

June 6th, 2013

Este era un “insider” que trabajaba para una agencia de reporte de créditos de consumo (si ve el enlace, no son muchas de las cuáles conjeturar http://www.fdic.gov/consumers/consumer/ccc/reporting.html). Su responsabilidad era mantener la información almacenada en la base de datos de crédito de consumo. A cambio de dinero que recibía de “outsiders”, ella inflaba la calificación de crédito de los consumidores para permitirles hacerse de préstamos de instituciones financieras de crédito y préstamo. Ella, también, asimiló a otros “insiders” a su conspiración quienes le ayudaron a modificar o borrar datos de historiales de créditos de 178 consumidores a cambio de recibir una parte de su paga. El propósito era fortalecer la confianza crediticia de los consumidores; el impacto de este fraude provocaría que las compañías de préstamos expidieran USD 4.2 millones en nuevos créditos a estos consumidores de mala tacha. (Historia de la base de datos del CERT/CC del libro The CERT Guide To Insider Threats). Quizás le recuerde a la película YES!

En cierto país de Sur América, a fines de la primera década del XXI, una entidad financiera corrompido por error los registros colectados de todo el sistema financiero, al reportar datos del backup del periodo anterior. La medida fue superada por las mismas entidades usuarias, al no poder usar los datos sincretizados del sistema, por lo menos durante el periodo afectado.

Una vez más, comunicar el incidente oportunamente y transparentemente es y seguirá siendo una estrategia importante del plan de crisis (BS25599, ISO 22301).

DDoS, Defensa Nacional

April 5th, 2013

JaCkSecurity

Análisis y Detección: Fuga Información

February 25th, 2013

¿Qué es Snitch?: Soplón.

Snitch

FanPage InPage

¿Día Protección Datos Personales?

January 29th, 2013

Violencia (RAE) = Acción violenta o contra el natural modo de proceder.

SB1386

28 Enero

FanPage InPage

LACSEC 2013, call for papers

January 23rd, 2013

***********************************************************************
LLAMADO A PRESENTACION DE TRABAJOS
***********************************************************************
LACSEC 2013
8vo Evento de Seguridad en Redes para América Latina y el Caribe
Mayo 5-10, 2013, Medellín, Colombia

http://www.lacnic.net/es/web/eventos/lacnic19

LACNIC (http://www.lacnic.net) es la organización internacional con sede
en Montevideo (Uruguay) que administra el espacio de direcciones IP, la
Resolución Inversa, los Números de Sistemas Autónomos, y otros recursos
para la región de América Latina y el Caribe en nombre de la comunidad
Internet.

En el marco de la realización de la decimonovena reunión anual de
LACNIC (LACNIC XIX), en la ciudad de Medellín (Colombia), tendrá lugar
el “8vo Evento de Seguridad en Redes para América Latina y el
Caribe” (LACSEC 2013). Hacemos entonces público este llamado para la
presentación de trabajos a ser expuestos en el mencionado evento.

Los temas de interés para este evento incluyen (pero no se limitan a):

* Honeypots, monitorización de red y herramientas de Situational
Awareness en general.
* Lucha contra el spam, particularmente ataque al spam desde el origen
(SPF, DKIM y tecnologías relacionadas. Email reputation)
* Lucha contra el phishing y el pharming
* Lucha contra malware
* Seguridad en protocolos de Internet
* Seguridad IPv6
* DNSsec
* Seguridad de Servicios de infraestructura de red (DNS, NTP, etc.)
* Seguridad web
* Respuesta y mitigación de DoS/DDoS, botnets
* Autenticación y control de acceso
* Seguridad en la nube
* Protección de infraestructuras críticas
* Seguridad en computación móvil
* Grupos de respuesta a incidentes de seguridad (CSIRTs por su sigla en
ingles): creación, gestión, experiencias
* Seguridad en entornos corporativos, cumplimiento y auditoría, retorno
sobre la inversión en seguridad
* Administración de la Seguridad (procedimientos, bitácoras operativas,
registros, etc.)
* Gestión de riesgos de Seguridad de la Información
* Informática Forense
* Protección de la privacidad
* Aspectos legales de la seguridad de la información

Guia para la presentación de trabajos

La presentación de trabajos para el “8vo Evento de Seguridad en
Redes para América Latina y el Caribe” (LACSEC 2013) deberá realizarse
teniendo en cuenta las siguientes consideraciones:

* La propuesta deberá consistir en un paper (artículo), o en su defecto
un Resumen Extendido más un borrador de las diapositivas.
* Se aceptarán propuestas presentadas en idioma inglés, portugués o
español
* Las propuestas deberán ser enviadas en formato Portable Document
Format (PDF)
* Los artículos deberán ser generados directamente desde un procesador
de textos (no escaneados)
* Las presentaciones no podrán exceder los 30 minutos de duración

Envío de propuestas

Los interesados en realizar presentaciones de trabajos deberán enviar
dentro de las fechas establecidas la siguiente información a la
dirección de correo electrónico :

* Título completo del trabajo a presentar
* Artículo completo, o en su defecto un Resumen Extendido (Extended
Abstract) más un borrador de las diapositivas. El artículo completo no
podrá superar las 10 páginas. El Resumen Extendido no deberá superar las
mil (1000) palabras. El Comité Evaluador podrá, a su criterio, solicitar
información adicional o complementaria
* Nombre completo, dirección de correo electrónico y afiliación del
autor (o los autores) del trabajo
* Especificar si al menos uno de los autores de la propuesta puede
garantizar su asistencia al evento, o si ésta depende de la posibilidad
de obtener asistencia económica por parte de los organizadores del
evento (ver “Privilegios para los Ponentes”).

Para mayor información, no dude en contactar al Comité Evaluador a
través del correo electrónico .

Evaluación de trabajos

El Comité Evaluador constituido para tal fin tendrá los siguientes
criterios básicos para la evaluación de los trabajos enviados:

* Originalidad
* Calidad Técnica
* Relevancia
* Presentación
* Aplicabilidad

Privilegios para los Ponentes

Aquellos autores cuyas propuestas de presentación resulten aceptadas
tendrán cubierta la registración al evento (la cual incluye almuerzos y
coffee-breaks). Sin embargo, no se encuentran cubiertos los gastos de
traslado ni hospedaje.

Aquellos ponentes que precisen asistencia económica para asistir al
evento deberán postularse al concurso de becas para el evento. Por favor
consulte las instrucciones correspondientes en la sección de Becas del
sitio web de LACNIC XIX:
. Para más información,
consulte al staff de LACNIC en

FECHAS IMPORTANTES

* Fecha límite de recepción de propuestas: Viernes 1 de marzo de 2013
* Notificación de aceptación de propuestas: Lunes 11 de marzo de 2013
* Fecha límite para el envío de versiones finales: Domingo 5 de mayo
de 2013

“8vo Evento de Seguridad en Redes para América Latina y el Caribe”
(LACSEC 2013)

Chair
Fernando Gont (SI6 Networks/UTN-FRH, Argentina)

Comité Evaluador
Iván Arce (Fundación Sadosky, Argentina)
Carlos A. Ayala Rocha (Arbor Networks, México)
Julio César Balderrama (ISM GLOBAL S.A., Argentina)
Matthias Bethke (Zonarix S.A., Ecuador)
Eduardo Carozo Blumsztein (ITC SA, Uruguay)
Jeimy J. Cano M. (Fac. de Derecho, U. de los Andes, Colombia)
Giovanni Cruz Forero (Consultor Independiente, Colombia)
Lorena Ferreyro (Consultora Independiente, Argentina)
Javier Liendo (Cisco México, Cisco)
Carlos Martinez-Cagnazzo (LACNIC, Uruguay)
Alex Nunes (MS2, Brasil)
Hernan Ochoa (Amplia Security, Argentina)
James Pichardo (DO-CSIRT, República Dominicana)
Patricia Prandini (Posg. en Seg. Informática, UBA, Argentina)
Javier Romero (JACKSECURITY, Perú)
Rodrigo Rubira Branco (Dissect PE Project, Brasil)
Hugo Salgado (NIC Chile, Chile)
Carlos Sarraute (Grandata, Argentina)
Leonardo Serodio (Alcatel-Lucent, Estados Unidos)
Arturo Servin (LACNIC, Uruguay)
Liliana V. Solha (CAIS/RNP, Brasil)
Leonardo Vidal (ISOC Capitulo Uruguay, Uruguay)

*************************************************************************
Convocação para apresentação de trabalhos
*************************************************************************
LACSEC 2013
Oitavo Evento de Segurança em Redes para a América Latina e o Caribe
De 5 a 10 de maio de 2013 em Medellin, Colômbia

http://www.lacnic.net/pt/web/eventos/lacnic19

LACNIC (http://www.lacnic.net) é uma organização internacional com sede
em Montevidéu (Uruguai), que gerência o espaço de endereçamento IP, a
Resolução Inversa, os Números de Sistemas Autônomos e outros recursos
para a América Latina e o Caribe em nome da comunidade Internet.

No marco da realização da XIX Reunião anual do LACNIC (LACNIC XIX), na
cidade de Medellin (Colômbia), vai acontecer o “Oitavo Evento de
Segurança em Redes para a América Latina e o Caribe” (LACSEC 2013).
Fazemos então pública esta convocação para apresentação de trabalhos a
serem expostos no mencionado evento.

O evento inclui o seguintes temas de interesse (porém não são
excludentes):

* Honeypots, monitoramento de rede e ferramentas de Situational
Awareness em geral.
* Luta contra o spam, particularmente ataque ao spam desde a origem
(SPF, DKIM e tecnologias relacionadas. Email reputation)
* Luta contra phishing e pharming
* Luta contra malware
* Segurança em protocolos da Internet
* Segurança IPv6
* DNSsec
* Segurança de serviços de infraestrutura de rede (DNS, NTP, etc.)
* Segurança na Web
* Resposta e mitigação de DoS / DDoS, botnets
* Autenticação e controle de acesso
* Segurança na nuvem
* Proteção de infraestruturas críticas
* Segurança em computação móvel
* Grupos de resposta a incidentes de segurança (CSIRTs, por sua sigla em
Inglês): criação, gestão, experiências
* Segurança em ambientes corporativos, compliance e auditoria, retorno
de investimento em segurança
* Administração da segurança (procedimentos, registros operacionais, etc.)
* Gestão de riscos na Segurança da Informação
* Computação forense
* Proteção da privacidade
* Aspectos legais da segurança informática

Orientações para o envio de trabalhos

A apresentação de trabalhos para o “Oitavo Evento de Segurança em Redes
para a América Latina e o Caribe” (LACSEC 2013) deverá ser realizada
levando em conta as seguintes considerações:

* A proposta deverá consistir em um artigo ou, na sua falta, em um
resumo estendido acompanhado de um esboço dos slides.
* Serão aceitas propostas em português, inglês ou espanhol.
* As propostas deverão ser apresentadas em PDF (Documento em Formato
Portável);
* Os artigos deverão ser gerados diretamente de um processador de texto
(não escaneados);
* As apresentações não poderão exceder os 30 minutos.

Envio das propostas

Os interessados em realizar apresentações de trabalhos deverão enviar,
dentro dos prazos estabelecidos, as seguintes informações ao e-mail
:

* Título completo do trabalho a ser apresentado
* Artigo completo ou, na sua falta, um resumo (Abstract) estendido
acompanhado de um esboço dos slides. O artigo completo não deverá
exceder as 10 páginas, e o resumo, as mil (1000) palavras. O Comitê
Avaliador poderá, a seu critério, solicitar informações adicionais ou
complementares.
* Nome completo, e-mail e filiação institucional do autor (ou autores)
do trabalho.
* Especificar se pelo menos um dos autores da proposta poderá garantir a
sua presença no evento ou se a mesma vai depender da possibilidade de
receber ajuda econômica por parte dos organizadores do evento (veja
“Privilégios para os Palestrantes”).

Para mais informações, entre em contato com o Comitê Avaliador através
do e-mail:

Avaliação dos trabalhos

O Comitê Avaliador instituído para este fim levará en conta os seguintes
critérios básicos para a avaliação dos trabalhos apresentados:

* Originalidade
* Qualidade técnica
* Relevância
* Apresentação
* Aplicabilidade

Privilégios para os Palestrantes

Os autores que tiverem o seu trabalho aceito, terão direito ao pagamento
da inscrição ao evento. Porém, as despesas de passagens e hospedagem não
estarão cobertas.

Aqueles palestrantes que precisarem ajuda econômica para assistir ao
evento, poderão inscrever-se ao concurso de bolsas que será anunciado
oportunamente no site do LACNIC. Por favor, leia as instruções na página
de Bolsas de LACNIC XIX: .

O fato de solicitar a bolsa, não garante em qualquer caso, a obtenção da
mesma. Para mais informações, entre em contato com a equipe do LACNIC
pelo e-mail

DATAS IMPORTANTES

* Prazo limite para recebimento das propostas: Sexta-feira 1 de
março de 2013
* Notificação de aceitação das propostas: Segunda-feira 11 de março de
2013
* Prazo limite para o envio das versões finais: Domingo 5 de maio de 2013

“Oitavo Evento de Segurança em Redes para a América Latina e o Caribe”
(LACSEC 2013)

Chair
Fernando Gont (SI6 Networks/UTN-FRH, Argentina)

Comitê Avaliador
Iván Arce (Fundación Sadosky, Argentina)
Carlos A. Ayala Rocha (Arbor Networks, México)
Julio César Balderrama (ISM GLOBAL S.A., Argentina)
Matthias Bethke (Zonarix S.A., Equador)
Eduardo Carozo Blumsztein (ITC SA, Uruguai)
Jeimy J. Cano M. (Fac. de Derecho, U. de los Andes, Colômbia)
Giovanni Cruz Forero (Consultor Independiente, Colômbia)
Lorena Ferreyro (Consultora Independiente, Argentina)
Javier Liendo (Cisco Mexico, Cisco)
Carlos Martinez-Cagnazzo (LACNIC, Uruguai)
Alex Nunes (MS2, Brasil)
Hernan Ochoa (Amplia Security, Argentina)
James Pichardo (DO-CSIRT, Republica Dominicana)
Patricia Prandini (Posg. en Seg. Informática, UBA, Argentina)
Javier Romero (JACKSECURITY, Peru)
Rodrigo Rubira Branco (Dissect PE Project, Brasil)
Hugo Salgado (NIC Chile, Chile)
Carlos Sarraute (Grandata, Argentina)
Leonardo Serodio (Alcatel-Lucent, Estados Unidos)
Arturo Servin (LACNIC, Uruguai)
Liliana V. Solha (CAIS/RNP, Brasil)
Leonardo Vidal (ISOC Capitulo Uruguay, Uruguai)

***********************************************************************
CALL FOR PRESENTATIONS
***********************************************************************
LACSEC 2013
8th Network Security Event for Latin America and the Caribbean
May 5-10, 2013, Medellin, Colombia

http://www.lacnic.net/en/web/eventos/lacnic19

LACNIC (http://www.lacnic.net) is the international organization based
in (Uruguay) that is responsible for the administration of the IP
address space, Reverse Resolution, Autonomous System Numbers and other
resources for the Latin American and the Caribbean region on behalf of
the Internet community.

The “8th Network Security Event for Latin America and the Caribbean”
will be held in Medellin, Colombia, within the framework of LACNIC’s
eighteenth annual meeting (LACNIC XIX). This is a public call for
presentations for that event.

The topics of interest include, but are not limited to, the following:

* Honeypots, network monitoring and situational awareness tools in
general.
* Fighting spam, particularly spam from origin (SPF, DKIM and related
technologies. Email reputation)
* Fighting phishing and pharming
* Fighting malware
* Internet protocol security
* IPv6 security
* DNSsec
* Security of network infrastructure services (DNS, NTP, etc.)
* Web security
* DoS/DDoS response and mitigation, botnets
* Authentication and access control
* Security in the cloud
* Critical infrastructure protection
* Mobile systems security
* Computer security incident response teams (CSIRTs): creation,
management, experiences
* Security in corporate environments, compliance and auditing, return on
information security investments
* Security management (procedures, operational logs, records, etc.)
* Risk management in Information Security
* Computer forensics
* Protection of privacy
* Legal aspects related to information security

Guidelines for Presenting Proposals

Proposals for the “8th Network Security Event for Latin America and the
Caribbean” (LACSEC 2013) must be presented taking into account the
following considerations:

* The proposal may consist of a paper, or (alternatively) an Extended
Abstract plus a draft version of the slides to be used during the
presentation.
* Proposals may be presented in English, Portuguese or Spanish.
* Proposals must be submitted in Portable Document Format (PDF)
* Submissions must be created directly using a word processing system
(scanned articles will not be accepted)
* Presentations may not be longer than 30 minutes.

Submitting a Proposal

Those interested in presenting at LACSEC 2013 must send the following
information to within the deadlines set
forth below:

* Full title of the presentation
* A paper or, alternatively, an Extended Abstract and a draft of the
slides to be used during the presentation. The paper should not be
longer than 10 pages. The extended abstract should not contain more than
one thousand (1000) words. The Evaluation Committee may, at its sole
discretion, request additional or complementary information.
* Full name, email address and organization with which the author (or
authors) of the submission is affiliated

For more information, please do not hesitate to contact the Evaluation
Committee at .

Proposal Evaluation

The Evaluation Committee created for this purpose will evaluate
proposals based on the following basic criteria:

* Originality
* Technical quality
* Relevance
* Presentation
* Applicability

Speaker’s Privileges

LACNIC will cover the registration fee for those authors whose
presentations are accepted. However, speaker travel and accommodation
expenses will not be covered.

Presenters who require financial assistance to attend the event may
apply for the LACNIC Financial Assistance Program. Please read the
corresponding instructions
. In no case does
applying for the sponsorship program guarantee that financial
assistance will be granted. For more information please contact LACNIC
staff at .

IMPORTANT DATES

* Deadline for proposal submission: March 1st, 2013
* Notification of acceptance: March 11st, 2013
* Deadline for submitting the final version the presentation: May 5th,
2012

“8th Network Security Event for Latin America and the Caribbean”
(LACSEC 2013)

Chair
Fernando Gont (SI6 Networks/UTN-FRH, Argentina)

Evaluation Committee
Iván Arce (Fundación Sadosky, Argentina)
Carlos A. Ayala Rocha (Arbor Networks, Mexico)
Julio César Balderrama (ISM GLOBAL S.A., Argentina)
Matthias Bethke (Zonarix S.A., Ecuador)
Eduardo Carozo Blumsztein (ITC SA, Uruguay)
Jeimy J. Cano M. (Fac. de Derecho, U. de los Andes, Colombia)
Giovanni Cruz Forero (Consultor Independiente, Colombia)
Lorena Ferreyro (Consultora Independiente, Argentina)
Javier Liendo (Cisco Mexico, Cisco)
Carlos Martinez-Cagnazzo (LACNIC, Uruguay)
Alex Nunes (MS2, Brazil)
Hernan Ochoa (Amplia Security, Argentina)
James Pichardo (DO-CSIRT, Dominican Republic)
Patricia Prandini (Posg. en Seg. Informática, UBA, Argentina)
Javier Romero (JACKSECURITY, Peru)
Rodrigo Rubira Branco (Dissect PE Project, Brazil)
Hugo Salgado (NIC Chile, Chile)
Carlos Sarraute (Grandata, Argentina)
Leonardo Serodio (Alcatel-Lucent, U.S.A.)
Arturo Servin (LACNIC, Uruguay)
Liliana V. Solha (CAIS/RNP, Brazil)
Leonardo Vidal (Uruguay ISOC Chapter, Uruguay)

Backdoors para Hollywood

January 8th, 2013

Backdoors para Hollywood

Habíamos mencionado -ya- que algunos programadores dejan backdoors (puertas traseras) en el código que desarrollan, por diversas razones. La más legítima (aunque nada agradable igual) es para probar la funcionalidad, al saltarse los mecanismos de control de acceso, y así hacerse la vida más sencilla en las pruebas constantes que un programador hace a su desarrollo.

Sin embargo, hay quienes la dejan por la simple razón de que llegan a sentirse dueños de lo que hacen o producen (Revise los investigaciones de insider-threat de CERT/CC).

El escritor de este blog deja la especulación suelta de la ruta backdoor que ciertas cámaras web disponen a pesar de tener mecanismos de autenticación exclusiva (user/password):

http://la.cuna.de.mi.bebe.por.web:80/anony/mjpg.cgi

Nota: la.cuna.de.mi.bebe.por.web (es puro relleno)

¿Qué podría permitir esa puerta trasera?
- Que escenas de Hollywood como las del Agente 007 en Skyfall (dónde el MI6 persigue las imágenes de cualquier webcam que quiera, como si fuera suya) sean potencialmente “reales”, y al alcance de quien puso ese backdoor o quien lo financió (si no fue el mismo programador, por propia voluntad).

Quién o qué dejó ese URL (oculto) en ese software de cámara web, es una pregunta muy interesante y muy disgustante a la vez, pero lo que no podemos negar es que “un backdoor” (una puerta trasera), que viola el concepto de seguridad con el que fue entregado el producto.

Por si dudas: aquí la cuenta Twitter de alguien que viene publicando URLs de esas webcam.

Aquí un mapa real, que sólo Hollywood podría superar:

Backdoors webcam en el globo

JaCkSecurityJACK YOUR INCIDENTS NOW!

Fanpage en Facebook

6to. Aniversario

July 25th, 2012

Protected: No estamos libres, ciber-coyuntura

June 4th, 2012

This content is password protected. To view it please enter your password below: