https://gs6.globalsuccessor.com/fe/tpl_ecb01ssl.asp?newms=jj&id=66521&newlang=1

Se busca ingeniero superior en informática o master equivalente con un año o dos de experiencia en dirección de proyectos. Salario bruto anual entre 15.000 € y 21.000 € según valía. Se ofrece un plan de carrera.

fuente: web de la Universidad de Almería

La Fundación Descubre organiza “Café con Ciencia”, una actividad para facilitar el contacto entre investigadores y estudiantes de una manera próxima, amigable y personalizada

La Semana de la Ciencia de la Universidad de Almería inicia su andadura el próximo lunes 7 de noviembre con una actividad novedosa: científicos charlando con estudiantes para contarles su día a día y su labor investigadora en un ambiente distendido y cercano, alejado del tradicional esquema ponente-asistente.

Se trata del “Café con Ciencia”, una iniciativa organizada por la Fundación Descubre con carácter regional para abrir la Semana de la Ciencia en Andalucía. Para ello ha contado con la colaboración de las principales entidades de investigación y divulgación de la Comunidad andaluza y la financiación de la Fundación Española para la Ciencia y la Tecnología (FECYT).

En la UAL, serán siete los investigadores de renombre que se sentarán en torno a una mesa a “tomar café” con diez alumnos de bachillerato para que estos puedan plantear todas las preguntas que sean de su interés en torno al tema escogido. El intercambio de ideas será continuo ya que los jóvenes han preparado con sus profesores las cuestiones que les van a plantear.

Así, Descubriendo un pasado remoto: La investigación arqueológica actual es el tema propuesto por el Catedrático de Historia Antigua José Luis López Castro mientras que Manuel Pérez García, director del CIESOL, hablará sobre las Formas de aprovechar la energía del sol.

Los robots salen de las fábricas es la temática de la mesa en la que se sentarán los investigadores Francisco Rodríguez Díaz y Antonio Giménez Fernández. Por su parte, el profesor del área de Fisioterapia, Rubén Fernández García, centrará su charla en torno a la Influencia de las técnicas de relajación en el bienestar físico y emocional.

Al mismo tiempo, el investigador Gabriel Acién explicará ¿Cómo podemos usar las microalgas para mejorar nuestro medioambiente? y la experta en Química Analítica, Antonia Garrido, desvelará el proceso para Analizar contaminantes.

Por último, La transmisión de vídeo a través de Internet será objeto de debate en la mesa del profesor del área de Arquitectura y Tecnología de Computadores, Vicente González Ruiz.

¿Y en el resto de Andalucía?
Científicos y sociedad conversarán en 177 cafés que se celebrarán durante la Semana de la Ciencia en 26 centros de investigación y divulgación de toda Andalucía y en cuatro centros Guadalinfo, que retransmitirán por Internet, en directo, los cafés al resto de la red social andaluza compuesta por más de 700.000 personas.

Para impulsar la participación y llegar al mayor número de ciudadanos se han organizado dos modalidades de encuentros: los cafés con ciencia presenciales y los cafés con ciencia virtuales a través de Guadalinfo.

Los ingenieros encargados de la seguridad no sólo la desarrollan para el SO en sí, también han de considerar al usuario final (aplicaciones) y Java no es un caso especial. Una arquitectura Java debe proporcionar cuatro atributos a los desarrolladores para sus aplicaciones :

1. Facilidad de uso : si se quiere que Java sea portable, debe ser fácil de usar.
2. Simplicidad: la máquina virtual debe ser fácil de analizar y debemos ser capaces de llegar a los detalles críticos de la vm y ser capaces de entenderlos.
3. Adecuación: la arquitectura debe proporcionar seguridad a todos los niveles, desde los más bajos (VM) a los más altos (aplicación).
4. Evolucionar : el diseño de la arquiectura Java debe ser capaz de evolucionar fácilmente con las tendencias del mercado.

La seguridad en el JDK 1.0 básicamente se trataba de identificar código que estaba fuera del “sandbox” frente al código que está dentro. Esto que parece sencillo dió origen a una arquitectura plagada de errores que se quiso solventar con el JDK 1.2. Se cuenta que el diseño de seguridad del JDK 1.2 se heredó del modelo de seguridad de Netscape, pero mejorado para tener un ámbito de aplicación mayor.

En el diseño de la arquitectura se ha buscado evitar los efectos colaterales (como es de suponer) de modo que :

1. Hay que cerciorarse de que sólo se puede ejecutar código JAVA válido (sabeis que las cabeceras de los ejecutables de JAva, los .class es  0xCAFEBABE -se debe ver con un editor hex-).
2. Se obtiene el resultado que se espera y para el cual el código ha sido diseñado.
3. Se debe evitar el acceso a estructuras de datos a las que no se debe acceder … [cuestión de privilegios].

A nadie se le escapa que estando Java en el punto de mira -de velocidad de ejecución- estos tests se deben hacer cuanto antes, mejor.  De modo que la amenaza en este tipo de arquitecturas es encontrar código en el que no confiamos que pueda convertirse en código malicioso. Según lo dicho, la arquitectura debe evitar ejecutar cógido malicioso, debe ser capaz de controlar el código en el que no confiamos, pero es incapaz de controlar errores de programación como por ejemplo generar código suceptible de ser atacado a través de inyecciones de sql … ante esto, no hay medidas de protección.

Normalmente una aplicación se escribe en código JAVA que será compilado a byte-code, que es código binario independiente de la arquitectura del procesador , es código diseñado para la máquina virtual de Java. Éste código será ejecutado por la máquina virtual de java. Es posible compilar a nativo directamente desde el código java, lo que hace que se esquiven todos los tests de seguridad que aporta la arquitectura, en este caso sólo podemos indicar que se permita el acceso a código nativo.  Por otro lado, tambien existen frameworks como Oolong que te permiten escribir código en ensamblador (byte-code) directamente. En cualquier caso, incluso el byte-code generado por compildores puede ser marcado como “código sospechoso”. Si uno considera que sólo debe confiar en el código que desarrolla uno mismo por completo …. la máquina virtual debe ser capaz de determinar si un trozo de bytecode es confiable o no, asi que uno se puede imaginar la dificultad.

El bytecode está muy bien estructurado, tal es así que los códigos de operación son exactamente de 1 byte. Un compilador de Java “en el que confiemos” será capaz de leer nuestro código Java y generar bytecode que cumpla los tres puntos anteriores. … que haga aquello que se ha escrito en el código de alto nivel, que mantenga la seguridad entre tipos de datos, de no ser así podemos estar ante una ventana abierta a vulnerabilidades.  Existe un problema que se llama “problema de la validación de la entrada” que consiste en determinar si un conjunto de códigos de operación es válido. El byte code se examina muchas veces y en distintos lugares. El verificador de byte code examina estáticamente el código que le llega para ejecutarse, se examinan la seguridad de los tupos de datos y poco más se puede hacer sin una verificación formal de todo el sistema. De modo que uno de los problemas que tienen las implementaciones de java (runtimes) es determinar que el bytecode que le llega de fuentes externas, tras compilar un código java, es confiable. La implementación Java de SUN lo consigue y se puede leer más sobre este tema (si se está interesado) buscando referencias a “BYTECODE BASHER”.

Una vez visto lo anterior, el siguiente problema que aparece es controlar el comportamiento anomalo no intencionado, por ejemplo, el SQL injection. Es decir que el programador hace la conexión con el driver de la base de datos, pero no controla las cadenas de texto que se le pasa para la consulta.  Aqui entran en juego las consabidas y afamadas SECURITY POLICIES. Por ejemplo, si desde una aplicación Java se quiere abrir un fichero, para lectura, que contiene información de tarjetas de crédito el acceso debería ser denegado. Si es para leer tipos de letra, debería ser proporcionado. Como los programas JAVA no abren directamente archivos sino que invocan a una API de JAVA y la JVM sabe que estas operaciones con archivos osn sensibles, entonces esta API usará el SECURITYMANAGER para controlar que el acceso se permite gracias a las politicas de seguridad que antes hemos mencionado. Os podeis imaginar el marrón que le cae al SECURITYMANAGER, éste debería dejar leer ficheros de fuentes, pero no debería dejar acceder a ficheros de fuentes del sistema por si se realizan modificaciones que afecten al resto….

En el JDK 1.0 / 1.1 donde la politica de seguirdad se apoyaba en un espartano modelo de sandbox, el SECURITYMANAGER revisaba el historial de llamadas ( el stack trace …. para los que vienen de C / C++) si todo el código es local, es decit toda la cadena de invocaciones de métodos es local, entonces se da el permiso ( la ejecución está dentro del sandbox ), en caso contrario se denegaba. Quien no recuerda el problema con los Applets … si un applet estaba en la cadena de invocaciones, el permiso directamente era revocado. … Adivinar la intencionalidad de un programa es dificil, por esto se decidió obligar al programador a declarar sus intenciones. De este modo ayudamos al SECURITYMANAGER. De hecho el SECURITYMANAGER en lugar de “intentar averiguar la intención del applet” contaba la distancia entre el applet y el securitymanager (en numero de llamadas) y en función de esto y de alguna heuristica se determinaba si se daba el acceso o no. La seguridad en JDK 1.2 se modificó por completo y se basó en el principio del menor privilegio (least privilege): todo el código tiene el mismo nivel de permisos (el mínimo). El privilegio final se calcula con la intersección de los privilegios de toda la cadena de invocaciones. De este modo se puede decir que el programador declarar sus intencines.

La gran lección aprendida del nuevo modelo implantado en el JDK 1.2 : hay que ser sistemático. Por ejemplo, cuando se auditó el código de la jvm se detectó que un progrmaador, para no tener problemas con los permisos duplicó parte del código del núcleo y lo movió a otro sitio. Si esto no se hubiera detectado, se habrian generado infinidad de vulnerabilidades.

El reescribir el JDK no se pudo hacer a la ligera, pues hay cosas como NULL que no pueden cambiar de significado asi que en algunos casos el classloader (cargador de clases) o el securitymanager podrían ser null …. Otro ejemplo, durante la ejecución de un programa, Java transforma código estático en objetos ésto se divide en dos pasos : localizar la descripción del código y definir un objeto a partir de esa descripción.  La primera parte se puede considerar abierta de bajo riesgo, la segunda parte sólo debe realizarse por código controlado del sistema, por desgracia estos dos pasos se integraron -desde el inicio- en un sólo método, que funcionaba bien para el modelo de JDK 1.0 pero daba muchos problemas en el 1.2.

Otro aspecto que llama mucho la atención de JAVA : java no asegura la ejecución secuencial de instrucciones consecutivas ya que puede ocurrir una excepción que derive la ejecución en una rutina de tratamiento de excepción, el remedio es usar clausulas TRY/FINALLY para regresar al código.  De hecho esto puede afectar a la seguridad de toda la máquina virutal, por ejemplo cuando la JVM se queda sin memoria, su comportamiento puede llegar a ser indeterminado, el tratamiento de estas excepciones está escrito en Java y puede padecer de efectos laterales.

Para más información recomiendo la lectura de Inside Java 2 Platform Security : Architecture, API, Design and Implementation.

Para seguir, hace dos días me encuentro en el periodico de La Voz de Almería de hace tres días aparece una noticia en la que se dice que los alumnos de FP tienen más insercción laboral que otros. Luego aclara que es sólo para determinadas titulaciones como “pesca, industria, …” y bueno, lo entiendo. No entiendo que el titular pretenda vender la FP como solución a la búsqueda de un futuro profesional. De hecho, hay que leer el artículo para darse cuenta. ¿Qué se pretende? Hace pocos días apareció otra noticia diciendo que “La Junta acuerda promover la FP” … pues genial. ¿Esto significa crear un carril de deceleración?

Porque hay titulaciones donde es normal que exista la FP y otras que no. De hecho, si informática tuviera su regulación, y se exigiera la responsabilidad civil que de por si se le entiende, ¿qué pasaría con la gente que cursa FP? ¿Se les reconocerían competencias? ¿Se les relegaría a un segundo plano? ….

No es justo que por cuestiones políticas y ajenas a la educación “per-se” se invite a la gente a cursar itinerarios con publicidad engañosa. Además, para cerrar la reflexión: Un profesor de informática en FP, si pudiera regresar a su etapa de bachiller ¿escogería -hoy- universidad o fp?  Creo que la respuesta es clara.

En fin, adios papel. Afortuandamente conservo y conservaré el último número impreso de LJ.

Job Details
Traineeship

Ref ECB/TR/048/11
Business Area Information Systems
Directorate / Division Analytical Domain Applications

Function

The Directorate General Information Systems of the European Central Bank (ECB) is seeking applications from university students for two traineeships in its Analytical Domain Applications Division for a period of up to six months.

The Analytical Domain Applications Division provides IT project management, application development, maintenance and functional support for IT systems required to accomplish the analytical and statistical tasks of the ECB and the European System of Central Banks (ESCB).

The successful candidates will join the teams responsible for providing technical expertise for existing and new analytical and statistical applications used by experts in the ECB and the ESCB. Successful applicants will be assigned a supervisor, but will also be expected to be able to work on their own initiative.

The traineeships are aimed at giving successful applicants the opportunity to participate in a range of projects and maintenance activities relating to large and complex IT systems. This position provides an excellent opportunity to deepen knowledge in this field and offers exposure to a multicultural environment.

The holders of these positions will be expected to carry out a range of professional tasks in the Division, depending on their academic qualifications. Specific tasks may include:

helping users (typically economists and researchers) adapt software to run in parallel processing environments;
installing and upgrading software;
collecting requirements and setting up reports within an existing business intelligence solution;
supporting the team in performing data analysis tasks.

Qualifications and experience

The successful candidates must have the knowledge and competencies listed below.

Candidates should have at least a first-cycle qualification (e.g. Bachelor’s degree) in information technology, computer science, information system security, engineering, mathematics, statistics, econometrics or related disciplines. Near-completion of an advanced-level degree would be advantageous.
For one of the vacancies, experience with HPC clusters and parallel processing would be an asset: experience in scientific programming such as MATLAB, C++ or Fortran or R would be an advantage.
Good knowledge of Linux would be an advantage.
Familiarity with data warehouse or business intelligence solutions as well as related experience is an asset.
Knowledge of or experience in data analysis tasks as well as knowledge of financial instruments and markets are an asset.
A very good knowledge of English with drafting ability is essential, and a good knowledge of one other official language of the EU is an asset.
Good IT skills and a sound knowledge of MS Office are basic requirements.

Behaviour Competences

The successful candidate will have the following behavioural competencies:

self-motivation, flexibility and a high level of team spirit;
commitment to achieving goals, a pragmatic approach and the ability to deliver results in the required time;
ability to learn quickly when faced with new challenges;
ability to communicate with a variety of users.

Duration of contract / Closing date

Traineeship of up to six months

Closing date for applications: 7 November 2011

Further information

Applications are to be made in English and submitted using our online application form. An “Applicants’ Guide” can be downloaded from the “FAQs & Help” page.

The recruitment process will include a telephone interview.

Applications are accepted from nationals of Member States of the European Union.

Before applying, applicants should check that they meet the conditions set out in Article 3 of the rules governing the traineeship programme: http://www.ecb.europa.eu/ecb/jobs/pdf/coe_traineeship.pdf.

Further information on the ECB’s traineeships can be found at http://www.ecb.europa.eu/ecb/jobs/apply/html/index.en.html