Security Engineering and Risk Analysis

VIDEO:  IoTSI SCCI Security Engineering Risk Analysis Phase  (opens in new window)

An asset register is a detailed list of maintainable assets that an organization owns or manages. It enables organizations to track important information about its owned assets including an asset’s name, unique identification number, location, etc.

Risk: IF an outside actor with malicious intent obtains a valid certificate through social engineering AND uses it to send an illegitimate CAP-compliant message by spoofing an AOS, THEN health, safety, legal, financial, and reputation consequences could result.

IoT devices are pieces of hardware, such as sensors, actuators, gadgets, appliances, or machines, that are programmed for certain applications and can transmit data over the internet or other networks.

The residual risk is the amount of risk or danger associated with an action or event remaining after natural or inherent risks have been reduced by risk controls.The general formula to calculate residual risk is residual risk=(inherent risk)−(impact of risk controls) where the general concept of risk is (threats × vulnerability) or, alternatively, (severity × probability).

This table presents the security attributes (i.e., confidentiality, integrity, and availability) for the three critical data items. The security attributes are essential input when identifying threats to the AOS.

A Threat Assessment is a process for evaluating and verifying perceived threats, including assessing their likelihood. In cybersecurity, a threat assessment is usually performed by security risk management and it precedes plans for mitigating threats against the enterprise.

In software and systems engineering, a use case is a list of actions or event steps typically defining the interactions between a role (known in the Unified Modeling Language (UML) as an actor) and a system to achieve a goal.The actor can be a human or other external system. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals.

The following scenario describes a spoofing attack that targets an IoT System of Interest: An outside actor with malicious intent plans to obtain a valid  certificate through social engineering and then use it to send an illegitimate CAP-compliant alert message to the IPAWS-OPEN Gateway. In carrying out this attack, the actor plans to spoof an AOS.

The workflow begins with a request from an initiator (e.g., law enforcement, NWS) to submit an alert (initiator alert request). A team from the Alert Originator (AO) organization receives the initiator alert request and decides, (1) whether or not to issue the alert and (2) the distribution channels for the alert (e.g., television, radio, roadside signs, wireless technologies, others). The workflow in  assumes a wireless alert will be issued.

 A top-level workflow that describes the core activities needed to distribute an emergency alert using the WEA service. The workflow provides the anchor for the subsequent security risk analysis. After we develop a workflow model, we then determine which technologies support that workflow. 

IoT Operational Model. This model provides a clear view of the 10 layer stack of an IoT Solution. This view can be beneficial in obtaining a high-level view of the IoT Solution's key design decisions. It is possible to utilise the IoT Asset Register document to obtain a detailed view of solution components and possible risk exposure. 

This document explains the rationale and steps involved in applying a "Risk Statements" approach to Risk Analysis. The SBRA- RS xls workbook is available for download within this category. Alternatively, follow the link provided. 

The IoTSI - Security Engineering Risk Analysis (SERA) risk management method incorporates two key design features that differentiate it from other security risk assessments. The first is the use of operational models. Participants applying traditional security-risk assessments typically rely on their tacit understanding of the operational context in which a software-reliant system must operate. Our experience indicates that tacit assumptions are often incorrect or incomplete, which adversely affects the results of a security risk analysis. We propose using operational models to describe a system’s operational context explicitly. All IoTSI Workbooks and instructional material. Free Download.