The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

Archive for March, 2013

LOB Update by Jonathan Lewis

This note is about a feature of LOBs that I first desribed in “Practial Oracle 8i” but have yet to see used in real life. It’s a description of how efficient Oracle can be, which I’ll start with a description of, and selection from, a table:

create table test_lobs (
	id              number(5),
	bytes           number(38),
	text_content    clob
)
lob (text_content) store as text_lob(
	disable storage in row
	cache
)
;

-- insert a row

SQL> desc test_lobs
 Name                    Null?    Type
 ----------------------- -------- ----------------
 ID                               NUMBER(5)
 BYTES                            NUMBER(38)
 TEXT_CONTENT                     CLOB

SQL> select id, bytes, dbms_lob.getlength(text_content) from test_lobs;

        ID      BYTES DBMS_LOB.GETLENGTH(TEXT_CONTENT)
---------- ---------- --------------------------------
         1     365025                           365025

1 row selected.

I’ve got a table with a single CLOB column holding a single row. The size of the single CLOB is roughly 365KB (or about 45 blocks of 8KB). Old hands who have had to suffer LONG columns will recognise the trick of recording the size of a LONG as a separate column in the table; it’s a strategy that isn’t really necessary with LOBs but old coding habits die hard. It’s quite hard to find details of how much space has been used in a LOB segment (thespace_usage procedure in the dbms_space package doesn’t allow you to examine LOBSEGMENTs), but I did a coupld of block dumps to check on this LOBSEGMENT and it had allocated 46 blocks on the first insert.

So here’s the clever bit – how big will the LOBSEGMENT grow when I update that one CLOB ?

It’s common knowledge (to users of LOBs) that the undo mechanism Oracle has for LOBs is simply to leave the old LOB in place and create a new one – so the intial response to the question might be to guess that the LOBSEGMENT will grow to roughly double the size. But it doesn’t have to be like that, at least, not if you update the LOB the way I happen to have done, which is like this:

declare

	m_length	integer;
	m_lob		clob;

begin

	select
		text_content,
		dbms_lob.getlength(text_content)
	into	m_lob, m_length
	from
		test_lobs
	where
		id = 1
	for update
	;

	dbms_output.put_line('Lob size: ' || m_length);

	dbms_lob.write(
		lob_loc	=> m_lob,
		amount	=> 17,
		offset	=> 1,
		buffer	=> 'This is an update'
	);

	commit;

end;
/

My code very specifically changes only the first 17 bytes of the LOB. So how much does Oracle have to do to effect this change ? The LOB-handling mechanisms are smart enough to work out that only the first (of 45) blocks in the LOB need to be changed, so Oracle need only add one block to the segment and write the new version of the first LOB block to that one block. (In fact the segment – which was in a tablespace using freelist management – grew by the “standard” 5 blocks from which Oracle selected just one block to add to the LOB.)

So how does Oracle keep track of the whole LOB if it can change it one piece at a time ? This is where the (notionally invisible and you don’t need to know about it) LOBINDEX comes into play. Oracle maintains an index keyed by (LOB_ID, chunk_number) *** pointing to all the chunks of a LOB in order, so when you update a single chunk Oracle simply creates an updated copy of the chunk and changes the appropriate index entry to point to the new chunk. So here’s an image representing our one LOB value just after we’ve created it and before we’ve updated:

lob_1

And then we “modify” the first chunk – which means we have to add a chunk (which in this case is a single block) to the segment, create a new version of the first chunk, modify the index to point to the new block, and add an index entr – keyed by time-stamp – to the end of the index to point to the old chunk; something like this:

lob_2

Now, when we run a query to select the LOB, Oracle will follow the index entries in order and pick up the new chunk from the end of the LOBSEGMENT. But the LOBINDEX is protected by undo in the standard fashion, so if another long-running query that started before our update needs to see the old version of the LOB it will create a read-consistent copy of the relevant index leaf block– which means that from its perspective the index will automatically be pointing to the correct LOB chunk.

The index is actually quite an odd one because it serves two functions; apart from pointing to current lobs by chunk number, it also points to “previous” chunks by timestamp (specifically the number of seconds between Midnight of 1st Jan 1970 and the time at which the chunk was “overwritten”). This makes it easy for Oracle to deal with the retention interval for LOBs – any time it needs space in the LOBSEGMENT it need only find the minimum timestamp value in the index and compare it with “sysdate – retention” to see if there are any chunks available for re-use.

To sum up – when you update LOBs, and it’s most beneficial if you have an application which doees piece-wise updates, you leave a trail of old chunks in  in the LOBSEGMENT. The version of the LOB you see is dictated by the version of the index that you generate when you request a copy of the LOB at a given SCN.

 

*** Footnote: My description of the LOBINDEX was an approximation. Each index entry carries a fixed size “payload” listing up to eight lob chunks; so the (LOB_ID, chunk_number) index entries in a LOBINDEX may point to every 8th chunk in the LOB. The significance of the “fixed size” payload is that the payload can be modified in place if the pointer to a LOB chunk has to be changed – and this minimises disruption of the index (at a cost of some wasted space).

 


Debian 7 podría adelantar su lanzamiento y estar disponible en breve by F.Manuel

Instalador de Debian 7 RC-1

La liberación de Debian 7 “Wheezy” puede estar más cerca de lo que pensamos. Apenas un dos años después del lanzamiento de “Squeeze”, la primera versión candidata del instalador de Debian se publicó hace un mes aproximadamente.

En la versión RC-1 del instalador hemos podido ver un aspecto uniforme para los elementos del menú, en un intento de homogeneizar su apariencia con independencia del método de inicio utilizado. Esto en cuanto a la parte que se ve, porque debajo hay cosas más interesantes, como diversos controladores de hardware nuevos y soporte UEFI.

 

Estado actual de desarrollo

En el momento actual, la lista de fallos críticos está por debajo de los 100 bugs, y para la mitad de ellos, los desarrolladores han decidido ignorar los problemas en cuestión o eliminar los paquetes si los parches que los corrigen no llegan pronto.

Además, el equipo responsable de la distribución no va a admitir nada distinto de parches pequeños que solucionen un problema concreto y que no afecten a otras partes del sistema, ya que está tratando de seguir adelante con el lanzamiento.

Según The H Open, al ritmo que avanza el proyecto podríamos tener Debian 7 Wheezy durante las vacaciones de Semana Santa. Antes han de solucionar al menos un bug, referido a las notas de versión, que si bien no afecta al rendimiento ni la estabilidad, es importante.

Debian 7, primeras impresiones del instalador

Proceso de instalación de Debian 7

Al margen de lo anterior, mientras escribo estas líneas estoy instalando Wheezy con la imagen ISO de instalación por red con la versión candidata del software. Lo primero que he notado en la interfaz es que es mucho más lógica y no hay que “adivinar” dónde hacer doble clic para seleccionar una opción.

Toda la interfaz emplea una gama de tonos grises, con las barras de progreso en color rojo fucsia. El aspecto general es agradable. La primera parte de la instalación está siendo muy sencilla, nada que ver con el pasado.

Configurar gestor de paquetes en Debian 7

Poco más que determinar el idioma de instalación, mapa del teclado, huso horario, contraseña de administración, usuario “normal” del sistema y su contraseña, nombre de la red, configuración del proxy, y del gestor de paquetes, si no he olvidado ningún paso.

Así he instalado el sistema base, hasta llegar a una sencilla pantalla donde se puede elegir a grandes rasgos qué instalar. Además de la propuesta por defecto (utilidades estándar del sistema y servidor SSH), he marcado entorno gráfico.

Debian 7, selección de programas

La instalación continúa sin novedad (instala 1.256 paquetes con la selección hecha), pero ya es hora de publicar esta noticia.¿Tendremos Wheezy esta Semana Santa? Aventurar una fecha con Debian es algo temerario, pero por si acaso estaremos muy pendientes para informaros.

Web | Descarga


¿Tu EXE? ¡¡ MI EXE !! (Mitm de ejecutables) by Yago Jesus

Los ataques ‘Man-in-The-Middle‘ son de las cosas mas divertidas que nos ha regalado TCP/IP, hay muchos usos creativos de estas técnicas y hoy, vamos a darle otra pequeña vuelta de tuerca.
 
Lo que vamos a hacer es una aproximación ‘a la Evilgrade‘ de sustitución de binarios al vuelo.
 
La idea es muy sencilla: Montamos un proxy y por cada .exe que se nos pida, vamos a servir un exe malicioso. Luego, usando un ataque clásico MitM haremos que todo el tráfico web de la víctima pase por ese proxy.
 
Hay escenarios donde solo se tiene acceso a la red, pero el objetivo a atacar resulta inexpugnable porque emplea cortafuegos o simplemente no es atacable vía exploits. En estos escenarios, un ataque como el que vamos a explicar aquí puede ser efectivo
 
En origen pensé en usar el protocolo ICAP y Squid para implementar este ataque, el problema es que hay pocas implementaciones de ICAP Servers y las que hay, o están desactualizadas, o directamente son complejas de adaptar.
 
En estas estaba cuando vi un sensacional artículo sobre como alterar al vuelo paquetes para pip (el instalador automático de paquetes para Python) empleando mitmproxy.
 
La aproximación, por sencilla y limpia de implementar, me pareció genial así que me hice mi propio script para mitmproxy orientado a sustituir binarios .exe.
 
Lo que hacemos es lo siguiente:
 
Cada vez que alguien pide a través de mitmproxy una URL que apunte hacia un .exe, alteramos la respuesta y le enviamos un .exe malicioso.
 
Apuntamos el par IP–>URL en un array, y la próxima vez que se nos pida, esta vez si, serviremos el .exe correcto. Esto lo hacemos para evitar levantar sospechas, si alguien se descarga un .exe y ‘falla’ pero a la segunda intentona si funciona, es probable que lo achaque a ‘fallos en la red’.
 
El código del script es este:

Para usarlo, tan solo se debe definir el fichero que vamos a servir desde el script, editando la variable ‘trojan’ y apuntando al fichero que queremos meter.
 
trojan = ‘malware.exe’
 
Aquí ya al gusto de cada uno, vale un meterpreter o vale algo más elaborado.
 
Cabe señalar que a la víctima le llegará el nombre del exe que supuestamente se está bajando, no el nombre de TU exe
 
 
Y finalmente ejecutamos mitmproxy así:
 
 mitmproxy -s binchange.py
 
Luego de eso, solo falta ‘arponear’ la red y configurar el firewall para mover el tráfico, aquí también influyen tus fobias y filias, los hay amantes de ettercap o como yo, los hay mas clásicos que les gusta arpspoof del mítico Dug Song.
 
Una vez vaya habiendo actividad, se genera un fichero de log llamado logpwned que tiene este aspecto:
 
[Primera descarga] 
 
Sun Mar  3 17:54:33 2013 Tenemos un cliente
IP de la victima 127.0.0.1
URL solicitada http://sbdtools.googlecode.com/files/CertMonSetup.exe
 
 
 
 
 
 
 
 
[Segundo intento]
 
Sun Mar  3 17:54:43 2013 Tenemos un cliente
la URL solicitada http://sbdtools.googlecode.com/files/CertMonSetup.exe ya ha sido envenenada
 
Cosas para el TODO:
 
-Analizar previamente el tamaño del fichero solicitado, no es lo mismo winamp.exe (2 M) que OfficeSetup.exe (1 Giga)
 
-Tomando como inspiración el script para pip, añadir una rutina que procese ficheros zip, los baje, los abra, intercambie exes y vuelva a generar el zip para servirlo
 
Me pregunto que hubiera pasado si hubiese dado de alta mi proxy en un sitio como este

Esteganografía: Ocultando el uso de LSB by Rafael Páez

Después de haber hablado en varias ocasiones sobre la esteganografia, volvemos al tema ampliando un poco más la técnica de LSB (Ocultando archivos en otros – LSBOcultando archivos en otros – LSB II).

Resumidamente, esta técnica consiste en ocultar información en el bit menos significativo de cada uno de los píxeles de una imagen, consiguiendo así que el cambio realizado sea invisible al ojo humano. El problema de esta técnica, es que la información oculta puede obtenerse fácilmente si esta no se ha codificado previamente o si no se sigue un patrón concreto a la hora de ocultarla. Para poder evitar que terceras personas puedan descubrir que una cierta imagen contiene información oculta, podemos utilizar la técnica que se explicará a continuación.

Este método de ocultación de información será útil (idealmente) para ocultar imágenes, de dos colores como máximo, dentro de otras imágenes, siendo necesario la posesión de un token (el cual será otra imagen) por ambas partes de la comunicación para obtener la imagen oculta. A pesar de decir que de forma “ideal” únicamente se pueden ocultar imágenes de dos colores, esto no implica que no se pueda introducir texto en una imagen bicolor, y esconder el resultado 😉

La técnica, básicamente consiste en dos imágenes, dónde una de ellas será una imagen que únicamente debería poseer el emisor y el receptor, y la otra será la imagen que queremos ocultar (la cual tiene que tener unas dimensiones menores o iguales que la imagen portadora).

Una vez se tienen ambas imágenes, se recorrerán todos los píxeles de la imagen a ocultar y si el color RGB del píxel es diferente de 0xFFFFFF (blanco puro), se restará “1″ al color del píxel en esa misma posición de la imagen portadora (o se sumará “1″ en el caso de que el valor del píxel sea “0″), modificando así únicamente aquellos píxeles cuya posición correspondan a píxeles “pintados” en la imagen a ocultar. De esta forma, para poder obtener la imagen oculta, se irán comparando uno a uno los píxeles de la imagen recibida con los de la imagen original (secreta entre ambas partes) y en aquellos que sean diferentes, será donde se han ocultado los píxeles “pintados” de la imagen a ocultar. Hay que remarcar, que con esta técnica, es posible que no se obtenga exactamente la misma imagen que al principio en el caso de que se usen más de dos colores, ya que en su obtención solo se “pintarán” dos colores (blanco o negro) perdiendo todos aquellos valores intermedios.

Por último, comentar que cuando se ha explicado esta técnica se ha dicho que es “ideal” para imágenes de dos colores, ya que en esos casos será donde menos diferencia visual exista entre la imagen original y la imagen modificada, pero que también se podría utilizar para tener en cuenta 3 o incluso más tonalidades, ya que el ojo humano no es capaz de diferenciar entre todos los valores existentes de color.

Para poder entenderlo todo mejor y verlo con nuestros propios ojos, se han creado dos scripts que se encargarán de ocultar una imagen en otra (Ocultar una imagen) y de obtener la imagen oculta de una imagen en base al token establecido (Obtener imagen oculta).

Suponiendo que tenemos la imagen1.png funcionando como token, y queremos ocultar la imagen2.png, deberemos realizar lo siguiente:

php ocultar.php png png imagen1.png imagen2.png imagen3.png

Obteniendo así una nueva imagen (imagen3.png) completamente “igual” a la anterior, pero con la imagen2.png oculta en su interior. Cuando la otra persona reciba la imagen3.png, podrá obtener su imagen oculta ejecutando el segundo script de la siguiente forma (donde OBLIGATORIAMENTE deberá indicar la imagen utilizada como token):

php obtener.php imagen1.png imagen3.png imagen4.png

Para aclarar un poco más el ejemplo dado, se mostraran las diferentes imágenes que se han utilizado a lo largo del proceso:

Imagen 1: Imagen en la cual se ocultará la segunda imagen. Podríamos decir que esta imagen funcionaría como password, ya que únicamente la deberían poseer las dos partes de la comunicación.

Imagen 2: Imagen que queremos enviar a la otra parte de forma secreta y que ocultaremos en la imagen 1.

Imagen aux: Superponiendo ambas imágenes, podríamos ver cuales serán los píxeles que se modificarán en la imagen original (imagen1.png) al ocultar la imagen 2.

Imagen 3: Esta será la imagen que deberemos enviar a la otra persona y que contendrá la imagen 2 oculta en ella, sin que nadie más pueda obtenerla sin poseer la imagen 1.

Como se puede observar, no se aprecia ninguna diferencia entre la imagen1.png y la imagen3.png, pero si las comparamos, vemos como son archivos diferentes.

Imagen 4: Está será la imagen que obtendrá el receptor cuando la extraiga de la imagen 3. Como se ve, a pesar de que “pierde” calidad, el mensaje oculto puede leerse perfectamente.

Con este ejemplo, hemos podido comprobar como modificando algunas de las técnicas básicas de esteganografía, se pueden obtener resultados bastante más seguros y potentes para ocultar información secreta sin dar indicios de que existe información oculta en nuestros archivos 😉

 


Mejorar el rendimiento de Windows 8 by Francisco Javier Santiago

En las siguientes líneas se expondrá unas sencillas prácticas para mejorar aún más el rendimiento de Windows 8.

Una vez situado en el escritorio del PC usar la combinación de teclas Windows + R para llamar a la aplicación “ejecutar” y escribir en ella SystemPropertiesPerformance y pulsar la tecla intro para confirmar.

 

clip_image002

Imagen 1: Ejecutar

 

Con esta orden ejecutada se abrirá la aplicación Opciones de Rendimiento, en la que se podrá observar las distintas opciones disponibles, en la primera pestaña se encuentra Efectos Visuales con sus diferentes configuraciones:

 

  • Dejar que Windows elija la configuración más adecuada para el equipo.

 

Esta opción es la trae por defecto Windows 8 y la más aconsejable para usuarios inexpertos.

 

  • Ajustar para obtener la mejor apariencia.

 

Lo que se consigue con esta configuración es activar todas las opciones, teniendo así la mejor apariencia, ideal para maquinas potentes, pero desaconsejable para maquinas con gráficas flojas.

 

  • Ajustar para obtener el mejor rendimiento.

 

Con esta configuración se consigue todo lo contrario que en la anterior porque desactiva todas las opciones de efectos visuales para tener un mayor rendimiento. Aconsejable para maquinas lentas.

 

 

  • Personalizar.

 

Esta opción permite elegir que opciones habilitar o deshabilitar que gusten mas o no independientemente del rendimiento.

 

clip_image004

Imagen 2: Efectos Visuales

 

En la siguiente pestaña Opciones Avanzadas se puede elegir la opción de asignar los recursos del procesador, ajustando y mejorando el rendimiento de programas o servicios en segundo plano.

 

clip_image006

Imagen 3: Opciones Avanzadas

 

La tercera pestaña sería Prevención de Ejecución de datos en la que se tiene dos opciones de configuración, Activar DEP solo para los programas y servicios de Windows esenciales o por otro lado Activar DEP para todos los servicios excepto los que se seleccione.

 

clip_image008

Imagen 4: Prevención de ejecución de datos

 

Si quieres aprender más secretos, configuraciones, integraciones, desarrollo de PowerShell te recomendamos leerel libro de Pablo González y Ruben Alonso “PowerShell: La navaja suiza de los administradores de sistemas”. Si quieres conocer las novedades y secretos de la nueva versión del sistema operativo servidor de Microsoft te recomendamos Windows Server 2012 para IT Pros. Si quieres aprender mucho más sobre los secretos de los sistemas Microsoft Windows, te recomendamos leer el libro de Sergio de los Santos “Máxima Seguridad en Windows: Secretos Técnicos”.

Además  si te ha gustado el artículo puedes suscribirte al Canal RSS de Windows Técnico, o seguirnos por el  Canal Google+ de Windows Técnico o  Twitter para estar al día de las novedades e información técnica de interés.


Gestionando riesgos con M_o_R® by Antonio Huerta

 

– ¡¡¡¡¡Me he dejado el coche nuevo abierto con las llaves puestas en el peor barrio de la ciudad!!!!! ¡¡¡¡¡SOCORRO!!!!!

– Tranquilo, que no cunda el pánico. Conozco una metodología de gestión de riesgos que nos dará la visión adecuada para solucionar este problema… Primero identificaremos las actividades de tu vida que se pueden ver afectadas (como ir recoger a tu mujer, ir a trabajar…) bla bla bla, después identificaremos las amenazas existentes, por ejemplo ocupación enemiga o sustracción. Luego calcularemos el riesgo, mediante una función entre la probabilidad de que suceda y el impacto, descontando de ambos las salvaguardas implantadas…. bla bla bla. ¿Dime cuál es tu apetito por el riesgo? bla bla bla… voy a definir un plan de tratamiento de riesgos….

– ZZZZZZZ

– Perfecto déjame decirte que la solución a tu problema es: Que la próxima vez, cierres el coche y cojas las llave cuando aparques.

 

Estimados lectores, creo que coincidirán conmigo, que en la vida diaria, quizá aplicar una metodología de gestión de riesgos no sea lo más óptimo (aunque a lo mejor el subconsciente funciona con algo parecido). Sin embargo en el ámbito de las organizaciones cada día resuena más el término gestión de riesgos, y es que no solamente se trata de adoptar una metodología de gestión de riesgos, si no de establecer una cultura de gestión de riesgos, para esto es conveniente hacer uso de un marco de trabajo como puede ser la ISO31000 o Management of Risk (M_o_R®).

Hoy les quiero introducir una guía para la gestión de riesgos, M_o_R®. Bien pues, M_o_R® es un marco de trabajo desarrollado por el Office of Government Commerce (OGC) de Reino Unido para la gestión del riesgo. Su primera edición se publicó en 2002 y la actual versión data de 2010 donde se alineo con la norma ISO 31000:2009 y en la cual se definen los principios y guías de implantación de la gestión de riesgos.

Este marco de trabajo se centra en 4 conceptos principales:

1. M_o_R®  principales:

Representa los principios en los que se debe sustentar la gestión de riesgos y sobre los que las organizaciones tienen que desarrollar sus propias políticas, procesos, estrategias y planes. Estos principios son los siguientes:

  • Alinear con los objetivos
  • Adaptarse al contexto
  • Involucrar a las partes interesadas
  • Proporcionar guías claras
  • Informar para la toma de decisiones
  • Facilitar la mejora continua
  • Crear una cultura que de soporte
  • Alcanzar valores cuantificables

2. M_o_R®  approach:

En este apartado se propone como adaptar la gestión del riesgo a las necesidades de la organización, además propone una serie de documentos que deberán ser desarrollados, los 3 principales son:

  • Política de gestión de riesgos
  • Guía del proceso de gestión de riesgos
  • Estrategias de gestión de riesgos

Más otra serie de documentos para dar soporte a estas:

  • Registro de riesgos
  • Registro de problemas
  • Plan de mejora de riesgo
  • Plan de comunicación de riesgo
  • Plan de respuesta a riesgos
  • Informe de progreso de riesgos

3.M_o_R®  process

El proceso de gestión del riesgo, está conformado por un ciclo similar al PDCA compuesto por 4 etapas y una actividad común que es la comunicación. Estas etapas son: Identificación, evaluación, planificación e implementación.

La identificación consiste principalmente en recabar información de la actividad que soporta a la entidad, de las partes interesadas, de los objetivos y del contexto. Así como la identificación de las amenazas y oportunidades aplicables.

La evaluación supone la estimación en términos de probabilidad e impacto de las amenazas y oportunidades previamente identificadas, para posteriormente obtener un cálculo del riesgo existente ya sea de modo cualitativo o cuantitativo.

La planificación sugiere la preparación de medidas específicas para eliminar o reducir las amenazas y maximizar las oportunidades. Algo similar a lo que muchos conoceréis como el Plan de Tratamiento de Riesgo.

En cuanto a la implementación consiste en garantizar que las acciones planificadas para la gestión de riesgos, se implantan y se lleva a cabo una medición de su efectividad. Del mismo modo acometer acciones correctivas en caso de que no  se alcancen las expectativas.

Quiero hacer mención sobre algo relativamente novedoso en el enfoque propuesto dentro del proceso de M_o_R®, y es que no sólo se habla de riesgos y amenazas, si no también de oportunidades, algo que me recuerda en cierto modo al análisis DAFO.

4. Embedding and reviewing M_o_R®

Este apartado se centra en dos ideas, la primera es imbuir en la organización una cultura de gestión del riesgo, sobre todo mediante el conocimiento y concienciación. La segunda es la medición de la efectividad y la idoneidad en la gestión del riesgo. Por lo que respecta a la efectividad a través de indicadores o modelos de madurez. En cuanto a la idoneidad mediante una revisión del apetito por el riesgo.

 

Y hasta aquí ha llegado el resumen sobre M_o_R®. Muchas veces pensamos en el análisis y gestión de riesgos como algo que forma parte de otro proyecto, algo secundario. Pero la gestión del riesgo no es algo que sólo afecte al área TIC, o que sea un requisito para la implantación de un SGSI o del ENS o necesario para la continuidad de negocio, va más allá y abarca mucho más y es lo que persiguen la ISO 31000 o M_o_R®, darle un enfoque más transversal a la gestión del riesgo dentro de un organización, más integrado con el negocio. ¿Cómo evolucionará la gestión del riesgo? Eso sólo el tiempo lo dirá…

Para concluir me van a permitir despedirme con un cliché clásico en esto de la seguridad pero adaptado a los riesgos. La gestión de riesgos no es un proyecto o un producto, es un Proceso.