Architecture for Security Monitoring and Automation in IoT Systems

In a recent post, we presented some of the most prominent security challenges for modern IoT systems, including challenges associated with protection of smart objects, the need for flexible, dynamic and automated security, as well as regulatory compliance challenges. Motivated by these challenges the EU funded H2020 SecureIoT project has introduce a security systems architecture for data driven monitoring and security automation of IoT systems. In following paragraphs, we present the main elements of this architectures, while in following post we will illustrate its practical deployment and use.

SecureIoT Architecture Overview and Groups of Components

The SecureIoT architecture specifies a number of components that enable the implementation of entire security monitoring and automation platforms. Some of the components are grouped together based on their functional relevant and they form composite components or component groups. As shown in the following figure, the SecureIoT architecture specifies the following groups of components:

• Data Management Group: This group comprises components that collect security-related data from the IoT systems, while at the same time implementing data-driven actuation and security automation functions towards the field. As such the group provides most of the components that underpin the data driven character of the architecture.
• Analytics Group: This group clusters together a number of components that process and analyze security related data in order to derive security insights that are accordingly used for security risk assessments, compliance auditing and other functionalities of SecureIoT compliant systems. Data analytics in the scope of the SecureIoT architecture are supported by a powerful mechanism of reusable “security templates”, which address different types of threats, vulnerabilities and attacks.
• Global Repository: This group comprises a number of databases and repositories where information generated from the various components is persisted. As shown in the architecture, the global repository is at the center of the architecture and interfaces to all the different/other groups of components.
•  SLA Group: This group comprises components that keep track and audit Service Level Agreements (SLA) between operators of IoT systems and the SecureIoT services providers in the scope of the SECaaS (Security as a Service) paradigm.
• Security and Privacy Group: This group consists of components that model and implement security policies, as a means of ensuring their interoperability across different IoT platforms and devices.
• Risk Assessment Group: This group comprises the set of components that deliver data driven risk assessments, which represent one of the main security services that are provided by SecureIoT.
• Compliance Auditing Group: This group comprises the set of components that enable and implement the compliance auditing services that are provided by SecureIoT compliant platform.
• Programming Support Group: This group comprises the set of components that support programmers and developers in securing their programs, based on a set of appropriate annotations that are decoded and operated based on security information collected by a SecureIoT platform.

Furthermore, a key communications’ component of the architecture is the Data bus i.e. a communications channel through which real time data are routed. Platform components may subscribe to the data bus to receive data of specific interest to them. Following paragraphs provide more information for each one of the above groups and of the components that they comprise.

The Data Management Group

Components in this group are responsible for collecting data from the parts of the IoT system or application to be protected. The data are accordingly streamed to the Observations repository of the Global repository. The main components of the group are:

• Deployed probes: Probes collect data from the target IoT system or application and stream them to the IoT platform through the data routing component.
• Probe Management and Configuration: This component is responsible for managing and configuring the deployed probes. It interacts with the SPEP, which provides it with automatic probe configuration commands that are used to configure the managed probes. Manual probe configuration commands may also be received by the dashboard. The Management and Configuration dashboard provides a user interface to the Probe Management and Configuration component.
• Probe Registry: This registry maintains a record of the deployed probes. Probe deployment data, as well as state and configuration data are maintained by the registry. The registry provides probe creation, reconfiguration and search capabilities.
• SPEP (Security Policy Enforcement Point): It is responsible for effecting actuations to the target IoT deployment or application. The main actuations include: (i) The automatic (re)configuration of probes, which can be triggered by security data analysis performed in the Analytics Engine; and (ii) Manual (re)configuration of probes and other components triggered by the Risk Assessment service i.e. as a risk mitigation action.

The Analytics Group

SecureIoT provides data-driven security services. Therefore, data analytics functionalities are at the very core of the architecture. They are provided and implemented as part of the Analytics Group. The main components of the group, include:

• Analytics engine: This component provides security analytics functionalities based on the monitored security data that are collected by the probes as well as training data and templates. The Analytics Engine trains itself using historic data that are stored in the Observations part of the Global Repository. The outcome of the training is a set of templates that are stored in the Security Template Database, which is used by the Engine for the real time identification of security issues by monitoring real time data that are streamed from the deployed probes through the data bus. The Analytics Engine is therefore the place where machine learning and AI algorithms for security patterns identification can be implemented. Note that the engine provides lifecycle support for the analytics algorithms it may run. At any given time, the engine may run several algorithms, each one trained with its own training sets and configuration. The Analytics Engine may raise alerts for security issues that may be detected while monitoring the target IoT system. The generated alerts may be intercepted either the SPEP component or by the Risk Assessment Engine. Depending on the defined reconfiguration policies they may carry reconfiguration commands that are to be applied to the deployed probes. Alerts that are intercepted by SPEP result into the reconfiguration of probes, which can be put into effect through the Management and Configuration component. Alternatively, probe reconfigurations may be put into effect manually through the Management and Configuration dashboard.
• Security Template Extraction: This component is in charge of training models based on historic data, as well as for extracting reusable templates. In particular, the training part of the analytics algorithm results into the generation of the security templates that are stored into the Security Templates database and are subsequently used by the monitoring part of the analytics algorithm (e.g., in order to generate alerts or trigger risk assessments).
• Security Templates Database: This stores the Security Templates i.e. pre-trained and ready to use machine learning and data mining models. The templates mechanism boosts reusability and modularity in handling many different security threat/risks, as different machine learning models (trained on different datasets) can be stored and used for each different type of threat/attack.

Note that the security templates are used during monitoring of the IoT system(s) to be protected in order to generate alerts in case security issues are detected. Hence, the templates express contextual information as well as the conditions that have to be met for alerts to be generated and actions to be taken. Moreover, the analytics engine makes use of reconfiguration policies, which reside at a Policy Repository and specify conditions under which reconfiguration of the deployed probes must be enforced.

The Global Repository

The Global Repository comprises a number of repositories that enable the persistent storage of the data that are used by the other components of the architecture. The particular repositories involved include information needed for implementing the Security and Privacy Policies. In particular, the following repositories of security data and metadata are included in the Global Repository:

• Probe registry: This contains a record of the deployed probes along with their attributes, including state information. It facilitates the automatic deployment of probes and their dynamic discovery.
• Observations: This repository contains historic security data that have been collected by the deployed probes. These data are used by the Analytics Engine to train itself and produce a set of security templates that will be used subsequently for identifying security issues on the IoT systems to be protected.
• Analytics Registry: This repository comprises information about the analytics algorithms that are employed by the SecureIoT platform and data to configuring their lifecycle, i.e., processor manifest, definition, orchestrator. The Analytics Registry serves similar purpose like the Probe Registry.
• Policy Repository: This repository stores the policies that prescribe the handling of security issues, which are detected in the IoT systems that are protected. These policies are defined by the operator of the SecureIoT platform and services.
• SLA repository: This repository contains SLA reports along with configuration data about SLAs. It interfaces to components of the SLA Group.
• Security Knowledge Base (SKB) Repository: This includes publicly available data on known vulnerabilities and risks, and corresponding CTI (Cyber Threat Intelligence) graphs. It’s role it to facilitate the look up and resolution of attack patterns, as a means of automating processes and task for risk assessment and compliance auditing services. In the scope of the implementation of the SecureIoT architecture, the contents of the SKB integrate sources of security knowledge from MITRE (Massachusetts Institute of Technology Research & Engineering) and NIST (National Institute of Standards and Technology): MITRE’s CAPEC (Common Attack Pattern Enumeration and Classification collection);MITRE’s CVE (Common Vulnerabilities and Exposures collection); MITRE’s CWE (Common Weakness Enumeration collection);MITRE’s CPE (Common Platform Enumeration collection). NISTs CVSS (Common Vulnerability Scoring System collection).
• Configuration Management Database (CMBD): This database contains information about all the assets of the IoT systems that are to be protected, along with their attributes and configuration parameters.

The Security and Privacy Group

This group of components models and keeps track of the different security and privacy policies that are used by SecureIoT compliant systems. It provides functionalities for modelling policies and trustworthiness in abstract, standards-based and interoperable ways. In particular, the security policies used by other groups and services of the SecureIoT architecture, can be interoperable as soon as they are mapped and transformed to the standards-based policy and trustworthiness models of this group. The group comprises two main modules:

• Security and Privacy Policies Interoperability: This component provides support for the definition of interoperable security policies, which are accordingly used by other components of the SecureIoT architecture. To this end, it provides support for policy abstractions and policy descriptions in a standards-based manner. For example, in the implementation of the SecureIoT platform, XACML (eXtensible Access Control Markup Language) based policies are supported in order to facilitate the assessment of attributes and rules in a common abstraction.
• The Trustworthiness Metrics and Utility Calculation: This component identifies the trustworthiness of each participant (e.g., provider of IoT platform) based on standards-based metrics specified by the Industrial Internet Consortium (IIC). It encompasses the IIC model and utility calculation tools that facilitate the assessment of a participant’s trustworthiness based on defined policies and configuration data.

The Risk Assessment Service Group

This group of components provides a service that checks the IoT system/deployment that is being protected against a set of known vulnerabilities databases, like NIST’s NVD (National Vulnerability Database) or CVSS (Common Vulnerability Scoring System). The service operates on the collected security data for the target IoT deployment as well as stored CTI (Cyber Threat Intelligence) data. In principle, The Risk Assessment service tries to match patterns of vulnerabilities against the collected data and in case it discovers that the IoT deployment is exposed to a vulnerability it raises an alert. To this end, the service leverages of the SKB of the Global Repository group. The Risk Assessment group service comprises the following components:

• Risk Assessment Engine (RAE): This engine implements the logic of the service itself. It makes use of a Risk Assessment database that contains sets of known vulnerabilities and interacts with its user through the Risk Assessment Dashboard. The RAE comprises it own database (RAE DB) and operates based on its own set of rules (RA-Rules) that implement the risk assessment logic.
• Risk Assessment Dashboard: This component provides a user interface to the Risk Assessment Engine. Mitigation actions that are proposed by the Risk Assessment Engine are presented to the Dashboard allowing the user to decide for their enforcement. These actions are eventually carried out through the SPEP component of the Data Management Group.

The Compliance Auditing Service (CAS) Group

This group checks and verifies the compliance of the protected IoT system/deployment to regulatory related requirements, e.g., GDPR, NIS, etc. The service operates on collected security data as well as regulatory requirements that are expressed as security and privacy policies. The engine that implements the service verifies that the collected data conform to the regulatory requirements as expressed through the respective policies. The latter are managed through the Policy Engine of the SecureIoT architecture. If no verification can be secured, it raises alerts to the CAS console. The group comprises the following components:

• Compliance Auditing Manager: Supports the auditing of the target IoT application, the specification of policies and the generation of the respective (compliance auditing) reports.
• Compliance Auditing GUI: This provides a user interface to the Compliance Auditing Manager.

The Programming Support Group

This groups implements the Programming Support Service, which provides programming level support for security controls through annotations and a set of policies for backing their handling at runtime. The Policy Engine of the SecureIoT architecture is responsible for applying the defined policies and is common to the Compliance Auditing and the Programming Support services. The main component of the group is the Programming Support Manager, which comprises the Policy Manager that allows the specification of policies and the Model Manager that enables the definition of the policy models.

The SLA Group

This group of components supports the management and auditing of Service Level Agreements (SLA) between IoT systems operators (i.e. security data providers) and the SecureIoT services providers (i.e. security data processors). In general, in the scope of a SECaaS service, an SLA has to be put in place between IoT system operators and SecureIoT services providers. To support the management of such SLAs, the group includes the following components:

• SLA probes: These are specialized probes that collect SLA related information. They are placed in different parts of the SecureIoT architecture, including probes in the Data Management, Analytics and Risk Assessment Groups. The latter probes are marked as “SLA probes” in the architecture figure. These probes enable the acquisition of (raw) data that are send to the data routing component. The latter transforms raw data to properly structured Observations and stores them to the Observations Repository of the Global Repository.
• SLA Processing Engine: This engine processes raw data and generates SLA reports i.e. reports that provide information about the execution of the SLA (e.g., data collected, data processed, risk assessment reports generated etc.). The latter are stored in a dedicated part of the Global Repository i.e. the SLA Repository, which is destined to support SLA Management. The SLA Repository hosts SLA reports along with configuration data about each SLA.
• SLA Admin Console: This console provides the means for configuring and managing SLAs, based on the processing of configuration data of the SLA Repository.

This architecture has driven the implementation of the SecureIoT platform and its use in securing smart objects and IoT systems in different settings. We intend to present indicative examples of development and deployment of SecureIoT in a future post.