Ingeniería de seguridad
¿Puede Kotoba admitir un programa NIST CSF 2.0?
Kotoba puede aportar controles técnicos a un programa de ciberseguridad. No afirmamos una cobertura completa de NIST CSF 2.0, certificación ni inmunidad frente a ataques. NIST no certifica productos CSF. La pregunta útil es qué paso del ataque detiene un control implementado y qué evidencia respalda esa afirmación.
Revisado el 2026-09-09. Las traducciones cuentan con asistencia automática; la revisión en el idioma nativo no está certificada. La evidencia de origen y el modelo de amenazas detallado están disponibles en inglés. Este artículo es una evaluación con alcance definido, no una prueba de penetración.
Tres productos, responsabilidades separadas
Kotoba declara efectos y comprueba los límites de capacidad. Su núcleo protegido de llamadas al host intersecta los recursos solicitados, las concesiones y la política local antes de invocar un controlador. El proveedor aún debe hacer cumplir las rutas concretas, los destinos y el alcance del inquilino.
Kotoba Cloud proporciona un flujo de trabajo orientado al cliente y a la organización. Su perfil público inspeccionado tiene hostedApply=false: con esa configuración no se incluye un servicio genérico de aprobación de cambios de producción. Las rutas específicas de publicación de bibliotecas y rotación de claves deben evaluarse por separado. La autenticación no equivale a la aprobación para desplegar o gastar.
Kotobase suministra datos y servicios de objetos con rutas de autorización del lado del servidor. Un CID identifica bytes; por sí solo no demuestra su autoría, confidencialidad, aprobación confiable, disponibilidad permanente ni recuperación exitosa. Eso requiere controles separados y evidencia operativa.
Un perfil CSF actual-objetivo acotado
Este es nuestro mapa seleccionado de contribuciones del producto, no un Perfil organizativo completo ni una puntuación de cumplimiento porcentual. Los clientes deben definir el alcance, los responsables, la tolerancia al riesgo y las evidencias para su propia implementación.
- Gobernar
- La política y los registros de riesgos proporcionan una base de diseño. Objetivo: responsables de decisión designados, excepciones revisadas y aprobación de la versión registrada.
- Identificar
- Los manifiestos y las identidades de contenido ayudan a realizar un seguimiento de los artefactos. Objetivo: un inventario de activos implementados, clasificación de datos y responsables de las dependencias.
- Proteger
- La admisión de capacidades y el envío protegido cuentan con evidencias de implementación y pruebas locales. Objetivo: vinculaciones de producción cualificadas, secretos delimitados, pruebas entre inquilinos y revocación medida.
- Detectar
- El host puede devolver comprobantes de denegación y ejecución. Objetivo: un destino protegido y duradero, alertas correlacionadas, retención y entrega demostrada a un responsable identificado.
- Responder
- Los procedimientos de respuesta están documentados. Objetivo: contención y comunicación practicadas, con tiempos de respuesta y revocación medidos.
- Recuperar
- Las identidades de contenido permiten verificar las entradas de restauración. Objetivo: copias de seguridad protegidas, restauraciones probadas y objetivos de recuperación específicos para cada cliente. Un hash de contenido no es una copia de seguridad.
Grafo de ataque: las instrucciones no otorgan autoridad
Suponga que un atacante controla el texto leído por un agente de IA, pero no el host, las claves de firma ni la política. El atacante intenta convertir una sugerencia en una exportación de datos de clientes. El gráfico muestra los cruces de control necesarios; no representa un compromiso observado ni afirma que todas las integraciones implementadas los hagan cumplir.
- Documento o respuesta de herramienta no confiable
- La IA propone una operación sensible
- Admisión de efectos y capacidades
- Comprobación del host y del proveedor con alcance de recursos
- Operación autorizada y resultado registrado
- Operación denegada; no se invoca el controlador
Historias de ataque y las pruebas que necesitan
Inyección de instrucciones para exportación de datos
El contenido controlado por un atacante pide a un agente que envíe datos de clientes fuera de su destino aprobado. En una ruta protegida, la falta de un efecto o una concesión de recursos disjunta debería detener el envío. Verifique que el controlador nunca haya sido llamado. Riesgo residual: concesiones demasiado amplias, redireccionamientos del proveedor y una integración que elude los controles.
Un inquilino solicita datos de otro inquilino
Un llamador autenticado proporciona un grafo o identificador de recurso diferente. Las comprobaciones del lado del servidor deben vincular la entidad principal, el inquilino, la operación y el objeto en cada ruta. Los menús del navegador y un CID no constituyen autorización. Inspeccione cada endpoint y pruebe las lecturas y escrituras denegadas; de una sola prueba del kernel no se deriva ninguna afirmación de aislamiento de toda la flota.
Un artefacto cambia después de la aprobación
Un editor o intermediario sustituye bytes. Exija el resumen criptográfico del contenido esperado, un firmante de confianza, validez y aprobación para la revisión exacta antes de usarla. Una firma válida en código malicioso sigue siendo posible; la firma de confianza y la identidad del artefacto son necesarias, pero no suficientes.
Se reutiliza una aprobación obsoleta o una concesión revocada
Una persona que llama vuelve a intentar una acción autorizada previamente. Las comprobaciones de expiración ayudan, pero el estado duradero contra repeticiones, el consumo atómico cuando sea necesario, la revocación actual y la vinculación con el recurso son responsabilidades separadas. Un recibo genérico del host no es un servicio de prevención de repeticiones.
Agotamiento de recursos e interrupción del servicio
Un programa de entrada o generado consume un trabajo excesivo. Los límites de admisión, el combustible de ejecución, los límites de memoria y los plazos del supervisor abordan etapas diferentes. Prueba el backend de producción real bajo carga; una prueba aprobada del lenguaje no demuestra resistencia ante una inundación de red o un compromiso del host.
Pérdida de evidencia durante un incidente
Un servicio falla después de una acción externa, o un atacante manipula los registros locales. El kernel del host puede devolver recibos, pero su registrador es opcional y su diario está en memoria. Implemente un registrador protegido y duradero con gestión de fallos, y pruebe la recuperación. Una operación exitosa no demuestra que un registro de auditoría externo se haya conservado.
Lo que verificamos y lo que sigue pendiente
En la revisión del lenguaje citada, las 24 pruebas de conformidad de capacidades pasaron localmente con ClojureScript, incluidos 9 casos de vinculación de componentes y 2 casos de despacho del host. Se verificaron los resultados esperados de permitir y denegar. Esta es evidencia del núcleo, no una prueba de ataque de extremo a extremo de los servicios activos.
El registro de garantías inspeccionado sigue sin estar cualificado operativamente. Su matriz de correspondencias almacenada informa de evidencias de diseño e implementación, pero no de evidencias operativas para sus controles SOC e ISO codificados. Esto es una afirmación sobre esta instantánea, no un hallazgo de que falte todo control de producción.
Antes de un piloto empresarial, vincule la propuesta, el principal, el entorno, el artefacto exacto y la política a una operación de alcance limitado. Pruebe los casos permitidos y denegados, la repetición simultánea, la revocación, el fallo del registro y la restauración. Mida los efectos no autorizados que llegan a un controlador, los comprobantes faltantes, el retraso de la revocación y el tiempo de recuperación. Publique el alcance probado y las brechas restantes.