Throughout the previous chapters of this book, we have presented how different parts of an IoT system could be built and what components and frameworks are important and useful. In this chapter, we present what Intel is doing in the arena of IoT as complete vertical solutions. IoT spans a broad range of different markets, and therefore solutions must be tailored to the specific purposes of those markets and the specific security threats encountered or expected in those environments. There are similarities, to be sure. Each industry has different security demands due to the nature of the information handled and the mandate to conform to particular regulatory and industry standard bodies’ requirements. This chapter will provide an overview of the different verticals, associated security requirements, threats, and mitigations.
It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood.
Throughout the previous chapters of this book, we have presented how different parts of an IoT system could be built and what components and frameworks are important and useful. In this chapter, we present what Intel is doing in the arena of IoT as complete vertical solutions. IoT spans a broad range of different markets, and therefore solutions must be tailored to the specific purposes of those markets and the specific security threats encountered or expected in those environments. There are similarities, to be sure. Each industry has different security demands due to the nature of the information handled and the mandate to conform to particular regulatory and industry standard bodies’ requirements. This chapter will provide an overview of the different verticals, associated security requirements, threats, and mitigations.
Advertisement
The IoT ecosystem is fragmented by nature with multiple verticals, but at the end of the day, we strive to leverage a common set of hardware and software building blocks, augmented with accelerators, to meet domain unique requirements. Security is a horizontal capability, as we have shown in Chapters 3 and 4. However, because of the differences within each vertical market, frequently different verticals expand and enhance the common set of security capabilities in order to achieve what their particular market demands. This perspective is shown in Figure 6-1 which articulates unique vertical security and regulatory requirements built from a common set of security minimal viable platform features. Successfully accomplishing this customization necessitates a system of systems perspective, which is an understanding that no system exists in a vacuum but must interact with other systems – human, technological, and process. As we delve into each vertical market in this section, common themes from the security MVP will stand out to the reader, but these will be adapted by each domain to address security and privacy by design, security-performance trade-offs at the system level, and integration into existing systems and processes – the system of systems perspective.
Before diving deeply into each vertical domain, we present a brief overview of each domain and point out the commonalities, and differences, between them.
Figure 6-1
IoT vertical framework: enhance the foundation with value-added features to enable verticals
×
The Transportation Solutions domain is focused on safety and leverages the foundational security MVP, augmenting HW/FW/SW capabilities to meet the prevalent standards and regulations including SAE J-3101, EVITA, HIS, AutoSAR, and autonomous driving standard (levels L1–L5). Anti-tampering which is related to preventing and/or detecting an attempt to alter or modify the platform for stealing secrets is critical to achieving transportation safety. Anti-cloning is related to preventing and/or detecting an attempt to copy or clone the platform including the HW/FW/SW. Some of these capabilities may align with other verticals. The Transportation Solutions domain also has some unique requirements such as memory zeroization where the state of the memory is initialized to a known value (zero) to eliminate the secrets from DRAM and to meet safety requirements for known state of software structures and variables. Virtualization support in hardware is mandatory for the transportation domain in order to maximize hardware utilization while minimizing cost without compromising security – this usually involves VTd and VTx technologies as we saw in the ACRN hypervisor in Chapter 4.
When a capability is aligned across more than two verticals, it makes sense to move this capability into the security MVP foundation. This then implies that some verticals do not make use of every security MVP feature. However, as we have found at Intel, as features move into the security MVP, other vertical domains begin to leverage that capability as well. An example of this is FIPS 140 Level 2 which is now a common requirement across all the verticals.
Advertisement
The Retail Solution domain’s security is focused on protecting the credit card payment information and the data in financial transactions. The identity of the users at the POS terminals is also of significance, leading to unique protections to handle personally identifiable information (PII). A new retail segment known as responsive retail addresses targeted marketing for the brick-and-mortar retailer while improving the shopping experience for consumers using advertisements customized according to the age, gender (using facial and body imaging), and other characteristics of the consumer. The retail domain in general is also heavily invested in remote manageable devices (upgradable and recoverable) over wired and wireless networks (in-band and out-of-band). Provisioning devices with the proper software loads and unique credentials to facilitate transactions to financial institutions and suppliers is an important, though not unique, characteristic of retail IoT systems.
In the in-band recovery scenario, a corrupt application can be recovered with the help of the operating system, and a corrupt operating system can be recovered with the help of the BIOS/UEFI/boot loader. We discussed some of these capabilities in Chapter 4, where we introduced the difficult problem of upgrading the platform firmware, such as the BIOS/UEFI/boot loader itself. For these situations, an out-of-band capability or physical access is required to recover the platform from corrupted firmware.
The Industrial Solutions domain covers the convergence of IT (information technology) with OT (operational technology), along with the related issues of incorporating existing systems and infrastructure (brownfield deployments) with new systems, capabilities, and infrastructure (greenfield deployments). Traditionally OT dealt with the factory and manufacturing floor tasks, and IT infrastructure managed the office and back-end tasks. Creating a smart factory requires the convergence of IT and OT, allowing the data to flow seamlessly between IT and OT for effective decision making and factory process execution. In a brownfield scenario, industries have long been deploying the devices and equipment with legacy bus interfaces and little to no network connectivity. The greenfield scenario is where the equipment and devices can all be true IoT with maximum high (or higher) bandwidth connectivity. Bridging the gap between brownfield and greenfield requires the use of proxy gateways with network protections and network admission technologies using device attestation. Software orchestration is essential in Industrial IoT (IIOT) where standards compliant architecture such as ISA-95 and Software-Defined Industrial Systems (SDIS) are federated for service orchestration, allowing all devices to both consume and provide services. Security services center around integrity and availability, and device recovery and reprovisioning for new services or changeovers to new tasks must be done quickly and efficiently or the loss on revenue can be steep.
The Military, Aerospace, and Government domain has the highest and most robust security requirements, and the need for performant crypto features, including encryption/decryption, digital signature/verification, and random number generation, has high-throughput requirements. This domain also demands a configurable Root of Trust (RoT), augmenting the Intel RoT with a particular custom hardware Root of Trust private to the domain with higher robustness requirements. The alternative roots of trust include customized RoT in an Intel SoC/PCH or an FPGA. Physical tamper prevention, detection, and recovery are key features which are also tied to the secure debug ports, protections from side-channel attacks on clock, and prevention/detection of power glitching, among a host of other hardware-specific attacks. When attesting the IoT devices in this domain, in addition to remote attestation, a local or offline attestation feature is a mandatory requirement. Many advanced security requirements appear first in the Government domain and then slowly begin to appear in other domains. Side-channel resistance is a recent example; protection from covert and side channels has been a long-standing requirement in the military domain, but not until the appearance of the Spectre and Meltdown attacks the side-channel protections are included in commercial RFPs. However, since these attacks were disclosed, side-channel protections are the new baseline and part of the common security MVP.
The Digital Surveillance System (DSS) domain is focused on network video recorders, networked Internet Protocol (IP) cameras, and computer vision accelerators. In a DSS system of systems, there is a need for multiple roots of trust including Intel SoC, FPGA, and Movidius. Provisioning the DSS cameras and video recorders is critical to prevent the IP camera–related attacks, including the Mirai botnet attacks which used default and brute-force login credentials2 and the Persirai botnet which took over cameras using a recent zero-day vulnerability.3 DSS systems also require performant crypto features, since the video stream must be encrypted and watermarked at line rate speeds. Another critical requirement for the DSS segment is data provenance, authenticated and integrity-protected metadata and attributes attached to the video and photographic data to prove the data, time, location, and device used for collection.
The DSS domain encounters some unique data protection and privacy regulations such as EU’s General Data Protection Regulation (GDPR) and the California data privacy regulations which impact every type of business and impose severe penalties for not complying.
Common Domain Requirements and the Security MVP
The IoT Base Platform MVP is defined with foundational building blocks and the realization that the security requirements are achieved, up to nearly 90% in many cases, through common silicon used across all the domains. System design is dynamic, and decision vectors usually include security, privacy, resiliency, availability, and safety. The MVP is a triad of HW, FW, and SW capabilities that enables dynamic design where the domain features from HW, FW, and SW are selected diligently to reflect the trade-offs and optimize for the relevant decision vector. The NIST Cyber-Physical Systems Framework4 for HW and SW co-design articulates trade-offs between the cyber and physical components of the IoT system.
Matthew Rosenquist articulated in a blog post5 that although security is valuable, it comes at a cost – the cost for new equipment, the cost for training personnel on new technology, and the cost to develop new processes to utilize the technology. But just because we do not pay the cost to build security into our systems does not mean the cost goes away. We still incur costs due to the risks we inherently adopt by rejecting certain security features and the potential (and actual costs) to clean up after a security incident. These choices leading to costs of failure determine the risk management process as shown in Figure 6-2. A potential future cost of a security incident must be weighed against the actual cost to add security and the soft cost incurred by productivity impacts due to additional security. Good security design involves teaming up with customers and end users to understand these costs and balance the overall system to achieve reasonable security, preventing or deterring the most egregious and most likely threats while providing a useful and useable system. Often ignored are the external costs where unrelated third-party entities suffer the consequences of attacks, and one specific example is the DNS-administrating company Dyn. For almost an entire day, Mirai botnet took down the sites including Twitter, CNN, Guardian, Netflix, and so on whose DNS services were being administered by Dyn.6 The optimal security is a balance of cost, user experience, and risk. Since the IoT domains are different, and the threats are ever evolving, and the user interface and experience paradigms change, this balancing act becomes a dynamic living act. The security MVP is only the start of that act. Engagement in the domain and balancing domain-specific requirements is the process. The detailed sections that follow articulate Intel’s perspective and engagement in these IoT-specific domains.
Figure 6-2
Balancing security against cost, risk, and productivity
×
One additional comment is warranted to the reader at this point. It has become a norm to employ complementary technologies such as FPGA accelerators, Movidius Computer Vision IP, and ASIC accelerators to meet the requirements from applications in various domain solutions. These complementary technologies augment the base platform for increased performance, HSM7 needs, functional safety, and real-time latency workloads. These technologies are outside the scope of this book, but details on these technologies can be found on the Intel web site.8 Finally, although we provide a reasonable overview of the use cases, threats, and security objectives for the domains, the following coverage is not meant to be comprehensive, and to do so would require a much more exhaustive threat modeling exercise, with subsequent peer reviews, to refine the threat model and design for specific products.
Some Common Threats
Just as the domains share a common hardware and software security MVP, the domains have threats that are common across all vertical domains as well. These common threats are discussed in this section.
Device masquerading: A device employed or modified by a hacker is tricked to identify as a legitimate system on the IoT network. This sometimes can be extremely difficult to detect and rectify. The consequences and methods employed to launch such an attack depend upon the particular use case, and these idiosyncrasies are discussed next.
Boot integrity compromise: The pre-OS FW such as BIOS or other boot loaders can be tampered with by modifying or replacing/reprogramming the image on flash device. This can have serious consequences since all other layers in the stack are on the top of this layer in the bootstrapping sequence.
Offline storage–related attacks: Mass storage or any removable storage media can be attacked offline by copying the media or stealing the physical media device, and then sifting through the data to find secrets, or using brute force techniques on keys or passwords to reveal sensitive data.
Retail Solutions
The retail POS devices are becoming a part of the IoT domain, and increasingly these devices such as the POS terminals, mobile payments, and so on are connected to the Internet and accessed by cashiers and staff using tablets and other mobile devices. In this section, we’ll discuss what is required to be Payment Card Industry (PCI) compliant on Intel platforms and a way to get there.
According to the PCI specification, the hackers are mainly interested in stealing the cardholder data. “By obtaining the Primary Account Number (PAN) and sensitive authentication data, a thief can impersonate the cardholder, use the card, and steal the cardholder’s identity.”
Sensitive cardholder data can be stolen from many places including a compromised card reader or data in a payment system database, snooping the store’s wireless or wired networks. Each of these is a trust boundary, and the assets need to be protected as they traverse each boundary.
Securing the cardholder data starts where it is captured at the point of sale and as it flows into the payment system. The ideal approach is refraining from storing any cardholder data. The protection should span card readers, POS systems, networks and wireless access routers, payment card data storage and transmission, and online payment applications and shopping carts.
Not complying with PCI and the associated security objectives will result in potential liabilities including the following: customer base loses confidence and goes to other merchants resulting in decreased sales, additional cost of reissuing new payment cards, losses from fraud claims, higher incremental costs of compliance, legal costs, settlements and judgments, fines and penalties due to financial regulation violation, termination of ability to accept payment cards, lost jobs (C-suite security and other positions), and in the worst case going out of business.
The PCI Data Security Standard (DSS)9 version 3.2.1 high-level overview is reproduced in Figure 6-3, and the Intel security assets that enable building a PCI compliant device are discussed.
Figure 6-3
High-level overview of PCI Data Security Standard
×
Security Objectives and Requirements
Assets in a retail IoT device include the following:
Data at rest and in transit: Cardholders’ data and transactional information.
Identity of the consumer: Personally identifiable information (PII) should be stored under strict access control, preferably using encryption for data-at-rest.
Identity of the POS device: Device’s credentials are essential to mitigate the remote hacker attacks and to have a robust connection to the device cloud infrastructure.
The hardware components: The HW BOM list in the platform must always be protected via a transparent supply chain during production and deployment and guarded in the field as appropriate.
The FW including pre-OS boot loader: The FW on the platform is a critical asset.
Kernel and user mode SW components: The OS kernel and user mode SW components including applications are all important assets.
Threats
The PCI DSS standard has outlined high-level threat groups. Figure 6-4 takes those groups and extends it to include responsive retail. System compromise or theft can be realized by masquerading the retail POS device. Data at rest or data in transit can be stolen by leveraging offline data and network sniffers/monitors for traffic analysis. The provisioning step can be compromised or missed/blocked updates can be leveraged to compromise the system. Identity theft and credit card disclosure of payment information are equally important concerns. The retail advertisement terminals can be compromised to display graffiti or distorted images on digital bulletin boards. The runtime environment of a retail POS or another device can be infected with malware to do extensive persistent damage to the assets on the device and on the cloud. The following bills from California State Legislature mandate provisioning a unique password and a device certificate for unique authentication before first use:
California Senate Bill10 No. 327, CHAPTER 886 TITLE 1.81.26. SECURITY OF CONNECTED DEVICES, 1798.91.04. (b) (1) and (2).
California Assembly Bill11 No. 1906, CHAPTER 860 TITLE 1.81.26. SECURITY OF CONNECTED DEVICES, 1798.91.04. (b) (1) and (2).
Figure 6-4
Threat groups of retail segment including responsive retail
×
The same threats can be mapped to a typical platform stack shown in Figure 6-5, and the mitigations using Intel technologies are also included. The HW layer includes all the relevant HW components including the System on Chip, storage, SRAM, scanner, communications modules, and so on. The stack continues upward with boot loader FW, OS Kernel to services to applications.
Figure 6-5
Threats to Retail POS devices with mitigation using Intel HW security building blocks
×
Threat #1: Allows hacker to easily break the integrity of the boot firmware and OS image. Hacker infiltrates the system by subverting execution flow. The mitigation is to implement Boot Guard as explained in Chapter 3 to establish a chain of trust based on a HW Root of Trust. When a FW is tampered and an attempt is made to boot with this unsigned FW, the Boot Guard will detect and will hold the device in reset to prevent further compromises of the sensitive assets.
Threat #2: Unauthorized actors could provision devices to their preferences including usernames, passwords, password reminders, and so on. The Intel Secure Device Onboarding technology could be leveraged to provision the device persona and force to change the default passwords with stricter ones and strong password reminders plus a dual factor authentication. Refer to Chapter 4 for details on SDO.
Threats #3, #7: Transaction data, logging to POS server. This is a critical threat for which an exploit could violate the P2PE requirements of PCI DSS where the cardholder’s data could be obtained by hackers on the network. Intel AES technology in the CPU can be used to encrypt the cardholder’s information to enforce confidentiality. To increase the robustness of this part of the solution, the encryption process can be done inside an SGX enclave to protect from ring 0 or rootkit attacks.
Threat #4: Leaves the cryptographic keys used to protect platform and owner secrets easily recovered or potentially retained in storage. This is once again a critical task to protect the keys used for encrypting the cardholders’ data by storing the keys in a PTT/TPM so that these keys are never exposed to hackers.
Threats #5, #6: Weakness may grant remote hacker access to the device and in turn local network from any remote location. This is a powerful exploit, and mitigation requires strong device credentials such as the Endorsement Key in PTT/TPM to be authenticated by device cloud infrastructure without much manual intervention (to eliminate potential and expensive human errors). All the POS devices should have the firewall and intrusion detection systems implemented. The network routers both wired and wireless must have firewall and intrusion detection SW actively monitoring the network traffic for logging anomalies in real time and store the data for analytics SW. It is important to have analytics SW to mine these logs for patterns for zero-day or known vulnerabilities. A complete platform security stack built pertinent to retail Solutions with Intel security ingredients is shown in Figure 6-6.
Figure 6-6
Platform security stack built pertinent to Retail Solutions
×
At the HW layer, the manageability with Intel Active Management Technology (AMT), secure boot with attestation, encryption, secure key, PTT/TPM, and platform protection are required to be implemented. UEFI/BIOS layer leverages the HW root of trust from Boot Guard and extends the chain of trust (transitive) to the upper layers in the stack. The hypervisor or VMM is optional; if present, it authenticates the VM pre-OS FW and the OS VMs while leveraging the VT HW capabilities to provide the necessary isolation between VMs. The OS is expected to be hardened by leveraging the Intel HW security features such as OS Guard for preventing ring 0 privilege escalation attacks, PTT for secure key storage, and AES and SHA New Instructions for performant crypto operations. The OS can also leverage the SGX for TEE applications and all the while enabling the in-band manageability features via Intel AMT. The application layer implements app whitelisting, virus/malware scanning, and so on.
The end-to-end data flow in a retail POS architecture is shown in Figure 6-7. The entities involved include the payment terminals, peripherals, the POS software inside an Intel-based platform, secure channels of communication, service provider data centers, bank gateway, and store servers.
Figure 6-7
The end-to-end data flow in a Retail POS architecture
×
1.
Native devices pair (cryptographically) directly with the applet for private/secure communications which involves mutual authentication via digital signatures and confidentiality through encryption/decryption and integrity through sign/verify. Establish secure channels from peripherals and servers to process data through the TEE applet. The TEE applet could be an SGX application enclave running inside the TEE to protect the sensitive and valuable code and the data. This will prevent the exposure of credit card or other PII during processing in the memory since the memory contents are encrypted inline.
2.
Legacy devices should encrypt the data to the applet using the Derived Unique Key Per Transaction (DUKPT) with AES-256. DUKPT is a method to manage the key between two endpoints; this key has properties: unique per transaction, symmetric, is a derived key from Base Derivation Key (BDK) known to both endpoints. This key is used in the AES algorithm for encryption and decryption. Currently Triple DES (TDES) is being used, but according to the guidance from NIST on Transitioning the Use of Cryptographic Algorithms and Key Lengths, two-key TDES is deprecated and three-key TDES should be used only for 220 (64-bit) blocks and should not be used after 2023.12
3.
The Dock protects legacy insecure devices to the applet; sample devices include magnetic ink character recognition, keyboards, and barcode scanner. This Dock performs as a proxy for the legacy devices which inherently may be insecure and abstracts the devices by consuming the data in the clear and protecting it before sending to TEE applet.
4.
Data can be encrypted for transmission to bank gateways or store servers. Use TEE applet to create a safe place to process transactions and enact policies.
5.
Management servers manage policies and behavior of the system. Through a secure channel from a console to the applet, the provisioning of keys, credentials, and policies is performed. This helps in managing peripheral crypto keys and telemetry data remotely and enables pull requests to access transactions at the request of the retailer.
Design trade-offs: Considering the PCI standard and vectors, functional safety is not a primary factor, but security and privacy are the critical factors. As outlined in PCI DSS standard, the resiliency in terms of mitigating physical attack threats is also applicable where a card reader could be stolen and replace legitimate devices with fraudulent devices to steal the card data.
Standards – Regulatory and Industry
The PCI Digital Security Standard (PCI DSS) is one of the main standards that mandate most of the preceding security objectives. The PCI DSS also mandates FIPS 140-2 for secure storage of keys via a PTT/TPM.13
The solutions in a vehicle can be grouped into Software-Defined Cockpit (SDC) as shown in Figure 6-8. Intel Silicon and solutions enable building SDC applications for the next generation of advanced automotive electronics. The SDC itself can be subdivided into rear seat entertainment, digital instrument cluster, in-vehicle infotainment, and advanced driver-assistance system (ADAS). The rear seat entertainment solutions include a DVD/Blu-ray player, virtual office, and connection to IVI front system and mobile devices with cloud connectivity.
The digital instrument cluster unit includes display for speed, fuel level, odometer, trips, and so on. This cluster may also be able to project images on the windshield (heads-up display) with alerts for low fuel or low tire pressure via tire pressure monitoring system (TPMS).
The in-vehicle infotainment (IVI) unit includes the GPS-based navigation system, audio/video entertainment systems, and connection to mobile devices for phone communication and music with voice recognition features. This unit also includes a backup camera and cameras for parking assist. The unit may include gesture or touch inputs.
The advanced driver-assistance system (ADAS) is a complex system of systems with features including blind spot monitoring, adaptive cruise control, lane departure warning, cross traffic warning, brake assist and collision avoidance, self-parking, and driver monitoring for fatigue or undesirable distractions.
As the vehicles start communicating with the external environment spanning more than just the cloud, many IoT-related threats become pertinent. In Figure 6-9, the vehicle communicates with many clusters including GPS systems, Vehicle-to-vehicle (V2V) network, local repair shop or dealership network, roadside assistance network, mobile devices, Radio Data Systems, and Internet backbone via Internet service provider (ISP) through 4G/5G wireless. Some of these network clusters such as repair shops and roadside assistance may also connect to the Internet backbone.
The devices in a car communicate with different external entities in regular and autonomous driving applications:
Vehicle to vehicle (V2V): These communications are occurring in real time between vehicles on the roads.
Vehicle to infrastructure (V2I): These communications are occurring between the vehicle and the infrastructure such as dealership or an auto body shop or a traffic management system.
Vehicle to device (V2D): These communications are occurring between a vehicle and a device such as smartphone over Bluetooth, remote control key, wireless diagnostics device, and so on.
Vehicle to cloud (V2C): These communications are occurring between a vehicle and a private or a public cloud to retrieve or upload the recent traffic/weather updates via GPS and Radio Data interfaces.
Figure 6-9
Connected vehicle infrastructure – more than just devices and cloud
×
Security Objectives and Requirements
Each electronic control unit (ECU) in the connected vehicle is expected to have the following security attributes:
A unique, hardware-based ID that’s immutable and standards compliant
Capability for mutual authentication
A HW root of trust
Protected Boot (verified and measured)
Secure storage for key material
Tamper detection, prevention, and policy enforcement
A Trusted Execution Environment
All intra-car information has the option of integrity (hash, HMAC), confidentiality (encryption), authentication (digital signatures), and nonrepudiation (digital signatures).
All data pertaining to users/occupants is encrypted to maintain privacy.
All inter-car information is authenticated and has integrity (hash, HMAC) and confidentiality (encryption).
Near real-time, secure over-the-air updates for SW and FW.
All safety-critical operations are partitioned; other services are virtualized for both efficiency and security.
Car network
Runs Anomaly Detection SW on the device and the gateway within the vehicle for detecting known and zero-day vulnerabilities. This SW could also connect to a Threat Intelligence database on the cloud for cross-referencing the signatures for quantifying and classifying against known viruses and malware signatures/patterns.
Provides whitelisting for identities allowed to authenticate and send data externally
Threats
With the preceding security objectives in the context, let’s discuss the attacker profiles, threat surfaces, and specific threats. Figure 6-10 depicts five attacker profiles with diverse technical knowledge, access levels, and goals. A car thief possesses varied technical knowledge with wireless and/or physical access with a goal of stealing the car which may entail disabling the alarm and jumping the wires to start the car and drive off. A car thief may employ remote attacks through Telematics Control Unit (TCU)/IVI and On-Board Diagnostics (e.g., On-Board Diagnostics (OBD-II) routinely accessed during service or tuning in the clear).
A hacker may possess medium to high technical knowledge with a remote/wireless access and may operate with goals to either get fame or steal any PII including passwords to music, credit card payment information, and so on. A hacker may employ device masquerading and launch remote attacks through Telematics Control Unit (TCU)/IVI. A hacker may also go after information disclosure of third-party algorithm/IP.
A criminal may possess medium to very high technical knowledge with wireless and/or physical access with an intent to harm the passengers and the bystanders. A criminal may employ remote attacks through Telematics Control Unit (TCU)/IVI and On-Board Diagnostics (e.g., OBD-II).
A workshop technician may possess medium to very high technical knowledge with physical access and will operate with a goal to modify the settings such as rewinding the odometer, fuel usage/statistics, and so on by leveraging the On-Board Diagnostics (e.g., OBD-II). A similar attack profile is where a persistent vehicle alteration is done by a legitimate user to modify the original design by either increasing the performance, jailbreaking, customizing the user interface, adding new regions into DVD/Blu-ray player, and so on.
A counterfeiter or a competitor may possess high to very high technical knowledge with physical access and may wish to study the design/architecture to reverse engineer and steal Intellectual Property or clone the device. This attacker has physical access to the device in a laboratory environment with access to sophisticated tools/logic analyzers, IR/thermal scanning, differential power analysis, and so on to monitor the vehicle networking bus traffic using On-Board Diagnostics (e.g., OBD-II) interfaces. The potential assets to be recovered could be intellectual property spanning Silicon, board-level HW, FW, and OS-level ingredients.
Figure 6-10
Attacker profiles in the Transportation Solutions domain
×
Automotive Threat Surfaces: Refer to Figure 6-11 for distinct hackable areas in a vehicle. These areas can be organized into three groups, physical access, in-vehicle network structure, and wireless/remote access to the vehicle.
Physical access
On-Board Diagnostics (e.g., OBD-II routinely accessed during service or tuning in the clear)
Vehicle networking bus (CAN, KLINE, MOST, Ethernet AVB, etc.) connections to various ECUs
Wireless access to vehicle
Keyless entry
Bluetooth and Bluetooth-connected devices
TPMS
Cellular, Internet, and applications (V2X)
Radio/audio system(s)
Remote telematics
Figure 6-11
Distinct hackable areas in a vehicle
×
Mitigations
Mitigating the preceding threats would require a defense in depth approach as shown in Figure 6-12, beginning with securing the vehicle systems and followed by securing the communications:
Securing the vehicle systems includes the following assets:
Sensors and actuators: All the sensors and actuators must be authenticated (digital signatures) before communicating and protect the integrity (sign/verify using SHA3) and confidentiality (using AES-256) of the valuable data on the bus interfaces.
Computer vision and AI (path planning): The machine learning or deep learning assets such as the weights, training data, test/validation data, models, and so on must be protected by encrypting the assets on the storage and decrypting into the memory in a TEE. The details for this architecture are outside the scope of this book.
Networks and ECUs: The networks and any gateways must have firewalls and intrusion detection systems, and the ECUs must be securely booted and deploy the HW security building blocks as listed here.
Securing communications:
Vehicle to everything (V2X): All the devices on the V2X interfaces must be mutually authenticated (using digital signatures) before communicating and protect the integrity (sign/verify using SHA3) and confidentiality (using AES-256) of the valuable data on the bus interfaces.
Maps, code, and data to/from the cloud: The maps database and access to online databases must be authenticated and authorized via digital signatures and login credentials. Any data exchange with the Cloud must also be subjected to the same protections.
Infotainment, mobile devices, wearables: The infotainment devices and mobile devices including wearables/smartphones/others must be mutually authenticated (digital signatures) before communicating and protect the integrity (sign/verify using SHA3) and confidentiality (using AES-256) of the valuable data on the bus interfaces
Figure 6-12
Defense in depth architecture
×
The threats explained earlier can be effectively mitigated by leveraging the Intel HW security building blocks shown in Figure 6-13. The boot integrity of the automotive systems can be secured with protected boot (verified and measured boot). The protected storage feature can be leveraged to store the keys securely and perform low bandwidth encryption/decryption and sign/verify of the message data. For higher robustness and high bandwidth use cases, the authentication of data whether it is messages or others can be achieved in the TEE such as SGX by invoking SHA-NI in the CPU instruction set.
Hardware security building blocks:
1.
Unique Device ID using PKI compliant keys/certificates via PTT/TPM.
2.
True RNG using the RNG instructions in the CPU. With reasonably good entropy to be used as a nonce or a seed for subsequent key generation.
3.
Verified boot using Boot Guard to ensure a HW Root of Trust and a robust transient chain of trust.
4.
Secure storage using PTT/TPM for both data and keys.
5.
Trusted Execution Environment using SGX.
6.
Cryptographic acceleration using AES and SHA new instructions.
7.
Key generation using PTT/TPM for application keys.
8.
Secure clock using tamper-resistant HW supplied timers for precise logging of retail transactions.
9.
Monotonic counters – HW supplied and tamper-resistant counters that are guaranteed to increment only.
10.
Secure debug for locking/disabling the debug ports at the factory and ability to unlock/enable to securely debug.
11.
Physical tamper detection and protection against side-channel attacks.
Figure 6-13
HW security building blocks for defense in depth
×
Design trade-offs: For the Transportation Solutions domain, functional safety, security, privacy, and resiliency are all pertinent. The automobiles have a long life and are safety/life critical by design; it is essential to integrate safety and security to prevent false positives and false negatives from functional safety infrastructure. There is also a need for the automobiles to detect the physical tamper and send a “kill pill” to the platform to trigger a lockdown of the security engine and vault the secrets to avoid unauthorized disclosure. This is critical so that Break Once Run Everywhere (BORE) attacks to retrieve the universal keys are mitigated.
Standards – Regulatory and Industry
The SAE J3101 is one of the main government regulations that mandate most of the preceding security objectives. FIPS 140-2 L2/3 and NHTSA are also considered vital for the US markets.
Industrial Control System (ICS) and Industrial IoT (IIoT)
As the manufacturers and producers seek to respond to greater pressures for higher production rates, lower production costs, and the ability to compete in a global marketplace, they continue to embrace the efficiencies created by a transition to Industry 4.0 and the Industrial IoT (IIoT). These are broad terms that encompass the concept of a combined information technology (IT) and operational technology (OT) and include flexible automation of OT processes, application of artificial intelligence to OT problems, automated device and process orchestration, and higher resiliency in the presence of system failures, to name a few of the more prevalent topics. In Figure 6-14, a notional diagram of an IIoT architecture is portrayed for the purpose of identifying security concerns and discussing threats and security objectives.
Figure 6-14
Notional Industrial IoT architecture
×
This architecture in Figure 6-14 is notional because it is not created from any actual deployment nor is it intended to portray a particular type of industrial plant. Instead it depicts different types of components in an industrial setting that are typical of the devices Intel produces or contributes components for in the IIoT. The notional diagram depicts an Edge-to-Cloud and a SCADA-to-Edge-to-Cloud architecture. On the left side of the diagram are various gateways that control devices. Simple devices such as meters, tank levels, temperature sensors, and vibration sensors can be controlled using a simple gateway. These gateways may control many such devices simultaneously. More complex devices such as industrial robots or CNC machines require more advanced smart gateways. These devices have the ability to load different types of control programs and workloads and may include real-time control loops that encompass line and human safety protocols. Finally, existing systems also need connectivity to the back-end IIoT systems and are connected through a service gateway that supports existing protocols and may translate those data elements into different forms to be carried in newer protocols and reformatted messages. All three types of gateways may be connected by various communications technologies including wired and wireless technology.
The back-end systems are still logically segmented into OT and IT concerns, though in the IIoT they may share some physical computing devices and servers. OT control is focused on orchestration and workload management and providing clear visibility of the systems and operations to OT engineers.
Security Objectives and Requirements
Assets in the IIoT gateways are included in the following security objectives, where sub-bullets are security objectives derived from top-level security objectives. These objectives are aligned with the IIC.15
Data at rest and in transit: All commands received by the gateway from the OT/IT control centers must be protected from modification (integrity), duplication (replay), and optionally disclosure (confidentiality).
Identity of the device: All devices shall maintain at least one identity public and private key pair used to uniquely identify the device to other entities.
Identity of the control authority: All commands received by the gateway from the OT/IT control centers must be verified as authentic by comparing the signing public key with authorized trust anchor keys. This security objective and the previous one imply the following derived security objective to address trust anchors and identity keys.
Protection of trust anchors and identity keys: All identity keys and trust anchors must be securely stored in the gateway to prevent use by unauthorized software processes/users. A trust anchor key is a public key of an entity (like the OT control center) that is inherently trusted by the device; an identity key is a public and private key pair that is used to prove the device’s identity to other entities. Protection of identity keys should include limiting the use of the identity key to a RoT (see Chapter 3).
Integrity of the boot system and operating system: Verification of boot firmware and software, with secure storage of trusted measurements collected during boot, shall be enforced at every soft and hard boot event.
Trusted reporting of device health: Devices shall be capable of reporting their current health including measurements from their last boot cycle and any software or firmware updates performed since their last boot. This reporting must include a proof of origin signature that unambiguously attests to the source of the report (Root of Trust for Reporting) and all claimants producing data for the report (Root of Trust for Measurement).
Verification of software updates, configuration, and workloads: All updates to the device shall come from an authorized source verified against one of the device’s trust anchors; updates shall be protected from modification (integrity) and verified by the device prior to first use that the update has not been corrupted. Updates include new or updated software and firmware, configuration files, and workloads.
Whitelisting of applications and network endpoints: Devices shall maintain a whitelist of authorized software and the identity and address of network endpoints that are authorized to communicate with the device, and the device shall prevent the execution of any software not on the whitelist and ignore/terminate any communication streams from network endpoints not on the whitelist.
Management of connected peripherals: Devices shall maintain a whitelist and authorized configuration of all connected peripherals, whether wired or wirelessly connected to the device, and ignore or disconnect any peripherals not authorized to be connected with the device.
Storage integrity: Devices shall maintain the integrity of stored elements including software, configuration files, workloads, data measurements, and processing logs; devices shall prevent unauthorized access to stored elements.
Design trade-offs: Industrial systems are designed specifically for harsh environments and for interoperability with existing systems and devices. Requirements around these constraints dominate the design decisions. Oftentimes, this means removing security protections, like encryption, because end systems cannot perform those security functions or intermediary systems are dependent on receiving this data unencrypted and do not have the capability to add this layer of protection. In addition, industrial type systems tend to require low power profiles, either because they are deployed in a remote location (oil pumping station) with limited power capabilities or crowded together in a small space where heat from power dissipation is considered a problem. In both cases, lower powered devices tend to have fewer security capabilities. The important trade-off in these cases is to support security features that address the most critical threat – identification of proper control authorities using protected trust anchors for authentication of commands, configuration, and software update.
Threats
The threats to IIoT systems are composed of both external threat actors and insiders. Both groups can mount destructive attacks on IIoT systems, though most threat analysis focuses on external attackers. Figure 6-15 identifies the primary threats and consequences.
Threat #1: Device hijacking – An attacker uses vulnerabilities in the device software to inject their own software or firmware on the device and corrupt data, stop executing processes, falsify health or data reporting, or disrupt the industrial operations flow.
Mitigation: Use of advanced containment techniques to isolate software, including virtualization, containers, and TEEs. Ability to restart workloads or execute workloads as microservices limits the attack surface and time an attack can be active.
Threat #2: Device masquerading – An attacker creates a digital twin of the real device and intercepts or copies data to discover proprietary information or to deny the real device access to important information, commands, or workloads.
Mitigation: Device identity and mutual authentication for all communications flows from the OT/IT center are vital to prevent these attacks. Physical and logical protection of the device’s identity credentials prevents an adversary from stealing credentials. Storage of a device’s unique identity credentials within a TEE is required to prevent the use of a digital twin to masquerade as the real device.
Threat #3: Application-level data tampering and denial of service – An attacker uses metadata spoofing or replay, SQL injection attacks, or resource exhaustion attacks to trick a device into performing an improper action or creating a temporary DoS attack on the device.
Mitigation: End-to-end authentication of all command flows and proper whitelisting of network endpoints are critical to preventing such attacks. Recognizing and responding to DoS and DDoS network attacks requires network infrastructure and the ability to reconfigure network components to isolate and quarantine misbehaving devices.
Threat #4: Permanent denial of service (PDoS) attacks – An attacker is able to inject a firmware update or critical operating system update that damages the hardware of the device or takes the device offline requiring depot-level service to repair the device.
Mitigation: All updates and changes to the device require an authorized command from the OT that is cryptographically verified from a secured trust anchor on the device. Device management agents with privileged capabilities on the device must not also have direct network capability, in order to reduce network attacks that also give attackers elevated privileges on the device, because such elevated privileges allow an attacker to perform actions that can modify the base firmware and software on the device.
Threat #5: Tampering and information disclosure of OT data – An attacker modifies or collects data flowing between the OT center and a device, exposing proprietary data.
Mitigation: All data between the OT/IT centers and the device should include confidentiality protection (end-to-end security), but minimally must include integrity protections.
Standards – Regulatory and Industry
There is not one standard that defines the Industrial IoT (IIoT), and within different segments of the industrial industry there are different regulatory or standards groups provide specific guidance and direction. It is not possible to cover all of these groups here. Generally, standards and industry groups attempt to create a set of interoperable frameworks and middleware, along with connectivity and data or protocol standards that enable the creation of heterogeneous system of systems to enable the IIoT. Figure 6-16 provides an overview of the major standards influencing Intel designs.
Figure 6-16
Common IIoT standards, middleware, protocols, and connectivity standards
×
Digital Surveillance System
Information security in digital surveillance systems (DSS) became a public problem in 2015 and 2016, culminating in the Mirai DDoS attacks, the largest botnet-based distributed denial of service attacks ever at that time in which two separate attacks took Akamai and Dyn (and all their customers) offline for hours. Because surveillance devices often need to be accessible over the Internet, not to mention that the industry moved only recently from analog interconnections to digital IP interconnections, information security is a new problem for the DSS segment. What can compound this problem is the industry is a physical security–driven industry (as opposed to IT driven), and the industry’s expertise in cybersecurity for surveillance systems has lagged the general Internet cybersecurity awareness.
The DSS segment spans more than just traditional building surveillance and closed-circuit TV (CCTV) systems. DSS includes mobile surveillance around vehicles and human beings, including vehicular cameras and emergency response body camera systems. And extending beyond simple surveillance, DSS includes the use of camera systems in smart cities for intelligent traffic control and smart toll collection systems. As briefly discussed in the last section, the use of camera systems in retail can aid a business in understanding customer experiences in brick-and-mortar retail establishments, adding extending information to the business intelligence systems that improve customer experience, inform decisions on product placement, and aid the design of store layout. As usage of these DSS systems increase, the opportunity for a repeat of the attacks like Mirai, Persirai,17 Devil’s Ivy,18 and Peekaboo19 can become more of a threat. Intel®’s robust hardware-based integrated security provides a capability stack which improves system security.
Figure 6-17
Digital Surveillance System (DSS) typical network architecture
×
In Figure 6-17, the network architecture of a typical DSS system is portrayed. Video flows from the camera to a managed switch where many devices may actually be connected, including other servers and individual laptops. The video data is typically separated from other traffic on the managed switch via a protected VLAN. This does not encrypt or otherwise protect the traffic or video streams, it merely creates a different logical segment on the network reserved only for video traffic. Depending on the type of managed switch, this may not present much difficulty for an attacker to overcome. Besides the cameras, a network video recorder (NVR) video management system (VMS) is also connected to the managed switch. This system enables the recording of multiple video streams to a storage array. There is typically a local storage array also connected to the managed switch on the VLAN, but a remote storage array in the cloud provides long-term storage. This means that the NVR VMS and the local storage device are involved in uploading the video streams to the cloud. Viewing of the video streams may be done locally, off the NVR VMS system, or remotely. Remote access may be enabled to the NVR VMS system, or more may be provided only from the cloud, depending on the network security at the local installation and the security features enabled on the NVR VMS.20
From the network architecture in Figure 6-17, it is also seen that input to the NVR VMS may come from devices other than video cameras. Multifunction print devices are capable of capturing scanned images and using the NVR VMS to store those images for the user. Additionally, a phone can be used to pipe in multimedia including audio only, audio and video, or other encoded streams as a download service (where the phone is acting as a modem) and supply those inputs to the NVR VMS. These input streams are important to understand in the overall DSS segment, since maintaining security for devices other than IP cameras needs to be incorporated into the network security, monitoring, and patch update systems.
The cloud segment of the DSS system includes analytics and advanced artificial intelligence (AI) algorithms used to process media files (audio, video, and still image) and collect data or file/index media according to criteria. This section does not address cloud security concerns, which must be properly accounted for in any DSS system. Cloud security is adequately addressed by other resources.
Security Objectives and Requirements
Using Figure 6-17 as the target for security analysis, the DSS segment includes the following security objectives, which focus on the primary video and audio assets in the system:
Data at rest and in transit: All incoming data streams received by the NVR VMS from the managed switch must be protected from modification (integrity), duplication (replay), and disclosure (confidentiality).
Identity of the device: All devices attached to the managed switch should be uniquely identified; the use of MAC addresses is not considered secure as these can be spoofed by a network adversary. Devices should maintain at least one identity public and private key pair used to uniquely identify the device to other entities and used to set up protected (integrity protected) streams to the NVR VMS.
Integrity of the boot system and operating system: Verification of boot firmware and software, with secure storage of trusted measurements collected during boot, shall be enforced at every soft and hard boot event for all elements of the system, including peripherals connected to the managed switch, the NVR VMS, and the local storage array.
Trusted reporting of device health: Devices shall be capable of reporting their current health including measurements from their last boot cycle and any software or firmware updates performed since their last boot. This reporting must include a proof of origin signature that unambiguously attests to the source of the report (Root of Trust for Reporting) and all claimants producing data for the report (Root of Trust for Measurement). This reporting should be collected by the NVR VMS system when devices connect to record/store their multimedia streams.
Verification of software updates, configuration, and workloads: All updates to the device shall come from an authorized source verified against one of the device’s trust anchors; updates shall be protected from modification (integrity) and verified by the device prior to first use that the update has not been corrupted. Updates include new or updated software, firmware, and configuration files.
Whitelisting of network endpoints: Devices shall maintain a whitelist of authorized network endpoints that are authorized to communicate with the device, and the device shall ignore/terminate any communication streams from network endpoints not on the whitelist.
Management of connected peripherals: The managed switch shall maintain a whitelist of all connected peripherals, whether wired or wirelessly connected to the switch, and ignore or disconnect any peripherals not authorized to be connected with the device. Authentication of connected devices should be performed via cryptographic credentials, not merely MAC or IP addresses which can be spoofed.
Storage integrity: Devices shall maintain the integrity of stored elements including media streams, media metadata, software, configuration files, and processing logs; devices shall prevent unauthorized access to stored elements. Particular care must be taken to protect private keys and symmetric encryption keys that are used for signatures, in transit data confidentiality and integrity or storage confidentiality and integrity. Many systems are required to produce evidence (surveillance videos, body cams, vehicle cams) and this evidence must provide cryptographically assured provenance of the media files and the media file’s metadata which ensures those data items are free from tampering. This protection is paramount to support legally binding evidentiary claims for authenticity and originating source.
Design trade-offs: DSS systems, especially the end collection devices (cameras and audio recorders), are extremely cost sensitive, yet must compete on the ability to collect data in various formats and transmit that data over the network. Those two primary goals translate to specialized hardware capabilities. But the end devices must also operate on very limited power budgets, not unlike the industrial systems, and therefore design trade-offs tend to remove the majority of the security features. Based on the history of attacks these systems have encountered, protection of the software running on these devices are most important. Protected trust anchors that authenticate control authorities and authorize firmware and software updates have the most effect on maintaining security for these devices. Back-end infrastructure, such as the video recorders, control systems, and storage arrays, are normally standard off-the-shelf server class devices that can utilize the full suite of hardware and software protections available on the commercial market.
Threats
Threats to DSS systems are primarily from outside network adversaries. However, from some systems, privileged insiders may need to be included in the threat analysis, especially when such DSS systems are used for building or other surveillance, and a privileged insider can be coerced, bribed, or forced to delete or modify evidence captured by the NVR VMS. Stolen credentials can also make a network outsider appear to be an authorized insider. The following threats should be considered in any DSS system:
Threat #1: Device hijacking – An attacker uses weak authentication credentials (Mirai attack) to take control of a peripheral device on the DSS system; or an attacker uses vulnerabilities in the peripheral device software (Devil’s Ivy or Perisai attacks) to inject their own software or firmware on the device and stop media capture, falsify metadata, or misuse the device computing power to perform other actions (mine for Bitcoin, perform a DDoS attack).
Mitigation #1: Device credentials must be changed prior to installation and fielding of devices. Intel’s Secure Device Onboarding protocol provides a fast and secure mechanism to provision devices with new credentials and configuration without requiring specialized or highly skilled system installation crews. Devices must never have default credentials or default management logins. Inspection of open ports and SNMP capabilities are required to ensure no unauthenticated or easily guessable password credentials are available to an attacker.
Mitigation #2: Although this threat is virtually the same as seen in other segments, the mitigation requirements due to power limitations and smaller compute often prevent using TEEs or software containers to prevent or limit the impact of compromised software. Frequent health checks on the device firmware are required to monitor for any potential zero-day attacks, and response to firmware corruption requires signed updates using a hardware root-of-trust (RoT) that cannot be modified by an attacker, even one that replaces the firmware through physical attack. Careful thought and study of recent attacks (Devil’s Ivy and Perisai) must be done.
Threat #2: Device masquerading – An attacker creates a digital twin of the real device and jams or blocks transmission from the real device to inject false media streams into the system.
Mitigation: Device identity must be used to set up mutually authenticated streams from the collection peripherals to the NVR VMS system; additionally the managed switch should perform access control on all connected devices. Physical and logical protection of the device’s identity credentials prevents an adversary from stealing credentials and creating an evil digital twin. Storage of a device’s unique identity credentials within a TEE is required to prevent the use of a digital twin to masquerade as the real device.
Threat #3: Permanent denial of service (PDoS) attacks – An attacker is able to inject a firmware update or critical operating system update that damages the hardware of the device or takes the device offline requiring depot-level service to repair the device.
Mitigation: All updates and changes to the device require a signed update package that cryptographically verifies against a secured trust anchor on the device. No changes to the software, and especially the firmware, can be made without a signed package update command that comes from a trusted, authenticated source. Additionally, software and firmware updates must be protected against rollback attacks, where an adversary installs validly signed but older software versions that install an old security vulnerability onto the device. Rollback attacks must be prevented by using a protected value to store the software version number for the currently installed software/firmware, and this must be verified against the integrity-protected software version found in the signed software update package.
Threat #4: Unauthorized access to surveillance data – An attacker gains access to surveillance footage that includes private or confidential information to which that attacker should not have access.
Mitigation: Proper access control for all surveillance footage is required. Best practice is to encrypt such footage and provide access control on the cryptographic keys. This ensures that all copies of the footage are equally protected, including backups. This of course shifts the burden of access control to the keys themselves. Proper key storage should include hardware-based protection with two-factor authentication to access the keys. Since backups are encrypted, the backup storage of keys becomes an issue. Having cold or warm sites with hardware security modules (HSM) that are unlocked with smartcards or other hardware tokens is best practice.
Standards – Regulatory and Industry
There are two primary industry standards organized around IP cameras and DSS: ONVIF and PSIA.21 ONVIF (Open Network Video Interface Forum) was formed in 2008 as a nonprofit industry organization to define an interoperable interface standard for IP cameras allowing better interoperability between different manufacturers. ONVIF was originally formed by Axis Communications, Bosch Security Systems, and Sony Corp, but now has over 480 members. ONVIF has defined four profiles for video cameras (Profiles S, G, Q, and T)22; however, as shown in Figure 6-18, necessary security features are not yet mandatory in many profiles.
PSIA (Physical Security Interoperability Alliance) is another industry consortium formed in 2008 covering the interoperability of IP media devices, recording and content management for recorders and video analytics.24 PSIA was founded by 20 member companies including Honeywell, GE Security, and Cisco, but adoption under this specification has stalled with the last publication from this body in 2010. Although there are still many cameras and devices on the market carrying PSIA compliance, PSIA is not considered a leading force in the industry.
Of all the driving forces for security in IP cameras, GDPR and the California Data Privacy Law in the United States are the main concerns. According to the European Data Protection Supervisor (EDPS),25 surveillance footage can be used to identify people directly or indirectly and therefore falls within the GDPR regulations. The EDPS provides guidelines26 to maintain compliance in digital surveillance systems, and much of this guidance focuses on policy, proper notifications through signage, and careful site planning and configuration. EDPS recommended protections cover data in transit (prevent transmissions from interception), data at rest (restriction on access to stored media, including backups), and access control, but these controls must follow the recommendations resulting from a threat analysis. Of all these issues, access control becomes the most difficult and requires good key management that is based in hardware-protected key storage and roots-of-trust. Compliance with the California law should follow similar guidance.
HIPAA (Health Insurance Portability and Accountability Act) may also be applicable in the medical field, relating to building surveillance systems used in hospitals and medical facilities, which must comply with the added burden of inference correlation between a person captured in a video feed within a medical facility and a person’s medical treatment privacy.
Summary
IoT security in the current fragmented ecosystem requires a completely different mindset. This includes leveraging the common Intel security building blocks and accelerators such as Movidius and Intel (Altera) FPGA solutions. It is feasible to maintain a baseline of security capabilities and add the domain-specific features on the top to make the security solution complete for deployment. In some cases, the solution may include a heterogeneous architecture with assets from Intel SoC and accelerators such as FPGA/Movidius. We have seen how the retail Solution domain is influenced by the PCI DSS standard and how this standard can be met with compliance on Intel product–based devices. We have also seen how the Transportation Solutions domain is changing with the connected vehicle concept and the plethora of threats looming over this domain. The specific requirements of TSD can be met using Intel security technologies. Industrial and Digital Surveillance System have their unique robustness and mandatory standards for compliance. Only a subset of IoT verticals are covered in this chapter, but most of these concepts apply readily to the medical field, gaming, print imaging, and so on.
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
