Experiencias en el diseño de un Sistema de Detección de Intrusos

Experiencias en el diseño de un Sistema de Detección de Intrusos
para el Sistema Operativo UNIX
Ing. Josué Cardoso Castro
Inv. Aux.
Resumen
En esta ponencia se aborda la problemática de la Detección de Intrusos en el Sistema Operativo UNIX.
Los elementos que se discuten están orientados al diseño de los Sistemas de Detección de Intrusos
(SDI), y aquellos aspectos que deberán tomarse en consideración para implementarlos. Todo lo que se
debate está orientado al tratamiento de la seguridad en el Sistema Operativo: usuarios, procesos,
ficheros y así, como todas las acciones en sentido general que se ejecutan. Se introduce el concepto de
intruso y cómo se clasifican, se categorizan los posibles errores en la emisión de las alertas, se definen
las características y propiedades que deberán tener los SDI. Las ideas expuestas son resultado de la
implementación de un Sistema de Control y Seguridad, en el cual un componente es un SDI. Este
documento no aborda lo concerniente a redes ni bases de datos en términos particulares, sino los trata
como elementos de un sistema. Quiénes lean esta ponencia encontrarán un punto de vista más, que
pudiera ayudarlos en la comprensión de este tema.
Introducción
Se puede definir una intrusión como cualquier conjunto de acciones que intenten comprometer la
integridad, confidencialidad y la disponibilidad de los recursos [HeadyLugerEtAl:01].
Las acciones de intrusos pueden ser originadas desde dentro o desde fuera, aunque algunas fuentes
[KatherinePrice:02] indican que el 80% de las acciones de intrusos se originan dentro de las
organizaciones.
Muchos Sistemas de Detección de Intrusos, en lo adelante los llamaremos SDI, se basan en analizar las
trazas dejadas por el sistema de auditoría propio del Sistema Operativo que se esté usando. Lo
conveniente de tales SDI es que esta información es proporcionada por la mayoría de los Sistemas
Operativos existentes, mientras tiene como desventaja que la información colectada no sea suficiente
para determinar todos los tipos de eventos que propicien una acción de un intruso. Es muy común ver
que los SDI toman sus propias muestras, creando así su propia fuente de información.
De cualquier modo los SDI deciden a partir de su fuente de información si una acción puede ser calificada
como una intrusión. Independientemente del origen de la fuente de información colectada, cada Sistema
Operativo computa estadísticas de la actividad del CPU, del uso y disponibilidad de los discos y la
Experiencias en el diseño de un SDI para el Sistema Operativo UNIX
Josué Cardoso Castro
2
memoria resultado del trabajo de los usuarios sobre el sistema, que no deben ser ignorados. Los SDI
pueden caracterizarse según la fuente de muestreo que usan:
-
Basados al servidor: toman las muestras de un solo servidor, donde corre el SDI.
-
Multiservidor: toman las muestras de varios servidores.
-
Basados a la Red: toman las muestras del canal de la red.
La fuente de muestreo es quien determina el alcance del SDI que se diseñe. La segunda clasificación,
para la conformación de sus muestras, puede seguir el mismo diseño que la primera y luego conformar
un colector de todos los servidores involucrados. La tercera clasificación si tiene un diseño y propósito
específico, en el control sólo interviene lo que circule por el canal de red, de hecho pierde los elementos
que lo relacionan con el sistema.
Sistema Avanzado de Control y Detección de Intrusos
El SDI que se discute aquí es un Sistema Avanzado de Control y Detección de Intrusos, en lo adelante
SACYDI, está asociado a un sistema de control dinámico de todos los servicios de un kernel UNIX, al
control de acceso y al estado general de la configuración de la seguridad del sistema.
El trabajo que se expone es el resultado del desarrollo de un Sistema de Control y Seguridad para UNIX,
en lo adelante se le hará referencia por SCS, y está compuesto por:
-
RESS: Reporte del Estado de la Seguridad del Sistema. El RESS está compuesto por varios
programas que intentan buscar problemas de seguridad en distintos áreas del sistema operativo
UNIX, que propician amenazas muy bien conocidas. Cada programa tiene su propio fichero de
configuración, donde se pueden ajustar los chequeos.
-
CAS: Control de Acceso al Sistema. El CAS está compuesto por un programa con sus ficheros de
configuración. Implementa esquema que no inhabilita ninguna función del sistema y cumple con
todos los requerimientos de un control de acceso normal, sólo que realiza un control adicional en una
base propia. Además tributa una estadística adicional con la que se alimentaría otros componentes
del sistema informático diseñado.
-
CYFEK: Control y Filtrado Empotrado al Kernel. El CYFEK implementa un modelo filtrado y auditoría
de todos los eventos asociados con los servicios del Kernel UNIX. El CYFEK intercepta todas las
llamadas al sistema y chequea si es permisible su ejecución con un conjunto de reglas, previamente
definida por el administrador. Estas reglas constituyen la política de filtrado de los servicios del kernel,
y son la base para la definición de la política de seguridad permitida para cada usuario, grupo de
usuarios o procesos activos en el sistema.
Experiencias en el diseño de un SDI para el Sistema Operativo UNIX
Josué Cardoso Castro
3
Todos los componentes del SCS tributan información a una base de datos que es la base informativa BI.
En la BI está colectada la información necesaria para que el sistema experto para la detección de
acciones de intrusos SEPDAI emita sus alertas.
El SEPDAI es el elemento del SACYDI que se encarga de hacer un análisis global y correlacionado de
los datos tributados por todos los componentes del SCS. En la fig. 1 se puede ver la composición del
SACYDI.
Clasificación de las intrusiones según las intenciones
Un sistema puede estar sometido a los siguientes tipos de acciones de intrusos:
-
malintencionadas: tienen bien definido sus ataques a los puntos vulnerables del sistema. Pueden
identificarse observando ciertas acciones sobre determinados objetos, a través del control de
auditoría [KumarSpafford:03].
-
anómalas: están basadas en las observaciones a las desviaciones del comportamiento normal en el
uso del sistema. Pueden identificarse construyendo un perfil de la actividad normal y registrar las
variaciones [Denning:04].
Las acciones malintencionadas son frenadas y alertadas en gran medida por cada componente del SCS.
El CAS es un SDI orientado a controlar el acceso de un usuario al sistema. En cada evento de conexión
de un usuario al sistema se conocen los siguientes elementos:
-
UNAME: nombre del usuario que se está conectando.
-
PASSWD: contraseña para ese usuario.
-
TARGET: nombre del sistema al cual se efectúa la conexión.
Experiencias en el diseño de un SDI para el Sistema Operativo UNIX
Josué Cardoso Castro
-
HOST: nombre del sistema desde cual se efectúa la conexión.
-
TDOMAIN: nombre del dominio al cual se efectúa la conexión.
-
HDOMAIN: nombre del dominio desde cual se efectúa la conexión.
-
TNAME: nombre de la terminal del usuario.
-
CIFSPMT: cantidad de intentos fallidos seguidos por la misma terminal.
-
CIFSPMU: cantidad de intentos fallidos seguidos por el mismo usuario.
4
Esta información obtenida del evento de conexión sirve para correlacionar sus elementos y someterlos a
un proceso de filtrado con respecto a las reglas de filtrado definidas por el administrador en las tablas de
control de acceso. Desde este punto de vista el CAS es capaz de detectar un conjunto de acciones de
intrusos orientadas a violar el acceso al sistema.
El CAS no puede determinar acciones anómalas ni es su objetivo, pues aquí sólo se pueden examinar las
correlaciones del evento de conexión y no las correlaciones más complejas que involucren otros eventos,
en este sentido sólo se tributa información para que el SEPDAI pueda posteriormente sacar sus
conclusiones.
El CYFEK no es más que un SDI orientado filtrar por el evento asociado con las llamadas al kernel con
respecto a un patrón. Con el evento asociado con las llamadas al kernel se conocen los siguientes
elementos:
-
SCNUM: número de la llamada al kernel.
-
UID: identificador del usuario.
-
GID: identificador del grupo del usuario.
-
EUID: identificador real del usuario.
-
EGID: identificador real del grupo del usuario.
-
PID: identificador del proceso que solicitó el servicio.
-
PPID: identificador del proceso padre del que solicitó el servicio.
-
NAME: nombre del objeto al que se le aplicará el servicio solicitado.
-
PCMD: nombre del proceso solicitante del servicio.
Esta información obtenida del evento asociado a las llamadas sirve para correlacionar sus elementos y
someterlos a un proceso de filtrado con respecto a las reglas de filtrado definidas por el administrador y
de esta manera determinar si se permite su ejecución.
El CYFEK puede determinar algunas acciones anómalas aunque no es su principal objetivo, pues aquí
sólo se pueden examinar las correlaciones del evento asociado a las llamadas y no las correlaciones más
Experiencias en el diseño de un SDI para el Sistema Operativo UNIX
Josué Cardoso Castro
5
complejas que involucren otros eventos. Más bien el CYFEK alimenta la BI, para que el SEPDAI deduzca
las acciones anómalas que puedan producirse.
El RESS, a diferencia del CAS y el CYFEK, no impide la ejecución de ningún evento, sólo emite
advertencias y tributa información para el
SEPDAI. El objetivo de este paquete es explorar las
vulnerabilidades que tiene el sistema y realizar algunos controles de integridad, confidencialidad y
disponibilidad a partir de los ficheros de configuración del sistema. La información que tributa el RESS
constituye un complemento de gran importancia para las conclusiones del SEPDAI.
Caracterización de los SDI según el modelo de detección
De acuerdo a la clasificación realizada en el acápite anterior y a la profundidad de detección de los SDI,
ellos deben ser concebidos de acuerdo al tipo de acciones de intrusos que se desee detectar:
-
Modelo de detección de Intrusiones malintencionadas: se observa la actividad que corresponde a
técnicas de intrusión conocidas basadas en la
vulnerabilidad de los sistemas. En este sentido
trabajan en el SCS: el RESS, el CAS y el CYFEK; orientados a los correspondientes frentes de
actividad de cada uno de ellos.
-
Modelo de detección de Intrusiones anómalas: se observa la actividad que difiere del
comportamiento normal de un usuario o del sistema. En este sentido sólo el SEPDAI puede emitir
alertas a partir de la BI creada por los componentes del SCS.
Los SDI, independientemente del modelo que implementen, deben tener su propia memoria para poder
correlacionar diferentes eventos que sucedan en momentos distintos. En este sentido los componentes
del SCS han sido implementados de forma simple para no ocasionar grandes retardos en la ejecución de
los procesos, pensando más en el filtrado inmediato que en la correlación entre eventos.
Cuando se diseña un SDI debe establecerse un compromiso en la estructura de sus componentes que
permita ser profundo en el análisis y minimizar la sobrecarga al sistema.
Una forma para tener en cuenta la correlaciones de eventos, principalmente para los modelos de
detección de Intrusiones anómalas fue propuesto por Denning [Denning:04]. Este método consiste en
incorporar en el cálculo una métrica que se derive de la operación que se está efectuando. Para
construirla propone usar una variable aleatoria x que represente una medida cuantitativa acumulada en
un período de tiempo. Esta métrica puede ser computada a partir de los parámetros disponibles en el
sistema como la carga media del CPU, el número de conexiones a la red por minuto o el número de
procesos por usuario.
Características de los Sistemas de Detección de Intrusos SDI
Experiencias en el diseño de un SDI para el Sistema Operativo UNIX
Josué Cardoso Castro
6
A la hora de construir un SDI, o algún componente de éste, debe tenerse en cuenta que cualquier
sistema que esté orientado a la observación y a la emisión de alertas continuas debe cumplir con los
siguientes requisitos:
-
Correr continuamente sin supervisión del hombre, ser abierto y monitorizado desde afuera. En
este régimen deben trabajar del SCS: el CYFEK todo el tiempo y CAS, mientras no haya ningún
usuario conectado en la terminal; y el SEPDAI. RESS, por sus funciones se activa por la voluntad del
administrador o por un evento previamente planificado.
-
Tolerante a fallo, que su BI pueda reconstruirse después de un fallo del sistema. Por la composición
del SACYDI, los sistemas tributantes de información del SCS y el que la procesa en el SEPDAI
pertenecen a
dos sistemas independientes. Esto
viabiliza la tolerancia a fallo y reduce la
complejidad del SACYDI.
-
Combatir la insubordinación, evitar que nadie evada el control. El principal tributante de
información para todo el SACYDI es el CYFEK que, por fundamentar su control con la interceptación
de los eventos asociados a las llamadas al kernel, asegura que ningún proceso evada su control. De
acuerdo a su rol en el sistema el CAS garantiza su permanencia activa en el sistema, mientras no se
haya establecido la conexión de un usuario por la terminal. El CAS fija un limite de conexiones
infructuosas al sistema por el mismo usuario y por la misma terminal de manera continua,
bloqueando, a ambos inclusive, si se excede el número intentos.
-
Ocasionar la menor sobrecarga posible al sistema. El SACYDI garantiza esto descomponiendo las
funciones de los respectivos sistemas en pequeños programas que compartan de igual modo el
procesador. Las funciones implementadas por el CYFEK en el kernel son simples y no introducen
una sobrecarga mayor que la necesidad de protección que proporcionan.
-
Detectar las desviaciones del comportamiento normal del sistema. En el SACYDI a partir de la BI
el SEPDAI puede determinar a partir de un perfil las variaciones del comportamiento normal del
sistema. En el SCS el CYFEK puede detectar algunas variaciones cuando un usuario solicita un
servicio del kernel para el cual el administrador no le concedió permiso para su ejecución, en este
caso se rechaza tal solicitud por denegación de acceso. En cambio, el RESS pronostica una
variación, si algunos de sus componentes detecta alteraciones en la configuración de los diferentes
subsistemas que componen el sistema.
-
Hacer frente a los cambios del comportamiento normal del sistema ante nuevas aplicaciones,
tener un comportamiento adaptable. Esta función le compete al SEPDAI, que es quién se encarga de
hacer el análisis global y correlacionado de todos los eventos registrados en la BI. Para ello
implementa un esquema de construcción adaptable de perfiles.
-
Configurable a la medida del sistema donde se instale. Todos los procesos que componen al
SACYDI tienen sus propios ficheros de configuración.
Experiencias en el diseño de un SDI para el Sistema Operativo UNIX
-
Josué Cardoso Castro
7
Difícil de engañar. Este es el aspecto más crítico a proponerse, a pesar que puede asegurarse
aportándole redundancia de controles a todo el SACYDI. Aunque una acción se controle por algún
componente del SCS debe controlarse adicionalmente en cualquier otro componente del SACYDI.
Por ejemplo, si todos los usuarios pueden correr el comando grep pero no el passwd, el
administrador puede prever esto en las reglas de filtrados; no obstante, si algún "listo" logra cambiar
passwd como grep, las reglas de filtrado no lo detectan, pero si se detecta un cambio de perfil para
el grep que enmascara al passwd. La redundancia de controles es un principio de primer orden para
todo el SACYDI, cuando no se quiere, por ejemplo, que alguien lea o escriba un fichero hay que
impedirlo, en las reglas de filtrado del llamado a access, que autoriza el acceso; en el open, que
abre el fichero; en el create, que crea el fichero; en el read, ejecuta la lectura; en el write, que
ejecuta la escritura.
Estas características no son fáciles de lograr, pero los SDI deben aproximarse a implementarlas con
mayor grado de plenitud. En la medida que la aproximación sea más exacta, más confiable será SDI que
se implemente; y si este criterio de aproximación pudiera ser medible, se pudiera cuantitativamente medir
su calidad.
Reglas de filtrado
Las reglas de filtrado están asociadas con la política de seguridad vigente. Toda política de seguridad
refleja por detrás una filosofía de concesión de permiso para la elaboración de las reglas de filtrado. Se
distingue dos filosofías básicas:
-
Prohibitiva: todo lo que no está expresamente permitido es denegado. Para los sitios dónde se es
exigente con la seguridad, esta filosofía es sin duda la elegida. Se requiere que las reglas de filtrado
expresen claramente qué filtrar; todas las acciones que no cumplan con ellas, se consideran
ilegítimas, que no se deben permitir. Para definir algunos esquemas de filtrado por la red, es muy
práctico adoptar esta filosofía, pero cuando el SDI involucra acciones tan complejas y privilegiadas
como son los servicios del kernel no es práctico esta filosofía. En el CYFEK se hace muy complejo
escribir las reglas de filtrado usando esta filosofía, pues habría que prever todos los servicios que se
van a permitir para cada uno de los procesos que serán corridos en el sistema. Esto implica que las
reglas de filtrado pudieran crecer ilimitadamente lo cual perjudica el rendimiento, pues para cada
servicio del kernel habría que revisar una lista larga de reglas.
-
Permisiva: todo lo que no está expresamente denegado es permitido. Esta filosofía se asemeja más
al espíritu tradicional seguido en los productos para computadora. Históricamente se tiende a poner
disponible todos los servicios y después se afina el sistema. El gran inconveniente de esta filosofía es
que no se puede prever todo lo que se necesita proteger, además, tampoco está exenta de que si
crece ilimitadamente afecte el rendimiento. La lógica utilizada para las reglas definidas en el CYFEK,
no se debe a la tradición sino a la optimización del rendimiento, cada
regla establece un "Y" lógico
Experiencias en el diseño de un SDI para el Sistema Operativo UNIX
Josué Cardoso Castro
8
con la próxima. Cuando se necesita chequear el permiso de un servicio se busca en las reglas
mientras no case; si aparece una, donde los patrones coincidan, se devuelve como resultado el
permiso que tenga asociado y no se continúa buscando. Las reglas definidas en el CYFEK cuentan
con un metalenguaje con las operaciones lógicas: not, or y and que permite el filtrado directo: a
través de la regla en sí, e indirecto por medio de otro programa previamente elaborado.
La conclusión más importante a sacar es que cuando la lista de reglas es considerablemente grande se
debe escoger una política con una filosofía que resulte óptima.
Clasificación de los posibles errores en la emisión de alertas
Un aspecto importante en la elaboración de SDI es la formación y emisión de las alertas. La formación de
las alertas debe producirse no sólo de lo que se detecte por el control en un momento dado, sino también
a partir de las regularidades encontradas en la BI que sugieran la necesidad de una alerta. Un SDI debe
mantener integra su BI, pues es la fuente principal para la emisión de las alertas. Durante este proceso
pueden producirse errores que pueden influir en la credibilidad del SDI que se elabore. Estos errores
pueden categorizarse como:
-
Falso positivo: se emite una alerta ante una acción legítima. La ocurrencia de este tipo de error le
resta credibilidad a los SDI. La tendencia debe ser minimizar o eliminar este tipo de error. Cuando el
número de alertas de este tipo abunda en un SDI, el administrador o quién lo opere deja de prestarle
atención sus salidas. Un SDI al cual no se le preste atención no está cumpliendo con su función.
-
Falso negativo: ocurre una acción de intruso y el sistema la permite como si fuera legítima. Este tipo
de error es peor que el falso positivo porque confunde el buen sentido que se pretende con la
seguridad. Pueden ocurrir acciones de intrusos que el SDI no los detecte.
-
Insubordinación: cuando el intruso modifica las operaciones del detector y para caer en el estado de
un falso negativo. Este tipo de error es más complejo que el falso negativo. Ocurre por lo general
cuando un usuario conoce las interioridades del SDI y altera la información de las alertas o de su
comportamiento simulando una normalidad del funcionamiento. Pudiera ser, también, violando las
restricciones del sistema de seguridad.
Muchos de estos errores pudieran ser detectados si se auditan los registros colectados periódicamente
de forma manual, para comprobar si el sistema experto está cumpliendo con su objetivo o aportándole
reglas redundantes al SDI. Si estos hechos son frecuentes en el SDI, hay que valorar qué realmente
aporta el SDI a la seguridad, para si no aporta mucho prescindir de él.
La Base Informativa
La BI tiene que tener todo lo necesario para poder dictaminar que ocurrió una acción de un intruso y
puede estar compuesta por varias tablas con las siguientes características:
Experiencias en el diseño de un SDI para el Sistema Operativo UNIX
Josué Cardoso Castro
9
-
Cada tabla de la BI tiene que tener un elemento de enlace con cualquier otra que se relacione.
-
Las tablas deben ser temáticas para garantizar una estructura homogénea, es decir estar asociadas
con la ocurrencia de un evento registrado por el sistema de control.
-
Cada tabla tiene que tener una marca de tiempo asociado con el momento del hecho,
preferiblemente enmascarado, pues el tiempo es otro elemento más de relación.
El sistema experto, encargado en el SDI de procesar los datos colectados en la BI, debe auxiliarse de la
Minería de Datos (MD) para aplicar reglas de asociación con el propósito de revelar, de manera fácil, las
correlaciones complejas de la BI. Supongan que X es un conjunto de eventos registrados en una de las
tablas de la BI, se define como support(X) al porciento que representa X en la tabla. Una regla de
asociación puede expresarse como { X  Y, c, s } donde X y Y son dos conjuntos de eventos de la tabla
mutuamente excluyentes, es decir XY = ; s=support(XY) y c=(support(XY)/ support(X)). La
regla de asociación { X  Y, c, s } puede leerse como que se han detectado un c porciento de eventos X
asociados los eventos Y, y esto representa s porciento de toda la actividad registrada. Se pueden prever
reglas más complejas que correlacionen más conjuntos, lo importante está en que la MD puede aportar
un procesamiento más cómodo de las tablas de la BI y nuevos indicadores de relación.
La BI puede residir en una Base de Datos (BD) o en ficheros. Si estuviera en una BD, formular las
recuperaciones fuera un proceso más sencillo; pero tuviera como inconveniente la necesidad de
depender de la presencia de un Sistema de Gestión de Bases de Datos (SGBD). Si estuviera soportada a
través de fichero, no existiera tal dependencia pero fuera más compleja la recuperación y mantenimiento
de la información.
El sistema experto que procesa la BI debe ser capaz de eliminar datos que no aporten al análisis de las
intrusiones y aquello que pueda ser realmente ocioso.
Es importante que la BI se mantenga integra, independientemente de la forma en que esté soportada: en
BD o en fichero.
Conclusiones
Se ha expuesto un trabajo que es el resultado de la experiencia en el desarrollo de un sistema de control
y seguridad. Se han dado elementos que pueden ser útiles para los que manejan la problemática de la
seguridad y la detección de intrusos.
Un SDI tiene éxito cuando se cuenta con sistemas de controles que le suministren información sobre el
estado del sistema para la BI y cuando exista un sistema, que usando reglas de asociación, sea capaz de
correlacionar la información colectada.
El aporte dado aquí consiste en que muchas acciones de intrusos pueden ser frenadas antes de que
ocurran. El SCS tiene el CYFEK que es un pequeño SDI de acción dinámica que está dotado de un
Experiencias en el diseño de un SDI para el Sistema Operativo UNIX
Josué Cardoso Castro
10
conjunto de reglas de filtrado para impedir que ocurran solicitudes privilegiadas al kernel, que no se
corresponda con lo previsto por el administrador para el usuario que las emitió. La BI, con toda la
información colectada por los componentes del SCS, es además explorada por el SEPDAI para indagar
en correlaciones más complejas, que no pueden ser descubiertas por el SCS.
Se hizo una clasificación de las intrusiones según su intención y se expusieron los modelos de SDI de
acuerdo al propósito que se proponga. Se enumeraron las características que debería tener un buen SDI
y como se ven reflejadas en el SACYDI y sus componentes. Se expusieron los criterios y la filosofía que
se pueden emplear en la elaboración de las políticas reflejadas en las reglas de filtrado, argumentando la
escogida para el CYFEK del SCS. Se hizo una clasificación de los posibles errores en la emisión de las
alertas y como pueden ser solucionados. También se expuso las características que se deben observar
en creación y tratamiento de la BI.
Como resultado el sistema diseñado crea una BI con elementos relevantes para un "Análisis Forense del
Sistema Operativo" [SpaffordWeeber:05] en caso de contingencia ante un cibercrimen.
Experiencias en el diseño de un SDI para el Sistema Operativo UNIX
Josué Cardoso Castro
11
Bibliografía
HeadyLugerEtAl:01
Richard Heady, George Luger, Arthur Maccabe, and Mark Servilla. The architecture of a network level
intrusion detection system. Technical Report CS90-20, Department of Computer Science, University
of New Mexico, August 1990.
KatherinePrice:02
http://www.cs.purdue.edu/coast. Intrusion Detection Pages, Last modified: Mon Sep 20 13:14:50 EST
1999.
KumarSpafford:03
Sandeep Kumar and Eugene H. Spafford. A pattern matching model for misuse intrusion detection. In
Proceedings of the 17th National Computer Security Conference, pages 11-21, October 1994.
Denning:04
Dorothy E. Denning. An intrusion-detection model. IEEE Transactions on Software Engineering,
13(2):222-232, February 1987.
SpaffordWeeber:05
Eugene H. Spafford and Stephen Weeber. Software Forensics: Can we track code to its Authors?
Purdue Technical Report CSD-TR 92-010, SERC Technical Report SERC-TR-110-P, February 1992.