Cómo Sysadmins Linux Pueden Adaptarse a la Nueva Política de Seguridad CJIS del FBI

Qué es CJIS y por qué importa para tu servidor Linux

CJIS Security Policy es el conjunto de controles que el FBI impone a cualquier organización que maneje Criminal Justice Information (CJI) en Estados Unidos. Aunque el alcance oficial es justicia penal — agencias estatales, federales, contratistas, integradores de software — los requisitos terminan filtrándose a toda la cadena de suministro: proveedores cloud, proveedores de identidad, fabricantes de hardware, y por supuesto cualquier sysadmin que opere infraestructura donde se almacena o transmite CJI.

La versión 6.1 se publicó el 25 de junio de 2026 y consolida el giro hacia controles explícitos mapeados a NIST SP 800-53. Si trabajas con un cliente del sector público estadounidense, con un integrador que vende a justicia, o simplemente quieres saber hacia dónde se inclina el péndulo regulatorio federal, este es el documento que tienes que mirar.

Los tres cambios técnicos concretos de la versión 6.1

La v6.1 corrige omisiones detectadas durante 2025. Tres controles sobresalen porque afectan implementaciones técnicas que puedes auditar con un comando.

SC-13: cifrado en tránsito sube de 128 a 256 bits

El control SC-13 cubre la protección criptográfica de CJI cuando sale de una ubicación físicamente segura. Bajo v6.0 el mínimo era clave simétrica de 128 bits. La nueva versión exige al menos 256 bits. En la práctica significa que si tu stack TLS todavía negocia AES-128-GCM o 3DES como cifrado preferido, no cumple.

Verifica hoy con qué cifra negocia tu servidor HTTPS:

# Verifica los cifrados disponibles y su prioridad
openssl ciphers -v 'AES:!3DES:!RC4:!NULL' | sort -k3 -r | head -10
# Negocia en vivo contra un endpoint y mostrame el cipher elegido
echo | openssl s_client -connect api.tu-dominio.example:443 -tls1_3 2>/dev/null | 
  grep -E 'Ciphers+:|Protocols+:'

Si te sale Cipher : TLS_AES_128_GCM_SHA256, ya estás negociando 128 bits con TLS 1.3 — técnicamente fuera de cumplimiento. TLS_AES_256_GCM_SHA384 es el camino correcto, y forzarlo requiere ajustar el orden de cipher suites o, idealmente, pasar a TLS 1.3 con preferencia explícita por AES-256-GCM en tu servidor web o balanceador.

SC-28: cifrado en reposo a 256 bits

El control SC-28 cubre CJI almacenada fuera de una ubicación físicamente segura. La v6.1 también eleva aquí el mínimo a 256 bits. Esto pega en cifrado de disco completo, cifrado de bases de datos, y cualquier solución de almacenamiento de objetos.

En servidores Linux los sospechosos de siempre:

• LUKS: verifica que el cifrado sea AES-XTS con clave de 512 bits (XTS duplica el tamaño efectivo de clave), no AES-CBC con clave de 128.
• ZFS: encryption=aes-256-gcm al crear el dataset, nunca aes-128-ccm legacy.
• PostgreSQL: pgcrypto con pgp_sym_encrypt(data, key, 'cipher-algo=aes256').
• S3/MinIO: SSE-KMS con algoritmo AES-256 explícito, no el default AES-128 que algunos SDK viejos negocian.

Para auditar todo el almacenamiento en un servidor:

# LUKS: volátiles que no sean XTS-512 son señal de alerta
lsblk -o NAME,TYPE,FSTYPE,CRYPT-TYPE 2>/dev/null | grep -E 'LUKS|crypt'
# ZFS: cipher de cada dataset cifrado
zfs get -t filesystem encryption,cipher,keyformat 2>/dev/null | 
  grep -v 'aes-128-ccm$' | grep -v 'off'
# PostgreSQL: extensión disponible y versión
sudo -u postgres psql -c "SELECT extname, extversion FROM pg_extension WHERE extname='pgcrypto';"

El output esperado para cumplimiento CJIS v6.1: cero líneas con aes-128 en producción. Cualquier volumen LUKS con LUKS1 y AES-128 es candidato a migración.

RA-5: escaneo de vulnerabilidades pasa de trimestral a mensual

El control RA-5 exige que la organización determine si hay actualizaciones de seguridad pendientes mediante escaneo. La v6.1 reduce el intervalo de “al menos trimestral” a “al menos mensual”. Para un equipo de operaciones Linux, esto pasa de “una tarea olvidable cada 90 días” a “un cron serio que tiene que correr cada 30 días sin fallar”.

El patrón mínimo viable:

# Cron mensual OpenVAS + reporte por correo
cat /etc/cron.d/openvas-monthly-scan <<'EOF'
0 2 1 * * root /usr/sbin/openvas --update && 
  /usr/bin/omp -u admin -w $OMP_PASS -h 127.0.0.1 
    -T 'a]b]d]e]' -t $TARGET_LIST -n 'CJIS-monthly' -c 
    | /usr/bin/mail -s "[OpenVAS] Monthly CJIS scan completed" [email protected]
EOF
# O más simple con Nessus/Tenable.io via curl a su API
curl -s -X POST https://cloud.tenable.com/scans 
  -H "X-ApiKeys: accessKey=$TENABLE_AK;secretKey=$TENABLE_SK" 
  -H "Content-Type: application/json" 
  -d '{"uuid":"","targets":["10.0.0.0/8"]}' | jq .

Si tu proceso actual es un recordatorio trimestral en el calendario, este es el momento de automatizarlo. Y no alcanza con correr la herramienta: CJIS quiere evidencia de que corrió, cuándo, qué encontró, y qué hiciste con los hallazgos críticos.

Lo que NO cambió y sigue aplicando igual

La v6.1 es incremental en la dirección. No reformula los controles más críticos; los refuerza. Dos áreas donde el cumplimiento sigue dependiendo del estado de tu stack, no de la versión de la política.

IA-2: MFA obligatoria para todo

El control IA-2 identifica y autentica usuarios organizacionales. Las mejoras Priority 1 obligan MFA tanto para cuentas privilegiadas como no privilegiadas, sin importar si el acceso es local, por red, o remoto. La v6.1 mantiene exactamente esto.

Para Linux con SSH, las opciones que cumplen:

• OpenSSH + claves FIDO2: AuthenticationMethods publickey,publickey con dos dispositivos físicos o una clave + PIN.
• TOTP local: Google Authenticator PAM (pam_google_authenticator.so) o libpam-oath integrado con tu IdP.
• SSO federado: OpenLDAP + Keycloak + WebAuthn, lo más alineado con Zero Trust y lo más portable entre sysadmins y contractors.

Lo que NO cumple: solo password, password + SMS, password + email link, o password + “pregunta secreta”. Esto es lo que Michigan State Police listó como hallazgo frecuente en la reunión de la CJIS Board de octubre de 2025.

IA-5: lista de contraseñas comprometidas

El control IA-5 exige mantener una lista de contraseñas comunes, esperadas o comprometidas, actualizarla al menos trimestralmente y cuando ocurran compromisos, y comparar las contraseñas memorizadas contra esa lista trimestralmente. También exige chequear prospectivamente cuando el usuario crea o cambia una contraseña.

Implementación práctica con el módulo pam_pwquality combinado con un diccionario:

# /etc/security/pwquality.conf (extracto endurecido CJIS)
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
dictcheck = 1
dictpath = /usr/share/dict/words
enforce_for_root
# Chequeo prospectivo via Haveibeenpwned (k-anonymity API)
curl -s -A 'cjis-audit' 
  https://api.pwnedpasswords.com/range/$(echo -n 'Password123!' | sha1sum | cut -c1-5) 
  | grep -i $(echo -n 'Password123!' | sha1sum | cut -c6-)
# Si devuelve una línea, esa contraseña está comprometida.

Para Active Directory el equivalente comercial es Specops Password Policy, que mantiene una base de 6 mil millones de contraseñas comprometidas y aplica las verificaciones de IA-5 automáticamente. En tu stack Linux open source, el patrón equivalente es un script cron que baje el feed SHA-1 de HIBP y bloquee los matches en el cambio de contraseña.

El cambio filosófico: hacia dónde va CJIS

La v6.1 no introduce Zero Trust formalmente, pero la dirección es inequívoca. Identidad verificable, autenticación continua de dispositivos y cuentas, mínimo privilegio aplicado en cada request — todos son controles que ya están en el documento y que se profundizarán en próximas versiones.

Lo que MSP planteó en octubre de 2025 como roadmap confirma esto: la auditoría trienal que hoy es el pan de cada tres años va camino a una línea base + revisiones trimestrales + planes de seguridad + evidencia continua + assessment continuo en el futuro. La pregunta deja de ser “tienes el control” y pasa a ser “puedes demostrar consistentemente que funciona”.

Para sysadmins Linux esto significa tres cosas concretas:

1. Tu documentación de cumplimiento tiene que ser exportable. No sirve un runbook en una wiki privada si no puedes sacar evidencia automatizada de él. Invertí en Ansible o Puppet que genere reportes legibles por auditores.
2. Los logs de autenticación, MFA, escaneo, y patching tienen que llegar a un SIEM. CJIS habla de “event logging” como hallazgo frecuente — significa que muchos operadores ni siquiera centralizan logs.
3. El ciclo de patching mensual (no trimestral) implica que tu unattended-upgrades o tu dnf-automatic tiene que estar al día y que tienes que tener un pipeline de testing que no rompa producción cuando aplique parches el día 1.

Un ejemplo concreto de pipeline que cumple con la parte de “evidencia continua”:

# /etc/ansible/roles/cjis-evidence/tasks/main.yml (extracto)
- name: Recolectar evidencia CJIS v6.1
  hosts: all
  gather_facts: yes
  tasks:
    - name: Capturar cipher TLS 1.3 negociado
      ansible.builtin.shell: |
        echo | openssl s_client -connect 127.0.0.1:443 -tls1_3 2>/dev/null 
          | awk -F': ' '/Cipher    :/ {print $2}'
      register: tls_cipher
      changed_when: false
    - name: Capturar configuración SSH AuthenticationMethods
      ansible.builtin.slurp:
        src: /etc/ssh/sshd_config
      register: sshd_conf
    - name: Subir reporte a S3 con fecha
      ansible.builtin.command: >
        aws s3 cp /tmp/cjis_evidence_{{ ansible_date_time.date }}.json
        s3://cjis-evidence/{{ inventory_hostname }}/{{ ansible_date_time.date }}.json
      delegate_to: localhost

Si corres esto semanalmente con ansible-pull en cada servidor, en seis meses tienes 26 snapshots por host con evidencia auditable de qué cifrados negocia, qué exige tu SSH, y qué escaneos pasaron.

Cómo auditar tu propio stack sin esperar al auditor externo

Antes de que llegue un CSA o un auditor externo a revisar, puedes correr tú mismo los chequeos. El script mínimo de autodiagnóstico:

#!/usr/bin/env bash
# cjis-v61-quickcheck.sh
# Devuelve exit 0 si todo OK, exit N si hay hallazgos en SC-13/SC-28/RA-5/IA-2/IA-5.
set -u
SCORE=0
check_sc13() {
  # Negocia contra localhost TLS 1.3 si hay HTTPS expuesto
  local cipher
  cipher=$(echo | openssl s_client -connect 127.0.0.1:443 -tls1_3 2>/dev/null 
    | awk -F': ' '/Cipher    :/ {gsub(/^ +| +$/,"",$2); print $2}')
  if [[ "$cipher" == *128* ]]; then
    echo "[SC-13] FAIL: cipher negociado es 128-bit ($cipher). Exigido 256."
    SCORE=$((SCORE+1))
  else
    echo "[SC-13] OK: cipher negociado $cipher"
  fi
}
check_sc28() {
  local weak
  weak=$(lsblk -o NAME,TYPE,FSTYPE 2>/dev/null | grep -c crypt)
  if [[ "$weak" -gt 0 ]]; then
    echo "[SC-28] INFO: hay volúmenes LUKS. Verificar manualmente con 'cryptsetup luksDump'"
  fi
}
check_ra5() {
  if ! systemctl is-enabled --quiet openvas-scanner.timer 2>/dev/null 
     && ! crontab -l 2>/dev/null | grep -qi 'vuln.*scan'; then
    echo "[RA-5] FAIL: sin escaneo de vulnerabilidades programado."
    SCORE=$((SCORE+1))
  else
    echo "[RA-5] OK: hay un cron/timer de escaneo configurado."
  fi
}
check_ia2() {
  if ! grep -qE 'pam_(google_authenticator|u2f|webauthn)' /etc/pam.d/sshd 2>/dev/null 
     && ! grep -qE '^[^#]*AuthenticationMethods.*publickey,publickey' 
        /etc/ssh/sshd_config 2>/dev/null; then
    echo "[IA-2] FAIL: SSH no exige MFA / segunda factor."
    SCORE=$((SCORE+1))
  else
    echo "[IA-2] OK: SSH exige al menos 2 factores."
  fi
}
check_ia5() {
  if ! grep -qE 'enforce_for_root|pam_pwquality' /etc/pam.d/common-password 2>/dev/null 
     && ! grep -qE 'dictcheck' /etc/security/pwquality.conf 2>/dev/null; then
    echo "[IA-5] FAIL: no hay chequeo de contraseñas comprometidas."
    SCORE=$((SCORE+1))
  else
    echo "[IA-5] OK: pwquality configurado."
  fi
}
check_sc13
check_sc28
check_ra5
check_ia2
check_ia5
echo ""
echo "=== Puntaje CJIS v6.1 ==="
echo "Hallazgos: $SCORE"
exit $SCORE

Ejecuta esto mensualmente, archivá el output en tu SIEM, y cuando llegue la auditoría ya tienes seis meses de evidencia continua. Cero improvisación.

Lo que cambia para ti si no trabajas con CJI directamente

Si tu empresa no toca CJI, la política no te obliga a nada. Pero la inercia regulatoria funciona así: NIST publica 800-53, FedRAMP lo exige para cloud, los integradores lo exigen para sus contratistas, y tarde o temprano aparece en los RFPs de cualquier sector que toca gobierno. Es lo que ya pasó con HIPAA, PCI, y SOX en décadas anteriores.

La conclusión práctica: si tu servidor Linux ya tiene AES-256 por default, MFA en SSH, escaneo de vulnerabilidades mensual, y pwquality con diccionario, estás mejor que la mayoría. Si no, esta v6.1 es una buena excusa para cerrar esa deuda técnica — porque la próxima versión, casi seguro, va a ser menos permisiva que esta.

Preguntas frecuentes

Lee también

• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux
• Guía Definitiva para Sysadmins: Configuración de Bonding de Interfaces de Red en Linux
• Guía Definitiva: Configura AppArmor para Proteger tus Aplicaciones en Linux