EDICIóN GENERAL
401 meneos
2960 clics
Los guardianes de Lexnet: Volverá a fallar o lo hackearán, hay agujeros gravísimos

Los guardianes de Lexnet: Volverá a fallar o lo hackearán, hay agujeros gravísimos

Joaquín supera los 40 años de edad y, en toda su trayectoria profesional, ha pasado por varias consultoras tecnológicas y empresas del sector. Una de sus etapas laborales transcurrió precisamente en dos de las grandes compañías que formaron parte del desarrollo de Lexnet. "Es uno de los muchos proyectos informáticos públicos que han pasado por mil manos: por una parte, las de todas las grandes consultoras que han estado en su desarrollo; por otra, las de las empresas de informática a las que las consultoras fueron subcontratando trabajo".

| etiquetas: lexnet , agujeros , indra , iecisa
Bonito artículo para no decir nada.

Todo es susceptible de fallo o de hacking. Un programa en código abierto y supertrillado y muy utilizado como es el ssh ha teñido problemas con el heart bleed o el bash con el shellshock. Son cosas que conozco por enfrentarme a ellas a diario y no me considero ningún experto en seguridad (al menos, cuando me comparo con gente que sabe, porque hay cada ganado por ahí ....)

Me temo que Lexnet debe estar bastante chapucero…   » ver todo el comentario
#1 yo creo que la idea del artículo no es tanto que pueda haber otros fallos (obvio), sino que debido al pésimo diseño de Lexnet estos serán muy fáciles de encontrar y explotar.
#2

Pero eso pasa en muchos otros. Tampoco dice nada nuevo.
#9 esos otros han costado millones del dinero publico?
#2 Es así pero si no lo das mascadito hay gente que no se entera.
#2 Y porqué es pésimo el diseño?
#1 ¿qué detalles quiere, que te diga que fallos concreto hay?

Ya dice bastante cuando dice que por ahí han pasado varias empresas, que cada una de ellas ha subcontratado lo que ha querido, que alguno de los del proyecto ha pasado por varias (cosa esta que me parece de psiquiatra, porque si yo estoy en esa mierda de proyecto no me voy a otra consultora para seguir en él), etc.
#3 En mi trabajo tengo un lema. Lo que empieza alguien lo termina esa misma persona. Ya sea un proyecto entero o un fragmento del mismo que hayamos dividido entre varios. He aprendido que cuando un proyecto cambia de manos además de ser una pérdida de tiempo ya que la persona que lo recibe no se entera de nada al principio, a la hora de hacer el Arte Final (ah, no lo he dicho, estoy hablando de diseño gráfico) el numero de despistes y erratas tontas se multiplica.

Soy el encargado y como tal…   » ver todo el comentario
#4 ya está el típico mando intermedio diciendo que su jefe no tiene ni puta idea y que si toma una decisión diferente a la que tomaria el, es un desastare.
Ejpaña!
#13 El típico mando intermedio al que no dejan hacer su trabajo y al primero que le cae la bronca cuando el proyecto sale mal, precisamente por haberlo puenteado.

Ejpaña!
#16 claro claro... lo de siempre, los malos son otros, el jefe no sabe nada y está ahí porque supo a quien llevarse de putas.
#17 El jefe está ahí porque tenía el dinero para montar la empresa. El jefe no es mala gente, sabe de su trabajo (conseguir clientes y gestionar la empresa) pero tiene sus errores. Uno de ellos es ese, saltarse los protocolos de trabajo de su propia empresa por intentar acelerar las cosas. Lo que acaba llevando a problemas. pero bueno, es su empresa y se la folla como quiere.
#18 umm, bueno, en este comentario estamos de acuerdo los dos.
#13 Si el mando intermedio es el que tiene la autoridad para definir tareas y responsabilidades el mando superior nunca debería puentearle y si lo hace lo debe justificar adecuadamente, así es como debería ser para que las cosas funcionaran ... pero efectivamente estamos en Ejpaña y la gente habla y hace sin tener ni puta idea.
#4 No creo que la complejidad sea comparable. Para mí es más un tema de estructuración y verificación del código entregado.

De hecho, que cambie de manos está bien, ya que garantiza detectar si es mantenible y ser independiente de los desarrolladores contratados.
#24 Siempre que no tengas a un superior diciendo "ya lo arreglaremos cuando haya tiempo". (Pista: nunca llega a haber tiempo)
#28 La Fase 2. ¿Nunca has trabajado en la fase 2 de un mismo proyecto? Yo tampoco.
#24 ¿Que cambien está bien? ... ¿Cómo? ¿Cuando? ¿Con qué criterio? ... Las pruebas del software se definen a la par que el propio software, entonces los cambios deberían estar controlados desde el principio, porque la gestión de riesgos también se debería definir al principio.
#32 Parto de la base de que es imposible mantener siempre el mismo equipo de desarrolladores para siempre. Independientemente del motivo o el criterio, no se puede depender del equipo de desarrolladores a riesgo de quedar cautivo. Por eso el cambio es bueno, porque fuerza que el mantenimiento sea traspasable entre equipos, que sea legible, mantenible... con un equipo diferente al original.

Las pruebas de software se deben realizar en función de los requerimientos, que pueden cambiar - y…   » ver todo el comentario
#4 Ese lema también lo tienen los funcionarios que adjudican los contratos pero la ley les obliga a cambiar de proveedor aunque el que gana haya mentido y ponga peor equipo de trabajo. Si cambian porque cambian, si sigue el mismo porque los soborna.
#3 si yo estoy en esa mierda de proyecto no me voy a otra consultora para seguir en él

Pues depende. Si en la otra pagan más, ¿por qué no?
#5 no todo es pasta, especialmente en consultoría.
#6 Pues ya me dirás para qué trabajas si no. ¿Por la satisfacción de ver a tu jefe comprándose un Ferrari nuevo?
#7 La pasta es fundamental. Pero no todo es pasta.

Yo mismo rechacé un trabajo enbel que me pagaban mejor porqe el horario que tenho aquí es inmejorable y en el otro era partido. Hay que saber ponderar lo que le conviene a cada uno.
#7 trabajo por dinero y para poder disfrutar de ese dinero. De nada me vale cobrar una pasta si al final tengo que aguantar las malas maneras de la gente más de 8 horas al día por sacar adelante un proyecto fracasado como es el caso de Lexnet. Esas cosas queman, y los trabajos que queman a la larga salen caros.
#3

Coge el articulo, cambia LEXNET por cualquier otro proyecto y te sirve.

Si quieres sugerencias, empieza por PERSIGO en CyL y veras que risa.
#8 veo que conoces esa mierda de nuestra comunidad. Una comunidad con un sistema informático con el que no sabe cuántos trabajadores tiene y te dan la holgura de + - 3000
#15

Conozco la adjudicación, sin cumplir los requisitos y a Accenture y a una empresa de Pimentel (ex ministro del PP)

No tengo detalles de su desarrollo, pero se ha restrasado un huevo, han tenido que meter un montón de pasta (la licitación inicial eran 7 kilos) y no va.
#1 Cualquier cerradura puede ser abierta, pero no es lo mismo una camara acorazada del banco que una puerta de madera atada con un alambre y con los goznes herrumbrados.
#1 Una cosa es que puntualmente aparezca algún problema en alguna aplicación, y otra es que sepas que la aplicación está llena de agujeros porque dentro del mismo código están los comentarios que indican los controles que han quedado sin hacer.
#1 Bueno, dejan entrever que para los responsables de Lexnet la seguridad es esto: giphy.com/gifs/security-11fot0YzpQMA0g
#1 Yo he trabajado y esas cárnicas en España y luego en otras tecnológicas en el extranjero, y no hay color. Nada es infalible, pero lo que hacen esas cárnicas son chapuzas. Pero bueno, aquí hay muchos informáticos currando en españa, seguro que sabéis de lo que hablo.
#1 "Cada empresa que ha participado en Lexnet se ha encontrado con los fallos que traía la anterior. Ha faltado uniformidad: lo que la mayoría de empresas ha hecho es poner parches, en vez de solucionar los problemas de fondo". No entra en detalles tecnicos porque este articulo no es una auditoria de codigo, pero suponiendo que sepa lo que dice deja bien claro que no se trata de un problema puntual sino un problema de calidad de codigo. Dice luego que muchos de los fallos son "de 1 de carrera", no nos enseñan el codigo pero podemos entender a que se refiere.
Lo lo lo lo lo lo looo lo lo lo looooo {0x1f602}
¿nadie va a decir lo de "país de pandereta"?

A nuestro ministro no parece preocuparle demasiado.

Por estas cosas somos el hazmereir de Europa.
#14 país de pandereta, exacto. Que empiecen a pagar sueldos de informático a su personal técnico, que se fijen en lo que se paga en los países vecinos. Y que se dejen de cárnicas.
"...muchos proyectos informáticos públicos que han pasado por mil manos..."

Este es el problema, y no sólo por los fallos de seguridad que son los que salen en la noticias y llaman la atención, lo que está mal de base es la forma en la que la administración desarrolla el software que necesita. A ver cuando alguien entiende que el software no es un producto cerrado que se encarga como el que compra una mesa, el software es algo en constante evolución que contiene las reglas de negocio…   » ver todo el comentario
#20 ya ves, los pliegos para una aplicación están hechos como si se fuera a pintar una fachada cuando la realidad es que el software es más parecido a un mural.
#20 El modelo está más que definido y probado, cuando se aplica adecuadamente funciona, lo que pasa es que se lo pasan por el forro.
Y han aprendido algo de esto las administraciones para tomar cartas en el asunto de las laaaargas cadenas de subcontrataciones que se dan en IT?

Porque ya no afecta solo al trabajador, se deberian dar cuenta de como les salpica.
#25 no hace falta aprender nada. Lo que tienen que hacer es copiar el modelo de los países de nuestro entorno. Que miren lo que hace UK, Alemania, Francia, etc... Yo solo he visto cadenas de subcontrataciones en nuestro país. En UK por ejemplo e Irlanda, que son los casos que mas conozco, un organismo oficial lo que hace es tener a expertos en plantilla que lleven los proyectos. Luego, cuando sale un proyecto, contratan en régimen de freelance por una duración determinada a los programadores,…   » ver todo el comentario
El tema lexnet es un claro ejemplo de la seguridad de pandereta que vendemos, independientemente de la calidad del código, que debe ser un tutifrutti de cientos de becarios, hay muchos otros medios para evitar lo que ha pasado y parece que se nos olvidan que es obligación del responsable de seguridad y arquitectura de la aplicación.
El primer principio que DEBE aplicar cualquier infrsestructura IT es el de DEFENSA EN PROFUNDIDAD, básicamente dice que debemos poner siempre dos sistemas de…   » ver todo el comentario
comentarios cerrados

menéame