Documento Stornelli

Estimado Lector:
Se pone en su conocimiento que, según lo dispuesto

en el Convenio suscripto entre la AGN y el CMPJN,
el informe de auditoría resultante tendrá carácter de
reservado.
Consejo de la Magistratura del Poder Judicial de la Nación

Análisis del Sistema de Gestión Judicial, con especial hincapié en el procedimiento de
sorteo de causas. Disp. AGN 555/16 – Convenio.
Auditoría General de la Nación

Gerencia de Planificación y Proyectos Especiales
Departamento de Auditoría Informática
Índice
1. OBJETO DE AUDITORÍA ............................................................................................... 1

2. ALCANCE ........................................................................................................................ 1
2.1. Ejecución del Trabajo de Auditoría .........................................................................................................1
2.2. Enfoque del Trabajo de Auditoría ...........................................................................................................2
2.3. Procedimientos de Auditoría ...................................................................................................................4
2.4. Limitaciones ............................................................................................................................................6
2.5. Hechos posteriores al período auditado ...................................................................................................9
3. ACLARACIONES PREVIAS ......................................................................................... 10
3.1. El Consejo de la Magistratura del Poder Judicial de la Nación ............................................................. 10
3.2. El Sistema de Gestión Judicial y el proceso de asignación de causas .................................................. 18
3.3. Contexto de TI del objeto de control .....................................................................................................22
4. COMENTARIOS Y OBSERVACIONES ...................................................................... 23
4.1. Procedimientos Técnicos ....................................................................................................................... 23
4.2. Módulo de Asignación de Causas .........................................................................................................39
5. RECOMENDACIONES.................................................................................................. 50
5.1. Procedimientos Técnicos ....................................................................................................................... 50
5.2. Módulo de Asignación de Causas. ........................................................................................................52
6. CONCLUSIONES ........................................................................................................... 53
7. COMUNICACIÓN AL ENTE ........................................................................................ 56
8. LUGAR Y FECHA.......................................................................................................... 56
9. FIRMA ............................................................................................................................. 57
Glosario
AGN: Auditoría General de la Nación.

CMMI: Integración de Modelos de Madurez de Capacidades, por las siglas del inglés de
Capability Maturity Model Integration. Se utiliza como marco de referencia de buenas
prácticas en TI.
CMPJN: Consejo de la Magistratura del Poder Judicial de la Nación.
CN: Constitución Nacional.
COBIT: Objetivos de Control para Información y Tecnologías Relacionadas, versión 4.1.,
por las siglas del inglés de Control Objectives for Information and Related Technology.
Se utiliza como marco de referencia de buenas prácticas en TI.
Convenio: Convenio suscripto entre la Auditoría General de la Nación y el Consejo de la
Magistratura del Poder Judicial de la Nación, el 20 de diciembre de 2016, aprobado por
Disposición AGN 555/16 y Resoluciones CMPJN 521/16 y 704/16.
CSJN: Corte Suprema de Justicia de la Nación.
Data Center: Centro de Procesamiento de Datos, o CPD.
DGT: Dirección General de Tecnología del Consejo de la Magistratura del Poder Judicial
de la Nación.
DRP: Plan de Recuperación de Desastres, por las siglas del inglés de Disaster Recovery
Plan.
HW: Hardware.
Incidente: De acuerdo con ITIL, es cualquier evento que no forma parte del desarrollo
habitual del servicio y que causa o puede causar su interrupción o una reducción de su
calidad. Ver también “problema”.
ISO 27000/1/2: conjunto de estándares desarrollados por la Organización Internacional de
Normalización - ISO (por las siglas del inglés International Organization for
Standardization) y por la Comisión Electrotécnica Internacional - IEC (por las siglas
del inglés International Electrotechnical Commission), que proporcionan un marco de
gestión de la seguridad de la información y que en este informe se utilizan como
referencia de buenas prácticas.
ITIL: Biblioteca de Infraestructura de Tecnologías de Información, por las siglas del inglés
de Information Technology Infrastructure Library. Se utiliza como marco de referencia
de buenas prácticas en TI.
Módulo de Sorteo de Causas: También denominado “Módulo de Asignación de Causas”, es
una funcionalidad del Sistema de Gestión Judicial para la asignación de causas a
juzgados, tribunales, salas, etc.
MPLS: Conmutación de etiquetas multiprotocolo, por las siglas del inglés de Multiprotocol
Label Switching. Es un tipo de enlace de comunicaciones que permite compartir el
medio físico de transmisión, pero aislando cada canal.
PJN: Poder Judicial de la Nación.
PMBOK: Compendio de Conocimiento de Gestión de Proyectos del inglés Project
Management Body of Knowledge.
Problema: Fallo producido en un sistema por un mal funcionamiento del software o
hardware, que puede generar desde una disminución en su rendimiento, hasta la salida
de servicio de todo el sistema afectado.
SGJ: Sistema Informático de Gestión Judicial Lex 100. En el marco de este informe se hará
referencia a este sistema como “SGJ”, “Lex 100”, “SGJ Lex 100” o “Sistema de
Gestión Judicial” de modo indistinto.
SW: Software.
TI: Tecnologías de la Información.
UPS: Sistema de Alimentación Ininterrumpida, por las siglas del inglés de Uninterruptible
Power Supply.
INFORME DE AUDITORIA
A la Señora Presidente del Consejo de la Magistratura

del Poder Judicial de la Nación
Dra. Adriana Donato
S. / D.
En uso de las facultades conferidas por el artículo 118 de la Ley 24.156 de Administración
Financiera y de los Sistemas de Control del Sector Público Nacional, la Auditoría General
de la Nación (AGN), en el marco del Convenio suscripto con el Consejo de la Magistratura
del Poder Judicial de la Nación (CMPJN)1, efectuó un examen en el ámbito de ese organismo
con el objeto que se detalla en el apartado 1.
1. OBJETO DE AUDITORÍA
Análisis del Sistema de Gestión Judicial, con especial hincapié en el procedimiento de sorteo
de causas. Disp. AGN 555/16 – Convenio.
2. ALCANCE
2.1. Ejecución del Trabajo de Auditoría
El examen fue realizado de conformidad con las Normas de Control Externo Gubernamental
y las Normas de Control Externo de la Gestión Gubernamental, aprobadas por Resoluciones
AGN 26/15 y 186/16, respectivamente, dictadas en virtud de las facultades conferidas la Ley
24.156 de Administración Financiera y de los Sistemas de Control del Sector Público
Nacional (Artículo 119 inciso d), aplicándose los procedimientos detallados en el punto 2.3.
El inicio de las tareas de auditoría se notificó al organismo el 02/03/2017 mediante Nota

AGN 95/17-P, recibida el 08/03/2017.
1
Aprobado por Disposición AGN 555/16 y Resoluciones CMPJN 521/16 y 704/16.
1
El período auditado comprende del 1º de enero de 2016 al 31 de diciembre de 2016.

Las tareas de campo se desarrollaron entre marzo y octubre de 2017.
2.2. Enfoque del Trabajo de Auditoría
El Convenio celebrado el 20 de diciembre de 2016 entre el Consejo de la Magistratura del

Poder Judicial de la Nación y la Auditoría General de la Nación, establece el siguiente
alcance desagregado en las denominadas “Fase 1: Procedimientos Técnicos” y “Fase 2”:
Módulo de Asignación de Causas:
Fase 1: Procedimientos Técnicos

Alcance: Analizar los procedimientos vinculados con los recursos tecnológicos y las
actividades relacionadas con el funcionamiento y mantenimiento del Sistema de Gestión
Judicial, según lo establecido en la Resolución Plenaria CMPJN 521/16:2
a. Administración de usuarios.
b. Documentación de la arquitectura seleccionada.
c. Administración de la infraestructura de TI relacionada con el módulo3 (bases de
datos, servidores, comunicaciones, seguridad física, seguridad lógica, seguridad de
datos, entre otras).
d. Ciclo de vida del software (examinando el cumplimiento de procedimientos y
mejores prácticas acerca del mantenimiento del software, control de versiones,
despliegue de la documentación de respaldo del sistema).
e. Verificación de la existencia de los correspondientes entornos de desarrollo, test,
producción y cumplimiento de los correspondientes procedimientos de seguridad,
desarrollo y despliegue en cada uno de ellos.
2
La revisión se acota a la infraestructura tecnológica involucrada en el procesamiento del Sistema de Gestión
Judicial Lex 100 (Convenio, Anexo 1, Fase 1).
3
Refiere al módulo mencionado en la Fase 2.
2
f. Respaldo y recuperación de la información.

g. Seguridad e integridad de la base de datos.
Fase 2: Módulo de Asignación de Causas

Alcance: Analizar el módulo de Asignación de Causas según lo establecido en la Resolución
CMPJN 521/16:
a. Arquitectura del módulo.

b. Desarrollo del módulo.
c. Parametrización por fuero.
d. Definición de roles de usuarios.
e. Pruebas de funcionamiento de las diferentes opciones.
f. Auditoría de funcionamiento:
i. Análisis de pistas de auditoría.
ii. Análisis del algoritmo de la secuencia de la asignación en base a las
definiciones surgidas de la documentación de la pieza de software construida.
iii. Análisis de la seguridad lógica del módulo.
iv. Análisis de la integridad, fiabilidad y disponibilidad de los datos.
v. Análisis de bolilleros de compensación.
vi. Análisis de métodos y resultados de búsqueda de conexidad.
La auditoría tuvo en cuenta estándares internacionales establecidos como marco de

referencia para buenas prácticas de TI, tales como:
- COBIT (Control Objectives for Information an Related Technology, por
Objetivos de Control para Información y Tecnologías Relacionadas, versión
4.1.),
- ISO/IEC 27002 sobre Seguridad de los Sistemas de Información,
- ITIL (Information Technology Infrastructure Library, por Biblioteca de
Infraestructura de TI),
3
- CMMI (Capability Maturity Model Integration, por Integración de Modelos de

Madurez de Capacidades),
- ICREA (International Computer Room Experts Association),
- PMBOK (Project Management Body of Knowledge, por Compendio de
Conocimiento de Gestión de Proyectos).
Cabe aclarar que los análisis y procedimientos ejecutados durante las tareas de campo se
realizaron sobre los recursos informáticos o procesos que son responsabilidad del Consejo
de la Magistratura del Poder Judicial de la Nación. En ningún caso se realizaron
procedimientos sobre recursos o procesos cuya administración recae exclusivamente sobre
la Corte Suprema de Justicia de la Nación, o sobre la gestión de dicho órgano en el caso de
responsabilidades compartidas con el Consejo de la Magistratura del Poder Judicial de la
Nación.
2.3. Procedimientos de Auditoría

En la etapa de análisis se realizaron los siguientes procedimientos:
• Análisis de la normativa de administración de usuarios.
• Verificación de la existencia de un Plan Estratégico de TI.
• Verificación de los análisis y la metodología utilizados para la definición de la
arquitectura del sistema.
• Verificación de la existencia y funcionamiento del Consejo de Arquitectura de TI.
• Verificación de la existencia y actualización de un modelo de arquitectura único para
el organismo.
• Verificación de disponibilidad de la arquitectura.
• Verificación de la existencia y actualización de un “diccionario de datos”
corporativos.
• Verificación de la existencia y utilización de un sistema de clasificación de datos
según su grado de criticidad y sensibilidad.
• Análisis de los informes de auditoría interna.
4
• Verificación de la existencia y confiabilidad de las medidas de control interno.

• Verificación de la ejecución de los planes de mantenimiento preventivo del hardware
(HW).
• Verificación del cumplimiento de los procedimientos ante incidentes que afecten a
la infraestructura tanto de HW como de software (SW).
• Verificación de la existencia y confiabilidad de un plan de mantenimiento de la
infraestructura.
• Análisis de la documentación que acredite los cambios realizados al SW para
verificar que se cumplan con los procedimientos previstos.
• Verificación de la existencia de una herramienta de soporte y repositorio central que
contenga información relevante sobre la configuración del sistema.
• Verificación de la existencia de procedimientos de configuración de la gestión y el
registro de cambios al repositorio.
• Control de periodicidad y verificación de la integridad de datos de configuración.
• Análisis del cumplimiento del esquema de clasificación de los datos y su aplicación
en las bases de datos.
• Control de la metodología del ciclo de vida del desarrollo de sistemas de la
organización, su aplicación al desarrollo de nuevos sistemas, cambios a los sistemas,
políticas y procedimientos.
• Verificación de los procesos de almacenamiento de SW.
• Verificación de las bibliotecas de almacenamiento de SW y su ubicación.
• Verificación del cumplimiento de procedimientos de backup y restauración.
• Verificación de la existencia de políticas y procedimientos que aseguren la adecuada
administración de los sistemas, a fin de garantizar la integridad de los datos y de los
programas productivos.
• Verificación de las medidas de protección perimetral.
• Pruebas orientadas a verificar el tipo de tráfico que puede circular en la red.
5
• Análisis de normativa relacionada con el objeto de auditoría.4

• Inspección ocular del Data Center del CMPJN, que incluyó las salas donde se
encuentran instaladas las UPS y los generadores.
• Observación de procesos de las oficinas de asignación de causas de los fueros
Contencioso Administrativo Federal, Civil y Comercial Federal, Penal Económico
Federal, y Criminal y Correccional Federal.
• Entrevistas realizadas con responsables y personal de diversas áreas y niveles de la
estructura orgánica: Dirección de Tecnología, Dirección de Seguridad Informática,
Departamento de Operaciones, Departamento de Organización y Sistemas,
Departamento de Ingeniería Informática y Departamento de Auditoría Informática.
• Análisis del funcionamiento de la funcionalidad de asignación de causas del Sistema
de Gestión Judicial Lex 100.
• Pruebas de funcionamiento (caja negra) sobre la funcionalidad de asignación de
causas del Sistema de Gestión Judicial en entorno de prueba, para los fueros
Contencioso Administrativo Federal y Penal Económico Federal.
2.4. Limitaciones
2.4.1. La falta de acceso a una copia de la base de datos productiva del Módulo de
Asignación de Causas impide emitir opinión sobre la consistencia, integridad, accesos y
permisos, entre otra información relevante, para establecer la confiabilidad de los datos
almacenados.
4
Ley 24.937 del Consejo de la Magistratura (t.o. por Decreto 816/1999) y modificatorias; Ley 25.506 de Firma
Digital; Ley 26.685 de Utilización de Expedientes, documentos, firmas, comunicaciones, domicilios
electrónicos y firmas digitales; Ley 26.856 de Publicación íntegra de Acordadas y Resoluciones; Acordadas
CSJN: 01/04, 02/04, 29/08, 31/11, 3/12, 8/12, 29/12, 14/13, 15/13, 20/13, 24/13, 35/13, 36/13, 38/13, 43/13,
02/14, 04/14, 06/14, 07/14, 11/14, 03/15, 13/15, 06/16, 09/16, 16/16, 38/16, 04/17, 05/17, 22/17 y 28/17;
Resoluciones CMPJN: 521/2016, 601/2016 y 704/2016; Reglamento de la Oficina de Asignación de Causas
de la Justicia Nacional en lo Civil y Comercial Federal de la Capital Federal (Acordada CNCCF 13/90 y
modificatorias); Reglamento para la Asignación de Causas en la Justicia Nacional en lo Contencioso
Administrativo Federal (Acordada CNCAF 7/94 y modificatorias); Reglamento de Informática de la Mesa
General de Entradas y Salidas y de los juzgados del fuero en lo Penal Económico (Actualizado al 30/08/2010);
Sistema de adjudicación de causas para el fuero Criminal y Correccional Federal de la Capital Federal
(Acordada CNCCF 4/17). Las normas citadas lo son al sólo efecto enunciativo.
6
Mediante Nota AGN 95/17-P, ANEXO I - apartado “Relativos al módulo de sorteos de

causas”, punto 6. iv), recibida por el organismo el 8/03/17, se solicitó copia de la base de
datos productiva a la fecha de recepción de la nota. El CMPJN respondió por Nota de la
Dirección General de Tecnología del CMPJN recibida por la AGN el 10 de mayo de 2017,
que “la administración de la base de datos es responsabilidad de la Corte Suprema de
Justicia de la Nación según acordada”. En el mismo sentido, tampoco se obtuvo
información sobre la metodología de despliegue de la base de datos, que impide saber cómo
se implementa.
2.4.2. La falta de acceso oportuno al registro de auditoría de transacciones impide emitir

opinión sobre la integridad de los datos almacenados en la base de datos que opera el
Sistema Lex 100.
Mediante Nota AGN 397/17-P, ANEXO I, apartado 2. Desarrollo, ítem 2.4., recibida por el
organismo el 4/05/17; y reiterada por Nota AGN 756/17-P, Anexo I ítem 4, recibida por el
organismo el 17/07/17, se solicitó el log de auditoría de todas las transacciones de todos los
usuarios con perfil de administrador del módulo de asignación de causas.5
2.4.3. La falta de acceso adecuado al código fuente del Módulo de Asignación de Causas
del Sistema de Gestión Judicial Lex 100 impide emitir opinión sobre su funcionamiento y la
calidad de los algoritmos, y sobre la exactitud y confiablidad del algoritmo utilizado para
la asignación de causas.
Mediante Nota AGN 95/17-P, ANEXO I – apartado “Relativos al módulo de sorteos de

causas”, puntos 6. ix) y 6. xiii), recibida por el organismo el 8/03/17, se solicitó la copia del
código fuente de la última versión en producción, y el documento que describe el algoritmo
5
Mediante nota de la Subadministración General del CMPJN, recibida por la AGN el 18/10/17, el organismo
informó la autorización de la CSJN, a través de su Dirección de Sistemas, para acceder a parte de la información
solicitada, con 151 días de retraso y en fecha posterior al cierre efectivo de tareas de campo.
7
aplicado en el sistema para realizar el sorteo, respectivamente. En respuesta al ítem 6. ix),

mediante Nota DGT CMPJN recibida por la AGN el 5/04/17, el organismo propone “dejar
disponible el código fuente en un entorno para que pueda ser analizado en detalle dentro del
ámbito del PJN”. En respuesta a ello, mediante Nota AGN 718/17-P de fecha 5/07/17, se
reclamó la entrega de una copia del código fuente para realizar las pruebas previstas en el
entorno de la AGN, de modo que la información suministrada pueda constituirse en
documentación de respaldo de los procedimientos. Mediante Nota DGT CMPJN de fecha
6/07/17 se informó que el envío de una copia del código fuente en CD se encontraba
pendiente de autorización. A la fecha de cierre de tareas de campo, la información no había
sido recibida por la AGN.
2.4.4. La falta de disponibilidad de información sobre la gestión de accesos a la base de

datos asociada al Lex 100 en tiempo oportuno, impide opinar sobre el resguardo de la
integridad de los datos de la base y la confidencialidad de la información.
Mediante Nota AGN 95/17-P, ANEXO I – apartado “Relativos al módulo de sorteos de

causas”, ítem 6.vi), recibida por el organismo el 8/03/17, se solicitó la lista de
administradores de la base de datos productiva y la descripción de los alcances de acceso y
funciones definidos para cada uno. A dicho requerimiento se respondió por Nota DGT
CMPJN, ingresada a la AGN el 10/05/17, que "la administración de la base de datos es
responsabilidad de la CSJN según acordada".6
2.4.5. La falta de disponibilidad del listado de usuarios del sistema Lex 100, con sus
permisos de acceso, impide determinar que las personas sólo accedan a la información o
ejecuten procedimientos para los que se encuentren autorizados.
6
Mediante Nota de la Subadministración General del CMPJN, recibida por la AGN el 18/10/17, el organismo
informó -con 208 días de demora y en fecha posterior al cierre efectivo de tareas de campo- la autorización de
la Dirección de Sistemas de la CSJN para acceder a la información solicitada.
8
Mediante Nota AGN 397/17-P, ANEXO I, apartado 2.Desarrollo, ítem 2.1, recibida por el
organismo el 17/07/17 se solicitó el listado de usuarios del Sistema Lex 100 y sus perfiles
de acceso. El CMPJN no brindó respuesta al cierre de tareas de campo.
2.4.6. La falta del listado del personal de sistemas y sus perfiles, impide determinar si
pueden acceder a entornos que deberían estar restringidos por su perfil.
Mediante Nota AGN 397/17-P, ANEXO I, apartado 2. Desarrollo, ítem 2.2, recibida por el
organismo el 17/07/17, se solicitó el listado de personal de la Dirección General de
Tecnología y de Seguridad con sus permisos de acceso (perfil completo). El CMPJN no
brindó respuesta al cierre de tareas de campo.
2.5. Hechos posteriores al período auditado
2.5.1. La configuración de perfiles del SGJ estuvo vigente desde su implantación hasta
agosto de 2017, momento a partir del cual se creó un nuevo perfil denominado “Monitoreo
de Cámara”, con permisos para acceder a los reportes “Auditoría de Gestión de Bolilleros”
y “Auditoría de Sorteos Realizados”. Dichos reportes permiten conocer o componer
información sobre la cantidad de expedientes asignados por rubro y juzgado. Antes de la
creación del perfil “Monitoreo de Cámara”, el perfil “Administrador de Sorteos” podía
acceder a ellos.
2.5.2. Durante las labores de campo fue aprobado el Protocolo de Actuación ante Incidencias
en la Asignación de Causas en el Sistema de Gestión Judicial, que dispone el procedimiento
a seguir por los operadores judiciales en el SGJ ante contingencias en el funcionamiento del
“Módulo de Asignación de Causas”. Ante la interrupción del proceso de carga, el principio
general es realizar las operaciones necesarias para completar la información de la causa, en
su ingreso y asignación. Bajo ningún concepto se deberá reingresar una causa, sino que se
9
deberán verificar los registros del sistema para constatar si el expediente fue creado y en su
caso qué información resultó registrada en la base de datos. En ningún caso, sin autorización
previa de la Cámara o Tribunal interviniente, la DGT del CMPJN operará sobre el sistema a
fin de agregar, suprimir o modificar información registrada por el usuario. Se establecen
expresamente las acciones a seguir en tres supuestos: inconvenientes durante el ingreso y
asignación de una causa nueva; ingreso doble de una causa e ingresos de demandas de AFIP
en forma masiva (Acordada CSJN 22/17).
2.5.3 Durante las labores de campo se suscribió un acta acuerdo que aprueba el
procedimiento “SISTEMA DE GESTIÓN JUDICIAL – CONTROL DE ACCESO”. En él
se detalla el procedimiento de registro de usuarios para otorgar o revocar el acceso al SGJ y
el proceso de asignación de contraseñas. En este mismo acuerdo se establecen, además,
cuales son las responsabilidades del usuario en el uso de contraseñas. (Acta Acuerdo del
28/04/17 entre la Subadministación General, la Dirección General de Tecnología y la
Dirección General de Seguridad Informática del CMPJN, y la Dirección de Sistemas del
CSJN).
2.5.4 Durante las tareas de campo se aprobaron la Política de Antivirus, la Política para
Grupos Electorales y un Recordatorio sobre medidas de seguridad en el Centro de Cómputos.
3. ACLARACIONES PREVIAS
3.1. El Consejo de la Magistratura del Poder Judicial de la Nación

El sistema de justicia de la República Argentina responde a la forma federal adoptada por la
Nación para su gobierno y está integrado por el Poder Judicial de la Nación, el de cada una
de las provincias y el de la Ciudad Autónoma de Buenos Aires (CN, Artículos 5º y 129).
Existe, por tanto, una justicia nacional y una justicia local, también denominada “ordinaria”
o “común”, que ejerce sus funciones dentro de su territorio a través de sus propios órganos
judiciales y legislación procesal.
10
El Poder Judicial de la Nación es ejercido por la Corte Suprema de Justicia de la Nación

(CSJN) y por los tribunales inferiores que establece el Congreso en el territorio de la Nación
(CN, Artículo 108). Como organizaciones constitucionales auxiliares, también forman parte
de este Poder el Ministerio Público Fiscal, el Ministerio Público de la Defensa, el Jurado de
Enjuiciamiento y el Consejo de la Magistratura, que se tratará luego con mayor detalle (CN,
Artículos 114, 115 y 120).
Además de las atribuciones jurisdiccionales, la Corte Suprema de Justicia de la Nación

detenta atribuciones en materia de reglamentación y superintendencia (CN, Artículo 113,
Acordada CSJN 4/2000).7
La estructura orgánica en la que se reparte la labor judicial tiene directa relación con la
noción de competencia8, que puede clasificarse según los siguientes criterios:9
a) territorial: según la circunscripción asignada por ley a la actividad de cada órgano

judicial, donde se radicarán las causas según distintas reglas establecidas por los
códigos de fondo y procesales (por ej. es juez competente el del lugar donde está
situada la cosa litigiosa cuando se ejercen pretensiones reales sobre bienes
inmuebles);
b) objetivo: define la competencia por razón de la materia (naturaleza de las causas:
civil, comercial, laboral, etc.) y del valor (cuando la pretensión no excede de
determinada suma, aunque sólo subsiste en algunas provincias);
7
En el ámbito de las atribuciones reglamentarias y de superintendencia de la CSJN, el Reglamento para la
Justicia Nacional (Acordada del 17/12/1952 y sus modificatorias) contiene disposiciones acerca del
ordenamiento administrativo, nombramiento y obligaciones de funcionarios y empleados, elección de
autoridades de la Corte y de las Cámaras, etc. Sin perjuicio de ello, la superintendencia directa sobre los
funcionarios y empleados de los tribunales inferiores se encuentra delegada en las Cámaras Nacionales
(Reglamento para la Justicia Nacional, Artículo 118).
8
Entendida como la capacidad que la ley reconoce a un juez o tribunal para ejercer sus funciones con respecto
a una determinada categoría de asuntos o durante una determinada etapa del proceso.
9
Principal bibliografía consultada: Palacio, Lino E.; Manual de Derecho Procesal Civil 21º Edición, Abeledo
Perrot, Ciudad Autónoma de Buenos Aires, 2016.
11
c) funcional o por el grado: según las diversas funciones que deben cumplir los jueces
y tribunales que intervienen en las distintas instancias de un mismo proceso. Esta
clasificación supone la división del proceso judicial en distintas instancias10, que
pueden variar según el fuero11;
d) Según el doble orden judicial establecido en la CN: existe una primera y fundamental
división entre competencia ordinaria y federal. La competencia federal se encuentra
asignada expresamente por la CN y por leyes dictadas por el Congreso en materias
relacionadas a la defensa de intereses públicos de carácter general que custodia el
poder central.12 La competencia de los jueces y tribunales federales se clasifica
también conforme a los criterios expuestos en a), b) y c).
e) Según la calidad o condición de las partes (por ejemplo, embajadores, cónsules, etc.)
o la vecindad o nacionalidad de éstas.
Se expone a continuación y a modo ilustrativo la organización de la Justicia Nacional en los

siguientes fueros: Justicia Nacional en lo Penal Económico, Justicia Nacional en lo Civil y
Comercial Federal, Justicia Nacional en lo Contencioso Administrativo Federal, y Justicia
en lo Criminal y Correccional Federal.
10
En este caso, conjunto de actuaciones practicadas en un proceso judicial hasta la sentencia definitiva. A
modo de ejemplo, el ordenamiento procesal nacional en materia civil, comercial, laboral y contencioso
administrativo se halla estructurado en un sistema de doble instancia donde el conocimiento inicial del proceso
corresponde a órganos unipersonales (juzgados) cuyas resoluciones son susceptibles de recursos ante tribunales
colegiados (cámaras de apelaciones) que revisan la sentencia recurrida y eventualmente la modifican, anulan
o confirman. Este principio admite excepciones cuando por el escaso valor de los montos cuestionados las
sentencias son irrecurribles. Se prevé además un tercer grado de conocimiento (aunque no configura una tercera
instancia) en los supuestos excepcionales de recursos ante la Corte Suprema de Justicia de la Nación. El
régimen es distinto en materia penal, correccional o tribunales y jueces de menores.
11
El término “fuero” puede ser entendido como el lugar del juicio (lugar o sitio donde se administra justicia);
el tribunal a cuya jurisdicción está sometido el reo o demandado, designado como fuero competente; o, el
distrito o territorio donde cada juez debe ejercer su jurisdicción.
12
Las causas de contrabando, ley de marcas, falsificación de moneda, narcotráfico, delitos contra la
administración pública nacional, son de competencia federal, por citar algunos ejemplos.
12
Fuente: Elaboración propia en base a Poder Judicial de la Nación (https://www.pjn.gov.ar/)
El Consejo de la Magistratura (CMPJN) fue incorporado a la Carta Magna como órgano del
Poder Judicial de la Nación por la Reforma Constitucional de 1994 y tiene a su cargo la
13
selección de los magistrados y la administración del Poder Judicial (CN, Artículo 114). Se
encuentra regulado por la Ley 24.937 (t.o. por Decreto 816/1999), reformada parcialmente
por la Ley 26.080 (t.o. por Decreto 207/2006).13 14
En lo que refiere a la Administración del Poder Judicial de la Nación, al CMPJN le

corresponde la administración de los recursos, la ejecución del presupuesto y el dictado de
los reglamentos relacionados con la organización judicial y los necesarios para asegurar la
independencia de los jueces y la eficaz prestación de los servicios de justicia (CN, Art. 114
párrafo tercero).
El CMPJN actúa en sesiones plenarias (Plenario) y a través de Comisiones, una de las cuales,
denominada “Comisión de Administración y Financiera”, tiene a su cargo realizar auditorías,
efectuar el control de legalidad e informar periódicamente sobre ello al Plenario del Consejo,
y fiscalizar la “Oficina de Administración y Financiera del Poder Judicial”15 (Ley 24.937,
Artículo 16, modificada por Ley 26.080). Entre las funciones de esta Oficina se encuentran
las de llevar el registro de estadística e informática judicial, proponer los reglamentos
internos necesarios para su funcionamiento, los reglamentos para la administración
financiera del Poder Judicial y los demás que sean convenientes para lograr la eficaz
administración de los servicios de justicia (Ley 24.937, Artículo 18 incs. “f” y “j”).
13
http://www.consejomagistratura.gov.ar/index.php/features/ique-es-el-consejo. Recuperado el 16/08/2017.
14
Además de la calidad y jerarquía constitucional, el CMPJN se caracteriza por la naturaleza de sus cometidos,
ya que auxilia o sirve al correcto ejercicio y desempeño del órgano-poder al que se incardina, es decir, el Poder
Judicial de la Nación. Así, el CMPJN tiene, entre otras, una competencia fundamental en la selección de los
jueces de las instancias inferiores a la CSJN, y también en la Administración del Poder Judicial. (Barra,
Rodolfo; “El sistema de control externo. La Auditoría General de la Nación”, en Revista Argentina del Régimen
de la Administración Pública Nº 387, 7. Recuperado de:
http://www.revistarap.com.ar/Derecho/administrativo/auditoria_general_de_la_nacion/1adm0018043505000.
html=).
15
A cargo del Administrador General del Poder Judicial (Ley 24.937, Artículo 17), designado por el Plenario
del CMPJN a propuesta de su Presidente (Ley 24.937, Artículo 7º inc. 6, modificada por Ley 26.080) y de un
Subadministrador General.
14
Corresponde señalar que el CMPJN decidió impulsar la reestructuración gradual de las áreas
de Tecnología dependientes de la Oficina de Administración y Financiera del organismo
(Ley 24.937, Art. 18, y Res. CMPJN 145/99). Posteriormente se resolvió crear la Dirección
General de Seguridad Informática en el área de la Oficina de Administración y Financiera;
crear la Dirección de Auditoría Informática dependiente del Cuerpo de Auditores; y
mantener al Subadministrador General a cargo de la supervisión de las Direcciones
Generales de Tecnología y Seguridad Informática hasta la concreción de la totalidad de las
medidas o reformas que resulten o que el Plenario disponga, entre otros aspectos (Resolución
CMPJN 521/2016)16.
Un organigrama de las áreas mencionadas precedentemente se expone a continuación:
16
También se creó la Unidad de Seguimiento y Control, dependiente del Plenario del CMPJN, que tiene a su
cargo el control del desarrollo de la auditoria externa, recibir y resolver sus requerimientos, considerar el
resultado y elevar al Plenario un informe para su consideración y posterior resolución a adoptar. Las misiones
y funciones de la Unidad de Seguimiento y Control fueron aprobadas por Resolución CMPJN 579/2016.
15
Áreas del CMPJN vinculadas al objeto de auditoría
Oficina de Cuerpo de
Administración y Auditores
Financiera
Dir. de Auditoría
Informática
Infraestructura
Fuente: elaboración propia a partir de información pública y datos suministrados por el auditado.
La CSJN y el CMPJN de manera conjunta, deben reglamentar la utilización y disponer la

gradual implementación de los denominados expedientes, documentos y firmas electrónicas,
firmas digitales, comunicaciones electrónicas y domicilios electrónicos constituidos (Ley
26.685, Artículos 1º y 2º).
En ese sentido se estableció que la Dirección de Sistemas de la CSJN y la Dirección General

de Tecnología del CMPJN estén a cargo de la administración del Sistema de Gestión Judicial
(SGJ) y de mantener y garantizar su funcionamiento. Ambas Direcciones deben disponer los
procedimientos para otorgar las cuentas de usuario y administrarlas, deben preservar 1a
integridad y la calidad de la información, informar posibles indisponibilidades del servicio,
guardar un historial de todas 1as actuaciones para dirimir cualquier duda o conflicto; realizar
capacitaciones, brindar apoyo a usuarios internos y externos, etc. (Acordada CSJN 14/2013).
16
Sin perjuicio de ello, la información almacenada en el SGJ, con la totalidad de los

documentos registrados, constituye una base de datos de la CSJN. Ésta ejerce la
administración, control y auditoria de todas las bases de datos que involucren el
cumplimiento de la difusión de sentencias, acordadas y resoluciones administrativas, a través
del Centro de Información Judicial y de la Dirección de Sistemas (Ley 26.856 de Publicación
Íntegra de Acordadas y Resoluciones, y Acordadas CSJN 15/2013 y 24/2013).
Asimismo, la CSJN a través de la Dirección de Sistemas, tiene a su cargo la seguridad

informática de las bases de datos del PJN vinculadas a funciones jurisdiccionales; y la
preservación de la integridad, infraestructura y control del Centro de Datos del PJN
(comprensivo de servidores, equipos de comunicaciones, bases de datos, seguridad
informática y todo otro componente del servicio, sin que esto implique la transferencia de
los mismos) (Acordada CSJN 6/2016).
Existen, por tanto, y de acuerdo a la normativa, competencias compartidas entre la CSJN y

el CMPJN respecto a la administración y reglamentación del SGJ, como así también órganos
–tales como la Dirección de Sistemas de la CSJN y la Dirección General de Tecnología del
CMPJN– con funciones compartidas (por ejemplo, la administración del SGJ, el
otorgamiento de las cuentas de usuario y su administración).
Otras, sin embargo, son competencia exclusiva de la CSJN a través de la Dirección de

Sistemas, como la administración, control, auditoria y seguridad informática de las bases de
datos del PJN.
No obstante, durante las tareas de campo se verificó que la operación del Centro de
Procesamiento de Datos, donde se alojan los servidores del Lex 100 y las bases de datos
asociadas, en la práctica recae sobre la DGT del CMPJN, al igual que la seguridad física y
perimetral.
17
3.2. El Sistema de Gestión Judicial y el proceso de asignación de causas 17

El Sistema de Gestión Judicial, denominado comercialmente “Lex 100”, es un sistema único
e integral que comenzó a implementarse gradualmente a partir de 2012, con una base de
datos que concentra todas las causas de la Justicia Nacional y Federal. El Sistema integra las
instancias desde el inicio, considerando todas las recurrencias u ocurrencias (Cámara de
Apelaciones, Tribunal Oral, Cámara de Casación y Corte); es parametrizable y adaptable a
las necesidades de cada fuero o tipo de proceso (multi-fuero, multi-materia y multi-
instancia); permite clasificar las causas por fuero durante toda la vida del trámite; y tiende a
la integración de todos los intervinientes del servicio (actores internos y externos) para lograr
la conformación del expediente judicial digital (consulta de causas judiciales, notificaciones
electrónicas, ingreso de copias de escritos, etc.).
Entre sus objetivos se encuentran lograr un servicio de administración de justicia eficiente,

eficaz y accesible a la comunidad en general, mediante la implementación de una
infraestructura basada en las tecnologías de la información y las comunicaciones; disminuir
los tiempos de tramitación de las causas, ofrecer mayor transparencia y fiabilidad en la
consulta de causas, estadísticas más confiables, incorporar mecanismos de control, etc.18
La CSJN dispuso el uso obligatorio del SGJ en cada jurisdicción nacional o federal y las
demás dependencias judiciales del PJN, en toda actuación vinculada con la tramitación de
las causas como único medio informático admitido. También estableció los lineamientos
generales de asignación, sin perjuicio de lo cual cada Cámara puede aprobar su propio
Reglamento, adaptando estos principios a las modalidades y necesidades de cada fuero
(Acordada 14/2013).
17
Parte de este apartado se basa en el Informe sobre el Sistema Lex 100 emitido por la Dirección General de
Seguridad Informática del CMPJN, entregado por el organismo en respuesta a la solicitud cursada por Nota
AGN 397/17-P, Anexo 1, punto 1.6.
18
http://www.cij.gov.ar/nota-16613-El-nuevo-software-de-gesti-n-de-expedientes-ya-funciona-en-todo-el-
Poder-Judicial-de-la-Naci-n.html, y de http://old.csjn.gov.ar/data/plan.pdf, recuperado el 26-09-2017.
18
La asignación de una causa en el SGJ requiere de su ingreso previo al sistema. Existen

diversas formas de ingresar una causa según el fuero, por ejemplo, mediante una denuncia
verbal en forma personal, mediante un escrito, o por envío electrónico. En los dos últimos
casos, el ingreso al sistema puede ser tanto inmediato como diferido, sin que el orden de
llegada necesariamente implique el mismo orden para el proceso de asignación o sorteo.
Una vez ingresada la causa al sistema, este contempla la búsqueda de antecedentes, proceso
orientado a identificar causas a priori relacionadas. La búsqueda de antecedentes se orienta
a detectar dobles inicios o causas gemelas (por identidad de partes, identidad de denunciante,
identidad de boleta de deuda, etc.) y procura lograr eficiencia procesal, al identificar
tribunales que hayan entendido en causas relacionadas.
La identificación de antecedentes es de naturaleza meramente informativa y puede concluir

en “conexidad” cuando una causa se asigna al tribunal en el cual se encontraron
antecedentes, y es aceptada por éste. La conexidad también puede ser solicitada por las partes
al momento de la presentación.
El “sorteo” es el proceso conforme al cual se asigna una causa a un juzgado.19 Tiene lugar
en las “mesas de entradas”, “oficina de sorteos” u “oficinas de asignación”, según el fuero
(en adelante se tomará esta última denominación). A partir del objeto del juicio, el operador
selecciona el rubro20 correspondiente y el sistema identifica los juzgados con el mínimo valor
de causas acumuladas para dicho rubro.21 A continuación se excluyen manualmente los
juzgados inhibidos (los que por alguna razón no pueden intervenir en el proceso de
asignación), y se procede al sorteo propiamente dicho. Para efectuar el sorteo, un proceso
19
En el marco de este informe, comprende tribunales, jugados, secretarías, salas, etc.
20
Los rubros son agrupaciones de objetos de juicio o subconjuntos de la competencia de acuerdo al tipo de
proceso, según lo definido por cada Cámara (por ejemplo, son rubros del fuero Civil y Comercial Federal:
incumplimiento de contrato, cese de oposición al registro de marca, etc.).
21
Para cada tribunal y rubro existe un acumulador donde se contabiliza la cantidad de causas asignadas, donde
se compensa o descompensa en función de la asignación de causas u otros eventos.
19
del sistema determina un número entero al azar22 representativo de uno de los juzgados
intervinientes23. Aunque el ingreso de expedientes puede ser masivo, la asignación se realiza
de a una por vez.
El proceso de asignación le suma un guarismo (variable denominada “factor suma”)24 al

acumulado de asignaciones del rubro/juzgado en el cual recayó la causa, lo que da lugar a
nuevos valores mínimos para todo el conjunto.
El sistema tiende así a distribuir la carga de trabajo que debe atender cada juzgado (“…
siendo facultad de cada Cámara Nacional o Federal su acumulación para lograr una
distribución compensada de la carga de trabajo de los Tribunales que las componen”,
Acordada 14/2013, apartado VI) Marco de Funcionamiento, punto 18º). La distribución
compensada implica que para ciertos procesos de asignación y bajo determinadas
circunstancias, el azar no interviene (se sortea un solo juzgado).
A título meramente ilustrativo del proceso de asignación, se presenta a continuación una

tabla con un ejemplo simplificado de acumulado de asignaciones para 3 juzgados que se
supondrán no inhibidos para el proceso de asignación. En t0 el juzgado B es el que tiene el
acumulado mínimo, por lo que bajo ciertas condiciones que se explicarán a continuación, la
asignación de una causa recaerá en él.
Tabla Nº 1: Ejemplo de compensaciones

Acumulado de Asignaciones
t Juzgado A Juzgado B Juzgado C
0 21 20 21
1 21 21 21
2 22 21 21
22
Generado mediante un programa para producir secuencias de números o semilla (número al azar).
23
Como si se extrajera una bolilla al azar de un bolillero conformado por todos los juzgados que pueden
intervenir en ese rubro.
24
El “factor suma” representa el valor a sumar al acumulado de asignaciones por rubro/juzgado. El sistema
admite que, para un determinado sorteo, se le asigne un número mayor a 1 si la complejidad de la causa así lo
amerita.
20
3 22 22 21
4 22 22 22
Fuente: elaboración propia en base a procesos relevados.
Suponiendo ese resultado, y considerando un “factor suma” = 1, la situación en t1 implicará

que todos los juzgados tendrán la mínima cantidad de causas acumuladas, por lo que la
asignación se realizará por sorteo entre los 3. En t2 el sorteo se hará entre los juzgados B y
C, y así sucesivamente.
El sistema permite definir cuál es la mínima cantidad admisible de oficinas a intervenir en

un proceso de asignación (mínima cantidad de bolillas). Cuando el parámetro se encuentra
en “1”, es posible proceder al sorteo aun habiendo un solo juzgado con menor cantidad de
causas acumuladas, tal como en t0 o t3. Si, en cambio, el parámetro fuera un valor superior a
“1”, se incluirá en el proceso de asignación a otros juzgados, por orden creciente de
acumulación de causas, de modo que no pueda sortearse entre uno solo.25
Respecto del fuero Criminal y Correccional Federal, cabe aclarar que adopta el modelo de
mínima cantidad de bolillas = 3 por cada rubro de compensación, entre los juzgados con
menos causas acumuladas de los que se encuentran de turno con Cámara.
Para los casos de valor de mínima cantidad de bolillas superior a “1”, la distribución
compensada reposa sobre la probabilidad de ocurrencia y la ley de los grandes números.
Por cuestiones de conexidad, recusación, excusaciones, cambio de objeto de juicio, etc.

puede re asignarse una causa para derivarse a un juzgado distinto a aquel que fuera sorteado
25
Para seguir con el ejemplo, si el valor de “mínima cantidad de bolillas” = 2, un sorteo a efectuarse en t 0
implicaría la participación de todos los juzgados al requerir tanto de la participación del juzgado que cuenta
con la cantidad acumulada mínima (que es uno sólo), como de los juzgados que le siguen en valor de
acumulación. Al totalizar 3 juzgados elegibles se cumple con la condición de mínima cantidad de bolillas.
21
inicialmente. Esto puede generarse tanto desde las oficinas de asignación como desde los
juzgados, según el fuero.26
3.3. Contexto de TI del objeto de control

El SGJ Lex 100 es una versión personalizada de un producto existente en el mercado, que
fue adquirido junto a los racks y servidores en 2012. Se trata de un sistema integrado con
distintas funcionalidades que pueden habilitarse o no para distintos perfiles de usuario. En
el marco del CMPJN a estas funcionalidades se las denomina “módulos”, uno de ellos es el
denominado “Módulo de Asignación de Causas”.27
Este sistema se encuentra instalado en servidores alojados en el Data Center del CMPJN, en
una sala cofre28 a la que se accede utilizando sistemas de acceso biométricos. Cuenta con
sistemas de control de temperatura y humedad, de detección y extinción de incendios, dos
sistemas de UPS independientes y tres generadores para el caso de cortes de energía
prolongados.
La sala de operaciones se encuentra fuera de la sala cofre y dispone de un videowall que

muestra distintos parámetros del sistema, tales como el uso de recursos o el estado de los
enlaces de comunicaciones.
26
Durante las labores de campo fue aprobado el Protocolo de Actuación ante Incidencias en la Asignación de
Causas en el Sistema de Gestión Judicial, que dispone el procedimiento a seguir por los operadores judiciales
en el SGJ ante contingencias en el funcionamiento del “Módulo de Asignación de Causas”. Ante la interrupción
del proceso de carga, el principio general es realizar las operaciones necesarias para completar la información
de la causa, en su ingreso y asignación. Bajo ningún concepto se deberá reingresar una causa, sino que se
deberán verificar los registros del sistema para constatar si el expediente fue creado y en su caso qué
información resultó registrada en la base de datos. En ningún caso, sin autorización previa de la Cámara o
Tribunal interviniente, la DGT del CMPJN operará sobre el sistema a fin de agregar, suprimir o modificar
información registrada por el usuario. Se establecen expresamente las acciones a seguir en tres supuestos:
inconvenientes durante el ingreso y asignación de una causa nueva; ingreso doble de una causa e ingresos de
demandas de AFIP en forma masiva (Acordada CSJN 22/17).
27
También denominado “Módulo de Sorteo de Causas”. En el marco de este informe se utiliza la expresión
“funcionalidad de asignación de causas” toda vez que resulte posible, por ser técnicamente más preciso.
28
Data Center aislado y construido para proteger el equipamiento de TI frente a desastres como incendios o
inundaciones.
22
El sistema está instalado bajo un esquema en el que múltiples copias del aplicativo servidor
se ejecutan en paralelo29 en una granja30 de 17 servidores físicos idénticos sin
virtualización.31 Cada uno de ellos cuenta con 256 a 384 GB de memoria RAM, ejecuta entre
4 y 6 instancias y corre una copia exacta de la aplicación. Según lo manifestado por el
auditado, la carga promedio de los servidores es del 50%.
Dado que los datos administrados por el CMPJN son principalmente archivos digitalizados,
estos no se encuentran cargados en una base de datos relacional, sino en un sistema de
archivos distribuidos gestionados por medio del sistema NFS (Network File System). Para
ello cuenta con tres equipos de storage (almacenamiento) de marca HP. Por esta razón y por
la alta disponibilidad provista por estas soluciones, el auditado considera innecesario realizar
copias de resguardo. El control del sistema NFS es realizado por un servidor dedicado
específicamente a esta tarea.
Para la comunicación con los usuarios, cada sitio (juzgados, oficinas dependientes del PJN,
etc.) se encuentra conectado por una red privada, y cada fuero se encuentra aislado de las
comunicaciones de otros mediante la configuración de redes lógicas independientes dentro
de una misma red física (VLAN).
4. COMENTARIOS Y OBSERVACIONES
4.1. Procedimientos Técnicos
4.1.1. La Dirección General de Tecnología no cuenta con un Plan Estratégico de

Tecnologías de la Información actualizado que permita definir la arquitectura de los
sistemas de información del organismo, lo que podría acarrear ineficiencias por
duplicación de esfuerzos o fallos de los sistemas al recurrirse a soluciones no integradas.
29
Múltiples instancias JBoss.
30
Grupo de servidores conectados entre sí que logran gran capacidad de procesamiento.
31
La virtualización habilita escalabilidad, disponibilidad y una mejor distribución de recursos de hardware.
23
Entre la información entregada por la Dirección General de Tecnología obran los planes
estratégicos, proyectos de informatización y previsiones presupuestarias generados en 2003,
2005, 2007, 2008, 2009 y 2015. Los documentos analizados no definen criterios para
modelar una arquitectura única de los sistemas de información, ni cuentan con un plan
estratégico de TI actualizado. La última versión completa corresponde a 2009 y se denomina
“Proyecto de Informatización Global del Poder Judicial de la Nación. Diagnóstico y estado
de Avance”.
Ante la ausencia de Planificación Estratégica de TI, y a medida que al SGJ se le agregan

funcionalidades o modificaciones, aumenta el riesgo que estos desarrollos provoquen fallos,
interrupciones no deseadas o bajas de rendimiento.
La Metodología de Planeación Estratégica de Tecnología de Información (PETI) está

concebida como la implantación de un modelo conceptual de planeación dinámico, que
integra las visiones estratégicas organizacionales con la visión estratégica de TI, en una
visión única final que a su vez permite definir un esquema o arquitectura estructural para los
sistemas de información de la organización.
4.1.2. No existe un Consejo de Arquitectura de Tecnología de la Información que

proporcione directrices sobre la arquitectura de TI y asesore sobre su aplicación en función
de las necesidades y objetivos estratégicos de la organización, lo que implica no contar con
una visión estratégica integral sobre el desarrollo de los sistemas de información críticos,
incluido el SGJ.
De las reuniones mantenidas con las distintas áreas de la Dirección General de Tecnología,
y a partir del análisis de la documentación recibida, se detectó que el organismo no cuenta
con un Consejo o Comité que defina y mantenga actualizada la arquitectura de las
tecnologías de la información que dan servicio a los procesos críticos de la organización. Si
bien la Resolución CMPJN 521/2016 prevé la creación de una Unidad de Seguimiento y
24
Control dependiente del Plenario, que de acuerdo a lo manifestado por el auditado debería
cumplir esas funciones, al cierre del período auditado dicha Unidad no se había reunido.
Las mejores prácticas orientadas al gobierno de las tecnologías de la información (COBIT e

ITIL) indican que la gestión de la arquitectura de TI tiene relevancia estratégica para la
organización pues las acciones del área de tecnología, en coordinación con la alta dirección,
permiten movilizar sus recursos de forma más eficiente para dar respuesta a los requisitos
legales, regulatorios, operativos o de reglas de negocio.
La coordinación entre el área de TI y la alta dirección para definir la arquitectura de TI,

determina el conjunto de elementos organizacionales (objetivos estratégicos, departamentos,
procesos, tecnología, personal, etc.) que describen a la organización y se relacionan entre sí,
y de este modo se garantiza la alineación desde los niveles más altos (estratégicos) hasta los
más bajos (operativos), con el fin de optimizar la generación de productos y servicios de TI
que conforman la propuesta de valor entregada a los clientes internos y externos.
La inexistencia de un Consejo/Comité de Arquitectura de Tecnología de la Información

implica no contar con un programa para el desarrollo presente y futuro del panorama
tecnológico de sistemas de información críticos, en este caso el SGJ, tomando en
consideración la estrategia del servicio a dispensar y las nuevas tecnologías disponibles que
puedan generar valor a la organización en función de sus objetivos. La necesidad de contar
con un órgano decisorio de tales características se acrecienta en organismos cuyas
definiciones se encuentran descentralizadas, como en el caso objeto de auditoría.
4.1.3. No se aplica un marco metodológico para la gestión de proyectos de TI en cartera de

la Dirección General de Tecnología. Esta circunstancia dificulta el seguimiento, control y
medición de los avances, la calidad y la efectividad de los entregables en cada etapa de los
proyectos.
25
Se ha constatado que la DGT recurre a planillas de cálculo para llevar el inventario de

proyectos y que no aplica un enfoque metodológico que permita verificar la formalización
de sus etapas ni los plazos de entrega, esquemas de validación/aceptación de entregables32,
seguimiento, control o medición de la productividad de los equipos involucrados en los
proyectos de TI.
Según lo indicado por las buenas prácticas (PMBOK, ITIL, COBIT, entre otros), la gestión
de proyectos es un enfoque metódico que permite planificar y orientar los procesos del
proyecto de principio a fin (iniciación, planificación, ejecución, control y cierre) y con altos
niveles de eficiencia. Lo anterior es aplicable a casi cualquier tipo de proyecto y es
ampliamente utilizado para controlar los complejos procesos de desarrollo de software.
La gestión y seguimiento de múltiples proyectos sin un marco metodológico concreto que

vele por el cumplimiento en tiempo y forma de los proyectos críticos planificados y
asignados a cada área de servicio, conlleva el riesgo de que éstos se tornen indefinidos en
sus plazos, que se pierda el control sobre su ciclo de vida, y que resulte poco efectivo para
la organización al momento de implementar los entregables.
4.1.4. El área de Organización y Sistemas no cuenta con procedimientos normalizados e

integrales de gestión de configuraciones y control de cambios, que permitan llevar un
adecuado registro de las modificaciones y nuevas versiones del SGJ, lo que puede derivar
en inconsistencias en los sistemas desarrollados y pérdidas de eficiencia para la
organización.
Los procesos de desarrollo y mantenimiento del SGJ (configuraciones de los activos de TI,
cambios y mejoras sobre el sistema) se gestionan en el área de Organización y Sistemas
dependiente de la Dirección General de Tecnología. El área recibe las solicitudes de los
interesados para realizar cambios en el sistema a través de múltiples vías, como notas
32
De las entrevistas realizadas con usuarios del sistema surge que la aceptación final de los desarrollos
solicitados es en ocasiones otorgada verbalmente.
26
formales (para el caso de solicitudes originadas en Acordadas de la CSJN u oficios judiciales

librados por los juzgados), correos electrónicos, e incluso por vía telefónica o presencial. La
existencia de canales múltiples aumenta el riesgo de brindar un servicio inadecuado y perder
la trazabilidad de los cambios realizados en el SGJ en un contexto en el que, tal como se
detalla a continuación, el marco metodológico para la gestión de cambios no abarca la
totalidad del proceso.
De acuerdo a las buenas prácticas en la materia (CMMI e ITIL) el ciclo de vida de gestión
de cambios en los sistemas comprende las siguientes etapas: i) identificación del
requerimiento, ii) evaluación y aprobación del requerimiento por parte del comité
competente, iii) intervención de los desarrolladores para la construcción del cambio dentro
de un ámbito de control de versiones, iv) pruebas de calidad, v) auditoría de configuración,
vi) informe de estado, vii) validación y aceptación del interesado, e viii) implementación. El
equipo de desarrollo de sistemas cuenta con un marco metodológico y una aplicación para
administrar el control de los cambios, lo que comprende exclusivamente la etapa “iii”.
En consecuencia, la DGT no cuenta con un esquema de gestión de las configuraciones y de

cambios integral para todo el ciclo de vida del desarrollo y los actores intervinientes, por lo
que el marco metodológico aplicado y las herramientas utilizadas resultan insuficientes para
una correcta administración de los cambios correctivos, adaptativos y evolutivos que se
aplican en las versiones del sistema de información que soporta el proceso crítico. En ese
orden, de acuerdo a lo manifestado por los usuarios entrevistados, se verifican demoras
significativas hasta la implementación de los desarrollos requeridos sobre el SGJ.
El adecuado registro de configuraciones y cambios contribuye a eliminar problemas de alto

costo para el proyecto, asegurar que no existan inconsistencias en el sistema desarrollado y
evitar demoras en los tiempos de desarrollo. Los eventuales conflictos pueden originarse en
actualizaciones simultáneas (cuando varios integrantes del equipo trabajan sobre un mismo
elemento al mismo tiempo), notificación de cambios (cuando un problema fue resuelto, pero
alguno de los desarrolladores no fue notificado), múltiples versiones, etc.
27
De acuerdo a lo establecido por las mejores prácticas para el desarrollo de software arriba
mencionadas, la gestión de las configuraciones y el control de cambios son esenciales para
lograr un efectivo control orientado a garantizar niveles aceptables de calidad sobre todos
los productos generados por el área de Organización y Sistemas.
4.1.5. La Dirección General de Tecnología no cuenta con un diccionario de datos para el

organismo. Su ausencia genera el riesgo de producir ambigüedades, interpretaciones
incorrectas, o inconsistencia en los flujos de datos, sus relacionamientos y estructuración.
A partir del análisis de la documentación recibida y de los relevamientos realizados en la

Dirección General de Tecnología se ha podido comprobar que no administra un diccionario
de datos que abarque a todo el CMPJN.
Las mejores prácticas orientadas a la gestión de TI sugieren la administración de un

diccionario de datos actualizado sobre los sistemas de información que dan soporte a la
operación de los procesos críticos de la organización. Estos diccionarios permiten indicar
cómo están organizados, estructurados, cuál es el significado, la relación, origen, formato y
uso de los datos. Entre otras funcionalidades, el diccionario de datos es una herramienta
clave para ser utilizada durante los distintos procesos del ciclo de vida del desarrollo de un
sistema de información, por ejemplo, al brindar soporte al equipo de analistas y usuarios
claves que participan en la determinación de requerimientos funcionales del sistema.
Su ausencia conlleva el riesgo de producirse ambigüedades, interpretaciones erróneas,

inconsistencia en los flujos de datos, sus relacionamientos y estructuración, y en la
posibilidad de formular estadísticas desagregadas y útiles.
4.1.6. Durante el periodo auditado la Dirección General de Tecnología no estaba sometida

a mecanismos de control interno suficientes, con la consecuente dificultad para la
identificación de riesgos y su correspondiente mitigación.
28
Para el período auditado no se encontró evidencia de la existencia de un efectivo control

sobre las políticas, procedimientos y procesos llevados a cabo por la Dirección General de
Tecnología ni sobre los servicios de TI prestados por las áreas internas de dicha dirección,
como tampoco por los servicios prestados por proveedores externos. La falta de control
interno adecuado expone a la Dirección General de Tecnología a riesgos no detectados, y
por lo tanto no mitigados.
Se deja constancia que desde el 27 de septiembre de 2016 se encuentra creada la Dirección

General de Seguridad Informática en el área de la Oficina de Administración y Financiera,
y la Dirección de Auditoría Informática bajo la dependencia funcional y jerárquica del
Cuerpo de Auditores, con facultades de control sobre la actuación de todas las dependencias
que tengan “contenido, efecto, fin o vinculación directa o indirecta con sistemas
informáticos, entornos virtuales, comunicaciones y cualquier otro elemento (…)”.
(Resolución CMPJN 521/16, Considerando 13 y Art. 1º y 3º). Ambas Direcciones tienen
funciones de control.
4.1.7. No existe un plan formalizado y aprobado por las máximas autoridades del CMPJN
para el mantenimiento de la infraestructura que soporta y da servicio al SGJ, lo que pone
en riesgo la confiabilidad y disponibilidad de la información.
Se ha detectado que no existe un plan formalizado para el mantenimiento de la

infraestructura que soporta al SGJ. Además, no se gestionan los servicios brindados por
proveedores externos bajo una mirada estratégica integral (véase al respecto observación
4.1.2., que refiere a la carencia de un Comité o Comisión de Arquitectura de TI), sino de
manera aislada, lo que conlleva el riesgo de incurrir en errores u omisiones al momento
29
de confeccionar los pliegos de licitación (por ejemplo, para la definición de los acuerdos de
niveles de servicio de los proveedores33 o su monitoreo).
De acuerdo a las mejores prácticas en el ámbito de TI recomendadas por COBIT e ITIL

específicamente en lo que refiere a Infraestructura Tecnológica, una adecuada planificación
basada en normativa aprobada por la alta dirección permite asegurar con mayor rigurosidad
la disponibilidad de los servicios soportados, obtener una mayor confiabilidad a la hora de
estandarizar servicios y disminuir la tasa de anomalías en la infraestructura.
La inadecuada planificación y ejecución, como así también la falta de control, aumentan el

riesgo de interrupciones de servicio no previstas, con la consecuente falta de confiabilidad
que podría generar en los servicios de TI que dan soporte a la operación crítica de la
organización.
4.1.8. En los entornos dispuestos para las pruebas de desarrollo y para el servicio de soporte
de primer nivel/capacitación, no se enmascara la información de la base de datos del SGJ,
lo que permite el acceso a información sensible por parte de personal no autorizado.
La base de datos del SGJ utilizada para testing y para el servicio de soporte de primer
nivel/capacitación es una copia íntegra de la base de datos del entorno de producción, a la
que no se le aplican procesos de enmascaramiento de la información. En ese marco, se pudo
comprobar que los agentes que trabajan en el equipo de desarrollo, los analistas funcionales
y el equipo que brinda servicio de soporte de primer nivel/capacitación, tienen acceso a
información sensible del Sistema de Gestión Judicial (actores, montos, objeto, entre otros).
Las buenas prácticas y procedimientos para la administración de entornos de prueba y

soporte contemplan la aplicación de procesos de enmascaramiento de la información crítica
33
Los acuerdos de niveles de servicio (o SLA, por sus siglas en inglés), son los acuerdos contractuales entre
una empresa de servicios y su cliente, donde se define, fundamentalmente, el servicio y los compromisos de
calidad que debe cumplir el proveedor.
30
al momento de desplegar la base de datos de los sistemas de información en entornos no

productivos, a fin de velar por la confidencialidad de la información organizacional.
4.1.9. El área de Operaciones de la Dirección General de Tecnología no cuenta con un

sistema de seguimiento de pedidos de soporte, lo que limita la calidad del mantenimiento
del SGJ.
El área de Operaciones de la Dirección General de Tecnología, realiza tareas de soporte al

usuario sobre el SGJ. Cuando los usuarios se encuentran con un inconveniente o deben
realizar alguna consulta al soporte técnico, lo registran en el Portal de Ayuda, Cursos y
Evaluaciones –PACE–, o bien recurren a correos electrónicos o llamados telefónicos
cursados al área a cargo de este servicio (sobre las debilidades de la multiplicidad de canales,
véase observación 4.1.4).
Algunos de estos pedidos de asistencia se registran, pero los medios utilizados para ello son
limitados (planillas de cálculo), lo que dificulta el seguimiento integral, limita la realización
de análisis históricos sobre problemas frecuentes y reduce la eficiencia de la tarea de
mantenimiento. Al respecto, los usuarios entrevistados manifiestan que se verifican demoras
en los tiempos de respuesta ante pedidos de soporte informático.
Tal y como indican las buenas prácticas, cada pedido de soporte debería registrarse en un
sistema que permita identificar en forma unívoca cada solicitud, tanto para hacer un
seguimiento del estado de los pendientes, como para servir de base de conocimiento de modo
de acelerar la tarea de los agentes, o bien para realizar análisis históricos. Podría incluso ser
abierta al usuario con el fin de disminuir la cantidad de contactos entrantes (llamadas y
correos electrónicos) al permitirles conocer el estado de los pedidos activos o acceder a
soluciones frecuentes.
La carencia de un sistema de registros de pedidos de soporte acorde con las buenas prácticas
conlleva el riesgo de que los inconvenientes de algunos usuarios no sean resueltos, o no se
31
les brinde la prioridad adecuada. Asimismo, imposibilita o dificulta la distribución correcta

de las tareas entre los agentes, e impide la identificación de problemas recurrentes a los fines
de brindar soluciones más eficientes.
4.1.10. Los procedimientos de gestión de incidencias y de problemas vinculados al SGJ son

inadecuados para adoptar acciones correctivas que mejoren la calidad de los aplicativos y
disminuyan los errores o falencias del software, lo que conduce a la falta de confiabilidad
sobre las herramientas informáticas que dan soporte a la operación de la organización.
En lo que respecta al tratamiento de las incidencias y problemas que se presentan en el SGJ,

se ha detectado que las anomalías informadas por los usuarios son registradas por personal
que realiza tareas de soporte, en una planilla de cálculo que ellos mismos controlan
diariamente para informarse de los errores detectados.
Si bien estos procedimientos permiten la adopción de las acciones correctivas necesarias

(dándole una solución de primer nivel o elevándolo a las áreas funcionales o de desarrollo
competentes), resultan insuficientes para llevar un adecuado historial de incidentes que
permita analizar y adoptar acciones correctivas de mayor impacto orientadas a mejorar la
calidad de los aplicativos y a disminuir los errores o falencias del software. De acuerdo a lo
manifestado por los usuarios entrevistados, el sistema sale de servicio por tareas
programadas de mantenimiento, pero también de forma intempestiva, siendo variable el
tiempo medido en horas hasta su restablecimiento.
De acuerdo a las mejores prácticas en el ámbito del ciclo de vida del desarrollo de software,
orientadas a la gestión de incidencias y problemas (CMMI e ITIL), una adecuada
administración y documentación del ciclo de vida de las anomalías que se presentan en los
sistemas aplicativos permite responder con mayor celeridad para brindar una solución,
obtener una mejor calidad en los resultados de la solución, y disminuir considerablemente la
tasa de anomalías en los sistemas. A partir de una base de conocimientos normalizada se
32
pueden planificar soluciones estructurales más sólidas que aseguren la estabilidad de los
servicios brindados por los sistemas de información.
La inadecuada gestión de incidencias y de problemas deriva en un servicio de TI deficitario

e inestable, que conduce necesariamente a la carencia de confiabilidad sobre las herramientas
informáticas que soportan la operación de la organización.
4.1.11. El área de Operaciones de la Dirección General de Tecnología no cuenta con un

entorno del SGJ con la última versión en producción. Los desfasajes entre las versiones
disponibles del SGJ entre este área y los usuarios, deriva en significativas limitaciones y
debilidades del servicio de soporte de primer nivel y capacitación.
El área de Operaciones dependiente de la Dirección General de Tecnología brinda el soporte

de primer nivel/capacitación a usuarios. Para ello recurre a un entorno del SGJ dispuesto
para la prestación de los servicios. Se ha comprobado que en dicho entorno se recurre a una
versión del SGJ que difiere de la versión en producción. También se ha verificado que las
modificaciones o nuevas funcionalidades que impactan sobre el SGJ a nivel adaptativo,
evolutivo o correctivo que no hayan sido tratadas por el área de capacitación, no son
comunicadas desde el área de Desarrollo dependiente de la misma Dirección. En efecto, el
equipo de soporte del área de Operaciones toma conocimiento de la existencia de
modificaciones o nuevas funcionalidades en el sistema a partir de las consultas e incidencias
reportadas por los usuarios.
Los desfasajes de versiones entre el entorno de producción y de soporte/capacitación, y las

deficiencias de comunicación entre las áreas de Operaciones y Desarrollo, exponen
significativas limitaciones y debilidades del servicio de primer nivel y de capacitación ante
el universo de usuarios del organismo.
33
4.1.12. El área de Organización y Sistemas de la Dirección General de Tecnología no cuenta

con un catálogo formal de especificaciones funcionales34 definidas para el SGJ, lo que
dificulta la adecuada gestión de los requerimientos funcionales (solicitudes de
modificaciones correctivas y evolutivas al sistema) y el uso eficiente de los recursos.
Se ha constatado que en el marco de los procesos asociados al mantenimiento evolutivo del

SGJ, no existe un catálogo de especificaciones que respalde los alcances funcionales puestos
en producción y a disposición de la organización. En el mismo sentido, tampoco se cuenta
con un manual de usuarios para el SGJ.
En la administración del ciclo de vida del desarrollo de software existe un proceso llamado
gestión de demandas que surge de las mejores prácticas de mercado (ITIL, CMMI, etc.).
Este proceso permite entender y administrar la demanda del usuario e implementar los
servicios de modo de satisfacer sus necesidades. Adicionalmente, permite documentar la
demanda y llevar un control por ambas partes (desarrollo y usuarios) de las funcionalidades
puestas en producción.
Un catálogo de especificaciones funcionales actualizado es una herramienta de apoyo al

momento de evaluar los niveles de alcance operacionales de los sistemas de información
puestos al servicio de los usuarios. Una gestión de la demanda inadecuada, por el contrario,
conduce a un uso indebido (infra o sobredimensionado) de los servicios y recursos
tecnológicos. Además, se pierde el control organizacional sobre los requerimientos faltantes
y sobre los alcances, origen y trazabilidad de las funcionalidades puestas en producción.
4.1.13. El equipo de desarrollo del CMPJN concentra funciones que deberían estar
segregadas en áreas diferentes, lo que debilita el proceso de control de calidad del sistema
y compromete la confidencialidad de la información.
34
Conjunto de funciones esperadas del sistema.
34
Se ha detectado que no existe un área de control de calidad a cargo de evaluar las versiones
del SGJ a ser puestas en producción. Por el contrario, es el propio equipo de desarrollo del
área de Organización y Sistemas, dependiente de la Dirección General de Sistemas, el que
tiene a su cargo el control de calidad de las versiones a ser implementadas. Esto vulnera el
principio de control por oposición de intereses. El mismo equipo, además, detenta la
responsabilidad de pasar a producción las nuevas versiones a implementar. De acuerdo a lo
manifestado por usuarios entrevistados, la implementación de los requerimientos efectuados
suele adolecer de problemas hasta su puesta a punto definitiva.
Las buenas prácticas referidas a la gestión del ciclo de vida del desarrollo de software
(CMMI) proponen la implementación de una adecuada segregación de funciones. Entre
ellas, sugiere que el equipo de desarrolladores no tenga a cargo la puesta en producción de
las versiones generadas a tal fin, sino que sea el área de operaciones la responsable de estas
actividades, segregación que debe estar acompañada por una fluida interacción entre ambos
equipos para nutrirse recíprocamente de herramientas, técnicas y procedimientos que
optimicen los procesos de puesta en producción de los aplicativos.
Las buenas prácticas también sugieren contar con un área independiente del equipo de
desarrollo que realice el control de calidad de las versiones a ser puestas en producción. El
objetivo consiste en identificar los defectos antes de que se ejecuten y, de forma proactiva,
tomar decisiones sobre las actividades necesarias para mejorar las condiciones del software
de modo de ofertar un producto que satisfaga las necesidades de los interesados.
La circunstancia de que el equipo de desarrolladores tenga a cargo la puesta en producción

de las versiones a implementar, sumado a la falta de una función de control de calidad
independiente, compromete la confidencialidad de los datos de producción y debilita el
control y la calidad de los desarrollos generados. El modelo de administración de ambientes
separados de desarrollo, testing y producción es esencial para proveer los controles y el
balance necesario para ejecutar en forma eficiente un entorno de producción de alta
disponibilidad.
35
4.1.14. El CMPJN no realiza copias de respaldo de los archivos documentales alojados en

los dispositivos específicos de almacenamiento (storage), ni se cuenta con políticas y
procedimientos formalizados de resguardo y restauración, con el riesgo de afrontar altos
costos de recuperación de información en caso de pérdida por eventos catastróficos.
La CSJN estableció que “la información almacenada en el Sistema Informático de Gestión

Judicial, con la totalidad de los documentos registrados, constituye una base de datos de la
Corte Suprema de Justicia de la Nación (conf. anexo de la acordada 24/2013)” (Acordada
CSJN 6/16, Considerando 4º).
Los datos que son administrados por el CMPJN son esencialmente archivos digitalizados
(documentos que componen un expediente judicial), por lo que no se encuentran cargados
en una base de datos relacional, sino en un sistema de gestión de archivos (NFS) integrado
por 3 equipos de Storage. Según lo manifestado por el auditado, la alta disponibilidad
provista por estas soluciones no amerita la realización de backups.
Si bien existe una “Política de resguardo de información de Servidores Centrales” de 2010

y una “Directiva de Resguardo de la Información en Servidores del PJN” de 2012, ambos
documentos se encuentran desactualizados y no hacen referencia específica al SGJ.
De acuerdo a lo establecido por las mejores prácticas para la seguridad de la información

(COBIT, ISO/IEC 27001 y NIST), deben establecerse procedimientos que protejan a las
organizaciones contra la pérdida de información, de forma de asegurar su disponibilidad ante
cualquier incidente que se produzca (véase observación siguiente). Para ello se establece la
creación y prueba regular de copias de seguridad que involucren a la información, software
e imágenes de sistemas.
36
4.1.15. El Consejo de la Magistratura del Poder Judicial de la Nación no cuenta con un

Plan de Contingencia ni DRP (plan de recuperación de desastres) aprobado. Estas
circunstancias ponen en riesgo la continuidad del servicio de TI.
El CMPJN no posee un plan que asegure la continuidad del servicio ante incidentes o
desastres ocurridos en el centro de procesamiento de datos. Si bien la infraestructura
informática se encuentra dimensionada correctamente e incluso contiene redundancia dentro
del mismo Data Center, se encuentra instalada solamente en el Data Center del CMPJN, sin
redundancia geográfica (no existe un sitio alternativo) que asegure la continuidad del
servicio en caso de suceder algún evento que impida operar ese Data Center. Por otra parte,
se observó que no existe redundancia de los enlaces MPLS35 que aseguren la continuidad de
las comunicaciones entre los distintos tribunales, juzgados y secretarías del país, y el Centro
de Procesamiento de Datos donde se aloja y corre el SGJ.
Además, esta auditoría no pudo constatar la existencia de una matriz de riesgo, ni la de un

catálogo de servicios de TI formal y específicamente asociado al SGJ.
Frente a la posibilidad de que ocurran eventos que puedan dejar fuera de servicio a los
sistemas, las organizaciones deben contar con un plan de recuperación de desastres (DRP),
que especifique los pasos a seguir para asegurar la continuidad del servicio. Los planes deben
ponerse a prueba con cierta regularidad para que, ocurrido el hecho, las funciones estén
automatizadas y aprendidas por los responsables y las áreas interesadas. La falta de DRP con
sus respectivos procedimientos y planes de prueba, y la falta de un sitio alternativo ponen en
riesgo la continuidad del servicio.
Las mejores prácticas en materia de continuidad de servicio (COBIT), establecen la

necesidad de detallar específicamente los procedimientos de restablecimiento de servicio
35
Los enlaces MPLS (Multiprotocol Label Switching) son uno de los varios tipos de enlace utilizados por el
organismo. En particular, estos se utilizan para canalizar tráfico con algunos juzgados del interior del país.
37
ante una eventualidad, incluyendo responsables asignados y tiempo de ejecución estimado

por cada tarea.
4.1.16. La administración de la infraestructura de seguridad presenta deficiencias que

podrían comprometer la protección perimetral del organismo, afectando la confiabilidad y
confidencialidad de los datos, y la disponibilidad del SGJ.
La infraestructura de protección perimetral del organismo es robusta. Al mismo tiempo, su

administración no está definida por procedimientos formales, lo que redunda en que existan
configuraciones que eventualmente pueden permitir operaciones distintas de las
estrictamente necesarias. Por ejemplo, se detectaron vulnerabilidades (puertos abiertos en
los firewalls sin que existan servicios o aplicaciones activas que los utilicen) que podrían
explotarse para el establecimiento de una “puerta trasera” permanente (acceso oculto
persistente). Además, se observó que los filtros web permiten el acceso a sitios inseguros o
lúdicos que podrían implantar software malicioso y se encuentra habilitado el acceso
remoto36 desde toda la red interna a los servidores del SGJ, lo que demuestra ausencia de
control por listas de acceso37. Por su parte, las reglas de control de seguridad no se encuentran
documentadas (algunas están justificadas por oficios o por correos electrónicos), y no existen
procedimientos de revisión periódicos. No existe una política integral de seguridad de la
información formalmente revisada y aprobada por el Plenario del CMPJN.
Cabe aclarar que el 27 septiembre de 2016 se creó la Dirección General de Seguridad

Informática en el área de la Oficina de Administración y Financiera (Res. CMPJN 521/16,
art. 1º).
Las mejores prácticas de seguridad de la información establecen que sólo debe permitirse
acceso a los servicios mínimos indispensables para la realización de las tareas del organismo,
36
Específicamente referido al protocolo SSH (Secure Shell).
37
Técnicamente, ACL (Access Control List), práctica que permitiría limitar o filtrar el uso de ese recurso a un
usuario en particular.
38
limitando estos servicios y accesos sólo al personal que realiza las respectivas tareas,
debiendo estar correctamente documentados y revisados mediante procedimientos
periódicos.
Existe una gran cantidad de riegos vinculados a una inadecuada administración de los
dispositivos de protección perimetral, que principalmente afectan a la confiabilidad y
confidencialidad de los datos, y ponen en riesgo la disponibilidad del sistema.
4.4.17. El Consejo de la Magistratura no cuenta de una “Política de Seguridad”

formalizada que se aplique a la totalidad de los sistemas del organismo.
De acuerdo a la información suministrada por la Dirección General de Seguridad

Informática, si bien existen directivas de seguridad informática que se aplican a
determinados aspectos y procedimientos de la gestión de TI, no se encuentra formalizada
una política de seguridad aprobada que abarque la totalidad de los sistemas del CMPJN,
incluído el SGJ.
Las mejores prácticas y la normativa existente en materia de seguridad de la información

(COBIT, ISO 27000) recomiendan la aprobación de un Manual de Políticas de Seguridad de
la Información que cubra toda la gestión de TI.
La falta de una Política de Seguridad de la Información impide que el CMPJN asegure la

integridad, confidencialidad y disponibilidad de la información utilizada por el SGJ.
4.2. Módulo de Asignación de Causas38
38
En este apartado se exponen las observaciones sobre la funcionalidad de asignación de causas y aquellas
que, originadas en el análisis de la gestión de TI, impactan directamente sobre el SGJ y la funcionalidad
mencionada.
39
4.2.1. No existe documentación formalizada respecto de los perfiles de usuarios y sus

permisos sobre el SGJ, al mismo tiempo que la administración de cuentas de usuarios
presenta debilidades significativas que atentan contra la seguridad, confidencialidad e
integridad de la información del sistema.
Los perfiles a cargo de la administración de las cuentas de usuarios del SGJ se encuentran
replicados (perfiles espejos, con las mismas responsabilidades y funciones) en el ámbito del
CMPJN y la CSJN. El esquema definido normativamente establece que la Dirección de
Sistemas de la CSJN y la Dirección General de Tecnología del CMPJN administren las
cuentas de usuario para el acceso al sistema. (Acordada 14/2013, Apartado III)
Administración del Sistema, punto 9º).
Al mismo tiempo, se ha verificado que el proceso de administración de cuentas y el módulo

de gestión de usuarios39 presentan significativas debilidades:
• El procedimiento para solicitar un alta de usuario consiste en el envío de un mail

genérico de los juzgados –en vez de recurrirse a la utilización de un formulario
estándar aprobado–, y la identidad del beneficiario no es validada exhaustivamente.
• La asignación inicial de contraseñas o su blanqueo es realizada en forma manual por
los administradores del módulo, lo que eventualmente permite asumir el perfil de
cualquiera de los usuarios y operar en su nombre sin ser detectados.
• El módulo de gestión de usuarios carece de pistas de auditoría que registren las
acciones realizadas por los administradores. Esto permite, por ejemplo, crear un
usuario o modificar una contraseña, sin dejar rastro de ello.
• No se aplican políticas de contraseña segura (como el uso obligatorio de una
combinación de mayúsculas, minúsculas, números y símbolos), lo que las hace
vulnerables a ataques de fuerza bruta.40
39
Programa complementario al SGJ, específico para administrar cuentas de usuario, denominado “Expand
Security”.
40
Método de evaluación automatizado de todas las combinaciones posibles para encontrar la correcta.
40
• No existe un adecuado control de reutilización de contraseñas (sólo se almacena la

última).
• El módulo de gestión de usuarios permite eliminar cuentas. Una vez eliminadas, no
queda registro de su actividad en el sistema.
Las buenas prácticas de TI indican que se debe contar con un procedimiento de gestión de
usuarios revisado y aprobado por la alta dirección, que debe ser administrado por el Área de
Seguridad de la Información del Organismo, para procurar asegurar la transparencia y
confiabilidad del proceso. Es esencial para una organización que los criterios y
responsabilidades relativos a la administración y controles de acceso a los recursos
informáticos se encuentren unificados.
Dado el contexto descripto y sus debilidades, la existencia de políticas y procedimientos

distribuidos con participación de diferentes actores a cargo de la administración de accesos
constituye un escenario de alta vulnerabilidad al momento de garantizar la confidencialidad
y seguridad de la información crítica. La ausencia de condiciones para asegurar una correcta
administración de usuarios permite la eventual realización de acciones maliciosas sobre el
Sistema de Gestión Judicial sin dejar rastros o dejando pistas inciertas. Asimismo, la falta
de documentación y definición formal de perfiles de usuarios acarrea un riesgo considerable
para la administración y seguridad de usuarios, y deja abiertas innumerables posibilidades
de errores o actividades maliciosas, como la fuga de información crítica o la manipulación
de procesos.
Sin perjuicio de lo anterior, distintas áreas del CMPJN y de la CSJN suscribieron un acta
acuerdo sobre el procedimiento: “SISTEMA DE GESTIÓN JUDICIAL – CONTROL DE
ACCESO” (al respecto, véase hecho posterior 2.5.3).
41
4.2.2. Los registros de operación del SGJ son de compleja lectura y no existe un
procedimiento de revisión periódico específico, lo que dificulta la detección de operaciones
inapropiadas en el proceso de asignación de causas.
El perfil administrador de oficina de asignación se encuentra habilitado a realizar acciones

sensibles (como inhibir una serie de juzgados a la hora de realizar el sorteo, o reasignar una
causa a otro juzgado, entre otras posibilidades que se detallan en la observación 4.2.4), sin
que el sistema le exija asentar adecuadamente la aprobación de instancias superiores. Los
registros de auditoría (Log) que se generan no contienen un código identificatorio por cada
tipo de movimiento y solo existe un campo en la tabla de la Base de Datos (denominado
"Descripción_Modificación") en donde se graba la operación realizada. Si bien el operador
cuenta con un campo en el que podría cargar información útil, por ser de texto libre permite
la imputación de un carácter cualquiera para continuar operando, con lo que el registro de
auditoría se genera con la palabra "Modificación" sin que quede asentado cuál fue el campo
que se modificó y, en este caso, sin una descripción que resulte de utilidad. El Log, además,
no distingue prioridad de eventos.
Estas particularidades generan que una eventual búsqueda de eventos críticos se torne
sumamente compleja y probablemente ineficaz.
Las mejores prácticas referidas a administración de eventos indican que estos deben ser
identificados en una escala de prioridades, contando de ser posible con alarmas visuales y
sonoras cuando se realiza una operación de alta criticidad; también indican que para
garantizar el buen uso de los sistemas es necesario que todas las operaciones de alto impacto
requieran control y autorización digital por una entidad jerárquica superior.
La inexistencia de medidas que restrinjan o permitan controlar adecuadamente la operación

del perfil administrador de oficina de asignación impide asegurar que no se realicen acciones
inapropiadas en la asignación de causas.
42
4.2.3. No se aplican procedimientos específicos para analizar las pistas de auditoría que
genera la funcionalidad de asignación de causas del SGJ, lo que debilita la identificación
de vulnerabilidades y la propuesta de medidas correctivas.
El “Protocolo de Administración, Control y Publicidad del Módulo de Asignación de Causas

del SGJ” tiene como objetivo brindar un marco de transparencia respecto de las asignaciones
de causas en los contextos definidos por la CSJN y como facultad delegada por las Cámaras
Nacionales y Federales. En ese sentido, a fin de verificar el normal funcionamiento del
Módulo de Asignación de Causas, se establece que la Dirección de Auditoría Informática
dispondrá de un proceso de auditoría permanente, que se realizarán auditorias periódicas
obligatorias alimentadas de la información de las bases de datos del SGJ, y que “se verificará
el funcionamiento de los bolilleros de compensación y, en su caso, los registros de auditoría
del sistema” (Resolución CMPJN 601/16).41
A partir de los relevamientos realizados con los responsables de los departamentos de la

Dirección General de Tecnología, de la Dirección de Auditoría Informática y con los
usuarios de los fueros visitados, se ha podido confirmar que no se han formalizado ni
aplicado procedimientos para realizar análisis proactivos sobre las pistas de auditoría que
genera el sistema en forma continua. Los análisis sobre los diferentes registros se realizan
de manera reactiva ante un pedido expreso y específico. Es pertinente reiterar que el 27 de
septiembre de 2016 fue creada la Unidad de Auditoría Informática bajo la dependencia
funcional y jerárquica del Cuerpo de Auditores (Res. CMPJN 521/16, art. 3º).
41
El Protocolo también prevé, respecto de la administración del Módulo de Asignación de Causas, que la
Dirección General de Tecnología debe informar al CMPJN la metodología de todas las Cámaras, todo cambio
de reglas de funcionamiento que resuelva cada Cámara; y, toda excepción a las reglas establecidas que implique
una operación particular sobre la base de datos, la que debe contar con el requerimiento escrito de la autoridad
competente y será puesto en conocimiento de la superioridad. Respecto de la publicidad del funcionamiento
del Sistema de Asignación de Causas, el Protocolo establece que la Secretaría de Estadísticas del CMPJN debe
publicar las pautas de funcionamiento de cada fuero (rubros, búsquedas de conexidad, cambios de asignación
por recusación, incompetencia, etc.), el listado periódico de causas ingresadas por fuero con la información
necesaria para exponer la secuencia de ingreso y asignación, y un cuadro periódico resumen de asignaciones
(con ingresos y egresos en los modos de asignación aplicados: sorteo, fuero de atracción y cambio de
asignación).
43
Tal como se expone en la observación siguiente, el perfil de administrador de oficina de

asignación cuenta con privilegios para modificar la parametrización del sorteo, sin controles
suficientes sobre dichas acciones.
La inexistencia de procedimientos formales y de acciones proactivas para analizar las pistas

de auditoría debilita la determinación de la razonabilidad de los datos y de las funciones y
actividades ejecutadas por usuarios clave sobre las operaciones críticas ejecutadas desde el
Módulo de Asignación de Causas, o sobre los informes y reportes generados. La ausencia
de auditorías formales deriva en la imposibilidad de obtener evidencias que permitan
sustentar objetivamente conclusiones, opiniones y recomendaciones de mejora.
4.2.4. La funcionalidad de asignación de causas del SGJ permite que el perfil administrador
de oficina de asignación pueda realizar acciones sensibles, sin que el sistema cuente con
autorizaciones de instancias superiores ni registros de auditoría sencillos de analizar, lo
que impacta sobre la confiabilidad del sistema.
Del análisis de la información recibida, de las reuniones mantenidas con los responsables de
la Dirección General de Tecnología y de las pruebas de funcionamiento sobre un ambiente
de pruebas, se pudo comprobar que el módulo de asignación de causas cuenta con una serie
de funcionalidades sensibles en el sentido de que su utilización inapropiada puede sesgar el
resultado de una asignación. Se aclara que estas funcionalidades no están necesariamente
disponibles para todos los fueros, y que estos pueden contar con procedimientos ad hoc de
registro y autorización complementarios al sistema, y diseñados para minimizar los riesgos
de que se realicen acciones inapropiadas. No obstante, las funcionalidades del sistema
expuestas a continuación son sensibles, y sus riesgos deben leerse a la luz de las debilidades
del Log de auditoría y de la carencia de mecanismos automatizados de autorización por
instancias superiores –entre otros controles posibles– (al respecto, véase observaciones 4.2.2
y 4.2.3).
44
• Existe un botón de “Ingreso Diferido”, que se podría utilizar para asignar una causa
a un juzgado en particular sin realizar sorteo por sistema, al que se recurre cuando se
lleva a cabo un sorteo manual, por ejemplo ante indisponibilidad del sistema. En la
pantalla de ingreso para esta funcionalidad, en el campo “tipo de asignación”, se
podría elegir “sorteo” desde una lista, aun sin haberse recurrido a uno.
• La variable “factor suma” determina el valor cuantitativo que se le asigna a una causa
y que incide sobre la cantidad total de causas (“carga”) del juzgado/rubro al que se
le asigne. Dicha variable es parametrizable, de modo que permite que una causa
asignada sume un valor superior a 1 en caso que, por ejemplo, fuera de alta
complejidad. Se observó que, en la pantalla de configuración de sorteo, se puede
modificar el valor del “factor suma” de cada juzgado/rubro de modo independiente.
Si el factor suma se modificase para un juzgado/rubro en particular, puede ocurrir
que reciba en promedio menos causas respecto de aquellos juzgados que operan bajo
condiciones normales.
• Se verificó la existencia de la opción de “inhibir oficinas” por rubro, lo que permite
sesgar el resultado de un sorteo al dejar como posibles beneficiaros de la asignación
de una determinada causa a los juzgados no inhibidos (se puede incluso dejar solo
uno). La misma opción está disponible en caso de reasignación de causas.
• El sistema permite definir cuál es la mínima cantidad admisible de oficinas a
intervenir en un sorteo y admite el valor “1”. Cuando el parámetro se encuentra en
ese valor, es posible proceder al sorteo aun habiendo un solo juzgado en condiciones
de participar en el sorteo. A la inversa, la imputación de un valor superior a “1”
permite incluir en el sorteo a otros juzgados por orden creciente de acumulación de
causas, hasta que su cantidad iguale o supere la que fuera parametrizada.
• El sistema permite asignar más de una bolilla por oficina de tal manera que cada
oficina siga participando del próximo sorteo aun habiendo salido sorteada
recientemente. Su valor configurado en “1” resta aleatoriedad a la distribución
compensada de asignación de causas.
45
• Al pie de la pantalla de configuración de sorteo, se encuentra la lista de juzgados

habilitados para el rubro. Es posible eliminar la lista y cargar un único juzgado. De
este modo se puede asignar la causa a un juzgado en particular sin necesidad de
inhibir al resto.
• Es posible resortear una causa un número indeterminado de veces sin que el sistema
exija autorización de instancias superiores y sin que esta acción genere una alarma
de auditoría.
Las funcionalidades expuestas son riesgosas en un contexto en el que no se cuenta con

controles y autorizaciones sistematizadas, Logs de auditoría robustos, procedimientos de
revisión periódicos ni alarmas activas ante eventos críticos.
Tal y como lo indican las buenas prácticas de TI, la segregación de funciones de los perfiles
de usuarios, administrada por el área de Seguridad Informática de una Organización,
permitiría darle transparencia y confiabilidad al proceso y evitaría la posibilidad de errores
o prácticas inapropiadas.
4.2.5. Durante las tareas de campo, el perfil de administrador de oficina de asignación

podía acceder a información crítica, como la cantidad de causas asignadas a cada juzgado,
con el riesgo de que pudiera prever o aproximar el resultado del próximo sorteo.
Los roles asignados al perfil de administrador de oficina de asignación le permitían, al

momento de ejecutarse las tareas de campo, acceder a 5 registros de auditoría. Entre ellos,
los reportes de “Auditoría de Gestión de Bolilleros” y “Auditoría de Sorteos Realizados”
que permiten visualizar información crítica. El primero expone la cantidad de expedientes
asignados por rubro y juzgado, lo que en algunos casos42 permite estimar la probabilidad de
asignación a los juzgados intervinientes en una nueva asignación a realizarse o, bajo ciertas
42
Aquellos en los que la mínima cantidad de bolillas es igual a 1.
46
condiciones, incluso conocer con anticipación el resultado de la asignación43. El segundo

registro muestra los resultados de todos los sorteos, lo que permite aproximar el acumulado
de causas.
Esta configuración de perfiles estuvo vigente desde la implantación del SGJ hasta agosto de
2017, momento a partir del cual se creó un nuevo perfil denominado “Monitoreo de
Cámara”, con permisos para acceder a esta información, al mismo tiempo inhabilitando
dichos privilegios para el perfil administrador (véase hecho posterior 2.5.1). Esta auditoría
no pudo acceder a información sobre quienes poseen dicho perfil ni cuál es su función en el
CMPJN (véase limitación al alcance 2.4.5).
4.2.6. - El SGJ no utiliza un mecanismo de transmisión de datos seguro, lo que pone en

riesgo la integridad de los datos que almacena y la confidencialidad de la información.
El SGJ utiliza para su interconexión entre el Data Center y las oficinas de los usuarios
protocolos sin encriptación. Además, la información contenida en los paquetes
intercambiados no se encuentra enmascarada. Esto permite que un usuario pueda interceptar
información y copiarla (por ejemplo nombres de usuario y contraseñas), y más grave aún,
realizar una ataque del tipo “hombre en el medio” y modificar la información intercambiada
entre un cliente del SGJ y el servidor.44
43
Bajo la condición de la nota al pie anterior, en particular cuando un solo juzgado cuenta con valor mínimo
de acumulado.
44
Un ataque de “hombre en el medio” consiste en que una persona sea capaz de interceptar, observar e incluso
modificar los mensajes transmitidos entre dos partes, sin que éstas se percaten de ello.
47
Fuente: Captura de pantalla del equipo de auditoría en la que se puede observar un nombre de usuario de
prueba y su contraseña en texto plano.
Las mejores prácticas de seguridad en aplicaciones recomiendan utilizar protocolos

encriptados (como HTTPS) y enmascarar la información -en la medida que sea posible- de
forma tal que no pueda ser utilizada aún si fuera interceptada. Un beneficio extra de utilizar
conexiones seguras es la identificación del emisor (mediante el uso de certificados digitales)
lo que dificultaría la realización de ataques del tipo “hombre en el medio”.
4.2.7. El SGJ no cuenta con controles de ingreso de datos que aseguren la unicidad de los
registros, lo que, entre otras cuestiones, imposibilita una adecuada búsqueda de conexidad.
El sistema no realiza validaciones de datos, más allá del dígito verificador de CUIT/CUIL.
Incluso entonces, y dado que para agregar un actor en el SGJ debe imputarse en el sistema
su número de CUIL o CUIT, el sistema no sólo indica si el dígito verificador imputado es
erróneo, sino también cuál es el correcto, lo que permite al operador continuar con la
operación aún con el riesgo de que la CUIT imputada no corresponda al actor.
Tampoco posee listas desplegables con los organismos oficiales (Ministerios, Fuerzas
Armadas, etc.) permitiendo a cada operador ingresarlo en forma discrecional (por ejemplo,
48
Ministerio de Agroindustria podría ser cargado como “Minagri”, “M.d.A”, etc.). El sistema
tampoco normaliza la utilización de mayúsculas, minúsculas y tildes.45
A su vez, según el fuero, los actores no son buscados en la base de datos por valores unívocos
tales como CUIT, CUIL o DNI, por lo que, a modo de ejemplo, una parte que utiliza su
primer o segundo nombre en causas distintas, no es detectado por el sistema como una misma
persona.
En este marco, el diseño del sistema no cumple con los requerimientos mínimos para detectar
de forma eficaz la conexidad de casos o evitar acciones inapropiadas, como tampoco evita
la generación de causas gemelas mediante la leve modificación de datos en los actores.
4.2.8. La funcionalidad de asignación de causas del SGJ presenta bajo rendimiento e

indisponibilidad del servicio en determinados horarios.
La funcionalidad de asignación de causas del SGJ presenta momentos de bajo desempeño.

Ejemplo de ello ocurre cuando se consulta el historial de causas asignadas a cada juzgado.
También el sistema ha denegado servicios cuando se ejecuta el procesamiento del sorteo de
las causas que se ingresan por lotes. Se verificó, asimismo, que se producen demoras
significativas cuando se ingresa a los listados de auditoría en pantalla. De acuerdo a lo
manifestado por usuarios del sistema, el rendimiento del sistema decae en horas del
mediodía.
Las bajas de rendimiento detectados en el SGJ impactan en atributos clave del sistema como
la usabilidad, la disponibilidad de procesos y de información, y la confiabilidad que los
usuarios depositan en él.
45
A modo de ejemplo, si el nombre Oscar fuese almacenado en su totalidad con letras mayúsculas (OSCAR),
el sistema no identificará óscar, Óscar, Oscar u oscar.
49
5. RECOMENDACIONES
Las recomendaciones aquí expuestas siguen la secuencia de las observaciones.
5.1. Procedimientos Técnicos
5.1.1. Elaborar y poner en práctica un Plan Estratégico de Tecnología de la Información que

defina la arquitectura de los sistemas de información en forma alineada a los objetivos
estratégicos del organismo.
5.1.2. Implementar un Consejo de Arquitectura de Tecnología de Información que permita

diseñar entornos de información compartidos para alinear adecuadamente los servicios de
TI y los sistemas de información críticos a los objetivos estratégicos de la organización.
5.1.3. Implementar, en las áreas de Planificación y Proyectos, y Organización y Sistemas,

una metodología para la gestión, seguimiento y control integral de los proyectos tecnológicos
encomendados a cada área de servicio.
5.1.4. Implementar un modelo de gestión integral de las configuraciones y de control de

cambios dentro de los proyectos de desarrollo de software, que permita obtener una adecuada
y eficiente planificación, evaluación, seguimiento y control de los procesos evolutivos de los
sistemas aplicativos de la organización por el área de Organización y Sistemas.
5.1.5. Implementar las acciones necesarias para gestionar un Diccionario de Datos central
sobre el SGJ Lex 100.
5.1.6. Implementar los mecanismos de auditoría interna previstos en la Resolución CMPJN

521/16.
50
5.1.7. Implementar una política formal de mantenimiento y soporte de la infraestructura

relacionada al SGJ, revisada y aprobada por la alta dirección, que permita asegurar una
adecuada y eficiente disponibilidad de la información y los servicios que lo soportan.
5.1.8. Desarrollar políticas y aplicar procedimientos que aseguren la protección de la

información de las bases de datos puestas al servicio de los entornos no productivos
(desarrollo y soporte), asegurando el cumplimiento del principio de confidencialidad.
5.1.9. Gestionar la implementación de un sistema de tipo CRM (Gestión de Servicio al

Cliente) para dar seguimiento, priorización y registro a los pedidos de asistencia técnica de
los usuarios.
5.1.10. Implementar un modelo de gestión de incidencias y de problemas, dentro de los

procedimientos de soporte y mantenimiento, que permita asegurar una adecuada y eficiente
disponibilidad de servicios en los sistemas aplicativos de la organización.
5.1.11. Implementar los procedimientos necesarios para garantizar la actualización del

entorno del SGJ utilizado por el servicio de soporte de primer nivel/capacitación. Establecer
procedimientos eficaces para la comunicación entre las áreas a cargo de desarrollo y soporte
de modo que esta última sea notificada en tiempo y forma sobre las últimas actualizaciones
aplicadas.
5.1.12. Implementar los procesos de gestión de requerimientos que permitan administrar un

catálogo actualizado de especificaciones funcionales del SGJ.
5.1.13. Implementar los procedimientos adecuados para que el área de Operaciones o de

Infraestructura Tecnológica tenga a cargo las actividades de puesta en producción de las
versiones del SGJ generadas por el equipo de desarrollo, del que debe encontrarse separada.
Gestionar la creación de un área o equipo a cargo del control de calidad de las versiones del
SGJ generadas por el equipo de desarrolladores, y separado de éste.
51
5.1.14. Implementar una política de respaldo de gestión documental, que permita asegurar
un adecuado, eficiente y confiable resguardo de la información, como así también asegurar
su posterior restauración, en caso de ser necesario, por el área de Organización y Sistemas.
5.1.15. Elaborar un procedimiento claro y preciso de acción ante un desastre, aprobado por
la Alta Dirección.
5.1.16. Restringir los accesos lógicos a los sistemas de información al mínimo posible como
para permitir estrictamente la realización de las tareas necesarias. Otorgar los permisos de
acceso mínimos indispensables al personal.
5.1.17 Formalizar una Política de Seguridad de la Información que se aplique a todo el

organismo, orientada a asegurar la integridad, confidencialidad y disponibilidad de la
información.
5.2. Módulo de Asignación de Causas.
5.2.1. Implementar un procedimiento de gestión de usuarios revisado y aprobado por la alta

dirección, unificar la gestión de usuarios y desplegar un sistema o módulo específico que
contenga herramientas para aplicar políticas de seguridad y activar pistas de auditoría en
todos los niveles. Inhibir la posibilidad de eliminar usuarios. Adicionalmente, aprobar e
implementar una Reglamentación de Perfiles de Usuarios y su composición, y una Política
de Auditoría de Permisos del Sistema de Gestión Judicial a cargo de la Dirección General
de Seguridad Informática, que asegure la segregación de funciones y minimice las
posibilidades de errores, fuga de información crítica o intervención indebida.
5.2.2. Identificar la criticidad de cada operación posible en el sistema y reforzar el monitoreo

y control de las operaciones críticas mediante la instalación de alarmas, procedimientos de
revisión de registros de operación y mecanismos de aprobación superior. De ser posible,
52
incorporar en las pistas de auditoría datos adicionales sobre la operación específica realizada
por el usuario, de modo de simplificar el análisis del Log.
5.2.3. Dar cumplimiento a lo establecido en el “Protocolo de Administración, Control y

Publicidad del Módulo de Asignación de Causas del SGJ” (Resolución CMPJN 601/16), e
implementar procedimientos de auditoría proactivas con especial énfasis en las pistas de
auditoría generadas por el Módulo de Asignación de Causas.
5.2.4. Implementar un procedimiento claro y conciso de segregación de funciones de

usuarios con controles jerárquicos y autorizaciones cruzadas, e implementar una política de
seguimiento y análisis de pistas de auditoría.
5.2.5. Identificar los perfiles de usuario críticos e inhibir la posibilidad de que accedan a
información que les permita prever o aproximar los resultados del próximo sorteo.
5.2.6. Realizar un proceso de reingeniería en el sistema de comunicaciones del Lex 100 que
asegure la confidencialidad e inalterabilidad de los intercambios de mensajes entre los
clientes y los servidores del sistema.
5.2.7. Tomar las medidas necesarias tanto a nivel de procedimientos como de desarrollo
(como la generación de bases de datos de magistrados, interacción con bases de datos de
AFIP y ANSES, etc.) para evitar el ingreso de datos de tipo texto libre, de modo de asegurar
una relación univoca entre un registro y un actor y optimizar la búsqueda de conexidad.
5.2.8. Diagnosticar y evaluar los motivos que producen un bajo rendimiento del sistema Lex
100 y definir un plan de mejora.
6. CONCLUSIONES
53
La gestión de TI del Consejo de la Magistratura del Poder Judicial de la Nación (CMPJN)

presenta debilidades que comprometen la gobernanza del Sistema de Gestión Judicial (SGJ),
que se considera un sistema crítico para el Poder Judicial de la Nación. Entre ellas, se
destacan la falta de un plan estratégico de TI actualizado; la inexistencia de un Consejo de
TI que proporcione directrices generales; la vigencia de un esquema informal para la gestión
de configuraciones, cambios y nuevas versiones del sistema; y la carencia de un plan de
contingencia y de recuperación de desastres aprobado. Respecto de esto último, si bien la
infraestructura informática se encuentra correctamente dimensionada y cuenta con
redundancia dentro del mismo centro de procesamiento de datos, carece de redundancia
geográfica; y dado que no se realizan copias de respaldo de los archivos documentales, el
organismo asume el riesgo de afrontar altos costos de recuperación de la información en caso
de ocurrir un evento crítico.
En cuanto a la seguridad y confidencialidad de la información, aunque la infraestructura de

protección perimetral del organismo es robusta, presenta vulnerabilidades en su
configuración que resultan explotables para la eventual ejecución de actividades maliciosas,
con riesgo para la confiabilidad y confidencialidad de los datos, o la disponibilidad del
sistema. En el mismo sentido, el mecanismo de transmisión de datos del SGJ es vulnerable
al no recurrir a un protocolo seguro. La confidencialidad de la información ingresada o
generada en el SGJ y registrada en la base de datos o en el storage documental, también se
encuentra comprometida desde el plano interno, puesto que el personal de desarrollo y
soporte a usuarios accede de modo irrestricto a datos sensibles sobre las casusas.
La administración de usuarios del SGJ es compartida entre el Consejo de la Magistratura del

Poder Judicial de la Nación y la Corte Suprema de Justicia de la Nación a través de una
aplicación complementaria. El perfil de administrador de usuarios cuenta con privilegios
excesivos en el marco de un esquema de responsabilidades compartidas, situación que se
agrava ante la inexistencia de pistas de auditoría que registren su actividad en esa aplicación.
La situación descripta compone un ambiente poco propicio para un adecuado control de
54
errores o acciones maliciosas sobre el SGJ, sobre los datos de la base relacionada o sobre la
documentación judicial asociada.
Específicamente en lo que respecta al funcionamiento del SGJ, el ingreso de un expediente

habilita a la búsqueda automatizada de antecedentes, función orientada a lograr economía
procesal por medio de la conexidad de causas. Sin embargo, como no existe un adecuado
control de ingreso de datos al sistema, no es posible asegurar la homogeneidad de los
registros históricos, lo que deriva en que la búsqueda de conexidad dependa más del
conocimiento, pericia y voluntad del operador que de la automaticidad que brinda el sistema.
Complementariamente, dado que el organismo no cuenta con un diccionario único de datos,
éstos pueden ingresarse al sistema y registrarse en la base con distintos formatos, con el
riesgo de generarse inconsistencias y, consecuentemente, dificultarse la búsqueda y
composición de información relevante para la toma de decisiones, como la conexidad o la
elaboración de estadísticas.
En cuanto a la funcionalidad del SGJ para la asignación de causas, si bien la normativa

vigente establece un marco de reglas obligatorias generales, las Cámaras Nacionales o
Federales se encuentran facultadas para dictar su propia reglamentación, lo que se traduce
en requerimientos funcionales particulares para cada una de ellas. En general, los fueros
recurren a la asignación de causas mediante procedimientos de compensación conforme a
los cuales los expedientes recaen sobre aquellos juzgados con menor cantidad de causas
acumuladas por rubro. En estos casos, si el SGJ contempla perfiles con facultades para
acceder a la secuencia o al stock de asignaciones históricas, éstos podrían componer
información y predecir con alta probabilidad –o incluso con certeza– cuál será el juzgado
sobre el cual recaerá la próxima asignación, situación que se agrava si se considera que el
orden de ingreso de expedientes al sistema para su asignación puede ser discrecional.
En adición a lo anterior, ciertos perfiles de usuarios pueden estar habilitados para modificar
los parámetros de cada evento de asignación mediante acciones que resultan sensibles (por
ejemplo, inhibir temporariamente a uno o varios juzgados, o resortear, entre otras
55
posibilidades). A ese respecto, el SGJ no cuenta con un organigrama interno que integre el
proceso de asignación de causas a un esquema que exija la intervención de instancias
superiores para autorizar acciones potencialmente riesgosas. Por su parte, el SGJ no genera
registros de auditoría claros y precisos, ni el organismo ejecuta proactivamente un análisis
continuo de las pistas de auditoría que se generan, lo que condiciona la identificación de
errores o acciones maliciosas.
Esta auditoría no pudo corroborar que las vulnerabilidades detectadas hayan sido
efectivamente explotadas, ya que no se brindó acceso en tiempo y forma a la base de datos,
al listado de sus administradores, al código fuente del SGJ y a los registros de auditoría, tal
como consta en las limitaciones de este informe (punto 2.4.).
El CMPJN debe tomar acciones conducentes a garantizar la confiabilidad del SGJ mediante
una gestión de usuarios alineada a las buenas prácticas y a la configuración de perfiles que
atiendan a una adecuada segregación de funciones, con acceso asimétrico a información
sensible, y autorizaciones jerárquicas informatizadas frente a acciones críticas ejecutadas
durante los procesos de asignación de causas. Estas acciones deben ser acompañadas de un
rediseño del log de auditoría y de la implementación de controles, de modo de contar con
alarmas ante situaciones riesgosas. Por su parte, también debe tomar acciones para optimizar
la gestión de TI del organismo en todo lo que pueda comprometer la confiabilidad,
disponibilidad y confidencialidad del SGJ.
7. COMUNICACIÓN AL ENTE
El 27 de noviembre de 2017 se realizó una reunión de cierre de la auditoría entre funcionarios

del CMPJN y de la AGN en oficinas de ésta última, en la cual se comunicaron los resultados
del trabajo realizado (Acta de cierre de auditoría del 27/11/17).
8. LUGAR Y FECHA
56
BUENOS AIRES,
9. FIRMA
57

Documento Stornelli

Uploaded by

Document Information

Original Title

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Documento Stornelli

Uploaded by

Copyright:

Estimado Lector:

Se pone en su conocimiento que, según lo dispuesto

Consejo de la Magistratura del Poder Judicial de la Nación

Auditoría General de la Nación

1. OBJETO DE AUDITORÍA ............................................................................................... 1

AGN: Auditoría General de la Nación.

A la Señora Presidente del Consejo de la Magistratura

2.1. Ejecución del Trabajo de Auditoría

El inicio de las tareas de auditoría se notificó al organismo el 02/03/2017 mediante Nota

El período auditado comprende del 1º de enero de 2016 al 31 de diciembre de 2016.

2.2. Enfoque del Trabajo de Auditoría

El Convenio celebrado el 20 de diciembre de 2016 entre el Consejo de la Magistratura del

Fase 1: Procedimientos Técnicos

f. Respaldo y recuperación de la información.

Fase 2: Módulo de Asignación de Causas

a. Arquitectura del módulo.

La auditoría tuvo en cuenta estándares internacionales establecidos como marco de

- CMMI (Capability Maturity Model Integration, por Integración de Modelos de

2.3. Procedimientos de Auditoría

• Verificación de la existencia y confiabilidad de las medidas de control interno.

• Análisis de normativa relacionada con el objeto de auditoría.4

Mediante Nota AGN 95/17-P, ANEXO I - apartado “Relativos al módulo de sorteos de

2.4.2. La falta de acceso oportuno al registro de auditoría de transacciones impide emitir

Mediante Nota AGN 95/17-P, ANEXO I – apartado “Relativos al módulo de sorteos de

aplicado en el sistema para realizar el sorteo, respectivamente. En respuesta al ítem 6. ix),

2.4.4. La falta de disponibilidad de información sobre la gestión de accesos a la base de

Mediante Nota AGN 95/17-P, ANEXO I – apartado “Relativos al módulo de sorteos de

2.5. Hechos posteriores al período auditado

3.1. El Consejo de la Magistratura del Poder Judicial de la Nación

El Poder Judicial de la Nación es ejercido por la Corte Suprema de Justicia de la Nación

Además de las atribuciones jurisdiccionales, la Corte Suprema de Justicia de la Nación

a) territorial: según la circunscripción asignada por ley a la actividad de cada órgano

Se expone a continuación y a modo ilustrativo la organización de la Justicia Nacional en los

Fuente: Elaboración propia en base a Poder Judicial de la Nación (https://www.pjn.gov.ar/)

En lo que refiere a la Administración del Poder Judicial de la Nación, al CMPJN le

Un organigrama de las áreas mencionadas precedentemente se expone a continuación:

Áreas del CMPJN vinculadas al objeto de auditoría

La CSJN y el CMPJN de manera conjunta, deben reglamentar la utilización y disponer la

En ese sentido se estableció que la Dirección de Sistemas de la CSJN y la Dirección General

Sin perjuicio de ello, la información almacenada en el SGJ, con la totalidad de los

Asimismo, la CSJN a través de la Dirección de Sistemas, tiene a su cargo la seguridad

Existen, por tanto, y de acuerdo a la normativa, competencias compartidas entre la CSJN y

Otras, sin embargo, son competencia exclusiva de la CSJN a través de la Dirección de

3.2. El Sistema de Gestión Judicial y el proceso de asignación de causas 17

Entre sus objetivos se encuentran lograr un servicio de administración de justicia eficiente,

La asignación de una causa en el SGJ requiere de su ingreso previo al sistema. Existen

La identificación de antecedentes es de naturaleza meramente informativa y puede concluir

El proceso de asignación le suma un guarismo (variable denominada “factor suma”)24 al

A título meramente ilustrativo del proceso de asignación, se presenta a continuación una

Tabla Nº 1: Ejemplo de compensaciones

Suponiendo ese resultado, y considerando un “factor suma” = 1, la situación en t1 implicará

El sistema permite definir cuál es la mínima cantidad admisible de oficinas a intervenir en

Por cuestiones de conexidad, recusación, excusaciones, cambio de objeto de juicio, etc.

3.3. Contexto de TI del objeto de control

La sala de operaciones se encuentra fuera de la sala cofre y dispone de un videowall que

4.1. Procedimientos Técnicos

4.1.1. La Dirección General de Tecnología no cuenta con un Plan Estratégico de

Ante la ausencia de Planificación Estratégica de TI, y a medida que al SGJ se le agregan

La Metodología de Planeación Estratégica de Tecnología de Información (PETI) está

4.1.2. No existe un Consejo de Arquitectura de Tecnología de la Información que

Las mejores prácticas orientadas al gobierno de las tecnologías de la información (COBIT e

La coordinación entre el área de TI y la alta dirección para definir la arquitectura de TI,

La inexistencia de un Consejo/Comité de Arquitectura de Tecnología de la Información

4.1.3. No se aplica un marco metodológico para la gestión de proyectos de TI en cartera de

Se ha constatado que la DGT recurre a planillas de cálculo para llevar el inventario de

La gestión y seguimiento de múltiples proyectos sin un marco metodológico concreto que