Securing the IMSS Assets

Abstract

This chapter provides an introductory understanding of assets, threat modeling, attacks, and mitigations. Let’s start with a few definitions. Assets are the things that have value or present risk. Assets include personally identifying data like IDs, names, locations; confidential data like trade secrets or intellectual property; and cryptographic secrets like keys. Also the security processes like encryption and decryption processing, hashing, and signing and signature verification can be considered assets.

This chapter provides an introductory understanding of assets, threat modeling, attacks, and mitigations. Let’s start with a few definitions. Assets are the things that have value or present risk. Assets include personally identifying data like IDs, names, locations; confidential data like trade secrets or intellectual property; and cryptographic secrets like keys. Also the security processes like encryption and decryption processing, hashing, and signing and signature verification can be considered assets.

A threat is an agent or activity that is motivated to attack: to steal or tamper with an asset. And Mitigations are the defensive methods to prevent the attacks.

For more information, see the references.

Why Should You Think About Threats?

Threat modeling is a standard practice in security analysis for a number of reasons.

First, threat modeling is a method that provides insight into the assets that need to be protected and into the ways those assets can be compromised. The analysis provides insight into how you can deliver the best value to your customer and maximize your investment in mitigations. You can focus your resources on the most common, easiest attacks on the highest value assets and avoid spending resources on mitigations for threats that are costly to develop or execute. Some of these methods also make it easy to understand defense in depth which not only makes it more difficult to attack an asset, but also, defense in depth may be much easier and less expensive to implement compared to one really elaborate mitigation.

The second benefit of careful security threat modeling is you can prevent losses before they happen, which raises customer satisfaction and keeps customers coming back.

Threat modeling requires thinking in militaristic terms, threats, attacks, defenses, and so on. While this may seem paranoid, it is a necessary mode of thinking for security analysis. One must change their mindset from how a system does work to how it can be fooled or get around mitigations in it to gain access to information or to make it stop working. In order to do that, one must think like an attacker. Secure design means thinking not only about making a system do what it is supposed to do but also designing a system that cannot do what it is not supposed to do.

Summary

Figure 4-1 illustrates the range of types of attacks, examples of typical system assets, technology that can mitigate the attacks, and the general types of adversaries at each level.

Figure 4-1

Attacks, threats, and mitigations

On the left-hand side of the figure, an inverted attack pyramid is shown. The general classes of assets in the white boxes are organized in a hierarchy where the easiest and most prevalent attacks are at the top and the most difficult and least common attacks are at the bottom. The hierarchy also represents the security hierarchy in terms of privilege. For example, if a hypervisor is attacked and compromised, that enables attacks on any higher assets, from the OS kernel to applications and data. As a general rule, when you progress down the asset stack, the assets are more immutable. Data and applications are easy to read or tamper with, but ROM and transistors are much more difficult to observe or change the state of. Some of that is inherent, and some is due to explicit design. The explicit design aspect is because of the hierarchy, that is, if those assets are compromised, anything else in the device or system can be compromised.

Threat Modeling

Threat modeling is performed by analyzing the assets and relevant threats in the context of the system environment, the value (or risk from) of the assets, and the cost and efficacy of the mitigations.

Threat Modeling Terminology

Abbr	Term	Definition
	Active Attack	An attack where the device, its inputs, or its environment are tampered with in order to make the device behave abnormally. Secrets are revealed by exploiting the abnormal behavior of the device. Active attacks are generally more detectable than passive attacks. (See Passive Attack and side channel attack)
APT	Advanced Persistent Threat	An advanced persistent threat is an attack in which an unauthorized person gains access to a network, or a malware component is inserted, and stays there undetected for a long period of time. The purpose of an APT attack is to steal data rather than to cause damage.
	Asset	An asset is something that has intrinsic value to an enterprise or an individual. Also, an asset’s value may be due to the liability or risk it carries for an enterprise or individual. Capabilities that protect functionality or valuable information are also considered security assets. Examples are: • Processing or Storage of data that reveals a person’s identity (private data), for example, IDs numbers, names, sensor data, localization data, affiliations, etc. • Processing or Storage of Cryptographic secrets, for example, Keys, Hashes, constants. • Processing or Storage of confidential data, for example, protected audio or video content streams. • Cryptographic processing capabilities.
	Confidential Data	A person’s or organization’s information, which is expected to be private or disclosed only to selected individuals.
CC	Common Criteria	common criteria for Information Technology Security Evaluation.
	Cryptographic Key	A cryptographic key is a number used by a cryptographic algorithm to convert plain text into cipher text. If the algorithm is symmetric, the same key also converts from cipher text to plain text. There are many different types of keys (see Key Types). According to Kerckhoff’s Principle, a cryptosystem should be secure even if everything about the system, except the key, is known.
	Foundational Asset	Device or System assets upon which the overall security architecture depends. The Root of Trust is the foundational element of security in a device. Other assets considered elements of the security foundation are platform Integrity; Secure IDs; cryptographic key generation and storage; Protected Data; cryptographic algorithms and the instructions and hardware used to compute them; Trusted Platform Modules, and Trusted Execution Technology.
	Malware	Malware (a portmanteau for malicious software) is any software intentionally designed to cause damage to a computer, server, client, or computer network (by contrast, software that causes unintentional harm due to some deficiency is typically described as a software bug)
	Passive Attack	An attack where the crypto device is operated largely within specification. Secrets are revealed by observing physical properties of the device. (see active attack, side channel attack)
	Personally Identifiable Information	“Personally identifiable information” (PII), as used in US privacy law and information security, is information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. The abbreviation PII is widely accepted in the US context, but the phrase it abbreviates has four common variants based on personal/personally, and identifiable/identifying. Not all are equivalent, and for legal purposes the effective definitions vary depending on the jurisdiction and the purposes for which the term is being used. (In other countries with privacy protection laws derived from the OECD privacy principles, the term used is more often “personal information,” which may be somewhat broader: in Australia’s Privacy Act 1988 [Cth] “personal information” also includes information from which the person's identity is “reasonably ascertainable,” potentially covering some information not covered by PII.) < http://en.wikipedia.org/wiki/Personally_identifiable_information >
POSM	Power On State Machine	State machine (now either logic or FW) that controls the power on sequence
	Private Data	Information that can be used on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context. <http://en.wikipedia.org/wiki/Personally_identifiable_information>
	Root Key	A root key is a type of cryptographic key from which all other keys are derived or a key used to encrypt other cryptographic keys for storage.
	Rootkit	A rootkit is a stealthy type of software, often malicious, designed to hide the existence of certain processes or programs from normal methods of detection and enable continued privileged access to a computer.[1] The term rootkit is a concatenation of “root” (the traditional name of the privileged account on Unix operating systems) and the word “kit” (which refers to the software components that implement the tool). The term “rootkit” has negative connotations through its association with malware.[1] Rootkit installation can be automated, or an attacker can install it once they've obtained root or Administrator access. Obtaining this access is a result of direct attack on a system (i.e., exploiting a known vulnerability, password [either by cracking, privilege escalation, or social engineering]). Once installed, it becomes possible to hide the intrusion as well as to maintain privileged access. The key is the root/Administrator access. Full control over a system means that existing software can be modified, including software that might otherwise be used to detect or circumvent it. Pasted from < http://en.wikipedia.org/wiki/Rootkit >
RoT	Root of Trust	A Root of Trust is a source that can always be trusted in a device or in a system. In order to be trustworthy, the Root of Trust must be immutable. The Root of Trust must begin in the hardware for immutability. And even being in hardware, it must be carefully protected from being tampered with in any way.
SCA	Side Channel Attack	In cryptography, a side channel attack is any attack based on information gained from the physical implementation of a cryptosystem, rather than brute force or theoretical weaknesses in the algorithms (compare cryptanalysis). For example, timing information, power consumption, electromagnetic leaks, or even sound can provide an extra source of information which can be exploited to break the system. Some side-channel attacks require technical knowledge of the internal operation of the system on which the cryptography is implemented, although others such as differential power analysis are effective as black-box attacks. Many powerful side channel attacks are based on statistical methods pioneered by Paul Kocher. Pasted from < http://en.wikipedia.org/wiki/Side_channel_attack >
Stride	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege	Microsoft security threat modeling method • Spoofing identity. An example of identity spoofing is illegally accessing and then using another user’s authentication information, such as username and password. • Tampering with data. Data tampering involves the malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet. • Repudiation. Repudiation threats are associated with users who deny performing an action without other parties having any way to prove otherwise—for example, a user performs an illegal operation in a system that lacks the ability to trace the prohibited operations. Nonrepudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package.
		• Information disclosure. Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it—for example, the ability of users to read a file that they were not granted access to, or the ability of an intruder to read data in transit between two computers. • Denial of service. Denial of service (DoS) attacks deny service to valid users—for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability. • Elevation of privilege. In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself, a dangerous situation indeed. From < https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=cs.20)?ranMID=24542&ranEAID=XdSn0e3h3*k&ranSiteID=XdSn0e3h3.k-bc.qorAlSQUZhRf2UdCMFQ&tduid=(f31bb4549339eedd006a8ba47b474f03)(256380)(2459594)(XdSn0e3h3.k-bc.qorAlSQUZhRf2UdCMFQ)() >
	Spoofing	In the context of network security, a spoofing attack is a situation in which one person or program successfully masquerades as another by falsifying data, thereby gaining an illegitimate advantage. Wikipedia
TCB	Trusted Computing Base	The trusted computing base (TCB) of a computer system is the set of all hardware, firmware, and/or software components that are critical to its security, in the sense that bugs or vulnerabilities occurring inside the TCB might jeopardize the security properties of the entire system. By contrast, parts of a computer system outside the TCB must not be able to misbehave in a way that would leak any more privileges than are granted to them in accordance with the security policy. From < https://en.wikipedia.org/wiki/Trusted_computing_base >
	Threat	An action which if successful would permit access to confidential information or permit a denial of service or escalation of service. Wiki: 1. In computer security, a threat is a possible danger that might exploit a vulnerability to breach security and thus cause possible harm. For more defs See also: http://en.wikipedia.org/wiki/Threat_(computer)
	Trojan	Malware that enters a device disguised or embedded in an apparently legitimate form. Trojans are most often SW but can also be embedded in component hardware as a malicious modification of logic. Once the trojan is executed it can take a wide range of actions.
	Trusted system	A system whose failure can break the security policy
	Trustworthy	A system or component that won’t fail
TE or TXT	Trusted Execution Technology	Intel TXT is the name of a computer hardware technology whose primary goals are (a) Attestation – attest to the authenticity of a platform and its operating system (OS); (b) assure that an authentic OS starts in a trusted environment and thus can be considered a trusted OS; (c) provide the trusted OS with additional security capabilities not available to an unproven OS. Pasted from < http://en.wikipedia.org/wiki/Trusted_Execution_Technology >
	Vulnerability	A property of a system which, in conjunction with a threat, can lead to a security failure.

Threat Taxonomy

Threats to assets can be broken down into SW threats, HW threats, and special cases which involve both HW and SW.

Basic Types of Software Threats

Unprivileged SW threats come from low privilege shells, applications, or drivers (Ring3 or user mode). The privileges are granted by the system SW. The capabilities for unprivileged SW are the ability read or write mapped memory with privileges granted by system SW. User mode applications can also execute from with a secure enclave instance.

Remote threats come from access and control over various network fabrics used to communicate to other platforms, both locally or over the Internet. The remote agent can read messages on the network, forge, inject, intercept, delay, delete, reorder, deliver to the wrong party, and resend messages. It can also cause network endpoints to reveal session and long-lived state.

System Software has control over the operating system, virtual machine monitor, and system management. The System software can control scheduling execution; the execution mode (e.g., privileged mode, 32/64 bit compatibility, host/guest mode); read all architecturally visible memory (including page tables); write to all unprotected memory; read architectural registers and write unlocked ones; execute an enclave (even a malicious one); program HW devices (memory controllers, DMA engines); write page tables; control contents of caches; force reset and control power states; and control installation of patches and firmware.

Threats from firmware not only enable system SW threats, but they also enable control of boot code and system management mode. This can bypass secure boot checkpoints, control system state during power state changes, modify SMM RAM without detection, create virtual devices, modify system firmware (and make it persistent), and modify registers that are open to SMM privilege.

Basic Types of Hardware Threats

Threats to system hardware require physical access to the system. Here accessible busses can be monitored, and even read and written. This includes busses such as I2S and I2C for peripheral devices, non-volatile and DRAM memory, and interfaces to sensors and displays. System inputs such as USB, keyboards, and pointing devices can be monitored and controlled. Also, hardware debugger capabilities can be exploited to gain access to valuable assets if not properly protected, for example, TAP, ITP, and JTAG debug interfaces.

Some threat analysis methods (and the mitigations to the threats) consider the cost of discovering and carrying out the attack. For these threats, it is important not only to have physical possession of a system but also to have the proper equipment to monitor or control the interfaces or devices (which can be very expensive).

Hardware Reverse engineering threats involve expensive equipment and highly specialized skillsets. The cost generally limits these to nation states or criminal enterprises, and these are generally very expensive to mitigate.

Insider, Supply Chain, and Authorized Agent Threats

These threats come from agents with a high level of authorization and may also involve access to design, manufacturing, or distribution facilities and devices that have not completed all the manufacturing steps.

Note that remote attacks which gain access to systems via phishing, poor cybersecurity hygiene like default passwords, backdoors, or credential stuffing are often followed by exploiting a vulnerability to escalate privileges and then proceed to exfiltrate documents, install APT or RAT trojans, or mount lateral attacks on other devices in the system. These are generally exploiting a common weak point in any system: the humans that are trusted within a system. These attacks can be difficult to differentiate from valid administrative activity and often are not defended because a system trusts devices and agents inside an enterprise system.

Side Channel Attack Threats

Side channels attacks exploit information leakage, often from resources that are shared between processes that are expected to be isolated from each other. The leakage comes from the physical implementation of the system rather than the cryptographic algorithm or the protocol. These are second order effects and may require critical information about system leakage, but can also require only publicly disclosed information or even no information at all. Systems leak information through power consumption, timing, electromagnetic emission, or even acoustic information.

Figure 4-2 shows a taxonomy format for threats. The easiest (and most common) attacks are passive and active SW attacks. These can be performed without having physical access to a system and often are combined or sequenced to advance the attack.

Figure 4-2

Threat taxonomy

The threats in Figure 4-2 may be combined with the observation methods in Figure 4-3 to reduce the time or effort of the attack. However, these generally require physical access and test equipment to perform.

Figure 4-3

Observation methods

Threat Analysis Methods

This section describes the basic concept of threat analysis and two publicly available methods of analyzing threats.

Basic Concepts

The generalized methods of analyzing threats and mitigations to the threats start with identifying assets and stating objectives for protecting those assets. The mitigations should fully meet the objectives and ideally there are multiple layers of mitigations (defense in depth) which increases the difficulty of an attack.

Consideration of the consequences or risks of a successful attack is also valuable. Pragmatically, it would not make sense to add cost to a product to protect an asset with no value. Likewise, when attacks are very expensive and difficult, they also tend to be expensive and difficult to mitigate, so it only makes sense to mitigate these attacks for high value assets.

Threat Trees

Threat Trees (also known as attack trees) are a helpful way to analyze defense in depth. These will show where the attack starts and how it may progress through a system. These are related to standard fault tree formal methods.

Analyzing the sequence of attacks and the methods helps to understand preferred methods based on the attacker’s skill set, tools that can be used, and visualize an attack path as it traverses through a device and across a system. When a system is modeled, a threat tree also helps to visualize unexpected attacks from trusted devices, nodes, and users. This also helps to show how several easy to implement defenses (defense in depth) may be provided better defense at less cost than a single-point defense.

Figure 4-4

Threat tree example

Common Criteria for Information Technology Security Evaluation

The Common Criteria for Information Technology Security Evaluation (often shortened to Common Criteria) is a framework for vendors to specify and evaluate claims about security attributes of their products. See www.commoncriteriaportal.org/ for more detail. Common Criteria is much more than a threat analysis method, but the CC analysis method has useful characteristics that are described here.

Common criteria defines a quantitative method of evaluating the cost of identification and exploitation of an attack. Identification is the cost and difficulty incurred in the process of discovering a method of attack, and exploitation identifies the cost and difficulty of executing the attack. This is useful because attacks that are expensive and difficult to identify may represent a valid threat that needs to be mitigated if the exploitation is low cost and easy to perform. This is particularly true if the assets are high value and numerous. Cybersecurity calls this the smart cow problem – you only need one smart cow to figure out how to get out of the pen, after that, the dumb cattle can follow that example. Conversely, even if an attack is simple and Inexpensive to identify, if it is expensive or difficult to perform, it will be less likely to happen.

The evaluation criteria for identification are the equipment and tools needed; expertise; knowledge of the target; elapsed time; access to the target; and whether the attack investigation requires open targets where the mitigations may not be active. Exploitation uses the first five categories. Each category is assigned a standardized rating score from 0 to 8. The scores are summed for the cost of identification and cost of exploitation, and those two are summed again, and binned and rated as low to high cost.

Another benefit of the CC method is that standardizing the rating scores allows the ratings to be compared across components and systems from different manufacturers.

STRIDE

STRIDE¹ is an acronym for Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege.

Spoofing is an attack on the security principle of authenticity. Here the attacker attempts to appear to be someone else.

Tampering is an attack on data or system integrity. The attacker attempts to alter data, processes, or system state to bypass security functions or disrupt proper functionality of the system.

Repudiation refers to denying that an event occurred or that data was produced by a specific system or person. Conversely, non-repudiation assures that an event occurred or data was produced by a specific system or person. Altering logs, timestamps, location data, system IDs, and user IDs are examples of repudiation attacks.

Information disclosure is an attack on the security principle of confidentiality or privacy. The target here is valuable information or other security assets that lead to valuable information like encryption keys.

Denial of service is an attack on the security principle of availability. Commonly, this attack will make a system unavailable by disrupting communication functions or overwhelming a system with activity. In some cases, a Denial-of-Service attack can cause permanent damage to a system, for example, by overheating the system.

Elevation of privilege is an attack on authorization. General users have limited rights in a system. But administrators have higher privileges of installing or deleting software; reading or writing anything in storage or DRAM; modifying system state; starting or stopping processes; changing logs; registering new users in a system; etc.

In the STRIDE analysis method, assets are examined under the STRIDE threats to understand the consequences of the attack and to define mitigations.

IMSS Assets

Value of Assets

An asset is something of value to an individual or enterprise or something that carries a risk if it becomes known. Functionality can also be considered an asset, not only from the availability perspective but also in the sense of proper execution of security protocol, cryptography, or components like machine learning applications that would result in economic damage, a compromise in safety, or loss of life if they fail.

In IMSS Systems, there are three basic classes of assets. These are classified by ownership of the asset into foundational, data, and application assets.

One measure of the security of an asset is its resistance to change. Although nothing is completely immutable, assets can be classified in terms of immutability. Often system security practices are designed to increase the immutability of assets and to detect when assets have been tampered with.

Figure 4-5 illustrates this relationship for the basic assets in a system.

Figure 4-5

Immutability ring diagram

Semiconductor hardware represents the most immutable layer in a system, especially at the transistor and state machine levels. Transistors are the most reliable and robust elements, which is why the most robust security overall must be based on a hardware root of trust.

The next layer is processing that runs from code stored in Read only Memory (ROM). ROM is essentially hardwired transistor storage which cannot be changed without changing the semiconductor masks themselves. While this layer is also very robust, it is considered less so than pure HW due to the complexity of the processor that runs the code (the number of transistors involved) and due to the potential for exploitable vulnerabilities in the code.

Firmware that is executed from non-volatile memory (like Flash memory) is the next level of robustness. Flash memory (unless it is protected) can be modified easily by a user. When code stored in non-volatile memory gets copied to DRAM for execution, even if that code is protected, its immutability must be considered in terms of DRAM reliability and protection, not as the properties of the initial storage method. Because non-volatile memory is easily modified, achieving this level of robustness requires both protecting the ability to write to it, and strong cryptographic authentication to ensure it has not been tampered with.

Foundational Assets

Foundational Assets for a device or system are the basis upon which the overall security architecture depends. The hardware Root of Trust is the foundational element of security in a device; without a hardware root of trust and supporting foundational security capabilities, it is impossible to protect data and applications assets in an IMSS. Other assets considered elements of the security foundation are Secure IDs; cryptographic key generation and storage; cryptographic algorithms and the instructions and hardware used to compute them; Trusted Platform Modules; and Trusted Execution Technology. In addition, isolation technologies like HW architecture to support enclaves and virtual machines are important parts of an overall secure HW base.

At the platform level, foundational assets might be components like the power supply, sensors, non-volatile storage, discrete Trusted Platform Modules, DRAM, as well as the communications between these components.

Many software components can also be considered foundational assets. Firmware that is part of the secure boot chain of trust, Hypervisors, Operating Systems, Device Drivers are part of the security foundation that protect system data and applications assets. Also, firmware that has a role in security protocols such as security services for communication security, device configuration, key exchange, key generation, key storage, cryptographic services such as encryption, integrity checking, and authentication can be part of the overall trust chain in a system. Another critical security role is a maintenance role, which provides status and telemetry as well as manages secure, authenticated updates to system FW and SW. And finally, security services like packet inspection, intrusion detection, anomaly detection, alerts, automated responses would be part of the chain of trust for platforms.

At the system level, in addition to platforms like cameras and video recorders, the network links, network switches, gateways, ISP and public Internet, communications like Wi-Fi and cellular data carriers, and platforms in operations centers or cloud service providers may be critical in an end-to-end system.

The Internet is resilient to failure and inexpensive to use compared to private networks. However, from the security principle that higher complexity means less security (or complexity is the enemy of security), the Internet is arguably the most complex thing ever designed by humans. So, it is very important to consider that complexity when an end-to-end system uses the public Internet for communications. The basic Internet architecture was not designed with security in mind, it assumes all endpoints and transmission nodes are trustworthy. So, security is layered on top of a security-agnostic architecture. Because of this, it is essential to properly configure security for Internet protocols.

Foundational assets are intrinsic to the hardware and software of systems. Providers like component manufacturers, Original Design Manufacturers, Original Equipment Manufacturers, and OS and infrastructure software vendors must include and utilize foundational security assets to secure valuable assets in the systems: data assets and application assets. This is a system cost for those providers which provides a security benefit to protection of the end user and software providers’ assets, which presents unique challenges to those parties that bear the cost. For more, see the section on Attackonomics.

Data Assets

Data assets in an IMSS are the inputs, event and sensor data; and the outputs, processed events and processed sensor data; plus the results of analytics inferences derived from the input data.

The IMSS inputs can be simple events like a door-opening indicator to more complex data from audio or still image or video systems. Output derived from these data range from basic understanding of characteristics of the data source to complex understanding requiring narrowly defined differentiating criteria all the way to high cognitive understanding such as situational awareness, which must process many different input data types and sources.

The value of the data assets depends on the cost of gathering and producing the data, and the benefit of the use of the data. In some cases, these data represent proprietary company data or trade secrets. Other types of data may be expensive to gather, such as Magnetic Resonance Imaging data.

The value of the output data is higher than the input data because of the additional knowledge provided by the analytics. Benefits of high accuracy, high throughput, and the amount of information that can be processed can save lives, provide improved outcomes, enable faster response, and more complete understanding based on more data than was possible until now.

These assets are generally the property of the system owner, but in some cases, laws confer ownership (or at least rights to determine use) to the subject that the data is gathered from and the system owner is a custodian of the data with legal responsibilities and limits for how it can be used or made public. This is particularly true for privacy-related data under the growing body of laws and regulations such as the EU General Data Protection Regulation and the California Consumer Privacy Act. These laws reflect how much people value their own privacy and want to control their personal data.

Application Assets

Application assets are the analytics applications themselves. Neural Networks are generally trained using an annotated set of training data, and there is a positive correlation between the amount of training data and the accuracy of the annotation with the accuracy of the inferencing results of the neural network.

In some cases, annotated data is the result of an existing data collection process. Take for example driver’s licenses or national IDs, which associate personal information like names and addresses with biometric identification like a photograph. These databases may be made available to train neural networks for no cost to the model developer based on legally mandated uses of that database to benefit the public. In other cases, the cost of gathering a large number of sample data sets that have the required diversity to produce an accurate NN model can be very high. Larger data sets result in higher accuracy for the algorithms and collating and processing the data can take months. Furthermore, annotation often must be performed by humans. Imagine annotating an image of an automobile for five attributes, even for an expert this might take 20 seconds per image. For 100,000 images it takes more than 500 hours. Images from Magnetic Resonance Imaging take nearly seven minutes on average to judge, and must be done by a highly paid expert, so the cost of this database could be 400x the cost of a simple database requiring no particular expertise.

These data may also be subject to privacy laws and regulations and not only carry the cost of gathering and annotating the data but also the cost of getting permission to use the data from the subject.

Model training is an iterative process and there is no way to guarantee that the network will converge to a good solution, converge quickly, let alone converge at all. And there can be additional time required to profile and optimize the network to perform trade-off optimizations between accuracy, parameter finite register length representation, performance, power use, power efficiency, memory footprint, etc. In addition, developers may want to try several network topologies to find the optimal solution for performance and power. All of this can add up to 100s of hours of server time.

The neural network topology itself can also be a significant cost and a significant source of product differentiation. Many model topologies are public and free to use; however, some enterprises develop proprietary NN models to maximize against goals like the best accuracy or highest performance.

A complex application like situational awareness may comprise several neural networks plus a cognate function perhaps written with fuzzy logic that requires multiple areas of human expertise, adding yet more cost to the application.

These factors mean that the investment in machine learning algorithms can be big. And the hyped value of neural networks amplifies the perception of value. Chapter 5 provides more detail on machine learning security. In the next section we will see why that is important due to the economics of attacks, or Attackonomics.

Threats

Attackonomics

Attackonomics is the economics of the threat environment. The basic economic principle is the return on investment of an attack. If the attack becomes more expensive than the value of the asset, it doesn’t make sense economically, so it won’t happen. Correspondingly, high value assets will be threatened by more expensive attacks and therefore require more expensive mitigations to defend. To that desired outcome, well-implemented mitigations raise the expense of the attack to economic unfeasibility. The scale of an attack is another factor in the value derived from an attack. The economies of scale that keep costs low also make attacks scale easier. While there are billions of devices, those all use one of several CPU architectures and several OS implementations. In addition, while Open Source software is touted as being more secure because of wide use and multiple authors, it also is another source of vulnerability-based attack scalability due to a monoculture. Vulnerabilities in those few core components enable attacks that scale to billions of devices.

A recent case of vulnerabilities in Open Source SW serves as an example. Security researchers at Forescout analyzed Open Source TCP/IP stacks and in seven of those, identified 33 vulnerabilities, dubbed Amnesia-33.² An Internet scan identified 158 manufacturers using these seven stacks, and estimated that millions of devices may be affected.

The good news is that the vulnerabilities have been identified, and seven SW stacks need to be updated rather than 158. However, the bad news is the complexity, multiple responsible parties, and controllability of the updates mean that you can’t count on actually updating the devices. The monoculture (in this case, seven cultures) scales the risks, but also scales the mitigations. The residual risk is a factor of the complexity of the updates and the timescale to update the devices.

Even in systems with full externalities, system manufacturers and system operators must consider the risk from disclosure of confidential or private information. The resultant loss of confidence and loss of reputation can have a devastating impact in the future, even if there is no direct revenue loss from a disclosure event. New ransomware business models³ combining file encryption with disclosure of an enterprise’s customer information are an example of that kind of risk.

There is also a perceptual problem with decisions on security and the risk of loss. Humans make poor judgments about risk that do not agree with objective measures. We tend to be risk averse when dealing with low probability losses and risk seeking when dealing with low probability gains. Why talk about that here? Because it is important to consider not only the quantitative probabilities when assessing the cost of mitigations, it is also important to understand how it will be perceived by non-expert decision makers. Methods to express decisions in ways to comprehend how people make decisions will lead to more effective cybersecurity policy.

The economics principle of externalities, which are common in Cybersecurity, are one of the most difficult conditions to address. Externalities occur when one party values an asset highly, but another party pays the cost for protecting that asset. For example, unless that asset is widely considered valuable, the cost of protecting that asset ends up falling solely on a small segment of the customer base who may not be able to afford the protection relative to the loss risk of the asset.

There is another economy in security that is vital: white hat hackers. These may be members of an internal team in an enterprise, or members of a security services company, independent experts, or academics. The economy that motivates security services and independent experts is bug bounties. Criminal hackers must stay hidden, but all types of white hat hackers are also motivated by recognition. The goal of white hat attacks is to disclose the vulnerability to the enterprise or group responsible privately, giving them time to mitigate the vulnerability before it becomes public. These do not generally represent threats; however, publishing vulnerabilities is often accompanied by a proof-of-concept attack which can be weaponized by an attacker. So, the proof of concept is relevant in attackonomics because it reduces the cost of developing an attack. It is also relevant because the mitigation is often a software update, and systems that have not installed the update will be vulnerable. The economics and complexity of keeping a system up-to-date is part of the economics of attacks. That is, having an automated system that maintains the software stack lowers the cost of that activity.

Current Threats

According to the Security Industries Association 2020 Security Megatrends Report, the top megatrend in physical security systems is the impact of cybersecurity.

Cybersecurity threats are increasingly sophisticated and complex. A useful example is the Mirai (future in Japanese) Malware. Mirai started its evolution as part of a scheme by three college students to gain an advantage in the online computer game Minecraft. Mirai is a self-replicating worm that crawled the Internet looking for IoT devices that were using the default manufacturers’ default login credentials. The infections initially doubled every 76 minutes. Realizing the power of this attack tool, the students started a new business model, botnets for hire. At its peak, the botnet had enslaved more than 600,000 devices worldwide, most of which were surveillance cameras, video recorders, and network routers, all of which are standard components in IMSS. As the attacks progressed from August to October 2016, the malware was iterated 24 times, making it more virulent. This botnet was used in four successive Distributed Denial of Service (dDoS) attacks that broke records. On September 16, 2016, the French hosting provider OVH suffered a 1.1 Tera bit per second (Tbs) dDoS attack from 145,000 devices. Up to that point, large dDoS attacks were in the range of 50 Megabits per second, so this was > 200 times as powerful. A few days later, a Mirai-based dDoS revenge attack was launched at the Krebs on Security website (hosted by Akamai), which peaked at 623 Giga bits per second, knocking the website offline for four days. Then, on October 21, most of Eastern United States was interrupted by the largest ever attack on Dyn, an Internet backbone DNS provider. This interrupted services in the United States and Europe for major sites like Amazon, Netflix, Paypal, and Reddit. Following the Dyn dDoS in November 2016, the entire country of Liberia was taken offline.

The Mirai source code was posted in September 2016, which opened the tool to a wide malware developer community to create their own attack variants and botnets. The DYN attack was significant because the code used to dDoS Dyn was a new evolution from the original source. By February 2017, more than 15,000 attacks were launched using dozens of variants of Mirai.

And Mirai is still being evolved to exploit new infection methods. Starting from default passwords as the entrance method, the tools were enhanced to add more default credentials, expand the portfolio of CPUs, add more attackable ports, and add more exploits like firmware and common use open source middleware vulnerabilities. Evolutionary Malware based on Mirai have been documented (Okiru, Satori, Matsuta and Pure Matsuta, and many more).

This illustrates several aspects of threats to IMSS systems. Poorly secured IoT devices will be exploited for nefarious means, threats evolve rapidly, and there is a market for developing and a market for exploiting vulnerable devices. It also illustrates the attackonomics aspect of monocultures in exploits of commonly used open source middleware like Simple Object Access Protocol (SOAP).

Vulnerabilities

There are several general types of vulnerabilities that can be exploited in IMSS systems.

The first and, in some analyses, the most common vulnerability is humans .

We can be fooled into revealing login credentials with social engineering or to download malware through Phishing emails, allowing attackers to remotely login to systems. Also, passwords are ubiquitous so people often will reuse passwords or use minor variants of passwords. When a website is hacked and improperly protected passwords are posted for sale on the dark web, not only can hackers purchase these to impersonate access to that website, but these also serve to prime credential stuffing tools to quickly crack passwords on other websites. Employing two-factor authentication also mitigates against leaked, stolen, and guessed credentials. Fast Identity Online (FIDO)⁴ authentication devices can provide a robust authentication method that is more secure than email or SMS two-factor authentication.

Because humans must at times have access to security and privacy assets, they must understand and participate in implementing the cybersecurity of IMSS. Training personnel to recognize social engineering and Phishing attacks, adopting email authentication, isolating or sandboxing emails, using two factor authentication, and using password lockers with automatic password generators will help mitigate these human-oriented attacks. Note that several of these mitigations (email authentication, sandboxing emails, using password lockers) improve security by removing the human from the trust boundary.

The second class of vulnerabilities are failures of basic system hygiene principles .

The first task is to implement the manufacturers’ security hardening recommendations. If they don’t have a recommendation, you should select another manufacturer.

Systems should never be provisioned by the manufacturer with missing, hardcoded, or fixed default login credentials (i.e., the vulnerability that Mirai initially exploited). Passwords for systems delivered to end customers should be unique for each device and complex enough that they are difficult to guess or brute-force attack. Hidden backdoors, either for future envisioned convenience or just neglecting to remove test access, must also be deleted from all login authentication protocols. It might seem OK because they are not published, but there are numerous examples of hidden backdoors being discovered and exploited. Also, passwords should be well protected in storage and memory in the system.

In IMSS, there may be tens of thousands of devices under central management. While it is convenient to use a common password, it enables a Break Once, Repeat Everywhere (BORE) attack. A device management framework should eliminate the need for common passwords.

See the section on FIDO Onboarding for information on a secure way to perform this on initial power-on.

Administrative log files should be secure for forensic purposes. It shouldn’t be easy for a hacker who poses as an administrator (escalates privileges) to cover their tracks by altering the log. Blockchain technology can ensure that log files can’t be altered with no trace. This will not prevent nefarious activity, but it will allow system administrators to see what was done to the system to repair it, and they may be used for legal action against the hacker.

Security vulnerabilities can creep into systems at the boundaries of secure processes. For example, in a system with ethernet link encryption and storage volume encryption, data must be decrypted and re-encrypted. Plaintext data may be exposed to SW, the OS kernel, or exposed in memory during the transcription process. Processing in isolated environments such as virtual machines, or end-to-end security protocols will eliminate the exploitable gaps.

Adopt Zero trust⁵ system design principles. Know what is on your network. While it is a good practice to physically isolate (airgap) the IP network used for physical security, it is more expensive, so some customers may not want to pay for the additional equipment (or naïvely believe their enterprise networks are secure). And some physical security systems are too geographically dispersed for a private network to be affordable, opting to use the public Internet instead. All devices have security weaknesses, plus devices may have latent interfaces like Wi-Fi, Bluetooth, or Zigbee that inadvertently bridge two networks resulting in a lateral attack on a physically isolated network. Endpoint devices like monitoring stations or the laptops, tablets, and cell phones providing remote monitoring capabilities may have both private network and public Internet access, serving as a bridge for attacks from the public Internet. Also, know who is on your network. IP addresses can be whitelisted for an extra layer of security. And the philosophy behind zero trust is based on the security principle of least privilege. That is, never automatically trust people or devices, only trust people and devices that you have authenticated, that you need to trust, and only for the time and to the level necessary. In addition, in consideration that the devices and personnel may not be trustworthy, provide defense in depth by encrypting all communications, irrespective of the expected isolation level of the network. See more details in the next section. Not only should you catalog the primary and secondary assets in the system but also you must measure them and monitor the integrity of those assets. Finally, the overall asset catalog, device catalog, authorized user catalog, activity logs, network traffic, asset access, requests for asset access, and asset data processing should be monitored, and abnormal behavior flagged. The multiple domains and the amount of information to be processed lends itself to a machine learning approach, which will be described in the Machine Learning Security Chapter.

Protect applications and data in storage and in transit. Applications should be deployed to be installed securely, allowing the installer to authenticate the application to make sure that it came from a reputable source (the one you expected), that the signature is current (has not been revoked), and that there were no transmission errors or tampering along the way. When stored, the storage media should also be protected with encryption and hashed to make it difficult to read or alter the drive contents. When read off the media at load time, the application should be integrity checked before allowing it to be executed. Additional runtime security isolation can be applied by using virtualization, isolating the applications from other applications running in the system, and for type 1 virtual machines, isolating them from the OS as well. In some platforms, high security trusted execution capabilities are available for applications such as Intel Software Guard Extension or Intel Trusted Domain. These capabilities add a HW enforcement layer for additional immutability and isolation.

An application developer may not want to rely on the system administrator to protect applications in storage. This is particularly true for high investment, high value applications such as machine learning. Applications can have a self-decrypting capability tied to license checks that enforces secure storage without relying on storage volume encryption. If storage volume encryption is also turned on, it then functions as a defense in depth, requiring two encryption protocols to be defeated to gain access to the application.

Data should likewise be protected in storage and in transit using encryption and integrity-checking protocols. Fully applying encryption and integrity not only protects the data but also if digital signatures are also applied (for example, having a camera sign the video stream), it also can allow assurance for forensic and legal use, and provides non-repudiation, preventing sources from denying where the content came from. ONVIF allows Secure Real Time Streaming Protocol (S-RTSP) which uses AES and AES-GCM cryptography to protect data transmitted over ethernet links. Proprietary and open source storage volume encryption protects the data while stored. And Digital Rights Management (DRM) methods can be used to protect streams across all transmission and Storage networks and devices.

Note that the application and data are often owned by different parties. While it is necessary for the applications to have access to the data in order to process it, the authentication and cryptographic keys belong to different parties and, therefore, must be delivered, maintained, and protected separately (i.e., isolated). Verifying that an application is not exfiltrating data that it shouldn’t is difficult for system integrators and end users, particularly if the application includes performance telemetry that is returned to the application developer. Any telemetry returned to the application developer or any other party such as a cloud service provider, must be optional and under user control. This highlights the necessity of a trust relationship between the end user who owns the data and the application provider.

Universal Plug and Play and Port Forwarding is a simple way to allow access to security cameras and routers via the public Internet. Universal Plug and Play (UPnP) automates port forwarding and can also enable Network Address Translation (NAT) traversal. End users may not even be aware of UPnP being enabled by default, hence the don’t shut it off and are not aware their systems are exposed and easily exploitable on the public Internet. This amounts to an open Internet interface and has been used in many attacks, including the Mirai and Persirai⁶ botnets. Automatic onboarding tools (described in the next section), Virtual Private Networks, and Virtual Local Area Networks are more secure alternatives to UPnP and Port forwarding.

Auxiliary device interfaces like debug and USB ports may be present in devices that can be used in a physical attack to insert malware into a system. In the best case, physical ports that do not have strong security incorporated by default should be removed and the corresponding SW and drivers removed as well. If the ports are mandatory, they should not be enabled by default and should be covered with an access limit panel.

Remote access Backdoors must be removed from the SW. History has shown that backdoors left in systems will be discovered and exploited even if they are undisclosed.

Performance Profiling can be legitimate and useful for product improvement, but careful consideration must be applied to ensure that only the disclosed performance data is sent back to the manufacturer using a secure method, the profiling data channel cannot be hijacked, and the data gathered does not leak any personal information on individuals. <how to ensure this?>

Use automated tools to maintain secure systems with updates. The simpler and quicker you can provide SW updates to systems, the more secure they will be. IMSS can be complex and updates will need to be tested before broadly deploying them to avoid outages due to unforeseen interactions from SW updates. Updates should be tested as soon as they are available in a lab environment or in a limited low-risk deployment and manufacturers should be consulted right away if there are problems. If your manufacturer does not have a published update process and support hotline, you may consider another manufacturer.

Manufacturers must be responsive and responsible to provide updates that fix SW vulnerabilities. Updates must be fully validated and authenticated to ensure they can be verified from a trustworthy source and they are untampered.

The third class of vulnerabilities is in the firmware and software components.

The two most common software vulnerabilities cited in the IVPM Directory of Video Surveillance Cybersecurity Vulnerabilities and Exploits⁷ are overflow and injection vulnerabilities.

Using Open Source software is a common cost-saving practice and also a good security practice in IMSS. Open Source software is often used for the OS kernel and drivers and middleware components. Just keep in mind, even though open source software have lots of inspection, all software have vulnerabilities. Also, malware has been discovered in Open Source SW many times. So, it is important to treat open source SW like custom-developed SW; analyze it for vulnerabilities and malware and monitor the source for sightings. Manufacturers must include the Open Source components into their vulnerability disclosure process. Also note that the monoculture of open source software scales the number of systems that may be attacked and therefore multiplies the risk. Prompt response to sightings is even more important for Open Source software.

The solution for SW vulnerabilities it to establish a Security Development Lifecycle that uses training in writing secure software, code inspections, and tools that test for vulnerabilities and enforce it.

Malware

Cited as the #1 threat by ENISA,⁸ malware is the most common way that software controls are defeated. Malware is entered into a system via a vulnerability like the ones from the previous section. Furthermore, malware is becoming increasingly prevalent and harmful by continuously evolving new features and distribution methods. Malware takes several forms and can have a large number of consequences.

Malware (a portmanteau of MALicious softWARE) is software designed to do damage to computers or networks, to provide malicious people access to confidential or private data, or to control computers or networks to extract valuable work from them.

Computer Viruses⁹ and Computer Worms¹⁰ spread by replicating themselves on adjacent systems or crawling from one system to another. Similarly, a Remote Access Trojan (RAT) or Trojan Horse¹¹ enters a system hidden inside another SW package or delivered through email phishing attacks, online forms, or document macros. A deep analysis of malware methods is out of the scope of this document, but it is important to understand that the consequences of malware in IMSS result in systems accessed to cause damage, extract information, or to use the systems for unintended purposes such as to form botnets.

Damage to computers can result from malware that erases files or encrypts files to make them unreadable. In less common cases, malware can cause systems to overheat or wear out prematurely by overworking them.

Gaining remote access to a computer can happen due to phishing emails, document macros, or stolen, stuffed, or guessed credentials. Once an attacker has gained access to a system, the attacker can load Advanced Persistent Threats, backdoor access credentials, and search for valuable confidential data. Attackers can also take advantage of implicit trust in local systems to traverse internal networks to penetrate other computers and storage devices for additional valuable assets. Often traversal attacks can enable access to personal devices like cellphones or tablets that are trusted in a local network. Or the attack could originate with the mobile device and traverse to a trusted corporate network. In the case of IMSS, the video feeds may be sensitive themselves carrying sensitive physical security information, privacy-related information or proprietary company secrets. Highly valuable data such as financial data, enterprise assets like intellectual property and trade secrets, and government sensitive classified information can be revealed, often without the data owner being aware until much later. The data can be sold on the dark web, used for ransom, leaked for revenge, or used to enable business use of technology without the cost of development. And nation states may use the data for strategic value in negotiations or warfare.

Malware can provide a means of taking control over a computer to use its compute resources. Cryptomining is a quite common example of this. Because cryptocurrency uses a distributed transaction validation method that pays the validators, cryptominers use the compute power (ultimately the electrical power) to extract payment for the attacker. Other uses of compute resources are sending spam email, delivering malware, command and control relays for obfuscation,

Many of these attacks are more successful when the attacker can hide their presence. Once the computer owner becomes aware the access may be revoked and the attacker may even be identified. Once compromised, a system also may lie in wait until a command and control server instructs them to perform some function. These collections of computers are called botnets.

Botnets date back to 2001,¹² though IMSS devices were largely ignored by botnets until the Mirai botnet of 2016. Botnets have evolved from function-specific, malware-specific collections of computers into a botnet for hire economy through the dark web. Botnets represent a unique risk because of their ability to act collectively in coordinated large scale attacks as well as to hide the attackers.

Trends and Emerging Threats

The general driver of emerging threats is the attackonomics of cybersecurity. The money gained from cyberattacks is easy money and the chances of getting caught are low.

Attackonomics has encouraged the growth of a marketplace for easy-to-use, weaponized malware and systems of botnets, network infrastructure, and Command and Control servers for hire. Unregulated digital currency and the dark Internet provides a layer of anonymity and an active marketplace for both the tools and the stolen data. And the developers adopt the arms dealer philosophy that they aren’t responsible for nefarious uses, they are simply supplying a market demand.

Malware, like biological viruses, is constantly evolving to adopt new ways of penetrating systems, more devices in a system, new replication methods, and evolution to avoid detection. Market forces are making the attack methods that cost just pocket money, return thousands for every dollar invested, are usable by an eleven-year-old, and can attack any system to get whatever asset that will generate untraceable cash for the attacker.

Attacks are becoming more carefully targeted and planned to gain access to highly valuable data such as financial data, intellectual property, trade secrets, classified data, and ransomable data. Along with the increased sophistication of the attacks comes greater ability to evade and defeat defenses.

These same market forces have created an active data marketplace. Lists of login credentials, vulnerable devices, banking information, and identity information can be purchased for pocket money. And these data fuel the cycle of exploitation. Corporate espionage as a service¹³ is also available today on the dark web, enabling individuals or corporations to easily obtain the intellectual property or strategic information of a competitor, shielded by the anonymity of the dark web. These services include hacking tools, backdoors, credentials, and tailored malware.

As you will read about in the next chapter, Machine Learning is also being weaponized. ML applications can multiply the speed and destructive power of an attack, or help malware evade detection. Generative adversarial attacks are developed by pitting one machine learning application against another to produce a false positive or false negative result.

The Internet and networks connected to the Internet are increasingly populated with inexpensive devices whose security ranges from no security at all to default pro-forma security with slapped-together open-source SW with no identifiable supplier and no commitment to provide security updates. These devices can be the easiest entry point to a network, traversing it to load malware or locate high value assets. Devices on internal networks must not automatically trust connections from local devices for this reason, instead applying zero trust policies to stay secure. IMSS increasingly have the ability for users to view data on personal devices such as cellphones and tablets. These devices may not have the same level of security control as an IT professionally maintained device in an enterprise system. These personal devices can also be a weak entry point into an otherwise secure system.

Cloud Computing, including video analytics as a service, is changing the cybersecurity environment both by presenting a concentrated captive data store, that is, a target-rich environment, and by providing another means of leveraging implicit trust in the cloud services provider (CSP) as well as obfuscating the responsible party of attacks. The cloud also encourages partnerships between CSPs and security software providers to raise the bar. And the cloud is a proving ground for zero trust policies and protocols.

On the positive side, laws and regulations are beginning to address cybersecurity. History has shown that regulations and holding parties responsible, including assessing penalties, can result in good solutions. This is particularly true when economic externalities are operative in a market.

So, what can you do about these problems? The next section outlines Intel technologies that system providers, software providers, and system integrators can use to help mitigate many of these types of threats.

Designing a Secure Platform Using Intel Technologies

During the design stage of a product, it is essential to understand the detailed capabilities of the selected HW, FW, and SW that’s targeted. The journey starts with leveraging a Root of Trust, a device identity, provisioning, implementing a chain of trust via secure boot, securing the keys and data, protecting the code/data at runtime, and concluding with a defense in depth strategy.

Root of Trust (RoT)

In simple terms, a RoT is often used to build a foundation in a platform on which the properties of security and trust can be implemented in the different layers. The RoT is expected to be immutable on highly trusted systems and in this case implemented in HW or ROM code. In less trustworthy systems, the RoT is also implemented in FW and SW, and this renders the resulting system vulnerable to RoT tampering and a complete system compromise. A FW/SW Root of Trust can be strengthened by programming the RoT key hash of the OEM or ODM into the Field Programmable Fuses (FPF) of the Silicon. As an example, Intel Silicon provides FPF storage for programming the hash of the public key associated with the private key used to sign the boot and subsequently the OS images.

Secure IDs

The security posture of a device requires an immutable identity that can be cryptographically verified. The same identity can be used by the device to get admitted into the network and for the purposes of local or remote attestation. Some examples of this ID are supported by discrete TPM or PTT or a key programmed into the Silicon. For constrained IOT devices, another viable option is Device Identity Composition Engine (DICE),¹⁴ which enables a layered identity and attestation scheme.

Provisioning the Device – FIDO Onboarding

One of the major threats exploited by hackers are the default passwords left un-provisioned on a device. The Onboarding standard being specified by FIDO alliance¹⁵ is a secure, robust way to provision the credentials and persona into an IoT device. In some cases, the OS build can also be downloaded, authenticated, and stored on the platform’s hard disk/storage.

Secure Boot – Chain of Trust

Also known as transitive trust is essential to ensure that the entire process and ingredients including boot, OS, and applications are verified before trusting to complete the platform bring-up. Secure boot is a mechanism to ensure that any/all FW and SW ingredients executing on the platform are authenticated, tethering back to the root of trust. Secure boot can include verified boot and measured boot where verified boot is a process of authenticating the ingredients and enforcing a predefined policy if there is a mismatch. Measured boot, on the other hand, stores the authenticated hash values into a secure storage such as TPM or PTT for a subsequent local or remote attestation. The following stack flow diagram shows how the transitive trust works to protect the boot process all the way from hardware to the applications running in a VM. The lowest layer to be the HW layer, and above that is the firmware layer which includes the modules required to handle the HW IP blocks and Digital Rights Management. Above that is the boot loader/UEFI used to initialize the CPU and chipset. The optional hypervisor supports the Virtual Machine Manager (VMM) functionality. The upper layers include the OS ingredients for kernel and User mode. Above that layer are the middleware/frameworks and applications. This diagram (Figure 4-6) also illustrates the security goal that trust begins at the lowest layers and must be extended into the layers above – and that doing so requires conscious techniques to get it right. If/when those techniques fail, the stack recovers by falling back to lower layers.

The stack includes booting into application TEEs and the need to distinguish security-sensitive function and workloads that should be separated from “traditional” function and workloads. We can refer to the TEE and lower layers as the trusted computing base upon which the rest of the stack depends.

Figure 4-6

Boot flow with the chain of trust and signing

Securing Keys and Data

During and after the boot phases of the device, there is a need to store the keys in a vault type of storage with access controls and TPM is a notable example where the keys can be generated and wrapped. The wrapped keys can be used with handles to perform operations including sign/verify, encrypt/decrypt, etc.

Cryptographic Keys

Cryptographic Keys are an essential part of enforcing the confidentiality in a system during the encryption and decryption operations. A key disclosure to unauthorized entities will result in the decryption of data and making it available in clear text for analysis and compromising the assets. Therefore, protecting the keys must be the highest priority and can be achieved at various levels in the platform, but utilizing the standards-based technologies such as discrete TPM or Intel PTT are strongly recommended.

Data in Flight

This problem is well-known, and one can use either TPM or PTT or Intel CPU instructions for SHA, AES, and Random Number generation. The data is protected at egress for confidentiality and integrity through encryption and sign/verify, respectively.

Data at Rest

Data at rest or when stored on a medium such as flash or hard disk or RAM needs adequate protections to mitigate the offline secret recovery or reverse engineering-related attacks.

Trusted or Isolated Execution

Providing a protected runtime environment for the application’s code and data is essential to protect the secrets and the assets that the code/data handles. In general, a Trusted Execution Environment (TEE) refers to an execution environment that is isolated from the normal general purpose execution environment. For example, the core CPU is a general-purpose execution environment and a security co-processor is an isolated environment. Trusted execution environments may include HW/SW/FW that establishes an isolated environment. By carefully controlling the infrastructure that produces the HW/FW/SW that implements the TEE, the TEE can have strong guarantees regarding safe and reliable execution of TEE workloads. Typically, workloads that involve use of cryptographic keys the confidentiality and integrity protection of data as it is transformed to and from cipher text are performed using a TEE.

There are several TEE technologies available across a variety of architectures. Intel® Software Guard Extensions (SGX) allows multiple instances of trusted execution environments for different applications and tenants. Intel® TXT allows trusted execution using CPU cache lines as RAM to minimize dependencies on external resources. It can be used for general purpose TEE operations when cache coherency isn’t needed. Intel® Virtualization Technology (VT) suite offers another form of TEE where a trusted hypervisor creates execution environments with distinct thread, memory, interrupt, and IO contexts. Virtualization allows full OS and application images to run which may be counterproductive to security due to increased attack surface of a large OS and application framework. Therefore, it may yet be appropriate to employ some other TEE capabilities in concert with virtualization.

Defense in Depth

Implementing strong security properties such as Confidentiality, Integrity, and availability at all layers in the platform stack ensures that the breaches are contained to a particular layer and any vertical expansion is limited. This strategy also enables a structured recovery where in the compromised or corrupted FW/SW components at layer can be recovered by the layer immediately below in the stack.

OpenVINO Security Add-on

The OpenVINO Security Add-on is an open source security capability for OpenVINO analytics model developers to help defend against copying, cloning, and reverse engineering their valuable intellectual property. This capability is detailed in Chapter 5, section 5.3.1.

Secure Development Lifecycle (SDL)

SDL is a set of industry standard processes that is usually tuned to the internal development processes.¹⁶ SDL should be applied to all the components within a platform including hardware, firmware, and software. SDL is essential to implement a security-minded development and validation disciplines within a company. The main goal of SDL follows defensive approach to prevent certain issues from occurring late in the development/validation phases by identifying triggers and mitigating them at different milestones throughout the product’s lifecycle. In the past, secure coding used to be the focus, but secure design and the implementation of DevSecOps where security principles are embedded in every phase of the product has become the norm. Refer to Figure 4-7 for an example of SDL phases and note that it starts with planning of product, architecting, high-level and low-level design, implementation/coding, functional/security validation, and deployment/maintenance.

Figure 4-7

Phases of SDL process

Support and Response

It is essential to have a Product Security Incident Response Team (PSIRT) to intercept the vulnerabilities in the products, issue common vulnerability exposures (CVE), develop mitigations and distribute the patches/updates. These updates either developed internally or acquired from external source should then be deployed by the customers either through any of the following infrastructures including firmware over the air (FOTA) or software over the air (SOTA) or application over the air (AOTA).

Summary

Securing the assets pertinent to IMSS starts with threat modeling which involves understanding the threat taxonomy and selecting the right method. Subsequently, the assets must be identified along with the value and associated priority with the assets classified into foundational, data, and application. Designing a secure platform involves leveraging multiple technologies, including the available Root of Trust, immutable device ids, and secure key storage. Using these technologies, a secure boot chain of trust could be implemented to protect the boot integrity of the IMSS system. Provisioning is an important step in the lifecycle of an IMSS system where the right cryptographic credentials are programmed into the system. Once a system is correctly provisioned, securely booted, the runtime protection of the code/data can be securely implemented. Defense in depth strategies should be designed in to prevent, detect, correct, and recover from the emerging security threats including zero-day vulnerability exploits. An example technology, the OpenVINO Security Add-on is briefly explained to articulate the architecture that helps protect the Machine Learning IP assets. Encompassing all the preceding is the necessity for a structured and comprehensive Secure Development Lifecycle process and an incident response/support system to identify, report, and release patches to address security vulnerabilities.

In the next chapter, we will learn more about Machine Learning policies and standards and about protection solutions specific to machine learning.