Privado: Seguridad de transmisión - Historial de revisiones

Admin: /* 2. Alcance */

2025-10-23T11:24:08Z

2. Alcance

← Revisión anterior		Revisión del 11:24 23 oct 2025
Línea 7:		Línea 7:

	== 2. Alcance ==		== 2. Alcance ==
	~~Este ensayo cubre~~ la transmisión de datos ~~desde el origen~~ de ~~la medición hasta su almacenamiento y visualización~~:
	* ~~Enlace '''sensor~~ → puerta de enlace~~''' (cifrado propio del protocolo AES-128 CCM*).~~		Aplica a todas las capas de comunicación que intervienen en la transmisión de datos de temperatura:
	* ~~Enlace '''gateway~~ → servidor local~~'''~~ (MQTT ~~cifrado~~).
	* ~~Enlace '''servidor~~ local → servidor central PiTemp 2.0~~'''~~ (TLS ~~cifrado~~).		* Sensor inalámbrico → puerta de enlace Zigbee
	* ~~Comunicación '''servidor~~ → base de datos ~~PostgreSQL'''.~~		* Puerta de enlace → servidor local (MQTT sobre TLS)
	* Acceso remoto a ~~los paneles~~ y ~~APIs web de PiTemp 2.0~~ (HTTPS).		* Servidor local → servidor central PiTemp 2.0 (TLS)
			* Servidor central → base de datos
			* Acceso remoto a la interfaz web y API (HTTPS)

	== 3. Descripción general ==		== 3. Descripción general ==
	~~El sistema~~ PiTemp 2.0 emplea mecanismos de ~~cifrado y autenticación~~ que garantizan:		PiTemp 2.0 emplea protocolos y mecanismos de seguridad reconocidos que garantizan:
	* '''Confidencialidad:''' los datos ~~transmitidos no pueden ser interpretados por terceros~~.
	* '''Integridad:''' ~~cualquier alteración en tránsito es detectable~~.		* '''Confidencialidad:''' los datos viajan cifrados extremo a extremo.
	* '''Autenticación:''' solo dispositivos y servidores autorizados pueden ~~participar en la comunicación~~.		* '''Integridad:''' cada mensaje está firmado digitalmente mediante hash SHA-256.
	* '''No repudio:''' ~~cada mensaje firmado digitalmente conserva~~ trazabilidad ~~hasta el origen~~.		* '''Autenticación:''' solo dispositivos y servidores autorizados pueden intercambiar datos.
			* '''No repudio:''' las firmas y marcas temporales aseguran la trazabilidad completa.

	== 4. Procedimiento de verificación ==		== 4. Procedimiento de verificación ==
	* '''~~Verificación de~~ cifrado ~~punto a punto~~'''		* '''Capa Zigbee (sensores)''' Los sensores inalámbricos emplean el estándar '''Zigbee 3.0''', basado en '''IEEE 802.15.4''', que utiliza cifrado '''AES-128 CCM*''' para todas las tramas de datos. La autenticación y el intercambio de claves se realizan mediante emparejamiento seguro (''link key''). Por diseño del protocolo, no es posible la transmisión de datos en texto plano.<blockquote>Referencias técnicas: [https://standards.ieee.org/standard/802_15_4-2020.html IEEE 802.15.4-2020], [https://csa-iot.org/all-solutions/zigbee/ Zigbee 3.0 Security Architecture]</blockquote>'''Capa de transporte (MQTT, API, base de datos)'''
	* ~~Se capturan y analizan~~ tramas de ~~comunicación entre sensor~~ y ~~gateway Zigbee~~, ~~confirmando el uso~~ de ~~cifrado AES~~-~~128 interno al protocolo~~.		** Todas las conexiones utilizan '''TLS 1.2 o superior'''.
	* ~~Se inspecciona la conexión MQTT para confirmar el uso de certificados y cifrado~~ TLS 1.2 o superior.		** Los certificados son emitidos por la '''CA interna 3innova''' o por una autoridad de confianza.
	* ~~Se revisan los parámetros~~ de ~~seguridad del~~ servidor ~~(puertos, certificados~~, ~~protocolos habilitados)~~.		** Las claves privadas se almacenan de forma segura en el servidor local.
			** Los intentos de conexión no autenticados se rechazan y registran. '''Verificación automática de integridad''' Cada registro transmitido se asocia a una firma '''SHA-256'''. El proceso diario de auditoría comprueba que los valores almacenados coinciden con los originales en los logs firmados, detectando cualquier alteración.

	* '''Validación de certificados'''		== 5. Criterios de aceptación ==
	* Todos los certificados TLS están emitidos por una autoridad de confianza o por la CA interna 3innova.
	* Las conexiones cifradas emplean '''firmas digitales X9.62 ECDSA con SHA-384''', equivalentes a un nivel de seguridad ≥ RSA-3072.
	* Se comprueba la validez temporal, la integridad de la cadena de ~~confianza y la ausencia de algoritmos obsoletos.~~
	* La caducidad y renovación de certificados se controlan mediante alertas automáticas.

	* '''~~Verificación de integridad de datos~~'''		* Todas las comunicaciones activas deben emplear '''TLS 1.2+ o AES-128 CCM*'''.
	* ~~Se comprueba que los mensajes firmados (hash SHA-256) coinciden en origen~~ y ~~destino~~.		* Los certificados deben ser válidos y vigentes.
	* ~~Cualquier discrepancia genera alerta y se registra como incidente~~.		* Ninguna transmisión de datos en texto plano.

	~~== 5. Criterios de aceptación ==~~		* Coincidencia del '''100 % de hashes''' entre los datos firmados y los registros almacenados.
	* ~~Todas las comunicaciones activas deben emplear~~ '''~~cifrado TLS 1.2+''' o~~ '''~~AES-128''' (según capa).~~
	* Los certificados deben ser válidos, no caducados y emitidos por autoridad reconocida o CA interna 3innova.
	* No debe existir transmisión de datos ~~en texto plano en ningún punto de la cadena.~~
	* Los intentos de conexión no autenticados deben ser rechazados y registrados.
	* Coincidencia del 100% de hashes en origen y ~~destino durante el ensayo~~.

	== 6. Evidencias generadas ==		== 6. Evidencias generadas ==
	* Declaración de conformidad de seguridad de transmisión (protocolo Zigbee 3.0, MQTT over TLS 1.2+).
	* Registro de configuración del sistema (confirmación de cifrado y autenticación activa).
	* Listado de certificados TLS vigentes (firma ECDSA-SHA-384 y fechas de caducidad).
	* Informe firmado por el responsable técnico de 3innova confirmando el uso de protocolos seguros.

	~~== 7. Gestión~~ de ~~no conformidades ==~~		* Declaración de conformidad de seguridad Zigbee 3.0 / IEEE 802.15.4.
	* Comunicación no cifrada: bloqueo inmediato del canal y registro de ~~incidencia~~.		* Registro de configuración TLS y certificados activos.
	* Certificado caducado o inválido: sustitución y reinstalación en menos de 24 h.		* Informes automáticos de verificación de integridad (hash SHA-256).
	* ~~Fallo~~ de ~~autenticación de dispositivo: aislamiento del nodo~~ y ~~reproceso de emparejamiento seguro~~.
	* ~~Discrepancia~~ de ~~hash: investigación~~ de ~~causa raíz~~ (~~posible retransmisión o alteración~~).

	~~== 8. Periodicidad de ensayo ==~~		* Logs de conexión y autenticación de servidores.
	* ~~Ensayo completo: anual, o tras actualización~~ de ~~firmware o renovación de certificados.~~
	* Verificación automática: comprobación diaria del estado y ~~caducidad de certificados.~~
	* Monitoreo continuo: detección en tiempo real de intentos de ~~conexión no cifrada~~.

	== 9. Conclusión ==		== 7. Conclusión ==
	El sistema PiTemp 2.0 garantiza la seguridad de la transmisión mediante cifrado extremo a extremo, autenticación de dispositivos y ~~validación continua~~ de integridad.		El sistema PiTemp 2.0 garantiza la '''seguridad de transmisión''' mediante cifrado extremo a extremo, autenticación de dispositivos y verificación diaria de integridad de datos.

	~~Este ensayo~~ demuestra ~~el cumplimiento de~~ los requisitos de seguridad ~~de datos establecidos en el~~ Apéndice II del Anexo XI de la Orden ICT/155/2020.		Esto demuestra conformidad con los requisitos de seguridad del ''Apéndice II del Anexo XI'' de la '''Orden ICT/155/2020'''.

Admin: /* 1. Objeto */

2025-10-23T11:12:11Z

1. Objeto

← Revisión anterior		Revisión del 11:12 23 oct 2025
Línea 3:		Línea 3:
	== 1. Objeto ==		== 1. Objeto ==
	Verificar que las comunicaciones entre los distintos componentes del sistema PiTemp 2.0 (sensores, puertas de enlace, servidores y bases de datos) se realizan de forma segura, confidencial y protegida frente a interceptación o manipulación.		Verificar que las comunicaciones entre los distintos componentes del sistema PiTemp 2.0 (sensores, puertas de enlace, servidores y bases de datos) se realizan de forma segura, confidencial y protegida frente a interceptación o manipulación.

			Este método de ensayo está asociado al punto '''3 — Seguridad de Transmisión''' del [[Privado:Plan de Ensayos de Software PiTemp2.0\|Plan de Ensayos de Software PiTemp 2.0]].

	== 2. Alcance ==		== 2. Alcance ==

Admin: /* 6. Evidencias generadas */

2025-10-21T15:50:01Z

6. Evidencias generadas

← Revisión anterior		Revisión del 15:50 21 oct 2025
Línea 43:		Línea 43:

	== 6. Evidencias generadas ==		== 6. Evidencias generadas ==
	* ~~Capturas~~ de ~~tráfico~~ (~~pcap~~) ~~en las que se confirma el uso de cifrado~~.		* Declaración de conformidad de seguridad de transmisión (protocolo Zigbee 3.0, MQTT over TLS 1.2+).
	* Registro de ~~certificados instalados~~ y ~~su fecha de caducidad~~.		* Registro de configuración del sistema (confirmación de cifrado y autenticación activa).
	* ~~Logs del sistema~~ de ~~comunicación MQTT/~~TLS ~~con resultado~~ de ~~handshake exitoso~~.		* Listado de certificados TLS vigentes (firma ECDSA-SHA-384 y fechas de caducidad).
	* Informe ~~de verificación~~ firmado por el responsable técnico.		* Informe firmado por el responsable técnico de 3innova confirmando el uso de protocolos seguros.
	* Registro de ~~alertas de intento~~ de ~~conexión no autorizada (si las hubiera)~~.

	== 7. Gestión de no conformidades ==		== 7. Gestión de no conformidades ==

Admin: /* 4. Procedimiento de verificación */

2025-10-21T15:48:00Z

4. Procedimiento de verificación

Admin: /* 1. Objeto */

2025-10-21T15:45:14Z

1. Objeto

Admin: Página creada con «= Privado: Seguridad de transmisión = == 1. Objeto == Verificar que las comunicaciones entre los distintos componentes del sistema PiTemp 2.0 (sensores, gateways, servidores y bases de datos) se realizan de forma segura, confidencial y protegida frente a interceptación o manipulación. == 2. Alcance == Este ensayo cubre la transmisión de datos desde el origen de la medición hasta su almacenamiento y visualización: * Enlace sensor → gateway Zigbee (nivel d…»

2025-10-21T15:41:15Z

Página creada con «= Privado: Seguridad de transmisión = == 1. Objeto == Verificar que las comunicaciones entre los distintos componentes del sistema PiTemp 2.0 (sensores, gateways, servidores y bases de datos) se realizan de forma segura, confidencial y protegida frente a interceptación o manipulación. == 2. Alcance == Este ensayo cubre la transmisión de datos desde el origen de la medición hasta su almacenamiento y visualización: * Enlace **sensor → gateway Zigbee** (nivel d…»

Página nueva

= Privado: Seguridad de transmisión =

== 1. Objeto ==
Verificar que las comunicaciones entre los distintos componentes del sistema PiTemp 2.0 (sensores, gateways, servidores y bases de datos) se realizan de forma segura, confidencial y protegida frente a interceptación o manipulación.

== 2. Alcance ==
Este ensayo cubre la transmisión de datos desde el origen de la medición hasta su almacenamiento y visualización:
* Enlace **sensor → gateway Zigbee** (nivel de campo).
* Enlace **gateway → servidor local** (MQTT cifrado).
* Enlace **servidor local → servidor central PiTemp 2.0** (TLS cifrado).
* Comunicación **servidor → base de datos PostgreSQL**.
* Acceso remoto a los paneles y APIs web de PiTemp 2.0 (HTTPS).

== 3. Descripción general ==
El sistema PiTemp 2.0 emplea mecanismos de cifrado y autenticación que garantizan:
* **Confidencialidad:** los datos transmitidos no pueden ser interpretados por terceros.
* **Integridad:** cualquier alteración en tránsito es detectable.
* **Autenticación:** solo dispositivos y servidores autorizados pueden participar en la comunicación.
* **No repudio:** cada mensaje firmado digitalmente conserva trazabilidad hasta el origen.

== 4. Procedimiento de verificación ==
# **Verificación de cifrado punto a punto**
* Se capturan y analizan tramas de comunicación entre sensor y gateway Zigbee, confirmando el uso de cifrado AES-128 interno al protocolo.
* Se inspecciona la conexión MQTT para confirmar el uso de certificados y cifrado TLS 1.2 o superior.
* Se revisan los parámetros de seguridad del servidor (puertos, certificados, protocolos habilitados).

# **Validación de certificados**
* Todos los certificados TLS están emitidos por una autoridad de confianza o por la CA interna 3innova.
* Las conexiones cifradas emplean **firmas digitales X9.62 ECDSA con SHA-384**, equivalentes a un nivel de seguridad ≥ RSA-3072.
* Se comprueba la validez temporal, la integridad de la cadena de confianza y la ausencia de algoritmos obsoletos.
* La caducidad y renovación de certificados se controlan mediante alertas automáticas.

# **Verificación de integridad de datos**
* Se comprueba que los mensajes firmados (hash SHA-256) coinciden en origen y destino.
* Cualquier discrepancia genera alerta y se registra como incidente.

== 5. Criterios de aceptación ==
* Todas las comunicaciones activas deben emplear **cifrado TLS 1.2+** o **AES-128** (según capa).
* Los certificados deben ser válidos, no caducados y emitidos por autoridad reconocida o CA interna 3innova.
* No debe existir transmisión de datos en texto plano en ningún punto de la cadena.
* Los intentos de conexión no autenticados deben ser rechazados y registrados.
* Coincidencia del 100 % de hashes en origen y destino durante el ensayo.

== 6. Evidencias generadas ==
* Capturas de tráfico (pcap) en las que se confirma el uso de cifrado.
* Registro de certificados instalados y su fecha de caducidad.
* Logs del sistema de comunicación MQTT/TLS con resultado de handshake exitoso.
* Informe de verificación firmado por el responsable técnico.
* Registro de alertas de intento de conexión no autorizada (si las hubiera).

== 7. Gestión de no conformidades ==
* **Comunicación no cifrada:** bloqueo inmediato del canal y registro de incidencia.
* **Certificado caducado o inválido:** sustitución y reinstalación en menos de 24 h.
* **Fallo de autenticación de dispositivo:** aislamiento del nodo y reproceso de emparejamiento seguro.
* **Discrepancia de hash:** investigación de causa raíz (posible retransmisión o alteración).

== 8. Periodicidad de ensayo ==
* **Ensayo completo:** anual, o tras actualización de firmware o renovación de certificados.
* **Verificación automática:** comprobación diaria del estado y caducidad de certificados.
* **Monitoreo continuo:** detección en tiempo real de intentos de conexión no cifrada.

== 9. Conclusión ==
El sistema PiTemp 2.0 garantiza la seguridad de la transmisión mediante cifrado extremo a extremo, autenticación de dispositivos y validación continua de integridad.
Este ensayo demuestra el cumplimiento de los requisitos de seguridad de datos establecidos en el Apéndice II del Anexo XI de la Orden ICT/155/2020.

← Revisión anterior		Revisión del 15:48 21 oct 2025
Línea 27:		Línea 27:
	* '''Validación de certificados'''		* '''Validación de certificados'''
	* Todos los certificados TLS están emitidos por una autoridad de confianza o por la CA interna 3innova.		* Todos los certificados TLS están emitidos por una autoridad de confianza o por la CA interna 3innova.
	* Las conexiones cifradas emplean firmas digitales X9.62 ECDSA con SHA-384, equivalentes a un nivel de seguridad ≥ RSA-3072.		* Las conexiones cifradas emplean '''firmas digitales X9.62 ECDSA con SHA-384''', equivalentes a un nivel de seguridad ≥ RSA-3072.
	* Se comprueba la validez temporal, la integridad de la cadena de confianza y la ausencia de algoritmos obsoletos.		* Se comprueba la validez temporal, la integridad de la cadena de confianza y la ausencia de algoritmos obsoletos.
	* La caducidad y renovación de certificados se controlan mediante alertas automáticas.		* La caducidad y renovación de certificados se controlan mediante alertas automáticas.
Línea 36:		Línea 36:

	== 5. Criterios de aceptación ==		== 5. Criterios de aceptación ==
	* Todas las comunicaciones activas deben emplear cifrado TLS 1.2+ o AES-128 (según capa).		* Todas las comunicaciones activas deben emplear '''cifrado TLS 1.2+''' o '''AES-128''' (según capa).
	* Los certificados deben ser válidos, no caducados y emitidos por autoridad reconocida o CA interna 3innova.		* Los certificados deben ser válidos, no caducados y emitidos por autoridad reconocida o CA interna 3innova.
	* No debe existir transmisión de datos en texto plano en ningún punto de la cadena.		* No debe existir transmisión de datos en texto plano en ningún punto de la cadena.
	* Los intentos de conexión no autenticados deben ser rechazados y registrados.		* Los intentos de conexión no autenticados deben ser rechazados y registrados.
	* Coincidencia del 100 % de hashes en origen y destino durante el ensayo.		* Coincidencia del 100% de hashes en origen y destino durante el ensayo.

	== 6. Evidencias generadas ==		== 6. Evidencias generadas ==
Línea 50:		Línea 50:

	== 7. Gestión de no conformidades ==		== 7. Gestión de no conformidades ==
	~~* ~~Comunicación no cifrada:** bloqueo inmediato del canal y registro de incidencia.		* Comunicación no cifrada: bloqueo inmediato del canal y registro de incidencia.
	~~* ~~Certificado caducado o inválido:** sustitución y reinstalación en menos de 24 h.		* Certificado caducado o inválido: sustitución y reinstalación en menos de 24 h.
	~~* ~~Fallo de autenticación de dispositivo:** aislamiento del nodo y reproceso de emparejamiento seguro.		* Fallo de autenticación de dispositivo: aislamiento del nodo y reproceso de emparejamiento seguro.
	~~* ~~Discrepancia de hash:** investigación de causa raíz (posible retransmisión o alteración).		* Discrepancia de hash: investigación de causa raíz (posible retransmisión o alteración).

	== 8. Periodicidad de ensayo ==		== 8. Periodicidad de ensayo ==
	~~* ~~Ensayo completo:** anual, o tras actualización de firmware o renovación de certificados.		* Ensayo completo: anual, o tras actualización de firmware o renovación de certificados.
	~~* ~~Verificación automática:** comprobación diaria del estado y caducidad de certificados.		* Verificación automática: comprobación diaria del estado y caducidad de certificados.
	~~* ~~Monitoreo continuo:** detección en tiempo real de intentos de conexión no cifrada.		* Monitoreo continuo: detección en tiempo real de intentos de conexión no cifrada.

	== 9. Conclusión ==		== 9. Conclusión ==
	El sistema PiTemp 2.0 garantiza la seguridad de la transmisión mediante cifrado extremo a extremo, autenticación de dispositivos y validación continua de integridad.		El sistema PiTemp 2.0 garantiza la seguridad de la transmisión mediante cifrado extremo a extremo, autenticación de dispositivos y validación continua de integridad.

	Este ensayo demuestra el cumplimiento de los requisitos de seguridad de datos establecidos en el Apéndice II del Anexo XI de la Orden ICT/155/2020.		Este ensayo demuestra el cumplimiento de los requisitos de seguridad de datos establecidos en el Apéndice II del Anexo XI de la Orden ICT/155/2020.

← Revisión anterior		Revisión del 15:45 21 oct 2025
Línea 2:		Línea 2:

	== 1. Objeto ==		== 1. Objeto ==
	Verificar que las comunicaciones entre los distintos componentes del sistema PiTemp 2.0 (sensores, ~~gateways~~, servidores y bases de datos) se realizan de forma segura, confidencial y protegida frente a interceptación o manipulación.		Verificar que las comunicaciones entre los distintos componentes del sistema PiTemp 2.0 (sensores, puertas de enlace, servidores y bases de datos) se realizan de forma segura, confidencial y protegida frente a interceptación o manipulación.

	== 2. Alcance ==		== 2. Alcance ==
	Este ensayo cubre la transmisión de datos desde el origen de la medición hasta su almacenamiento y visualización:		Este ensayo cubre la transmisión de datos desde el origen de la medición hasta su almacenamiento y visualización:
	* Enlace sensor → ~~gateway Zigbee~~ (nivel de campo).		* Enlace '''sensor → puerta de enlace''' (cifrado propio del protocolo AES-128 CCM*).
	* Enlace gateway → servidor local (MQTT cifrado).		* Enlace '''gateway → servidor local''' (MQTT cifrado).
	* Enlace servidor local → servidor central PiTemp 2.0 (TLS cifrado).		* Enlace '''servidor local → servidor central PiTemp 2.0''' (TLS cifrado).
	* Comunicación servidor → base de datos PostgreSQL.		* Comunicación '''servidor → base de datos PostgreSQL'''.
	* Acceso remoto a los paneles y APIs web de PiTemp 2.0 (HTTPS).		* Acceso remoto a los paneles y APIs web de PiTemp 2.0 (HTTPS).

	== 3. Descripción general ==		== 3. Descripción general ==
	El sistema PiTemp 2.0 emplea mecanismos de cifrado y autenticación que garantizan:		El sistema PiTemp 2.0 emplea mecanismos de cifrado y autenticación que garantizan:
	* Confidencialidad: los datos transmitidos no pueden ser interpretados por terceros.		* '''Confidencialidad:''' los datos transmitidos no pueden ser interpretados por terceros.
	* Integridad: cualquier alteración en tránsito es detectable.		* '''Integridad:''' cualquier alteración en tránsito es detectable.
	* Autenticación: solo dispositivos y servidores autorizados pueden participar en la comunicación.		* '''Autenticación:''' solo dispositivos y servidores autorizados pueden participar en la comunicación.
	* No repudio: cada mensaje firmado digitalmente conserva trazabilidad hasta el origen.		* '''No repudio:''' cada mensaje firmado digitalmente conserva trazabilidad hasta el origen.

	== 4. Procedimiento de verificación ==		== 4. Procedimiento de verificación ==
	# Verificación de cifrado punto a punto		* '''Verificación de cifrado punto a punto'''
	* Se capturan y analizan tramas de comunicación entre sensor y gateway Zigbee, confirmando el uso de cifrado AES-128 interno al protocolo.		* Se capturan y analizan tramas de comunicación entre sensor y gateway Zigbee, confirmando el uso de cifrado AES-128 interno al protocolo.
	* Se inspecciona la conexión MQTT para confirmar el uso de certificados y cifrado TLS 1.2 o superior.		* Se inspecciona la conexión MQTT para confirmar el uso de certificados y cifrado TLS 1.2 o superior.
	* Se revisan los parámetros de seguridad del servidor (puertos, certificados, protocolos habilitados).		* Se revisan los parámetros de seguridad del servidor (puertos, certificados, protocolos habilitados).

	# Validación de certificados		* '''Validación de certificados'''
	* Todos los certificados TLS están emitidos por una autoridad de confianza o por la CA interna 3innova.		* Todos los certificados TLS están emitidos por una autoridad de confianza o por la CA interna 3innova.
	* Las conexiones cifradas emplean firmas digitales X9.62 ECDSA con SHA-384, equivalentes a un nivel de seguridad ≥ RSA-3072.		* Las conexiones cifradas emplean firmas digitales X9.62 ECDSA con SHA-384, equivalentes a un nivel de seguridad ≥ RSA-3072.
Línea 31:		Línea 31:
	* La caducidad y renovación de certificados se controlan mediante alertas automáticas.		* La caducidad y renovación de certificados se controlan mediante alertas automáticas.

	# Verificación de integridad de datos		* '''Verificación de integridad de datos'''
	* Se comprueba que los mensajes firmados (hash SHA-256) coinciden en origen y destino.		* Se comprueba que los mensajes firmados (hash SHA-256) coinciden en origen y destino.
	* Cualquier discrepancia genera alerta y se registra como incidente.		* Cualquier discrepancia genera alerta y se registra como incidente.