(Editorial Changes)
 
(39 intermediate revisions by 7 users not shown)
Line 1: Line 1:
__NOTOC__
 
<imagemap>
<imagemap>
Image:2.4-TrustSecurity.png|frameless|1000px|Ignite AIoT - Trust & Security
Image:2.4-TrustSecurity.png|frameless|1000px|Ignite AIoT - Trust & Security


rect 79 4 341 65 [[Ignite_AIoT_Framework|Ignite AIoT]]
rect 4 0 651 133 [[AIoT_Framework|More...]]
rect 357 4 618 63 [[Artificial_Intelligence|Artificial Intelligence]]
rect 970 0 1298 133 [[AIoT_Data_Strategy|More...]]
rect 636 4 894 65 [[Internet_of_Things|Internet of Things]]
rect 651 0 970 133 [[Artificial_Intelligence|More...]]
rect 1460 117 1788 209 [[Business_Model|Business Model]]
rect 1298 0 1767 133 [[Digital_Twin_Execution|More...]]
rect 1462 222 1788 312 [[Product_Architecture|Product Architecture]]
rect 1767 0 2095 133 [[Internet_of_Things|More...]]
rect 1462 328 1786 420 [[DevOps_and_Infrastructure|DevOps & Infrastructure]]
rect 2095 0 2542 133 [[Hardware.exe|Hardware.exe]]
rect 1462 434 1786 523 [[Trust_and_Security|Trust & Security]]
 
rect 1462 539 1786 631 [[Reliability_and_Resilience|Reliability & Resilience]]
rect 2764 128 3539 257 [[Product_Architecture|More...]]
rect 1462 645 1786 735 [[Verification_and_Validation|Verification & Validation]]
rect 2764 257 3539 390 [[Agile AIoT|More...]]
rect 2764 385 3539 518 [[AIoT_DevOps_and_Infrastructure|More...]]
rect 2764 518 3539 651 [[Trust_and_Security|More...]]
rect 2764 651 3539 784 [[Reliability_and_Resilience|More...]]
rect 2764 779 3539 917 [[Verification_and_Validation|More...]]
 


desc none
desc none
</imagemap>
</imagemap>


== Ignite AIoT: Trust & Security ==
<s data-category="AIoTFramework"></s>
Digital Trust – or trust in digital solutions – is a complex topic. When do users deem a digital product actually trustworthy? What if a physical product component is added, as in smart, connected products? While security certainly is a key anbler of Digital Trust, there are many other aspects which are important, including ethical considerations, data privacy, quality and robustness (including reliability and resilience). Since AIoT-enabled products can have a direct, physical impact on the well-being of people, safety also plays an important role.


Safety traditionally is closely associated with Verification and Validation, which has its own, dedicated section in Ignite AIoT. The same holds true for robustness (see Reliability and Resilience). Since security is such a key enabler, it will have its own, dedicated discussion here, followed by a summary of AIoT Trust Policy Management. Before delving into this, we first need to understand the AI and IoT-specific challenges from a security point of view.
Digital Trust (or trust in digital solutions) is a complex topic. When do users deem a digital product truly trustworthy? What if a physical product component is added, as in smart, connected products? While security is certainly a key enabler of Digital Trust, there are many other aspects that are important, including ethical considerations, data privacy, quality and robustness (including reliability and resilience). Since AIoT-enabled products can have a direct, physical impact on the well-being of people, safety also plays an important role.


Safety is traditionally closely associated with Verification and Validation; which has its own, dedicated section in Ignite AIoT. The same holds true for robustness (see Reliability and Resilience). Since security is such a key enabler, it will have its own, dedicated discussion in this section, followed by a summary of AIoT Trust Policy Management. Before delving into this, we first need to understand the AI and IoT-specific challenges from a security point of view.
__TOC__
__TOC__


== AI-related trust and security challenges ==
= Why Companies Invest in Cyber Security =
As excited as many business managers are about the potential applications of AI, as sceptical are many users and citizens. A key challenge with AI is that it is per-se not explainable: There are no more explicitly coded algorithms, but rather „black box“ models which are trainined and fine-tuned over time with data from the outside, with no chance of tracing and „debugging“ them the traditional way at runtime. While Explainable AI is trying exactly this challenge, there are no satisfactory solutions available yet.
[[File:2.4-WhySecurity.png|800px|frameless|center|link=|Why companies invest in cyber security]]
 
= AI-related Trust and Security Challenges =
As excited as many business managers are about the potential applications of AI, many users and citizens are skeptical of its potential abuses. A key challenge with AI is that it is ''per se'' not explainable: there are no more explicitly coded algorithms, but rather "black box" models that are trained and fine-tuned over time with data from the outside, with no chance of tracing and "debugging" them the traditional way at runtime. While Explainable AI is trying to resolve this challenge, there are no satisfactory solutions available.


One key challenge with AI is bias: While the AI model might be statistically correct, it is being fed training data which includes a bias, which will result in usually unwanted behaviour. For example, an AI-based HR solution for the evaluation of job applicants which is trained on biased data will result in biased recommendations.  
One key challenge with AI is bias: while the AI model might be statistically correct, it is being fed training data that include a bias, which will result in (usually unwanted) behaviour. For example, an AI-based HR solution for the evaluation of job applicants that is trained on biased data will result in biased recommendations.  


While bias is often introduced unintentionally, there are also many potential ways to intentionally attack and AI-based system. A [https://www.belfercenter.org/publication/AttackingAI recent report] from the Belfer Center describes two main classes of AI attacks: Input Attacks and Poisioning Attacks.
While bias is often introduced unintentionally, there are also many potential ways to intentionally attack an AI-based system. A [https://www.belfercenter.org/publication/AttackingAI recent report] from the Belfer Center describes two main classes of AI attacks: Input Attacks and Poisoning Attacks.


'''Input attacks:''' These kind of attacks are possible because an AI model never covers 100% of all possible inputs. Instead, statistical assumption are made and mathematical functions are developed to allow creation of an abstract model of the real world, derived from the training data. So-called adverserial attacks try to exploit this by manipulating input data in a way that confuses the AI model. For example, a small sticker added to a stop sign can confuse an automous vehicle and make it think that it is acually seeing a green light.  
'''Input attacks:''' These kinds of attacks are possible because an AI model never covers 100% of all possible inputs. Instead, statistical assumptions are made, and mathematical functions are developed to allow creation of an abstract model of the real world derived from the training data. So-called adversarial attacks try to exploit this by manipulating input data in a way that confuses the AI model. For example, a small sticker added to a stop sign can confuse an autonomous vehicle and make it think that it is actually seeing a green light.  


'''Posioning attacks:''' This type of attack aims at corrupting the model itself, typically during the training process. For example, malicious training data could be inserted to install some kind of back-door in the model. This could, for example, be used to bypass a building security system or confuse a military drone.
'''Poisoning attacks:''' This type of attack aims at corrupting the model itself, typically during the training process. For example, malicious training data could be inserted to install some kind of backdoor in the model. This could, for example, be used to bypass a building security system or confuse a military drone.


== IoT-related trust and security challenges ==
= IoT-related Trust and Security Challenges =
Since IoT is dealing with the integration of physical products, one has to look beyond the cloud and enterprise perspective, including networks and physical assets in the field. If a smart connected product is suddenly not working anymore because of technical problems, users will lose trust and wish back the dumb, non-IoT version of it. If hackers use an IoT-connected toy to invade a family`s privacy sphere, this is a violation of trust beyond the normal hacked internet account. Consequently, addressing security and trust for any IoT-based product is key.
Since the IoT deals with the integration of physical products, one has to look beyond the cloud and enterprise perspective, including networks and physical assets in the field. If a smart connected product is suddenly no longer working because of technical problems, users will lose trust and wish back the dumb, non-IoT version of it. If hackers use an IoT-connected toy to invade a family's privacy sphere, this is a violation of trust beyond the normal hacked internet account. Consequently, addressing security and trust for any IoT-based product is key.


The OWASP (The Open Web Application Security Project, a nonprofit foundation) project has published the OWASP IoT Top 10, a list of the top security concerns which each IoT product must address:
The OWASP (The Open Web Application Security Project, a nonprofit foundation) project has published the OWASP IoT Top 10, a list of the top security concerns that each IoT product must address:
* Weak Guessable, or Hardcoded Passwords
* Weak Guessable, or Hardcoded Passwords
* Insecure Network Services
* Insecure Network Services
Line 49: Line 57:
* Lack of Physical Hardening
* Lack of Physical Hardening


Understanding these additional challenges is key. However, in order to address them - together with the previously discussed, AI-related challenges - a pragmatic approach is required which fits in directly with the product teams DevOps approach. The result is sometimes also referred to as DevSecOps, which will be introduced in the following.
Understanding these additional challenges is key. However, to address them -- together with the previously discussed AI-related challenges -- a pragmatic approach is required that fits directly with the product team's DevOps approach. The result is sometimes also referred to as DevSecOps, which will be introduced in the following.
 
== DevSecOps for AIoT ==
DevSecOps augments the DevOps approach, integrating security practices into all elements of the DevOps cycle. While traditionally many security teams are centralized, in the DevSecOps approach it is assumed that security is actually delivered by the DevOps team and processes. This starts with Security-by-Design, but also includes integration, testing and delivery.


From an AIoT perspective, the key is to ensure that DevSecOps is addressing all challenges presented by the different aspects of AIoT: AI, cloud/enterprise, network, and IoT-devices/assets. The figure below provides an overview of the proposed AIoT DevSecOps model for AIoT.
= DevSecOps for AIoT =
DevSecOps augments the DevOps approach, integrating security practices into all elements of the DevOps cycle. While traditionally many security teams are centralized, in the DevSecOps approach it is assumed that security is actually delivered by the DevOps team and processes. This starts with Security-by-Design, but also includes integration, testing and delivery. From an AIoT perspective, the key is to ensure that DevSecOps addresses all challenges presented by the different aspects of AIoT: AI, cloud/enterprise, network, and IoT devices/assets. The following figure provides an overview of the proposed AIoT DevSecOps model for AIoT.


[[File:2.4-DevSecOps.png|1000px|frameless|center|DevSecOps for AIoT]]
[[File:2.4-DevSecOps.png|1000px|frameless|center|link=|DevSecOps for AIoT]]


DevSecOps needs to address each of the 4 DevOps quadrants, as defined in the Ignite AIoT section on [[DevOps_and_Infrastructure|DevOps and Infrastructure]]. In addition, Security Planning is added as a fifth quadrant. The following will look at each of these 5 quadrants in detail.
DevSecOps needs to address each of the four DevOps quadrants. In addition, Security Planning was added as a fifth quadrant. The following will look at each of these five quadrants in detail.


=== Security Planning for AIoT ===
= Security Planning for AIoT =
Security Planning for AIoT must first determine the general approach. Next, Threat Modeling will provide insights into key threats and mitigation strategies. Finally, the security architecture and setup has to be determined. Of course this is an iterative approach, which required continuous evaluation and refinement.
Security Planning for AIoT must first determine the general approach. Next, Threat Modeling will provide insights into key threats and mitigation strategies. Finally, the security architecture and setup must be determined. Of course, this is an iterative approach, which requires continuous evaluation and refinement.
==== DevSecOps Approach ====
== DevSecOps Approach ==
The first step towards enabling DevSecOps for an AIoT product organization is to ensure that key stakeholders agree on the security method used, and how to integrate it with the planned DevOps setup. In addition, clarity must be reached on resources and roles:  
The first step toward enabling DevSecOps for an AIoT product organization is to ensure that key stakeholders agree on the security method used and how to integrate it with the planned DevOps setup. In addition, clarity must be reached on resources and roles:  
* Is there a dedicated budget for DevSecOps (training, consulting, tools, infrastructure, certification)
* Is there a dedicated budget for DevSecOps (training, consulting, tools, infrastructure, certification)?
* Will there be a dedicated person (or even team) with the security hat on?
* Will there be a dedicated person (or even team) with their security hat on?
* How much time is each developer expected to spend on security?
* How much time is each developer expected to spend on security?
* Will the project be able to afford dedicated DevSecOps training for the development teams?
* Will the project be able to afford dedicated DevSecOps training for the development teams?
* Will there be a dedicated security testing team?
* Will there be a dedicated security testing team?
* Will there be external support, e.g. an external company performing the penetration tests?
* Will there be external support, e.g., an external company performing the penetration tests?
* How will security-related reporting be set up during development and operations?
* How will security-related reporting be set up during development and operations?


==== Threat Modeling ====
== Threat Modeling ==
Threat Modeling is a widely established approach for identifying and predicting security threats (using the attacker’s point of view), and protecting IT assets by building a defense strategy that prepares the appropriate mitigation strategies. A threat models provides a comprehensive view of an organization’s full attack surface, and helps to make decisions on how to prioritize security-related investments.
Threat Modeling is a widely established approach for identifying and predicting security threats (using the attacker’s point of view) and protecting IT assets by building a defense strategy that prepares the appropriate mitigation strategies. Threat models provide a comprehensive view of an organization’s full attack surface and help to make decisions on how to prioritize security-related investments.


There are a number of established threat modeling techniques available, including [https://threatmodeler.com/threat-modeling-methodologies-overview-for-your-business/ STRIDE and VAST]. The figure below describes the overall threat modeling process.
There are a number of established threat modeling techniques available, including [https://threatmodeler.com/threat-modeling-methodologies-overview-for-your-business/ STRIDE and VAST]. The figure following describes the overall threat modeling process.


[[File:2.4-ThreatModeling.png|700px|frameless|center|Threat Modeling]]
[[File:2.4-ThreatModeling.png|700px|frameless|center|link=|Threat Modeling]]


First, the so-called [https://en.wikipedia.org/wiki/Security_Target Target of Evaluation (ToE)] must be defined, including security objectives and requirements, as well as a definition of assets in scope.
First, the so-called [https://en.wikipedia.org/wiki/Security_Target Target of Evaluation (ToE)] must be defined, including security objectives and requirements, as well as a definition of assets in scope.
Line 83: Line 89:
Second, the Threats & Attack Surfaces must be identified. For this, the STRIDE model can be used as a starting point. [https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html STRIDE] provides a common set of threats, as defined in the table below (including AIoT-specific examples).
Second, the Threats & Attack Surfaces must be identified. For this, the STRIDE model can be used as a starting point. [https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html STRIDE] provides a common set of threats, as defined in the table below (including AIoT-specific examples).


[[File:2.4-STRIDE.png|800px|frameless|center|STRIDE]]
[[File:2.4-STRIDE.png|800px|frameless|center|link=|STRIDE]]
 
The STRIDE threat categories can be used to perform an in-depth analysis of the [https://community.arm.com/iot/b/internet-of-things/posts/five-steps-to-successful-threat-modelling attack surface]. For this purpose, threat modeling usually uses component diagrams of the target system and applies the threat categories to it. An example is shown in the following figure.
 
[[File:2.4-STRIDEApplied.png|700px|frameless|center|link=|Analyzing the attack surface]]


The STRIDE threat categories can be used to perform an in-depth analysis of the [https://community.arm.com/iot/b/internet-of-things/posts/five-steps-to-successful-threat-modelling attack surface]. For this purpose, threat modeling usually uses component diagrams of the target system, and applies the threat categories to it. And example is shown in the figure below.
Finally, the potential severity of different attack scenarios will have to be evaluated and compared. For this process, an established method such as the Common Vulnerability Scoring System (CVSS) can be used. CVSS uses a score from zero to ten to help rank different attack scenarios. An example is given in the following figure.
[[File:2.4-CVSS.png|800px|frameless|center|link=|CVSS]]


[[File:2.4-STRIDEApplied.png|700px|frameless|center|Analyzing the attack surface]]
Next, the product team needs to define a set of criteria for dealing with the risks on the different levels, e.g.
* High risk: Fixed immediately
* Medium risk: Fixed in next minor release
* Low risk: Fixed in next major release


Finally, the potential severity of different attack scenarios will have to be evaluated and compared. For this process, an established method like the Common Vulnerability Scoring System (CVSS) can be used. CVSS uses a score from zero to ten in order to help rank different attack scenarios. An example is given in the figure below.
To manage the identified and classified risks, a risk catalog or risk register is created to track the risks and the status. This would usually be done as part of the overall defect tracking.
[[File:2.4-CVSS.png|800px|frameless|center|CVSS]]


==== Security architecture & setup ====
== Security Architecture & Setup ==
Securing an AIoT system is not a single task, and the results of the threat modeling exercise are likely to show attack scenarios of very different kinds. Some of these scenarios will have to be addressed during the later phases of the DevSecOps cycle, e.g. during development and testing. However, some basic security measures can usually already be established as part of the system architecture and setup, including:
Securing an AIoT system is not a single task, and the results of the threat modeling exercise are likely to show attack scenarios of very different kinds. Some of these scenarios will have to be addressed during the later phases of the DevSecOps cycle, e.g., during development and testing. However, some basic security measures can usually already be established as part of the system architecture and setup, including:
* Basic security measures, such as firewalls and anti-virus software
* Basic security measures, such as firewalls and anti-virus software
* Installation of network traffic monitors and port scanners
* Installation of network traffic monitors and port scanners
* Hardware-related security architecture measures, e.g. Trusted Platform Module (TPM) for extremely sensitive systems
* Hardware-related security architecture measures, e.g., Trusted Platform Module (TPM) for extremely sensitive systems


These types of security-related architecture decisions should be made in close alignment with the product architecture team, early in the architecture design.
These types of security-related architecture decisions should be made in close alignment with the product architecture team, early in the architecture design.


=== Secure AIoT Dev ===
== Integration, Testing, and Operations ==
In DevSecOps, the development teams must be integrated into all security-related activities.
 
On the code-level, regular code reviews from a security perspective can be useful.
In '''DevSecOps''', the development teams must be integrated into all security-related activities. On the code-level, regular code reviews from a security perspective can be useful. On the hardware-level, design and architecture reviews should be performed from a security perspective as well. For AI, the actual coding is usually only a small part of the development. Model design and training play a more important role and should also be included in regular security reviews.
On the hardware-level, design and architecture reviews should be performed as well from a security perspective.
For AI, the actual coding is usually only a small part of the development. Model design and training plays a more important role, and should also be included in regular security reviews.


=== Secure AIoT and Continuous Integration ===
'''Continuous Integration''' has to address security concerns specifically on the code level.  
Continuous Integration has to address security concerns specifically on the code level.
Code-level security tests/inspections include:
Code-level security tests/inspections inlucde:
* Before compilation/packaging:  SAST can be used for Static Application Security Testing.
* Before compilation/packaging:  SAST can be used for Static Application Security Testing.
* IAST (Interactive application security testing) uses code instrumentation, which can slow down performance. Individual decisions about enabling/disabling it will have to be made as part of the CI process.
* IAST (Interactive application security testing) uses code instrumentation, which can slow down performance. Individual decisions about enabling/disabling it will have to be made as part of the CI process.


=== Secure AIoT and Continuous Testing ===
'''Security testing''' includes tests with a specific focus on testing for security vulnerabilities.
Security testing includes tests with a specific focus on testing for security vulnerabilities.
These can include:
These can include:
* Applications, e.g. DAST (Dynamic Application Security Testing)
* Applications, e.g., DAST (Dynamic Application Security Testing)
* Hardware-related security tests
* Hardware-related security tests
* AI model security tests
* AI model security tests
* End-to-End System, e.g. manual and automated penetration tests
* End-to-End System, e.g., manual and automated penetration tests


=== Secure AIoT and Continuous Delivery ===
'''Secure operations''' have to include a number of activities, including:
Secure Operations has to include a number of activities, including:
* Threat Intelligence
* Threat Intelligence
* Infrastructure and Network Testing (incl. Secure OTA)
* Infrastructure and Network Testing (including Secure OTA)
* Security tests in the field
* Security tests in the field
* RASP: Runtime Application Self-Protection
* RASP: Runtime Application Self-Protection
* Monitor/Detect/Response/Recover
* Monitor/Detect/Response/Recover


== Security Standards and Regulatory Compliance for AIoT ==
== Minimum Viable Security ==
TBD
The key challenge with security planning and implementation is to find the right approach and the right level of required resource investments. If too little attention (and % of project resources and budget) is given to security, then there is a good chance that this will result in a disaster - fast. However, if the entire project is dominated by security, this can also be a problem. This relates to the resources allocated to different topics, but also to the danger of over-engineering the security solutions (and in the process making it too difficult to deliver the required features and usability). Figuring out the Minimum Viable Security is something that must be done between product management and security experts. Also, it is important that this is seen as an ongoing effort, constantly reacting to new threats and supporting the system architecture as it evolves.


== Trust Policy Management for AIoT ==
= Trust Policy Management for AIoT =
In addition to the security-related activities, an AIoT product team should also consider taking a proactive approach towards broader trust policies.
In addition to security-related activities, an AIoT product team should also consider taking a proactive approach toward broader trust policies.
These trust policies can include topics such as:
These trust policies can include topics such as:
* Data sharing policies (e.g. sharing of IoT data with other stakeholders)
* Data sharing policies (e.g., sharing of IoT data with other stakeholders)
* Transparency policies (e.g. making data sharing policies transparent to end users)
* Transparency policies (e.g., making data sharing policies transparent to end users)
* Ethics-related policies (e.g. for AI-based decisions)
* Ethics-related policies (e.g., for AI-based decisions)


Taking a holistic view on AIoT trust policies and establishing a central trust policy management can significantly contribute to creating trust between all stakeholders involved.
Taking a holistic view of AIoT trust policies and establishing central trust policy management can significantly contribute to creating trust between all stakeholders involved.


{{Infobox|The [http://digitaltrustforum.org/ Digital Trust Forum (DTF)] is working on Trust Policy Management for AIoT-based smart, connected products}}
{{Infobox|The [http://digitaltrustforum.org/ Digital Trust Forum (DTF)] is working on Trust Policy Management for AIoT-based smart, connected products}}


== Authors and Contributors ==
= Authors and Contributors =


{|{{Borderstyle-author}}
{|{{Borderstyle-author}}
|{{Dirk Slama|Title=AUTHOR}}
|{{Designstyle-author|Image=[[File:Dirk Slama.jpeg|left|100px]]|author={{Dirk Slama|Title=AUTHOR}}}}
<br>
{{Designstyle-author|Image=[[File:Pablo Endres.jpg|left|100px]]|author={{Pablo Endres|Title=CONTRIBUTOR}}}}
|}
|}

Latest revision as of 17:48, 27 June 2022

More...More...More...More...More...Hardware.exeMore...More...More...More...More...More...Ignite AIoT - Trust & Security

Digital Trust (or trust in digital solutions) is a complex topic. When do users deem a digital product truly trustworthy? What if a physical product component is added, as in smart, connected products? While security is certainly a key enabler of Digital Trust, there are many other aspects that are important, including ethical considerations, data privacy, quality and robustness (including reliability and resilience). Since AIoT-enabled products can have a direct, physical impact on the well-being of people, safety also plays an important role.

Safety is traditionally closely associated with Verification and Validation; which has its own, dedicated section in Ignite AIoT. The same holds true for robustness (see Reliability and Resilience). Since security is such a key enabler, it will have its own, dedicated discussion in this section, followed by a summary of AIoT Trust Policy Management. Before delving into this, we first need to understand the AI and IoT-specific challenges from a security point of view.

Why Companies Invest in Cyber Security

Why companies invest in cyber security

AI-related Trust and Security Challenges

As excited as many business managers are about the potential applications of AI, many users and citizens are skeptical of its potential abuses. A key challenge with AI is that it is per se not explainable: there are no more explicitly coded algorithms, but rather "black box" models that are trained and fine-tuned over time with data from the outside, with no chance of tracing and "debugging" them the traditional way at runtime. While Explainable AI is trying to resolve this challenge, there are no satisfactory solutions available.

One key challenge with AI is bias: while the AI model might be statistically correct, it is being fed training data that include a bias, which will result in (usually unwanted) behaviour. For example, an AI-based HR solution for the evaluation of job applicants that is trained on biased data will result in biased recommendations.

While bias is often introduced unintentionally, there are also many potential ways to intentionally attack an AI-based system. A recent report from the Belfer Center describes two main classes of AI attacks: Input Attacks and Poisoning Attacks.

Input attacks: These kinds of attacks are possible because an AI model never covers 100% of all possible inputs. Instead, statistical assumptions are made, and mathematical functions are developed to allow creation of an abstract model of the real world derived from the training data. So-called adversarial attacks try to exploit this by manipulating input data in a way that confuses the AI model. For example, a small sticker added to a stop sign can confuse an autonomous vehicle and make it think that it is actually seeing a green light.

Poisoning attacks: This type of attack aims at corrupting the model itself, typically during the training process. For example, malicious training data could be inserted to install some kind of backdoor in the model. This could, for example, be used to bypass a building security system or confuse a military drone.

IoT-related Trust and Security Challenges

Since the IoT deals with the integration of physical products, one has to look beyond the cloud and enterprise perspective, including networks and physical assets in the field. If a smart connected product is suddenly no longer working because of technical problems, users will lose trust and wish back the dumb, non-IoT version of it. If hackers use an IoT-connected toy to invade a family's privacy sphere, this is a violation of trust beyond the normal hacked internet account. Consequently, addressing security and trust for any IoT-based product is key.

The OWASP (The Open Web Application Security Project, a nonprofit foundation) project has published the OWASP IoT Top 10, a list of the top security concerns that each IoT product must address:

  • Weak Guessable, or Hardcoded Passwords
  • Insecure Network Services
  • Insecure Ecosystem Interfaces (Web, backend APIs, Cloud, and mobile interfaces)
  • Lack of Secure Update Mechanism (Secure OTA)
  • Use of Insecure or Outdated Components
  • Insufficient Privacy Protection
  • Insecure Data Transfer and Storage
  • Lack of Device Management
  • Insecure Default Settings
  • Lack of Physical Hardening

Understanding these additional challenges is key. However, to address them -- together with the previously discussed AI-related challenges -- a pragmatic approach is required that fits directly with the product team's DevOps approach. The result is sometimes also referred to as DevSecOps, which will be introduced in the following.

DevSecOps for AIoT

DevSecOps augments the DevOps approach, integrating security practices into all elements of the DevOps cycle. While traditionally many security teams are centralized, in the DevSecOps approach it is assumed that security is actually delivered by the DevOps team and processes. This starts with Security-by-Design, but also includes integration, testing and delivery. From an AIoT perspective, the key is to ensure that DevSecOps addresses all challenges presented by the different aspects of AIoT: AI, cloud/enterprise, network, and IoT devices/assets. The following figure provides an overview of the proposed AIoT DevSecOps model for AIoT.

DevSecOps for AIoT

DevSecOps needs to address each of the four DevOps quadrants. In addition, Security Planning was added as a fifth quadrant. The following will look at each of these five quadrants in detail.

Security Planning for AIoT

Security Planning for AIoT must first determine the general approach. Next, Threat Modeling will provide insights into key threats and mitigation strategies. Finally, the security architecture and setup must be determined. Of course, this is an iterative approach, which requires continuous evaluation and refinement.

DevSecOps Approach

The first step toward enabling DevSecOps for an AIoT product organization is to ensure that key stakeholders agree on the security method used and how to integrate it with the planned DevOps setup. In addition, clarity must be reached on resources and roles:

  • Is there a dedicated budget for DevSecOps (training, consulting, tools, infrastructure, certification)?
  • Will there be a dedicated person (or even team) with their security hat on?
  • How much time is each developer expected to spend on security?
  • Will the project be able to afford dedicated DevSecOps training for the development teams?
  • Will there be a dedicated security testing team?
  • Will there be external support, e.g., an external company performing the penetration tests?
  • How will security-related reporting be set up during development and operations?

Threat Modeling

Threat Modeling is a widely established approach for identifying and predicting security threats (using the attacker’s point of view) and protecting IT assets by building a defense strategy that prepares the appropriate mitigation strategies. Threat models provide a comprehensive view of an organization’s full attack surface and help to make decisions on how to prioritize security-related investments.

There are a number of established threat modeling techniques available, including STRIDE and VAST. The figure following describes the overall threat modeling process.

Threat Modeling

First, the so-called Target of Evaluation (ToE) must be defined, including security objectives and requirements, as well as a definition of assets in scope.

Second, the Threats & Attack Surfaces must be identified. For this, the STRIDE model can be used as a starting point. STRIDE provides a common set of threats, as defined in the table below (including AIoT-specific examples).

STRIDE

The STRIDE threat categories can be used to perform an in-depth analysis of the attack surface. For this purpose, threat modeling usually uses component diagrams of the target system and applies the threat categories to it. An example is shown in the following figure.

Analyzing the attack surface

Finally, the potential severity of different attack scenarios will have to be evaluated and compared. For this process, an established method such as the Common Vulnerability Scoring System (CVSS) can be used. CVSS uses a score from zero to ten to help rank different attack scenarios. An example is given in the following figure.

CVSS

Next, the product team needs to define a set of criteria for dealing with the risks on the different levels, e.g.

  • High risk: Fixed immediately
  • Medium risk: Fixed in next minor release
  • Low risk: Fixed in next major release

To manage the identified and classified risks, a risk catalog or risk register is created to track the risks and the status. This would usually be done as part of the overall defect tracking.

Security Architecture & Setup

Securing an AIoT system is not a single task, and the results of the threat modeling exercise are likely to show attack scenarios of very different kinds. Some of these scenarios will have to be addressed during the later phases of the DevSecOps cycle, e.g., during development and testing. However, some basic security measures can usually already be established as part of the system architecture and setup, including:

  • Basic security measures, such as firewalls and anti-virus software
  • Installation of network traffic monitors and port scanners
  • Hardware-related security architecture measures, e.g., Trusted Platform Module (TPM) for extremely sensitive systems

These types of security-related architecture decisions should be made in close alignment with the product architecture team, early in the architecture design.

Integration, Testing, and Operations

In DevSecOps, the development teams must be integrated into all security-related activities. On the code-level, regular code reviews from a security perspective can be useful. On the hardware-level, design and architecture reviews should be performed from a security perspective as well. For AI, the actual coding is usually only a small part of the development. Model design and training play a more important role and should also be included in regular security reviews.

Continuous Integration has to address security concerns specifically on the code level. Code-level security tests/inspections include:

  • Before compilation/packaging: SAST can be used for Static Application Security Testing.
  • IAST (Interactive application security testing) uses code instrumentation, which can slow down performance. Individual decisions about enabling/disabling it will have to be made as part of the CI process.

Security testing includes tests with a specific focus on testing for security vulnerabilities. These can include:

  • Applications, e.g., DAST (Dynamic Application Security Testing)
  • Hardware-related security tests
  • AI model security tests
  • End-to-End System, e.g., manual and automated penetration tests

Secure operations have to include a number of activities, including:

  • Threat Intelligence
  • Infrastructure and Network Testing (including Secure OTA)
  • Security tests in the field
  • RASP: Runtime Application Self-Protection
  • Monitor/Detect/Response/Recover

Minimum Viable Security

The key challenge with security planning and implementation is to find the right approach and the right level of required resource investments. If too little attention (and % of project resources and budget) is given to security, then there is a good chance that this will result in a disaster - fast. However, if the entire project is dominated by security, this can also be a problem. This relates to the resources allocated to different topics, but also to the danger of over-engineering the security solutions (and in the process making it too difficult to deliver the required features and usability). Figuring out the Minimum Viable Security is something that must be done between product management and security experts. Also, it is important that this is seen as an ongoing effort, constantly reacting to new threats and supporting the system architecture as it evolves.

Trust Policy Management for AIoT

In addition to security-related activities, an AIoT product team should also consider taking a proactive approach toward broader trust policies. These trust policies can include topics such as:

  • Data sharing policies (e.g., sharing of IoT data with other stakeholders)
  • Transparency policies (e.g., making data sharing policies transparent to end users)
  • Ethics-related policies (e.g., for AI-based decisions)

Taking a holistic view of AIoT trust policies and establishing central trust policy management can significantly contribute to creating trust between all stakeholders involved.

The Digital Trust Forum (DTF) is working on Trust Policy Management for AIoT-based smart, connected products

Authors and Contributors

Dirk Slama.jpeg
DIRK SLAMA
(Editor-in-Chief)

AUTHOR
Dirk Slama is VP and Chief Alliance Officer at Bosch Software Innovations (SI). Bosch SI is spearheading the Internet of Things (IoT) activities of Bosch, the global manufacturing and services group. Dirk has over 20 years experience in very large-scale distributed application projects and system integration, including SOA, BPM, M2M and most recently IoT. He is representing Bosch at the Industrial Internet Consortium and is active in the Industry 4.0 community. He holds an MBA from IMD Lausanne as well as a Diploma Degree in Computer Science from TU Berlin.


Pablo Endres.jpg
PABLO ENDRES, SEVENSHIFT
CONTRIBUTOR
Pablo Endres, Founder of SevenShift GmbH. Experienced security consultant and Professional Hacker. Pablo’s career has taken place mostly doing security in a variety of industries, like Cloud Service providers, Banks, Telecommunications, contact centers, and universities. He holds a degree in computer engineering, as well as a handful security certifications. Pablo has founded multiple companies in different continents and enjoys hacking, IoT, teaching, working with new technologies, startups, collaborating with Open Source projects and being challenged.