Era CISO de Telefónica, no? Algún vídeo de sus charlas vi hace tiempo y lo cierto es que no me despertó mucho interés. En alguna feria tipo Mobile o Smartcity tuve conversaciones más interesantes con gente de Telefónica I+D.
 
El problema es del que le puso ahí como directivo. Que lo hicieron por imagen, no por otra cosa.

Es un tío con carisma que sabe contar las cosas, no es el mejor técnicamente ni lo pretende.
 
El problema es del que le puso ahí como directivo. Que lo hicieron por imagen, no por otra cosa.

Es un tío con carisma que sabe contar las cosas, no es el mejor técnicamente ni lo pretende.
Si. Lógicamente el que le puso en un cargo para el que no estaba cualificado, es quien tiene la responsabilidad.

Pero lo jodido, es que él se lo creyó. Y las cuatro ideas del artículo, son suyas, desoyendo a la gente que tenía por debajo.
 
No es responsable de un área, lo es de dos. Casi nada.

Yo no le tengo inquina, es que ha conseguido justo lo contrario de lo que hacía falta. Lo pusieron por imagen y la imagen ha sido lamentable. Luego le dieron unos cargos increíbles y ha sido un desastre tras otro.

Telefónica lo contrató por la imagen, un hacker de verdad va a hacer que la seguridad de la empresa sea perfecta. Nada más lejos de la realidad.

Y ya lo de estas semanas con Cloudflare… que una empresa como Telefónica parezca no saber cómo funciona una de las empresas más importantes del mundo de internet, están dando vergüenza. Me sorprendería que no estuviesen teniendo quejas muy gordas de las empresas afectadas.
 
.
814f87f14071836c54a936c471b059c0.jpg


Enviado desde mi CPH2247 mediante Tapatalk
 
NoName (prorruso/gubernamental) atacando a saco a organismos públicos en España (casa Real, gobiernos/parlamentos autonómicos...)
 
El artículo es con saña, pero merecidísima. El mayor vendehumos de la historia tecnológica de nuestro país. Increíble cómo llegó hasta ahí a base de palabrería.

Leyendo el artículo esta mañana ya no recordaba la historia de que las grandes tecnológicas se beneficiaban de ellos y que tenían que pagarles. Y lo de Aura, una risa.
 
Pero entonces, no es el más puto amo de España en ciber seguridad? Yo pensaba que era el que iba a acortar las distancias en disrupción con EEUU en cuestión de crear valor y mercado

Enviado desde mi CPH2247 mediante Tapatalk
 
Otra lección que una vez más nos debe recordar que la seguridad de un sistema, es la de su eslabón más débil.


Cómo ocurrió el mayor atraco a las criptomonedas de la historia

El exchange de criptomonedas Bybit perdió 1.500 millones de dólares a manos de piratas informáticos norcoreanos el mes pasado, y todo se remonta a una cuenta en un servicio de almacenamiento digital gratuito.


Por David Yaffe-Bellany, 6 de marzo de 2025

En la noche del 21 de febrero, Ben Zhou, el director ejecutivo del exchange de criptomonedas Bybit, se conectó a su computadora para aprobar lo que parecía ser una transacción de rutina. Su empresa estaba moviendo una gran cantidad de Ether, una popular moneda digital, de una cuenta a otra.

Treinta minutos después, Zhou recibió una llamada del director financiero de Bybit. Con voz temblorosa, el ejecutivo le dijo a Zhou que su sistema había sido hackeado.

"Todo el Ethereum se ha ido", dijo.

Cuando Zhou aprobó la transacción, había entregado inadvertidamente el control de una cuenta a piratas informáticos respaldados por el gobierno de Corea del Norte, según el FBI. Robaron 1.500 millones de dólares en criptomonedas, el mayor atraco en la historia de la industria.

Para llevar a cabo la asombrosa brecha, los piratas informáticos explotaron una falla simple en la seguridad de Bybit: su dependencia de un producto de software libre. Penetraron en Bybit manipulando un sistema disponible públicamente que el exchange utilizaba para salvaguardar cientos de millones de dólares en depósitos de clientes. Durante años, Bybit había confiado en el software de almacenamiento, desarrollado por un proveedor de tecnología llamado Safe, incluso cuando otras empresas de seguridad vendían herramientas más especializadas para empresas.

El hackeo provocó una caída libre de los mercados de criptomonedas y socavó la confianza en la industria en un momento crucial. Bajo la administración de Trump, favorable a las criptomonedas, los ejecutivos de la industria están presionando para que se establezcan nuevas leyes y regulaciones de EE. UU. que facilitarían que las personas inviertan sus ahorros en monedas digitales. El viernes, la Casa Blanca tiene previsto celebrar una "cumbre de criptomonedas" con el presidente Trump y altos funcionarios de la industria.

Los expertos en seguridad de criptomonedas dijeron que estaban preocupados por lo que el atraco reveló sobre los protocolos de seguridad de Bybit. Las pérdidas eran "completamente evitables", escribió una firma de seguridad en un análisis de la violación, argumentando que "no debería haber sucedido".

La herramienta de almacenamiento de Safe es ampliamente utilizada en la industria de las criptomonedas. Pero es más adecuado para los aficionados a las criptomonedas que los exchanges que manejan miles de millones en depósitos de clientes, dijo Charles Guillemet, ejecutivo de Ledger, una firma francesa de seguridad de criptomonedas que ofrece un sistema de almacenamiento diseñado para empresas.

"Esto realmente tiene que cambiar", dijo. "No es una situación aceptable en 2025".

En Bybit, el hackeo desencadenó 48 horas frenéticas. La compañía supervisa hasta USD 20 mil millones en depósitos de clientes, pero no tenía suficiente Ether disponible para cubrir las pérdidas del atraco de USD 1.5 mil millones. Zhou, de 38 años, se apresuró a mantener el negocio a flote pidiendo prestado a otras empresas y recurriendo a las reservas corporativas para satisfacer una oleada de solicitudes de retiro. En las redes sociales, parecía sorprendentemente relajado, anunciando unas horas después del robo que sus niveles de estrés "no eran tan malos".

A medida que se desarrollaba la crisis, el precio de Bitcoin, un referente para la industria, se desplomó un 20 por ciento. Fue la caída más pronunciada desde la quiebra de FTX en 2022, el exchange dirigido por el magnate caído en desgracia Sam Bankman-Fried.

En una entrevista esta semana, el Sr. Zhou reconoció que Bybit había advertido con anticipación sobre posibles problemas con Safe. Tres o cuatro meses antes del hackeo, dijo, la compañía notó que el software no era totalmente compatible con uno de sus otros servicios de seguridad.

"Deberíamos habernos actualizado y alejarnos de Safe", dijo Zhou. "Definitivamente estamos buscando hacer eso ahora".

Rahul Rumalla, director de productos de Safe, dijo en un comunicado que su equipo había creado nuevas características de seguridad para proteger a los usuarios y que los productos de Safe eran "la columna vertebral de la tesorería para algunas de las organizaciones más grandes en el espacio".

"Nuestro trabajo no es solo arreglar lo que sucedió", dijo Rumalla, "sino asegurarnos de que todo el espacio aprenda de ello, para que esto no vuelva a suceder".

Fundada en 2018, Bybit opera como un mercado de criptomonedas, donde los day traders y los inversores profesionales pueden convertir sus dólares o euros en Bitcoin y Ether. Muchos inversores tratan a exchanges como Bybit como bancos informales, donde depositan tenencias de criptomonedas para su custodia.

Según algunas estimaciones, Bybit es el segundo exchange de criptomonedas más grande del mundo, procesando decenas de miles de millones de dólares todos los días. Con sede en Dubái, no ofrece servicios a clientes de Estados Unidos.

El 21 de febrero, Zhou estaba en su casa en Singapur, terminando un trabajo, dijo en la entrevista.

Pero primero, él y otros dos ejecutivos necesitaban firmar una transferencia de criptomonedas de una cuenta a otra. Se supone que estas transferencias rutinarias son seguras: ninguna persona en Bybit puede ejecutarlas, lo que crea múltiples capas de protección contra los ladrones.

Sin embargo, tras bambalinas, un grupo de hackers ya había irrumpido en el sistema de Safe, según la auditoría de Bybit sobre el hackeo. Habían comprometido una computadora que pertenecía a un desarrollador de Safe, dijo una persona con conocimiento del asunto, lo que les permitió plantar código malicioso para manipular las transacciones.

Un enlace enviado a través de Safe invitó al Sr. Zhou a aprobar la transferencia. Era una treta. Cuando firmó, los piratas informáticos tomaron el control de la cuenta y robaron USD 1.5 mil millones en criptomonedas.

Las salidas repentinas aparecieron en la cadena de bloques, un libro de contabilidad público de transacciones de criptomonedas. Los analistas de criptomonedas identificaron rápidamente al culpable como Lazarus Group, un sindicato de piratas informáticos respaldado por el gobierno de Corea del Norte.

Esa noche, Zhou fue a la oficina de Bybit en Singapur para manejar la crisis. Anunció el hackeo en las redes sociales e inició un protocolo de crisis conocido en la empresa como P-1, pulsando un botón para despertar a todos los miembros del equipo de liderazgo.

Alrededor de la 1 a.m., el Sr. Zhou apareció en una transmisión en vivo en X, bebiendo un Red Bull. Prometió a los clientes que Bybit seguía siendo solvente.

"Incluso si esta pérdida de hackeo no se recupera, todos los activos de los clientes están respaldados 1 a 1", dijo en una publicación. "Podemos cubrir la pérdida".

Esas garantías no son suficientes. En cuestión de horas, dijo Zhou, aproximadamente la mitad de las monedas digitales depositadas en la plataforma, o cerca de 10.000 millones de dólares, habían sido retiradas. El mercado de las criptomonedas se desplomó.

Para limitar el daño, otras empresas de criptomonedas se ofrecieron a ayudar. Gracy Chen, la directora ejecutiva de un exchange rival, Bitget, le prestó a Bybit 40,000 en Ether, o aproximadamente USD 100 millones, sin solicitar ningún interés o incluso garantía.

"Nunca cuestionamos su capacidad para devolvernos el dinero", dijo Chen.

Entre las reuniones de crisis, el Sr. Zhou proporcionó un comentario continuo sobre X. Compartió capturas de pantalla de una aplicación de salud, mostrando que sus niveles de estrés eran sorprendentemente normales.

"Demasiado concentrado al mando de todas las reuniones. Olvidé estresarme", escribió. "Creo que llegará pronto, cuando empiece a comprender realmente el concepto de perder 1.500 millones de dólares".

Después de saquear Bybit, los piratas informáticos norcoreanos distribuyeron los fondos robados a través de una vasta red de billeteras criptográficas en línea, una estrategia de lavado de dinero que también habían empleado después de otros atracos.

"Lazarus Group está en otro nivel"
, escribió Haseeb Qureshi, un inversor de riesgo, en X después del robo.

Los expertos en seguridad culparon a Bybit por ponerse en riesgo. Para autorizar la transferencia de rutina que condujo al hackeo, dijo Zhou, utilizó una herramienta de hardware diseñada por Ledger, la firma de seguridad de criptomonedas. El dispositivo no estaba sincronizado con Safe, dijo. Por lo tanto, no podía usar la herramienta para verificar los detalles completos de la transacción que estaba aprobando, siempre una práctica arriesgada en el mundo de las criptomonedas.

"Safe simplemente no te da el tipo de controles que querrías si vas a hacer transferencias operativas con frecuencia", dijo Riad Wahby, profesor de ingeniería informática en la Universidad Carnegie Mellon y cofundador de la firma de seguridad digital Cubist.

Zhou dijo que desearía haber tomado medidas antes para reforzar las defensas de Bybit. "Ahora hay muchos arrepentimientos", dijo. "Debería haber prestado más atención a esta área".

Aun así, Bybit continuó operando después del hackeo, procesando todos los retiros en 12 horas, dijo Zhou. Poco después de la violación, anunció en X que la compañía estaba moviendo otros USD 3 mil millones en criptomonedas.

"Esta es una maniobra planificada, para su información", escribió. "Esta vez no nos han hackeado".

:ok :ok :ok
 
Como tantas cosas en la vida, el mundo de las crypto se me escapa al entendimiento. Especulación pura y dura de alto voltaje, subidas y bajadas bestiales que te puede hacer millonario como sumirte en la banca rota.
 
Recuerdo en mis tiempos de juventú un dicho entre hackers. Más o menos decía algo así "no te metas nunca en los bancos o los gobiernos". (ojito a la memoria que no tengo ni idea de dónde salió esa frase). Hasta hoy en día es cierto... a no ser que tú seas otro gobierno. En la noticia parece que dejan caer que es Corea del Norte; así como que si no importara.
Si es cierto que era un ataque "respaldados por el gobierno de Corea del Norte, según el FBI.", que también puede ser una trola para desviar a atención y encontrar un "malo", eso nos deja casi con el culo al aire. Hagan lo que hagan no los pillan jamás aunque sepan quienes han sido. Lo mismo con ataques desde Rusia o cualquier país de Oriente Medio.

Miedito, acojone y culo prieto. ¿Cómo luchar contra alguien que no teme las represalias? ¿Cómo defenderse de quien no teme perder porque no le va a pasar NADA? Hasta Putin sufrió represalias económicas por lo de Ucrania. Y le afectó, vaya que le afectó, pero tira de bolsillo y de recursos que extraer y vender pero esta gente, así en general... es como un juego para ellos. Si les pone GAME OVER, juegan otra partida.

Ojalá la Seguridad Informática fuera sólo evitar que pase
 
Lazarus "es" Corea del Norte.
NoName057 es Rusia.
APT1 es China.
APT33 y APT34 Irán.
("APT" significa "Advanced Persistent Threat", que se traduce como "Amenaza Persistente Avanzada).

Grupos de delincuentes promovidos, patrocinados y protegidos por sus respectivos gobiernos.
 
Ojalá la Seguridad Informática fuera sólo evitar que pase
Es que el problema de fondo es otro y no se quiere entender, o mejor dicho, no se acepta.

El problema que tienen hoy TODAS las empresas del mundo relacionadas en mayor o menor medida con a tecnología es EL TIEMPO.
Sí, el tiempo. Y es que no hay tiempo suficiente para hacer las cosas bien. Todo se quiere para "ya mismo", todo es urgente, todo ha de ser concebido o arreglado en un pestañeo.

Nosotros llevamos una época demasiada larga, ni recuerdo cuando empezó, donde todo es con carácter inmediato o de urgencia, donde no se respetan los tempos, donde el cliente tampoco los acepta.

Y en esas estamos, que sin tiempo no se pueden hacer las cosas bien y tarde o temprano acaban apareciendo cagadas que parecen inexplicables cuando se juzgan desde la calma y el sosiego. Lo tengo tan claro que estoy por echarme al monte a vivir como un ermitaño.
 
Es que el problema de fondo es otro y no se quiere entender, o mejor dicho, no se acepta.

El problema que tienen hoy TODAS las empresas del mundo relacionadas en mayor o menor medida con a tecnología es EL TIEMPO.
Sí, el tiempo. Y es que no hay tiempo suficiente para hacer las cosas bien. Todo se quiere para "ya mismo", todo es urgente, todo ha de ser concebido o arreglado en un pestañeo.

Nosotros llevamos una época demasiada larga, ni recuerdo cuando empezó, donde todo es con carácter inmediato o de urgencia, donde no se respetan los tempos, donde el cliente tampoco los acepta.

Y en esas estamos, que sin tiempo no se pueden hacer las cosas bien y tarde o temprano acaban apareciendo cagadas que parecen inexplicables cuando se juzgan desde la calma y el sosiego. Lo tengo tan claro que estoy por echarme al monte a vivir como un ermitaño.
Si... y no.

Para mi, el futuro de la ciberseguridad, está en el código.
Pero esto ni quita que tengas que tener tus equipos, no sólo parcheado sino que los puedas parchear si sale un 0day.
Y hay una serie de medidas preventivas que puedes tomar, llámese waf, 2fa, siem ...

Y, a día de hoy no se pueden asumir según que riesgos. NoName057 puede tirar 30-40 páginas "gubernamentales" esta semana. Perfecto, esto es asumible. Pero lo que no puede hacer es llevarse los datos médicos, por ejemplo.
 
Si... y no.

Para mi, el futuro de la ciberseguridad, está en el código.
Pero esto ni quita que tengas que tener tus equipos, no sólo parcheado sino que los puedas parchear si sale un 0day.
Pues dime cómo lo haces... es imposible. Algunos parches no son suficientes, en ocasiones pasa por cambiar una tecnología.
Cuando salió lo de log4j, hubo quien se esperó a que saliera un parche de ellos mismos, otros optamos por cambiar directamente el proveedor a otro más seguro. Pero es que "mañana" puede salir algo nuevo y puede ser que te enteres ya demasiado tarde.

Dependiendo de la complejidad de un sistema puede ser algo sencillo o imposible, y voy a poner un ejemplo muy simple que cualquiera va a entender. Imagínate que tienes un sistema basado en Oracle y sale a la luz un problema de seguridad con esa versión y de momento no hay solución por parte de la marca. ¿Qué haces? ¿Cambias el sistema de base de datos a otro e inviertes varios años de trabajo haciendo ese cambio? ¿Y mientras tanto qué demonios haces?

Tampoco puedes estar cambiando y actualizando todo siempre a las últimas versiones. Resulta que ahora sale una nueva versión de una librería de componentes, la instalas, compilas y.... ZAS!, aquello no va porque han cambiado métodos y te encuentras con que algunos incluso los han eliminado. ¿Cuánto tiempo crees que hace falta para arreglar algo así?

Es imposible estar además al día de todo y con los tempos de presión constantes que hay en las empresas. A nivel de Sistemas más o menos puedes tratar de estar al día, pero en un desarrollo de SW grande los cambios no siempre son aplicar un parche.

Yo llevo años viéndolo y de un tiempo a esta parte tengo muy claro que tarde o temprano van a pasar desgracias que los de fuera no entenderán.
 
En sistemas es peor que en software, aunque cueste creerlo. Sistemas operativos, firmwares... y tablas de compatibilidades para ver qué pasa si actualizas el firmware de la tarjeta de la cabina de almacenamiento, con el driver, el sistema operativo... Una auténtica chaladura, a años luz del software.

Ahora, utilizando ciertas metodologías y procesos, cualquier línea que se modifique en un código se puede automatizar para que sea analizada por un lote de herramientas de seguridad, he trabajado implantándolas. No es perfecto, pero es un logro tremendo. Y además que estamos en lo de siempre, si tienes 3 ó 4 entornos, puedes testear en el primero cambios rápidos e ir pasando "anillos" hasta llegar a producción.

¿El problema? Implantar la forma de trabajo en las empresas, tarea realmente compleja.
 
No entro en si es mejor o peor, pero mismamente el otro día hablando con uno de IT "Es necesario que cambien de Desarrollo TAL cosa".
Me lo quedo mirando y le digo, ¿eres consciente del trabajo que implica lo que pides?

Lógicamente no tenía ni idea, pero cuando le pregunto a él el porqué es imperativo... resulta que así le es más sencillo hacer noseque en Azure.
Mira macho... si para hacerte a ti una tarea más sencilla hay un departamento que ha de dedicar alrededor de algo más de 2000 horas de trabajo, apaga y vámonos.

Conste que este tipo de reuniones las disfruto, poco, pero las disfruto, porque desde el otro lado siempre se va todo taaaaaaan sencillo, jajaja, es como cuando un comercial me envía un correo con dos párrafos y quiere que con eso le de el presupuesto de una integración entre sistemas heterogéneos.

@Tim todo depende de la complejidad de un sistema, pero en ciertos niveles las cosas son muuucho más complejas de lo que parece.
En serio, que a mi me han pedido en una aplicación que usa más de 350 tablas de base de datos relacional, el cambio de SQL Server a Postgre SQL pensando que algo así se hace en poco más de un bostezo.
 
En serio, que a mi me han pedido en una aplicación que usa más de 350 tablas de base de datos relacional, el cambio de SQL Server a Postgre SQL pensando que algo así se hace en poco más de un bostezo.

Un ejemplo más del grave problema que tenemos en el sector por no haber sabido proteger adecuadamente a sus profesionales, evitando que suceda precisamente eso, que la gente en general piense que construir un sistema es algo tan sencillo como actualizar una aplicación en el móvil.

Al "iluminao" que te pide eso, le enseñaría qué es lo que hace falta hacer para cambiar de Oracle a PostgreSQL algo tan sencillo como una consulta que devuelva los nombres y los salarios (respuesta elaborada por Gemini de Google, por cierto).

Transcodificar el código de una aplicación que utiliza Oracle como SGBD para que use PostgreSQL implica más que simplemente cambiar las cadenas de conexión. Requiere un examen exhaustivo del SQL, los procedimientos almacenados y los tipos de datos utilizados, ya que existen diferencias significativas entre los dos sistemas. Aquí hay un ejemplo simplificado para ilustrar el proceso, centrándose en las diferencias comunes de SQL:

Escenario:

Imagine una aplicación con una tabla simple EMPLEADOS y una consulta para recuperar los nombres y salarios de los empleados.

Código Oracle Original (Ejemplo):

Insertar CODE, HTML o PHP:
-- Oracle SQL (Recuperando nombres y salarios de empleados)
SELECT UPPER(ename), sal
FROM employees
WHERE hiredate > TO_DATE('2023-01-01', 'YYYY-MM-DD');

Desafíos y Pasos de Transcodificación:

  1. Diferencias en los Tipos de Datos:
    • El tipo DATE de Oracle a menudo incluye componentes de tiempo, mientras que el tipo date de PostgreSQL es específicamente para fechas. Es posible que necesite ajustar el manejo de los tipos de datos.
    • VARCHAR2 de Oracle se convierte en VARCHAR en PostgreSQL.
    • NUMBER de Oracle debe asignarse al tipo numérico apropiado de PostgreSQL, como NUMERIC, INTEGER o REAL.
  2. Diferencias en las Funciones de Fecha:
    • La función TO_DATE de Oracle tiene una sintaxis ligeramente diferente en comparación con la conversión de fecha/hora de PostgreSQL.
  3. Diferencias en las Funciones de Cadena:
    • Aunque UPPER() es estándar, algunas funciones de cadena o sus argumentos pueden diferir.
  4. Diferencias en las Secuencias:
    • Oracle utiliza secuencias para las claves primarias de incremento automático. PostgreSQL utiliza columnas SERIAL o IDENTITY.
  5. Procedimientos Almacenados/PL/SQL vs. PL/pgSQL:
    • Oracle utiliza PL/SQL, mientras que PostgreSQL utiliza PL/pgSQL. Estos son lenguajes de procedimiento diferentes, que requieren reescrituras significativas.
    • Los paquetes de Oracle deberán reestructurarse en esquemas y funciones de Postgres.
  6. Cadenas de Conexión y Controladores:
    • Deberá cambiar los controladores JDBC/ODBC y las cadenas de conexión en la configuración de su aplicación.
Código PostgreSQL Transcodificado (Ejemplo):

Insertar CODE, HTML o PHP:
-- PostgreSQL SQL (Recuperando nombres y salarios de empleados)
SELECT UPPER(ename), sal
FROM employees
WHERE hiredate > '2023-01-01'::date; -- O use la función de fecha: WHERE hiredate > DATE '2023-01-01';

Ejemplo de diferencias de secuencia/serial:

Oracle:

Insertar CODE, HTML o PHP:
CREATE SEQUENCE employees_seq;
CREATE TABLE employees (
    id NUMBER PRIMARY KEY,
    ename VARCHAR2(100)
);

INSERT INTO employees (id, ename) VALUES (employees_seq.NEXTVAL, 'John Doe');

PostgreSQL:

Insertar CODE, HTML o PHP:
CREATE TABLE employees (
    id SERIAL PRIMARY KEY,
    ename VARCHAR(100)
);

INSERT INTO employees (ename) VALUES ('John Doe');

Consideraciones Clave:

  • Pruebas Exhaustivas: Pruebe a fondo la aplicación después de la transcodificación para garantizar la integridad y funcionalidad de los datos.
  • Migración de Datos: Utilice herramientas como pgloader o scripts personalizados para migrar datos de Oracle a PostgreSQL.
  • Manejo de Errores: Ajuste el manejo de errores para que coincida con los códigos y mensajes de error de PostgreSQL.
  • Optimización del Rendimiento: Optimice las consultas e índices de PostgreSQL para el rendimiento.
  • Conversión de Procedimientos Almacenados/Funciones: La tarea que consume más tiempo probablemente sea la conversión de procedimientos y funciones almacenadas.
  • Librerias de terceros: Asegurese de que las librerias de terceros que utilize su aplicacion sean compatibles con postgres.
  • Sintaxis especifica de Oracle: Sintaxis especifica de oracle como tablas "dual", o sintaxis de outer join usando "(+)" deberan ser re escritas.
Herramientas y Recursos:

  • pgloader: Una herramienta de migración de datos para mover datos a PostgreSQL.
  • ora2pg: Una herramienta diseñada para migrar esquemas de Oracle a PostgreSQL.
  • Documentación de PostgreSQL.
Este ejemplo proporciona una descripción general básica. Los proyectos de transcodificación del mundo real son significativamente más complejos y requieren una planificación y ejecución cuidadosas.

:ok :ok :ok
 
Algún día me tenéis que explicar la inquina que le tenéis algunos al del gorro. :juas
La primera vez que lo vi en la tele, hará casi 20 años, me saltaron todas las alarmas: Un tipo que lo ves en programas "de variedades" y que se presenta a sí mismo como hacker y que lleva un impostado look-estereotipo "de hacker". Blanco y en botella.

Y el tipo tiene mérito por ser el perfecto vende humos y lograr enamorar al mismísimo presi de telefónica para que le pagara la fiesta.
 
@TheReeler por eso cuando en mi antigua empresa se creó el departamento de Cloud me pusieron de jefe. Porque coordinar a ambas partes es poco menos que una tarea titánica. No eres negociador de paz en un conflicto armado, pero conflictos y puñaladas no faltan 🤣🤣
 
La primera vez que lo vi en la tele, hará casi 20 años, me saltaron todas las alarmas: Un tipo que lo ves en programas "de variedades" y que se presenta a sí mismo como hacker y que lleva un impostado look-estereotipo "de hacker". Blanco y en botella.

Y el tipo tiene mérito por ser el perfecto vende humos y lograr enamorar al mismísimo presi de telefónica para que le pagara la fiesta.

Cuando los albores de esto de la seguridad, los virus, y tal, solía ir al SIMO invitado. Y me paseaba por los stands de multitud de firmas. Uno de nuestros proveedores me invitó a tomar unas cervezas y unas tapas en el stand. Me presentaron a un tipo trajeado, con un porte impresionante, extremadamente educado, con un maletín de documentos Louis Vuitton, que hablaba inglés con un marcado acento que no identifiqué. Supuse que sería el CEO de la empresa o algo así.

Al cabo del rato, nos despedimos, y me quedé charlando con el comercial de la empresa. Le conté la jodienda que llevábamos desde hacía semanas con un puto virus que infectó media Europa, que solo podías eliminar accediendo al equipo por terminal mediante puerto serie (que tiempos). Me miró, y me dijo que si no sabía quién era el del traje. Le dije... ¿tu CEO? y empezó a descojonarse. Resulta que el individuo era un hacker de fama mundial, y uno de los coder de demos (que tiempos) más conocidos. Lideraba un grupo de gente... cof, cof... que había programado ese virus, y se había ofrecido a esta empresa para que desarrollasen con su "ayuda" un antivirus que luego se hizo famoso.

No he visto a nadie en mi vida con menos pinta de hacker. Y resulta que era uno de los más grandes del mundo. Joer.
 
Nosotros hemos hecho por segundo año consecutivo un ejercicio de test mediante phishing por email, a ver cuanta gente picaba.
Pues nada, tras todos los emails, trainings presenciales y demás, siempre hay quien se la traga hasta el fondo e incluso personas que no deberían... pero pasa.

Un parche puede solucionar un problema, pero el error humano siempre va a estar ahí.
 
Arriba Pie