10 IoT Cyber Security
481
10.3.1 Establishing a Secure IoT System Development
Methodology
Much of today’s software is exposed to multiple threats when deployed. Pressure
to meet Sprint and Release commitments often overrides the proper handling of
security requirements within an application or device. It is easy to push off security
functionality in favor of satisfying a functional requirement or staying on track
with cost and schedule. The approach defined in this section provides a framework
for ensuring that software and firmware are developed on a secure foundation
and that cyber security requirements are not dropped from a sprint backlog. The
recommendations here are based on adaptation of the Microsoft Agile Development
model [6] as well as secure agile approaches from the Open Web Application
Security Program (OWASP). Each development project begins with a threat model,
which is created during project initiation and updated continuously as the project
matures. The threat model requires an examination of the functionality of the
application or device in order to understand the threats and vulnerabilities associated
with the system.
10.3.1.1 Threat Modeling an IoT System
Organizations typically have a limited amount of resources that can be applied to
the cyber security of their systems. Leaders must make informed decisions as to
the impact of a particular threat as well as the likelihood of that threat occurring to
be able to determine where to invest funds for mitigations. Threat modeling is the
process of documenting a system, identifying the threats to that system and then
rating the threats based on their impact and likelihood. Without threat modeling,
security engineers operate somewhat in the dark as to what risks require the most
attention, and may possibly invest in security tools that don’t even apply to the
most serious concerns. Microsoft’s threat modeling approach – a component of
the Microsoft Agile SDL – begins with documenting the assets within a system,
creating and analyzing a system architecture, decomposing the system to identify
data flows, and identifying high value assets within the system. These are the assets
that a malicious actor might attempt to compromise – for example, a database or
gateway. Once complete, the process includes steps to identify, document, and rate
the threats to the system (Fig. 10.3).
Simply because a threat to your system exists does not mean that action must
be taken. There may be esoteric threats that would likely never occur. In these
instances, it is often better to invest funds in mitigating threats that would be much
more likely to occur. Risk analysis allows security engineers to assign a risk score to
each risk in the system. The risk score (Risk = Likelihood of Occurrence ∗ Impact
of Occurrence) provides a quantifiable view of all the risks of a system and allows
them to be objectively prioritized. The Microsoft Agile SDL includes a process
termed DREAD that security engineers can use to assign risk scores.
481
10.3.1 Establishing a Secure IoT System Development
Methodology
Much of today’s software is exposed to multiple threats when deployed. Pressure
to meet Sprint and Release commitments often overrides the proper handling of
security requirements within an application or device. It is easy to push off security
functionality in favor of satisfying a functional requirement or staying on track
with cost and schedule. The approach defined in this section provides a framework
for ensuring that software and firmware are developed on a secure foundation
and that cyber security requirements are not dropped from a sprint backlog. The
recommendations here are based on adaptation of the Microsoft Agile Development
model [6] as well as secure agile approaches from the Open Web Application
Security Program (OWASP). Each development project begins with a threat model,
which is created during project initiation and updated continuously as the project
matures. The threat model requires an examination of the functionality of the
application or device in order to understand the threats and vulnerabilities associated
with the system.
10.3.1.1 Threat Modeling an IoT System
Organizations typically have a limited amount of resources that can be applied to
the cyber security of their systems. Leaders must make informed decisions as to
the impact of a particular threat as well as the likelihood of that threat occurring to
be able to determine where to invest funds for mitigations. Threat modeling is the
process of documenting a system, identifying the threats to that system and then
rating the threats based on their impact and likelihood. Without threat modeling,
security engineers operate somewhat in the dark as to what risks require the most
attention, and may possibly invest in security tools that don’t even apply to the
most serious concerns. Microsoft’s threat modeling approach – a component of
the Microsoft Agile SDL – begins with documenting the assets within a system,
creating and analyzing a system architecture, decomposing the system to identify
data flows, and identifying high value assets within the system. These are the assets
that a malicious actor might attempt to compromise – for example, a database or
gateway. Once complete, the process includes steps to identify, document, and rate
the threats to the system (Fig. 10.3).
Simply because a threat to your system exists does not mean that action must
be taken. There may be esoteric threats that would likely never occur. In these
instances, it is often better to invest funds in mitigating threats that would be much
more likely to occur. Risk analysis allows security engineers to assign a risk score to
each risk in the system. The risk score (Risk = Likelihood of Occurrence ∗ Impact
of Occurrence) provides a quantifiable view of all the risks of a system and allows
them to be objectively prioritized. The Microsoft Agile SDL includes a process
termed DREAD that security engineers can use to assign risk scores.