IoT Cyber Safety Policy Database

Version 1.0
I Am The Cavalry
Originally published August, 2018
 I Am The Cavalry IoT Cyber Safety Policy Database

What it is
The IoT Cyber Safety Policy Database is a set of policies, mapped to distinct reference
statements, encompassing a relatively comprehensive set of ideas for protecting human life and
public safety from cybersecurity incidents. The database is meant to serve as a guide and
reference policymakers, industry, and others to ensure best practice becomes common
practice.

Why it’s needed

Adoption of connected technology has grown faster than the capability and willingness to secure
them, in areas impacting human life, public safety, and national and economic security.
Meanwhile, adversaries are increasingly willing and capable of causing harm through these
same technologies. As these trends are increasingly manifesting, public policy dialogues have
begun to manifest as formal positions in legislature, regulation, academia, and other outlets.

The number and divergence of cyber safety policy positions has become overwhelming, as the
rate of introduction exceeds the capacity of organizations to learn lessons from prior policies. A
database of existing policies and positions can serve as a central repository for research,
analysis, and synthesis. Meanwhile, an exhaustive set of comprehensive policy statements
improves quality, speed, and consistency of new policies.

The primary database of correlations can be found here: https://iatc.me/iotcpdb_raw

A visual mapping of database correlations can be found here: https://iatc.me/iotcpdb_vis

How it was created

Several of the public policy documents have been authored, influenced, and shaped by our
volunteers. These served as an early starting point for correlation of different policy statements.
Quickly, a superset of policy statements emerged, which allowed further mapping and extension
to other documents. The initial set of reference policy statements is fairly exhaustive, within the
scope of IoT Cyber Safety, and each statement is fairly distinct and nuanced.

How others might use this database

● Policymakers - to map authorities and existing statements to new rules, to fully account
for domain-relevant policy issues, and to maintain consistent language across policies
● Industry - to understand how policies correlate to each other, and view an existing
superset that may be predictive of future policies
● Academic researchers - to catalog existing policies and individual statements, and
identify policy gaps to propose new policy recommendations
● Enthusiasts and Mavens – to access authorities and existing statements to propose
better, consistent language, and leverage the resource to create IoT Cyber Safety
educational materials for public awareness and use

Version 1.0
Originally published August, 2018
https://iatc.me/IoTCyberPolicyDB
 I Am The Cavalry IoT Cyber Safety Policy Database

Future work and known database gaps

● Adding new policies to the reference library
● Correlating additional policies against the reference statements
● Refining and reorganizing existing policy statements
● Adding new policy areas and statements
● Expanding beyond the IoT Cyber Safety scope
● Lineage mapping to see where ideas come from and how they move
● Converting the reference library into an analysis-friendly database

I Am The Cavalry Credo

We believe that our dependence on computer technology is increasing faster than our ability to
safeguard ourselves. As the question around technology is less-and-less “can we do this” we
must more-and-more be asking “should we do this.”

The Cavalry is not a spectator sport. To effect change and to improve public safety and human
life the way we need to, we need you. No matter who you are, no matter where you are globally,
your help can make the world – and the Internet of Things – a safer place.

License
This work is licensed under a Creative Commons Attribution 4.0 International
License.

Contact
To recommend policies additions to the IoT Cyber Safety Policy Database, provide a list of
identified policy gaps for public consideration, or to volunteer with expanding/developing this
work, contact info -at- iamthecavalry.org.

Version 1.0
Originally published August, 2018
https://iatc.me/IoTCyberPolicyDB
 I Am The Cavalry IoT Cyber Safety Policy Database

Appendix A: Compiled Policy Statements

The following policy statements come from analysis of government, industry, academic, and civil
society policy-level documents listed in Appendix B. For a full list of the policy statements and
mappings, refer to the raw dataset at https://iatc.me/iotcpdb_raw and to see the same data
visualized, refer to https://iatc.me/iotcpdb_vis.

1. Cyber Safe and Secure by Design

a. Standard-based (not standard-bound). Existing International and industry standards
for secure design and development of software components are highly mature.
Manufacturers who use these can accelerate the security of their software development,
baselines, and processes. While there is no single consensus standard, common
practices can help mature a program and lay the groundwork for adoption of a preferred
standard or framework later. However, standards are slow to develop and change, so
should not slow adoption of safety and security by design principles.
b. Adversarial resilience analysis and testing. All other things equal, a component and
system that has been more rigorously tested has fewer unknown flaws or defects.
Adversarial threat modeling, fault testing, and other cyber security practices build on
safety engineering to consider failure and misuse caused by adversaries. Assessments
should be carried out by qualified personnel, independent of design and development.
c. Provide transparency of security practices. Safety, security, and resilience is a union
of the device’s inherent capabilities, operation in its environment. The best safety and
security possible is achieved when the device and operator do what each is best poised
to do. In the absence of clear statements of design assumptions and expectations, the
ability of defenders and operators to replicate assumed environments and processes will
be fortunate coincidence, rather than inherently systemic. Communicate expected
deployment conditions, known failure conditions, operational requirements, design
assumptions, architectural elements, reference implementation guidance, specific
warnings or prohibitions, and other considerations.
d. Reduce elective attack surface & complexity. There are relationships between
security and: complexity, interfaces, attack surfaces, code flaws per thousand lines of
code, etc. As such, more secure designs seek to minimize these types of exposure.
e. Consider separate strategies for legacy and future designs. Optimal strategies for
cyber safety will differ, depending on options available at each point in a device's
lifecycle. Other things equal, the number and quality of options tend to increase the
earlier the phase of development, such that security strategies for already-deployed
devices tend to differ from those for designs still on the drawing board. Manufacturers
and operators should account for increased optionality of devices in early stage, rather
than assuming aftermarket security capabilities are the most effective and efficient path.
f. Continual improvement. Understanding causes of vulnerability, failure and harm are a
precursor to addressing them, not the end in itself. Insights must inform all aspects of the
device security lifecycle. Share lessons learned with the broader community where it can
improve the public good.
Version 1.0
Originally published August, 2018
https://iatc.me/IoTCyberPolicyDB
 I Am The Cavalry IoT Cyber Safety Policy Database

g. End of Life Strategy. Companies, devices, and components all have a finite lifespan
that impact cyber safety of device design. Devices expected to operate for decades will
outlive components supported for months or years. Likewise, designs should account for
changes in device ownership or retirement, revoking access or resetting data and
configuration. The most proactive companies may find it easier to buy back outdated
devices, rather than continue to support them.

2. Supply Chain Rigor

a. Avoid known defects in software and hardware. Avoid third-party software
components with known vulnerabilities when less vulnerable alternatives are available
and will not compromise required functionality. Other things being equal, favor
components and providers exposed to more rigorous assessment, fix discovered
vulnerabilities in a timely manner, and maintain greater stability.
b. Maintain traceability and provenance of software and hardware components. Well-
governed, traceable hardware and software supply chains establish predictable quality
and provenance of device components. A more trustworthy supply chain enables better
resilience and a more agile response to accidents and adversaries. Off-the-shelf
hardware and software, acquired with appropriate rigor, can increase reliability, reduce
cost, and speed time to market compared to other alternatives.
c. Favor well-tested and vetted software and hardware components. Off-the-shelf
hardware and software, acquired with appropriate rigor, can increase reliability, reduce
cost, and speed time to market compared to other alternatives. All other things equal, a
component and system that has been more rigorously tested has fewer unknown flaws
or defects.
d. Publish a software "bill of materials". A software bill of materials (SBOM) for third-
party and open source software packages allows buyers, operators, and others to
account for cost and risk, even beyond the expected lifetime of the device.

3. Vulnerability Discovery and Coordination

a. Published coordinated vulnerability disclosure policy. Unknown flaws represent
potential harm. Delays between finding and fixing a vulnerability increase adversary
advantage, especially for those discovered by third-parties. All due care should be taken
to reduce the time window, degree, and impact of known but unmitigated vulnerabilities.
This necessitates coordination among researchers, affected parties, and other
stakeholders. A coordinated vulnerability disclosure policy supports a positive,
productive collaboration between manufacturers and security researchers, inviting
reports made in good faith in order to reduce potential adversary advantage.
b. Existing standards, mechanisms, and interfaces. Published policies and programs in
the software industry can serve as effective examples for medical device manufacturers.
Use of vetted external standards (including ISO 30111 and 29147, NTIA Early Stage
Template, and others) and practices accelerate an organization’s maturity and ensure
predictable, normalized interfaces to those who report issues. Use of existing internal
processes and structures reduces time to develop an effective program, increases
participation, and reduces administrative burden. Processes and policies already in
Version 1.0
Originally published August, 2018
https://iatc.me/IoTCyberPolicyDB
 I Am The Cavalry IoT Cyber Safety Policy Database

place to accept and respond to reports of safety concerns may also be used to handle
reports of potential safety or security issues. External vulnerability reporting coordinators
have normalized interfaces between manufacturers and third-party researchers. This
brokers trust on all sides and reduces effort required.
c. Incentives-focused. Cyber safety should be in everyone’s best interest. Positive
incentives, such as outreach, recognition, and financial incentives, drive earlier, higher
quality reporting. This reduces cost, time, and negative perception to eliminate flaws, at
the same time gives defenders an edge on adversaries by disrupting their ability to
monetize attacks. Negative incentives may deny these benefits to customers, investors,
and others.
d. Vulnerability awareness processes for publicly disclosed vulnerabilities. Maintain
awareness of vulnerabilities disclosed through public or private means, such as
disclosure lists, vulnerability databases, and those reported to information sharing
organizations.
e. Share information about vulnerabilities. Unknown flaws represent potential harm.
Revealing discovered or reported vulnerabilities allows defenders to address them and
their root causes. Disclose information about vulnerabilities with others, including
industry groups and public sources.

4. Forensically Sound Evidence Capture

a. Publish review mechanism. Identifying the roles and mechanisms by which reviews
take place increase reliability and trustworthiness. Facilitating independent analysis
permits stakeholders to investigate adverse events in a timely manner, to improve
transparency of findings, and to support lines of accountability. Where the manufacturer
is the primary analyst, publish how to engage the review mechanism.
b. Tamper resistant, forensically sound. Mechanisms should provide a legal standard of
care for preserving logs and other information about the event, including tamper
resistance, tamper evidence, and chain of custody.
c. Privacy sensitivity. The benefits of safety investigations are intrinsically linked to
records that demonstrate the impact of failure. However, these benefits can be realized
without creating privacy and surveillance concerns by decoupling security and integrity
logs from private records.
d. Logging and legal standards. Lowest Common denominator syntax and verbosity
increases the value within a manufacturer and across the industry. Conforming to
existing legal standards of care around cyber forensics permit chain of evidence, lower
the threshold for training, and other benefits.

5. Secure, Prompt, and Agile Update Mechanism

a. Secure update process. Verifying the authenticity and integrity of software updates
prevents adversarial, malicious, or accidental tampering. Remote update capabilities
provide cost, reputational, and speed advantages if implemented in KNOWN effective
ways.
b. Software security update labeling. Buyers that cannot anticipate end-of-support
cannot factor operational and maintenance requirements. Publishing an anticipated or
Version 1.0
Originally published August, 2018
https://iatc.me/IoTCyberPolicyDB
 I Am The Cavalry IoT Cyber Safety Policy Database

minimum supported lifetime allows buyers and operators to understand roles and
responsibilities. Making the reasons for the support lifetime known helps inform buyers
and operators of the assumptions the manufacturer has made, so they can anticipate
future shifts in those assumptions, either during the supported lifetime or beyond.
c. Robust notification and communication. Communication to stakeholders should be
prompt, transparent, and forthright. Manufacturers should notify relevant stakeholders
when and where flaws exist, their severity, contents of the update, and instructions for
each role. Updates may be exclusively communication about workarounds, warnings,
unsafe conditions, labeling, instructions for use, or other relevant information.
d. Support dependency updates. Safety depends on the integrity of third-party software
dependencies. Safety must not be undermined by vulnerabilities in these platforms, nor
in applying updates to fix them. Verification processes specific to off-the-shelf software
security updates can enable a more agile response.
e. Automation and documentation. Update processes that are more automated and
better controlled are less prone to error, delay, malice, misinterpretation, or other issues.
Process documentation should outline clear roles and responsibilities for relevant
stakeholders and allow development of corresponding processes inside stakeholder
groups.

6. Resilience, Containment, and Isolation

a. Isolate and contain. Unexpected or hostile interactions between devices and their
environment are more likely to lead to harm than well-understood interactions. A more
secure design and implementation seeks to shield components and systems from
adversaries or unexpected conditions. Determine benefits weighed against exposures,
threats, and capabilities to defend a device throughout its lifecycle.
b. Minimize elective exposure. Connectivity can provide critical capabilities. It also
increases exposure to hazardous conditions and adversaries. Exposure that does not
meaningfully improve capabilities adds attack surface. As such, more secure and lower
(total) cost designs seek to minimize these types of exposure.
c. Publish impact of operational isolation. Document which specific features and
benefits will continue to work with limited or no Internet or network access, as well as
those which are Internet or network dependent.
d. Avoid unmitigated remote access. Capabilities in the hands of an operator, working in
good faith, can be used for harm in the hands of an adversary or unskilled individual.
Credentials gating remote access must remain unknown to adversaries yet available to
defenders. Hard coded or default credentials (passwords, keys, etc.), absent other
gating methods, cannot assure security or safety, so should be avoided or augmented.
e. Fail safely and visibly. Failure conditions should not cause undue harm to patients and
should clearly indicate that the device is not operating normally. Unexpected modes of
operation or known failures should trigger a “fail safe” or “safe mode” that can prevent a
failure in one device or software component from spreading. Communicate indications
and known conditions of failure to stakeholders.
f. Integrity of input and storage. Tamper resistant, tamper evident techniques safeguard
against life-critical decisions or actions from untrustworthy information or instructions,
Version 1.0
Originally published August, 2018
https://iatc.me/IoTCyberPolicyDB
I Am The Cavalry IoT Cyber Safety Policy Database

ideally with real-time feedback. Decisions rely on accurate records. These records
should be protected against tampering, manipulation, loss, and gaps. Capabilities such
as ample storage, confirmation after transfer, integrity validation, and privacy protection
allow higher fidelity decisions.

Version 1.0
Originally published August, 2018
https://iatc.me/IoTCyberPolicyDB
 I Am The Cavalry IoT Cyber Safety Policy Database

Appendix B: Sources and Mapped Policies

While the list of reference policy statements draws from dozens of documents, the formal
mapping draws from the following. For more detail, refer to the raw dataset at
https://iatc.me/iotcpdb_raw.

US Government
● DHS Strategic Principles For Securing The Internet Of Things
● Department of Commerce (NTIA) Multistakeholder Process: Internet of Things (IoT) Security
Upgradability and Patching
● Department of Commerce (NTIA) Multistakeholder Process: Cybersecurity Vulnerabilities
● FDA Content of Premarket Submissions for Management of Cybersecurity in Medical
Devices
● FDA Postmarket Management of Cybersecurity in Medical Devices
● NHTSA Cybersecurity Best Practices for Modern Vehicles
● Federal Aviation Administration Reauthorization Act of 2017

Foreign Government
● UK Secure by Design Code of Conduct
● Republic of Korea A study on security enhancement for IoT device and service

Private Sector, Academia, and Civil Society

● Atlantic Council Smart Homes and the Internet of Things
● Atlantic Council The Healthcare Internet of Things: Risks and Rewards
● Automotive ISAC Automotive Cybersecurity Best Practices
● I Am The Cavalry Five Star Automotive Cyber Safety Framework
● I Am The Cavalry Hippocratic Oath for Connected Medical Devices
● Microsoft Cybersecurity Policy for the Internet of Things
● (Multiple) Charter of Trust

Version 1.0
Originally published August, 2018
https://iatc.me/IoTCyberPolicyDB