Aniversario

Como ya os habrá informado él mismo, mañana domingo 17 de mayo es el Día de Internet; hagamos un pequeño resumen de las principales ventajas e inconvenientes que han surgido desde que este nuevo medio apareció en escena:

Ventajas:

  • Un gran lugar de consulta.
  • Mejora de las comunicaciones.
  • Aumento de la efectividad de distribución de la información.

Desventajas:

  • A pesar de su crecimiento, no todo el mundo dispone de acceso o un conocimiento básico de la red.
  • Adicción.
  • Fraudes, pérdidas de información, requiere mucha seguridad…

[Read more…]

Honeytokens

Los sistemas de decepción de intrusos siempre me han parecido muy interesantes de cara a garantizar la seguridad de una organización; si bien los más complejos, las honeynets, no suelen implantarse con frecuencia salvo en entornos grandes y/o especialmente concienciados en temas de seguridad (digamos que los beneficios obtenidos del sistema no suelen cubrir el coste asociado a la implantación y al mantenimiento del mismo), los sistemas sencillos, los honeypots, tienen, bajo mi punto de vista, una buena relación coste/beneficio.

Dentro de los honeypots, los sistemas más triviales son los honeytokens: elementos que simplemente por “tocarlos”, por acceder a ellos, generan una alarma que puede proporcionar información muy valiosa a la organización: intentos de intrusión, intentos de robo de información, etc. Este subconjunto es particularmente interesante, porque a cambio de una inversión mínima —existen honeytokens muy sencillos, y su mantenimiento una vez implantados es casi inexistente— obtenemos una información de alto valor.

En la red existen multitud de honeytokens ya prediseñados y listos para ser “dejados caer” en los sistemas corporativos con una mínima parametrización; una vez implantados, nos indicarán que algo anómalo sucede con una tasa de falsos positivos casi igual a cero, lo cual es obviamente muy interesante (uno de los problemas de los sistemas de detección de intrusos basados en red es la tasa de falsos positivos que pueden llegar a generar, y el coste asociado a procesar toda la información que producen día a día). Aparte de los honeytokens ya prediseñados y que todo el mundo conoce, no es difícil diseñar alguno “ad hoc” para nuestra organización: un registro JFK, un fichero que no debe ser accedido, un puerto que no debe ser usado… Uno de estos sistemas, que IMHO es muy interesante y nos permite detectar usuarios “curiosos” (generalmente internos) que tratan de acceder a información a la que no deberían puede ser el siguiente:

– Creemos un fichero “DESPIDOS.DOC” en un recurso compartido por Samba, por ejemplo.

– Gracias a la API inotify (en Linux), y al paquete inotify-tools, podemos hacer un monitor que detecte diferentes accesos al sistema:

inotifywait -m -e access DESPIDOS.DOC | while read FILE ACTION; do ACCION done

– Generalmente, un acceso de un usuario a un fichero utilizando una aplicación se traduce internamente por N accesos; podemos utilizar un buffer intermedio que “limpie” los accesos espúreos. El monitor se complica ligeramente, pero no deja de ser trivial (y lo lanzamos pasándole como parámetro la ruta del fichero a monitorizar):

#!/bin/sh

MARGEN=60
LASTU=0
LASTT=0

# Accion a realizar ante un acceso
function action(){
echo "ACCESO de $USER a $FILE en modo $ACTION"
}

# Al realizar un acceso para el usuario, en ocasiones se traduce internamente
# por N accesos. Ponemos un tampon para registrar el ultimo y no realizar
# ninguna accion si el siguiente es del mismo usuario dentro de un margen de
# tiempo definido ($MARGEN)

function buffer(){
if [ $USER -eq $LASTU ]; then
	DIFF=`expr $TIME \- $LASTT`
	if [ $DIFF -gt $MARGEN ]; then
		action
	fi
else action
fi
LASTU=$USER
LASTT=$TIME
}

if [ $# -ne 1 ]; then
	echo "Deteccion de acceso a ficheros"
	echo "USO: $0 fichero" 
	exit -1
fi

inotifywait -m -e access $1|while read FILE ACTION; do 
	USER=`ps -ef|grep $FILE|head -1|awk '{print $1}'`
	TIME=`date +%s`
	buffer 
done

– Si lo lanzamos en el arranque, invocándolo convenientemente, y sustituyendo en la función action() la orden echo por algo más elaborado (un evento, un mensaje a móvil, un correo electrónico…), conseguiremos detectar, como hemos dicho, a los usuarios que puedan ser más curiosos en la organización. No tenemos más que sentarnos a esperar nuestros eventos, SMS o lo que hayamos decidido enviar cuando se detecta un acceso :)

Ojo, el código anterior es fruto de veinte minutos de trabajo y por supuesto se puede mejorar por mil sitios, pero espero que sirva para hacernos una idea. Adicionalmente, yo provengo del mundo Unix y no conozco otros entornos con la profundidad necesaria para hacer algo parecido a esto, pero estoy seguro que en la mayor parte de sistemas (Windows, AS/400…) es posible —y no especialmente costoso— diseñar cosas parecidas que nos permitan detectar el interés de nuestros usuarios por acceder a información que no deberían ver…

Extracción de Metadatos

A la hora de realizar una auditoría de seguridad lógica, uno de los primeros pasos a dar es la recopilación de la mayor cantidad de información “útil” del objetivo a auditar, lo que en el ámbito de la seguridad denominamos como “information gathering”. Dentro de esta fase, podemos incluir el análisis de metadatos obtenidos a partir de ficheros contenedores como pueden ser de tipo pdf, odt, jpg, etc…

Antes de entrar en materia, me gustaría definir lo que son los metadatos de una manera más formal. Curiosamente, si consultamos el diccionario de la real academia española no encontramos este término, pero para ello tenemos la referencia de la wikipedia:

Metadatos (del griego μετα, meta, «después de» y latín datum, «lo que se da», «dato»), literalmente «sobre datos», son datos que describen otros datos.

De manera más informal, podemos decir que los metadatos son datos que caracterizan a un fichero que contiene cierto tipos de datos, de modo que a través de los metadatos podemos conocer características de un fichero como el autor, revisiones del documento, etc.

En cuanto a las herramientas de extracción de metadatos, y aunque hay en Internet múltiples recursos al respecto, me gustaría destacar principalmente dos de ellas, cuyo funcionamiento es muy sencillo. La primera de ellas es “extract“, una aplicación para sistemas operativos Unix/Linux cuya finalidad es justamente mostrar la información contenida en los metadatos de un fichero. De esta manera podemos obtener información como nombres de usuarios, nombres de equipos, rutas del equipo donde se ha creado/modificado un fichero, etc., tal y como se muestra en la siguiente imagen (el documento analizado se encuentra disponible en Internet):

extract

En el ejemplo mostrado, podemos observar los datos que podemos obtener de un fichero “.doc” que no ha sido previamente “limpiado”, entre los cuales cabe destacar rutas de unidades de red, nombres de usuarios, nombre del registrador de la aplicación, aplicación con la que está creado el documento y su versión, etc. A la vista del ejemplo, no es difícil ver la importancia y la atención que debemos prestar a los metadatos, sobre todo si el documento va a ser públicamente accesible.

Si enfocamos la obtención de metadatos al mundo de la fotografía digital, podemos en algunos casos obtener incluso la geolocalización de la obtención de la imagen en concreto. Para ello utilizaremos la herramienta exif (que simplemente accede a los datos del formato Exif):

exif

Queda clara la importancia de mantener en la fotografía únicamente información que deseamos que sea pública, para evitar que circule información “oculta” a primera vista y que no deseamos ofrecer. Herramientas como Metagoofil o lafoca están enfocadas a la obtención de los metadatos, lo que puede ser el primer paso de un análisis más exhaustivo, que dé pie a posteriores etapas en un proceso de auditoría técnica.

Como no puede ser de otra manera, la recomendación es eliminar aquellos metadatos innecesarios que impliquen información privada que en cierta manera nos hace vulnerables, ya sea por dar a conocer nombres de usuarios, o ubicaciones de objetos a través de imágenes. Eso lo veremos en la siguiente entrada.

Tu hijo usa Chrome (y no sabe qué es el modo incógnito)

Se habrán fijado que, irónicamente, la página principal de Google que aparece al acceder mediante Internet Explorer ha sido sutilmente modificada, y ahora aparece la frase “Obtén la nueva versión de Google Chrome, navega más rápido. Instalar Ahora.“, con un enlace al navegador del buscador. Para aquellos que sufren de alergia a los productos de Microsoft, o utilizan otros sistemas operativos, una imagen:

instalarahora

[Read more…]

Clasificación y tratamiento de la información (II)

Comenzaba el otro día Alberto su entrada sobre clasificación de la información comentando que éste suele ser un motivo habitual de incumplimiento. En efecto, cuando estamos trabajando en una organización y pedimos el procedimiento de clasificación y tratamiento de la información, en muchos casos nos miran con cara de póker y nos vienen a decir algo del tipo “¿Yesoqués?”.

Tener definido —e implantado— un procedimiento que nos diga cómo trabajar con la información corporativa es no sólo una buena práctica recogida en estándares como ISO 27.002 , sino en ocasiones incluso un requisito legal: la propia LOPD recoge restricciones diferentes en función del nivel de cada tratamiento declarado. No debemos olvidar que la información es sin duda uno de los activos más importantes de nuestra organización, y que muchos de los esfuerzos que a diario realizamos van orientados a proteger este activo, por lo que la clasificación y el tratamiento de la información son una pieza básica para garantizar la seguridad.

Un procedimiento de clasificación y tratamiento de la información debe ser acorde tanto a los requisitos del negocio (no implantemos unas restricciones propias de la NASA en una empresa que no las necesita, porque acabarán incumpliéndose) como a los requisitos legales (ojo a la LOPD y las restricciones que impone a los tratamientos declarados en función de su nivel). En mi opinión, un procedimiento de este tipo debe contemplar al menos los siguientes puntos:

— Clasificación.

¿Cómo clasificamos la información corporativa? ¿Qué diferencias hay entre SECRETO, CONFIDENCIAL o INTERNO? Si no sabemos clasificar de forma clara la información con la que trabajamos, difícilmente podremos protegerla.

— Restricciones de tratamiento, incluyendo difusión, copia, almacenamiento y transmisión.

¿Quién tiene o puede tener acceso a cada tipo de información? ¿Cómo debe tratarse, por ejemplo, cuando sea necesario sacarla fuera de las premisas de la organización? ¿Puedo utilizar un dispositivo USB sin cifrar para almacenar —o extraer— información confidencial? Debemos tener claro que no podemos hacer lo que nos venga en gana con la información, sino que debemos adecuarnos tanto a la legalidad como a la normativa interna definida en la organización.

— Marcado.

¿Qué marcas debe tener un soporte —físico o lógico— con información de cierto tipo? ¿Debo disponer de algo tan simple como un cuño con la leyenda “SECRETO”? La información que queramos proteger —esto es, probablemente, toda salvo la pública— debe marcarse de forma adecuada, garantizando así que quien la maneja sabe en todo momento con qué tipo de información está tratando (y por tanto puede aplicar correctamente las restricciones de tratamiento).

— Caducidad.

¿Cuándo pierde una información de cierta categoría su valor? ¿Pasa por defecto la información secreta a ser pública en algún momento? Si es así, ¿cuándo? El valor de la información cambia con el tiempo, y quizás debamos plantearnos —o no— tiempos de vida para nuestros datos.

— Destrucción.

¿Cómo destruyo cada tipo de información? ¿Utilizo un simple formateo para eliminar información secreta de un soporte, o por el contrario debo utilizar un borrado seguro? ¿Y si es confidencial? Los mecanismos de destrucción de la información, sin importar el tipo de soporte sobre el que se almacene, deben estar identificados de forma clara, garantizando que no es posible recuperar aquellos datos que creemos haber eliminado.

— Auditoría y control.

¿Qué salvaguardas aplico para garantizar que lo que he escrito en el procedimiento se cumple en la realidad? ¿Hago un muestreo de mesas limpias? ¿Registro las destrucciones de medios? Todo lo especificado en un procedimiento queda muy bien sobre el papel, pero debo garantizar su cumplimiento en la realidad y detectar en el menor tiempo posible cualquier desviación con respecto a lo definido.

— Régimen disciplinario.

¿Qué sucede si alguien de la organización incumple el procedimiento y se lleva un dispositivo USB con información secreta sin cifrar? ¿Y si usa un medio de destrucción incorrecto para la clasificación a eliminar? En el procedimiento debo identificar claramente qué sucede cuando alguien —en especial de forma consciente— incumple lo especificado.

Una buena referencia en la materia, algo antigua pero que nos puede aportar mucha información e ideas para definir la clasificación y el tratamiento de la información corporativa, es la directiva 5200.1 (y derivadas) del Departamento de Defensa estadounidense, disponibles desde http://www.dtic.mil/. Eso sí, tengamos presente que se trata de un estándar militar, y que por tanto no es de completa aplicación en la mayoría de organizaciones con las que habitualmente trabajamos (lo dicho antes: no matemos moscas a cañonazos, no nos pasemos a la hora de imponer restricciones, y hagamos bien nuestro trabajo de consultoría: definamos e implantemos controles adecuados a cada organización).

VoIP Hopper

Como indicamos el pasado viernes en nuestro twitter, el pasado 5 de mayo llegó a la lista pen-test de Securityfocus el anuncio de la liberación de la version 1.0 de la herramienta VoIP Hopper, una herramienta para sistemas Unix/Linux, escrita en C y licenciada como GPL3, que nos va a ser muy útil para securizar nuestra red, concretamente la capa dos (muchas veces olvidada), debido a que está basada en la tecnica conocida como Vlan Hopping con la cual podemos ser capaces de saltar a una Vlan del switch a la que no pertenecemos.

Con la aparición de esta nueva versión de la herramienta, se amplía la lista de herramientas dedicadas exclusivamente a auditoría de redes de Voz sobre IP, como pueden ser SIPVicious, Voiper, sipdump/sipcrack, VoipPong, etc.

Puesto que cada día son más las empresas que llevan a cabo una unificación de sus comunicaciones, partiendo con la implantación de una red Voz usando su propia red local, y finalizando con la unificación total de sus comunicaciones (Voz sobre IP, mensajería unificada, servicio de presencia, etc.), la seguridad de la red se convierte en un aspecto crítico a tener muy en cuenta a la hora de realizar dicha integración, para garantizar, no solo la calidad del servicio, sino también la disponibilidad, confidencialidad e integridad de la informacion que atraviesa el sistema. Por lo tanto, en caso de disponer de sistemas VoIP en nuestra red, debe ser una buena práctica de seguridad llevar a cabo un plan de auditoría de vulnerabilidades específico contra los servicios que forman parte de dichos sistemas.

Clasificación de la información (I)

En las auditorías de seguridad de la información, al igual que en las de protección de datos personales, uno de los temas que es motivo frecuente de incumplimiento, es la carencia de un procedimiento de clasificación de la información y adicionalmente, la clasificación de los riesgos inherentes a aquella. ¿Cómo se entiende que una organización pueda controlar la información que gestiona (importante activo) sin establecer ciertas categorías en la misma y aplicar los debidos controles para su validación, protección y limitación de uso y acceso?

Unos ejemplos

El periódico que está sobre la mesa de recepción, no tiene clasificación alguna y es de acceso público, pero si casualmente hablase de la organización, probablemente se intentaría evitar su acceso (en caso negativo) o se pincharía en el tablón de anuncios (caso positivo); vemos que el contenido —la información— delimita la categoría del soporte. Un albarán de envío de materiales (pongamos una fábrica de tubos) a un cliente sólo mostrará la dirección social del cliente y la lista de productos, siendo por tanto una información confidencial, pero de bajo nivel de riesgo. Sin embargo, si el mismo albarán va valorado, mostrará precios aplicados al cliente así como posibles descuentos y formas de pago (no quisiera pensar que mostrase la cuenta bancaria), conteniendo de este modo información confidencial de un nivel superior en relación al caso anterior, dado que cualquiera que tuviera acceso a él, podría conocer detalles sobre los términos comerciales de acuerdos en precios, descuentos y formas de pago con el cliente. Esta información es sensible y muy apetecida por la competencia.

[Read more…]

Cuantificación de la seguridad

(La entrada de hoy es la tercera colaboración de Francisco Benet, un amigo de algunos de nosotros —y familia de algún otro— que tiene gran experiencia en la gestión e integración de sistemas, protección de datos de carácter personal y evaluación de soluciones de integración de software y hardware, entre otros aspectos. Esperamos que les guste.)

En el mundo empresarial, tan alejado del mundo real de la seguridad informática, todo debe ser cuantificable; se definen ROIs (Return On Investment), ROSIs (Return On Security Investment) y otros tantos conceptos con sus correspondientes acrónimos para poder cuantificar los gastos e inversiones. La norma es que todo debe ser metido en caja. Y esto aplica para la seguridad, ya que la seguridad aunque no lo parezca, también se vende.

[Read more…]

Copias de seguridad: Virtual Tape Library (VTL)

Es incuestionable que uno de los activos más valiosos de una empresa son sus datos, y como tal es imprescindible que estemos preparados para poder recuperar el servicio lo más rápido posible. Esta fórmula se aplica desde un simple fichero hasta la restauración de toda la infraestructura de un negocio.

Desde siempre, el método preferido para salvaguardar toda la información han sido nuestros amigos los llamados cartuchos o cintas. La diferencia de capacidad de almacenamiento entre estos dispositivos secuenciales y los discos duros de nuestras máquinas siempre ha sido bastante amplia, y prueba de ello es que para este mismo año se espera el lanzamiento de las cintas LTO5, con una capacidad nativa de 1,6Tb y comprimida de 3,2Tb. Y para el 2010/2011 las LTO6, doblando las características de las anteriores (¡¡hasta 6,4Tb en un solo cartucho!!).

Hasta hace unos años, la diferencia de precio entre disco y cinta era mayor. Hoy en día no lo es tanto, una LTO4 (800Gb nativos) puede costarnos aproximadamente unos 60€, y un disco de esa capacidad ya no está tan lejos. Hay que tener en cuenta que cada vez hay más datos que salvar y cada vez menos tiempo para hacerlo. Las ventanas de Backup se reducen, los sistemas necesitan estar en producción más tiempo, y por tanto necesitamos soportes más rápidos, terreno en los que los discos se llevan el gato al agua. Pero, ¿cómo vamos a gestionar los volúmenes de copia en un disco duro? Pues para ello tenemos las Virtual Tape Library (VTL), que es a todos los efectos como una cabina de discos. La tecnología detrás de esta idea es bastante sencilla: tomando como base un conjunto de discos físicos se crean cartuchos de cinta virtuales; a grandes rasgos y salvando las diferencias, es como cuando compramos un disco duro para nuestro PC y lo particionamos en varias unidades.

Este sistema es totalmente transparente para la aplicación que tengamos de Backup. La VTL es detectada simplemente como un robot de cintas, con la excepción que no dispone de cartuchos físicos. Quedarnos sin cintas es así casi imposible, ya que la propia VTL particiona nuevo espacio si lo necesita y crea nuevos cartuchos virtuales. Es lo que se conoce como copias D2D (Disk to Disk). Si el robot de cintas fue un punto de inflexión, las VTL son el cambio definitivo.

Más de uno ha vaticinado el fin de los cartuchos en unos pocos años. No obstante, el punto más fuerte de éstos es la fiabilidad, ya que en una caída accidental el porcentaje de supervivencia de este soporte es muy alto, pero imaginemos la misma situación para un disco duro. Esto hace de los cartuchos soportes ideales para las copias OFFSITE, aunque también hoy en día esto se puede solucionar con las VTL. Hay librerías VTL que llevan incluidas un lector de cinta, con lo que tenemos como resultado un sistema híbrido que permite usar las dos tecnologías. Otra opción para administrar las copias OFFSITE es sincronizar con un centro de contingencia los cartuchos virtuales usados: a una escala WAN mandarlos por la línea de comunicaciones a otra ubicación física, con lo que siempre tendremos duplicadas todas las copias realizadas en dos ubicaciones diferentes, y a las pocas horas de haber realizado dichos backups (siempre que la línea de comunicaciones lo permita, claro). Como es obvio, esta última solución tiene un coste no despreciable, aunque puede ser recomendable (o necesaria y/u obligatoria) en sistemas de negocio críticos. En definitiva, si tenemos bien estructurada y monitorizada nuestra plataforma de copias, con esta opción tenemos la cura definitiva contra el insomnio.

Visto y dicho esto, ¿Quién recordará en un tiempo lo que era una DAT, una DLT o una LTO? Yo no.

(N.d.E.) Es de bien nacidos ser agradecidos, por lo que todo el equipo de Security Art Work quiere dar las gracias a Security By Default por incluirnos en su lista de blogs interesantes sobre seguridad, y a los lectores por seguir leyéndonos. ¡Gracias!

Peritajes informáticos

Cuando una organización sufre determinados incidentes de seguridad (por ejemplo, una intrusión), se plantea la realización de un análisis forense, en el que se tratan de obtener y presentar evidencias electrónicas del problema acaecido; adicionalmente, en ocasiones —no siempre, aunque si se ha producido un delito debería ser así—, es necesario efectuar una denuncia, y es entonces cuando surge la necesidad de realizar un peritaje informático por parte de un perito cualificado.

Un peritaje informático tiene como objeto dar respuesta técnica a una serie de cuestiones planteadas bien por una de las partes bien por el propio juez; dicha respuesta, por muy complejos que sean el desarrollo o las bases de la misma, debe ser concisa y sencilla (pensemos que la tienen que interpretar personas que no tienen por qué estar familiarizadas técnicamente con el objeto del informe). Así, siempre es conveniente incluir un apartado de “conclusiones” dentro de nuestro informe, en el que en base a todo lo desarrollado en el cuerpo del mismo, se muestren de forma resumida las respuestas a las cuestiones planteadas.

Para poder realizar y defender un informe pericial no es necesario, a priori, ningún requisito especial; no obstante, en la práctica suele ser positivo para que el informe sea tenido en cuenta por el juez, bien disponer de una titulación académica adecuada al objeto del informe, o bien disponer de una experiencia profesional en el campo al que el informe hace referencia. Dicho de otra forma, yo podría presentar un informe pericial acerca de los problemas de salud que un determinado individuo dice padecer y dar mi opinión acerca de si estos problemas han influido en la comisión de un delito, pero como no soy médico, mi informe sería poco más que papel mojado ante un tribunal. Por este motivo, cuando estamos tratando casos en los que entran en juego la informática o las telecomunicaciones, tanto el juez como las partes tratarán de buscar peritos Ingenieros Informáticos o de Telecomunicación. Las empresas de seguridad que tienen entre su catálogo de servicios, dentro de los aspectos de gestión de incidentes, los peritajes, disponen —o deben disponer— de Ingenieros cualificados para realizar estos informes; además, los Colegios Oficiales disponen en muchos casos de turnos de actuación profesional (algo equivalente al turno de oficio para los abogados) para aportar peritos en aquellos casos en los que se solicitan (por ejemplo, en la Comunidad Valenciana, el Colegio Oficial de Ingenieros en Informática dispone de este turno de actuación).

Los que hemos realizado y defendido informes periciales —tanto de parte como judiciales— ante un juez, nos hemos tenido que enfrentar en muchas ocasiones a los principales problemas que bajo mi punto de vista existen a la hora de emitir un informe; en este orden:

— Incapacidad técnica para la emisión del dictamen.

Si hay que realizar un informe acerca de un individuo que se ha roto una pierna, desde el juzgado buscarán a un traumatólogo, no a un neurocirujano, por muy médico que este sea. Obvio, ¿verdad? Pues cuando entra en juego la tecnología, esto no es tan obvio… exagerando un poco, si asesinan a alguien dándole golpes con un portátil, es fácil que se busque a un Ingeniero Informático para emitir el informe en cuestión. Ante casos de este tipo, el perito debe ser tajante: se rechaza la realización del informe por incapacidad técnica. Por muy perito informático que yo sea, rechazaré una pericia relacionada con el mal funcionamiento de un SAP, porque desconozco técnicamente su funcionamiento y no me siento capacitado para hablar con propiedad sobre este entorno —y más cuando delante tengo a gente que puede estar jugándose penas de cárcel—.

— Técnicamente, todo es posible.

Por muy obvia que para un técnico sea una cuestión, para un juez o un abogado no lo es tanto; así, si estamos realizando un informe en el que se indica que un individuo ha utilizado su ordenador para atacar sistemas de terceros, y al individuo en cuestión se le incauta un equipo lleno de herramientas de hacking (con sus correspondientes accesos directos en el escritorio), ficheros de contraseñas, logs de chats… el acusado siempre puede decir que todo eso “se lo han puesto por la WiFi” y que él no sabe nada. Y cuando nos pregunten si eso es técnicamente posible, tendremos que decir que sí (aunque insistamos en la baja probabilidad por N motivos). En función del juez que lleve el caso, se declarará al acusado inocente.

— Contraposición de visiones: juristas y peritos.

Como hemos dicho antes, cuando realizamos un informe pericial debemos responder desde un punto de vista técnico a una serie de cuestiones que se nos plantean; es vital no incluir nunca opiniones personales no fundadas, y también es importante no entrar en el ámbito del abogado o del juez: un perito nunca puede decir, por muy obvio que técnicamente le parezca, que el acusado es culpable o inocente. Los aspectos jurídicos no entran de ninguna manera en el ámbito de actuación de un perito. De la misma forma, el perito no puede admitir —esto suele suceder en los informes de parte, no en los judiciales— opiniones legalistas que no se correspondan con la estricta realidad: si en nuestro informe decimos que algo es “altamente improbable” queremos decir sólo eso, que es altamente improbable, y no que es imposible (un término que seguramente para el abogado será mucho más directo y efectivo, y por tanto tratará que incluyamos en el informe, pero que técnicamente puede no ser cierto).

Finalmente, un problema que no es exclusivo de los peritos, sino que quizás es generalizado en el sistema judicial: para defender durante quince minutos nuestro informe, seguramente invirtamos toda una mañana en los juzgados. Ante esto, paciencia: es lo único que podemos hacer como peritos :)