módulo ara::idsm — Intrusion Detection System Manager

El Intrusion Detection System Manager, como servicio central de la plataforma, recopila eventos relevantes para la seguridad procedentes de clústeres funcionales y aplicaciones a través de instancias estandarizadas de la clase [SWS_AIDSM_10101] AUTOSAR_AP_EXP_SWArchitecture p. 124. Los avisos entrantes pueden enriquecerse con marcas de tiempo y datos de contexto, filtrarse y reenviarse como eventos de seguridad cualificados a destinatarios autorizados [SWS_AIDSM_10800]. La conexión de todas las interfaces e IDs de evento requiere un modelado consistente mediante el manifiesto AUTOSAR AUTOSAR_AP_TPS_ManifestSpecification p. 257.

más ›

El Intrusion Detection System Manager (IdsM) actúa en la AUTOSAR Adaptive Platform como Functional Cluster central basado en demonio para la agregación, filtrado y evaluación de eventos relevantes para la seguridad AUTOSAR_AP_EXP_PlatformDesign p. 95. Tanto clústeres funcionales como Communication Management, Firewall y Diagnostic Management como componentes específicos de la aplicación notifican incidentes de seguridad de forma segura para subprocesos (thread-safe) al IdsM a través de instancias estandarizadas de la clase [SWS_AIDSM_10101] AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13.

Diagrama de contexto: Integración del demonio IdsM como sumidero central para eventos de seguridad procedentes de clústeres funcionales y aplicaciones. Fuentes: AUTOSAR_AP_EXP_SWArchitecture p. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13.

La notificación de eventos a través de ReportEvent admite grados de detalle variables, desde contadores simples pasando por marcas de tiempo explícitas hasta datos de contexto con o sin versión [SWS_AIDSM_10302], [SWS_AIDSM_10307]. Para el enriquecimiento dinámico, las aplicaciones pueden integrarse mediante [SWS_AIDSM_10400] y [SWS_AIDSM_10500] como proveedores de marcas de tiempo o bytes de contexto adicionales AUTOSAR_AP_EXP_SWArchitecture p. 122. Tras la evaluación de cadenas de filtros internas, el IdsM reenvía los eventos cualificados a destinatarios registrados a través de callbacks de notificación de la clase [SWS_AIDSM_10800] [SWS_AIDSM_10807].

Diagrama de secuencia: Notificación síncrona de un evento de seguridad por parte de un componente sensor mediante EventReporter. Fuentes: AUTOSAR_AP_EXP_SWArchitecture p. 232, [SWS_AIDSM_10101].

La configuración de los puertos y la asignación de definiciones de eventos se realiza a través de elementos de metamodelo estandarizados en el manifiesto AUTOSAR_AP_TPS_ManifestSpecification p. 257. El comportamiento de notificación de eventos individuales también se puede controlar en tiempo de ejecución mediante [SWS_AIDSM_10600], señalizándose IDs de eventos no válidos a través del dominio de error [SWS_AIDSM_10706] con el código de error kUnknownEventId [SWS_AIDSM_10204], [SWS_AIDSM_10602].

más ›

Rol y límites del sistema del Intrusion Detection System Manager

El Intrusion Detection System Manager (IdsM) constituye la instancia central de la plataforma para la recopilación, prefiltrado y cualificación de eventos relevantes para la seguridad (Security Events) en una AUTOSAR Adaptive Platform AUTOSAR_AP_EXP_PlatformDesign p. 95. De conformidad con los requisitos de ciberseguridad de la ISO/SAE 21434, el IdsM actúa en unidades de control basadas en POSIX como servicio en segundo plano independiente (daemon-based Functional Cluster) AUTOSAR_AP_EXP_SWArchitecture p. 124. Su tarea principal consiste en recopilar anomalías y posibles intentos de ataque, evaluarlos en función de reglas configuradas como límites de tasa o valores umbral y consolidarlos en eventos de seguridad cualificados (Qualified Security Events) AUTOSAR_EXP_SWArchitecture p. 97.

La arquitectura del IdsM está diseñada para la interoperabilidad con otros clústeres funcionales. Servicios de plataforma como Communication Management AUTOSAR_AP_SWS_CommunicationManagement p. 34, Firewall AUTOSAR_AP_SWS_Firewall p. 11 y Diagnostic Management AUTOSAR_AP_SWS_Diagnostics p. 67, así como procesos específicos de la aplicación, actúan como sensores de seguridad AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13. La siguiente vista general ilustra la integración del demonio IdsM en el entorno de ejecución de la Adaptive Platform.

Diagrama de contexto: Integración del demonio IdsM como sumidero central para eventos de seguridad procedentes de clústeres funcionales y aplicaciones. Fuentes: AUTOSAR_AP_EXP_SWArchitecture p. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13, AUTOSAR_AP_EXP_PlatformDesign p. 95.

Notificación de eventos mediante EventReporter y formas de interacción

La interfaz de entrada primaria para la transmisión de incidentes de seguridad se realiza mediante la clase [SWS_AIDSM_10101]. Una entidad notificadora instancia esta clase indicando un puerto definido mediante ara::core::InstanceSpecifier de forma segura para subprocesos a través del constructor [SWS_AIDSM_10301]. Con ello se establece la conexión con el SecurityEventReportInterface definido en el manifiesto AUTOSAR_AP_TPS_ManifestSpecification p. 257. La transmisión propiamente dicha se efectúa mediante variantes sobrecargadas del método síncrono ReportEvent, pudiendo ejecutarse cada una de ellas de forma segura para subprocesos [SWS_AIDSM_10302].

En función del tipo de evento y de los datos de sensor disponibles, la interfaz ofrece formas de notificación graduales. El método base solo transmite un número de repeticiones de tipo [SWS_AIDSM_10203] (valor por defecto 1) sin más metadatos [SWS_AIDSM_10302]. Para operaciones críticas en tiempo, se puede proporcionar directamente una marca de tiempo específica del sensor de tipo [SWS_AIDSM_10202] [SWS_AIDSM_10303]. Además, se pueden transferir datos útiles inmutables como span de bytes de tipo [SWS_AIDSM_10201], ya sea de forma aislada [SWS_AIDSM_10304] o combinados con una marca de tiempo [SWS_AIDSM_10305]. Para formatos de eventos estructurados existen sobrecargas con datos de contexto versionados de tipo [SWS_AIDSM_10206], que representan un par de valores formado por un span de datos de contexto y un indicador de versión de 16 bits [SWS_AIDSM_10306], opcionalmente complementado con una marca de tiempo explícita [SWS_AIDSM_10307].

Un escenario típico para esta vía de notificación es el descarte de paquetes de red no permitidos por parte de la pila TCP/IP y el Firewall: el sistema operativo notifica los paquetes bloqueados al demonio del Firewall, el cual llama de inmediato a ReportEvent AUTOSAR_AP_EXP_SWArchitecture p. 232. El siguiente diagrama de secuencia ilustra este proceso de notificación síncrono.

Diagrama de secuencia: Notificación síncrona de un evento de seguridad por parte de un componente sensor mediante EventReporter. Fuentes: AUTOSAR_AP_EXP_SWArchitecture p. 232, [SWS_AIDSM_10101], [SWS_AIDSM_10302].

Datos de contexto extendidos y marcas de tiempo mediante interfaces de proveedor

Para no sobrecargar los procesos notificadores con consultas de tiempo costosas o información de contexto estática, la arquitectura admite una inversión del flujo de control mediante interfaces de proveedor AUTOSAR_AP_EXP_SWArchitecture p. 122. Las aplicaciones pueden actuar como prestadoras de servicios de marcas de tiempo derivando de la clase abstracta [SWS_AIDSM_10400]. Tras la instanciación mediante el constructor [SWS_AIDSM_10401], la aplicación activa el servicio con Offer() [SWS_AIDSM_10408]. A partir de ese momento, el IdsM puede llamar según sea necesario al método virtual puro GetTimestamp() para consultar el valor de tiempo actual [SWS_AIDSM_10407]. La provisión finaliza con StopOffer() [SWS_AIDSM_10409].

De forma análoga, la clase base [SWS_AIDSM_10500] permite el enriquecimiento dinámico o la modificación de datos de contexto. El constructor espera, además del InstanceSpecifier, la indicación de tamaño de bytes adicionales, así como el desplazamiento (offset) para los datos de contexto originales [SWS_AIDSM_10501]. Tras la habilitación mediante Offer() [SWS_AIDSM_10507], el demonio IdsM llama al método ModifyContextData al recibirse el evento [SWS_AIDSM_10509]. En esto se transfiere un span de bytes modificable en el que la aplicación escribe los datos modificados y notifica el tamaño de datos resultante como ara::core::Result<std::size_t> [SWS_AIDSM_10509]. Con StopOffer() se desactiva la recepción de más solicitudes de modificación [SWS_AIDSM_10508].

Diagrama de secuencia: Ciclo de vida y flujo de inversión de control en el enriquecimiento de eventos de seguridad mediante TimestampProvider y ContextDataProvider. Fuentes: AUTOSAR_AP_EXP_SWArchitecture p. 122, [SWS_AIDSM_10408], [SWS_AIDSM_10509].

Recepción de eventos de seguridad cualificados y control operativo

Una vez que el IdsM ha procesado los eventos entrantes y los ha cualificado según sus reglas de filtrado, se puede informar a las Adaptive Applications autorizadas sobre la presencia de un evento cualificado AUTOSAR_AP_EXP_SWArchitecture p. 123. Para ello se utiliza la clase [SWS_AIDSM_10800], que se instancia a través de su constructor específico de puerto [SWS_AIDSM_10801]. Tras llamar a Offer() [SWS_AIDSM_10808], el IdsM reenvía las notificaciones a la aplicación invocando la retrollamada correspondiente. Si hay datos no versionados disponibles, la llamada se realiza mediante OnEventQualification con contexto opcional y marca de tiempo opcional [SWS_AIDSM_10807]. Si se dispone de datos de contexto versionados, el demonio atiende la interfaz sobrecargada [SWS_AIDSM_10810]. La notificación puede finalizarse con StopOffer() [SWS_AIDSM_10809].

Diagrama de secuencia: Recepción de eventos de seguridad cualificados por parte de una aplicación de reacción mediante QualifiedEventsReceiver. Fuentes: AUTOSAR_AP_EXP_SWArchitecture p. 123, [SWS_AIDSM_10801], [SWS_AIDSM_10808], [SWS_AIDSM_10807].

Para el control dinámico del comportamiento de notificación por evento existe la clase [SWS_AIDSM_10600], que se inicializa mediante el constructor [SWS_AIDSM_10601]. Mediante GetReportingMode se puede consultar el modo actual para un ID de evento de tipo [SWS_AIDSM_10205] [SWS_AIDSM_10602]. Mediante SetReportingMode se puede modificar el modo en tiempo de ejecución [SWS_AIDSM_10603]. La enumeración [SWS_AIDSM_10207] define los modos disponibles, que van desde la desactivación completa (kOff) hasta el registro estándar y detallado (kBrief, kDetailed), pasando por la omisión deliberada de cadenas de filtrado internas (kBriefBypassingFilters, kDetailedBypassingFilters) [SWS_AIDSM_10207].

Diagrama de estados: Modos de notificación y de filtrado del procesamiento de eventos según ReportingModeType. Fuentes: [SWS_AIDSM_10207], [SWS_AIDSM_10602], [SWS_AIDSM_10603].

Modelado de manifiesto, vinculación de puertos y despliegue

La integración de todas las interfaces en el sistema global se realiza de forma declarativa a través del manifiesto de AUTOSAR. Todas las interfaces de puerto relativas al IdsM derivan en el metamodelo de la clase base común IdsmAbstractPortInterface AUTOSAR_AP_TPS_ManifestSpecification p. 257. El reporting se modela mediante un SecurityEventReportInterface, que se vincula mediante un SecurityEventReportToSecurityEventDefinitionMapping con una SecurityEventDefinition formal AUTOSAR_AP_TPS_ManifestSpecification p. 146. Este desacoplamiento explícito permite reutilizar componentes de software estandarizados y asignar IDs de eventos específicos del proyecto recién en el nivel de configuración TPS_ManifestSpecification p. 146.

En el nivel de despliegue, los diferentes providers y receivers se representan como UploadableDeploymentElement TPS_ManifestSpecification p. 881. Entre ellos se cuentan IdsmTimestampProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 664, IdsmContextProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 665, IdsmReportingModeProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 667 así como IdsmQualifiedEventReceiverMapping AUTOSAR_AP_TPS_ManifestSpecification p. 669. Estas metaclases vinculan la instancia de plataforma modular IdsPlatformInstantiation con el proceso respectivo (Process) y el puerto de destino (PPortPrototype o bien RPortPrototype) TPS_ManifestSpecification p. 664. Para clústeres funcionales existe además un mapeo especial FunctionalClusterToSecurityEventDefinitionMapping con el fin de asignar eventos de plataforma conformes a la norma sin vinculación directa a procesos AUTOSAR_AP_TPS_ManifestSpecification p. 873.

Comportamiento en caso de error y gestión de diagnóstico

Las situaciones de error dentro del módulo IdsM se gestionan según el concepto estandarizado de tratamiento de errores de AUTOSAR a través del dominio de error [SWS_AIDSM_10706]. Este se referencia mediante la función global GetIdsmErrorDomain() [SWS_AIDSM_10702]. Los errores de API concretos se representan mediante la enumeración [SWS_AIDSM_10204] (alias [SWS_AIDSM_10707]). Si, por ejemplo, al consultar o establecer un modo de reporting aparece un ID de evento desconocido, las operaciones GetReportingMode y SetReportingMode devuelven un ara::core::Result erróneo con el código IdsmErrc::kUnknownEventId [SWS_AIDSM_10602], [SWS_AIDSM_10603].

Para la conversión en objetos de error estructurados se utiliza la función auxiliar MakeErrorCode [SWS_AIDSM_10703]. El dominio de error implementa las interfaces para consultar el nombre de dominio [SWS_AIDSM_10710] así como el mensaje de texto descriptivo [SWS_AIDSM_10711]. Si las excepciones están habilitadas en el sistema, se puede lanzar un código de error mediante ThrowAsException [SWS_AIDSM_10712] como excepción de tipo [SWS_AIDSM_10704] (alias [SWS_AIDSM_10708]), cuyo constructor encapsula el ErrorCode subyacente [SWS_AIDSM_10705].

Evidencias detalladas complementarias y referencia a especificaciones

La siguiente recopilación resume los documentos de especificación y los pasajes de arquitectura esenciales del módulo:

• Ingreso de eventos y reporte de sensores: Las especificaciones [SWS_AIDSM_10101] y [SWS_AIDSM_10302] a [SWS_AIDSM_10307] definen la firma de C++ de EventReporter. La integración arquitectónica mediante sensores de plataforma se ilustra en AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13 y AUTOSAR_AP_EXP_SWArchitecture p. 121.
• Integración interna en la plataforma: Las dependencias y los patrones de uso de otros clústeres funcionales como Communication Management (AUTOSAR_AP_SWS_CommunicationManagement p. 34), Firewall (AUTOSAR_AP_SWS_Firewall p. 11) y Diagnostic Management (AUTOSAR_AP_SWS_Diagnostics p. 67) acreditan el rol universal del IdsM como recolector de seguridad.
• Proveedores de datos adicionales y de marca de tiempo: Las especificaciones [SWS_AIDSM_10400] y [SWS_AIDSM_10500] regulan el patrón de provisión para marcas de tiempo y modificaciones de contexto, complementado por el diagrama de arquitectura AUTOSAR_AP_EXP_SWArchitecture p. 122.
• Recepción de eventos cualificados y modos de funcionamiento: Los requisitos [SWS_AIDSM_10800] y [SWS_AIDSM_10600] describen la comunicación de egreso y la configuración en tiempo de ejecución, ilustradas en AUTOSAR_AP_EXP_SWArchitecture p. 123.
• Modelado de manifiesto y de despliegue: Las reglas del metamodelo en AUTOSAR_AP_TPS_ManifestSpecification p. 257 así como los mapeos de despliegue AUTOSAR_AP_TPS_ManifestSpecification p. 664 a AUTOSAR_AP_TPS_ManifestSpecification p. 669 aseguran la instanciación y vinculación consistentes en tiempo de diseño y de carga.
• Tratamiento de errores: Las definiciones [SWS_AIDSM_10204] y [SWS_AIDSM_10706] constituyen el fundamento del tratamiento de errores ante identificadores de eventos no válidos.