Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Rewriting S&P section without normative statements #155

Merged
merged 1 commit into from Feb 14, 2019
Merged

Rewriting S&P section without normative statements #155

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
272 changes: 157 additions & 115 deletions index.html
View file
Open in desktop
Expand Up @@ -1480,133 +1480,175 @@ <h3>The <dfn data-dfn-for="">Observable</dfn> interface</h3>
A detailed discussion of security and privacy considerations for the Web of Things,
including a threat model that can be adapted to various circumstances, is
presented in the informative document [[!WOT-SECURITY-CONSIDERATIONS]].
This section includes only normative recommendations relevant to
the WoT Thing Description.
</p>
This section discusses only security and privacy risks and possible mitigations
directly relevant to the scripts and WoT Scripting API.
</p>

<p><span class="rfc2119-assertion" id="td-sec-best-practices">
<p>
When designing new devices and services for use with the WoT,
we have documented a set of best practices
in [[!WOT-SECURITY-BEST-PRACTICES]] that SHOULD be followed.</span>
we have documented a suggested set of best practices
in [[!WOT-SECURITY-BEST-PRACTICES]] to improve security.
This best-practices document may be updated as security measures evolve.
Following these practices does not guarantee security,
but it at least will help to avoid common known vulnerabilities and pitfalls.
</p>

<p>
In addition to describing security and privacy risks relevant for
script developers in <a href="sec-security-consideration-script">
Scripts Security and Privacy Risks</a>, <a href="sec-security-consideration-runtime">
WoT Scripting Runtime Security and Privacy Risks</a> also presets the risks relevant
for the WoT Scripting Runtime itself, since both are important to take into
consideration while building an overall WoT software stack.
A suggested mitigation for each risk is also proposed.
</p>

<p>Below are specific recommendations related to WoT runtime implementations:
<ul>
<li>In basic WoT setups, all scripts running inside the WoT runtime are considered trusted, and
therefore there is no strong need to perform strict isolation between each running script instance.
However, depending on device capabilities and deployment use case scenario risk level it might be
desirable to do so.
<ul>
<li>For example, if one script handles sensitive privacy-related data and well-audited,
it might be desirable to separate it from the rest of the script instances to minimize the risk of data
exposure in case some other script inside WoT gets compromised during the runtime.
<span class="rfc2119-assertion" id="scripting-sec-isolation-scripts">
Therefore the WoT runtime SHOULD perform isolation of script instances and their data in cases
when scripts handle privacy-related or other critical security data.
</span>
</li>
<li>
Another example is mutual co-existence of different tenants on a single WoT device. In this case each
WoT runtime instance will be hosting a different tenant, and isolation between them is required.
<span class="rfc2119-assertion" id="scripting-sec-isolation-runtimes">
Therefore the WoT runtime SHOULD perform isolation of WoT runtime instances and their data if
a WoT device has more than one tenant.
</span>
</li>
</ul>
Such isolation can be performed within the WoT Runtime using platform security mechanisms
available on the device. For more information see Section "WoT Servient Single-Tenant" and
"WoT Servient Multi-Tenant" of [[!WOT-SECURITY-CONSIDERATIONS]].
</li>

<li>WoT scripts are using WoT Scripting API to implement the functionality and logic for WoT Things.
In addition to providing the isolation between script and runtime instances, the WoT runtime needs
to protect the underlying physical device from potentially misbehaving WoT scripts.
<span class="rfc2119-assertion" id="scripting-sec-native">
Therefore the WoT Runtime SHOULD avoid directly exposing the native device interfaces
to the script developers.
</span>
Instead a WoT Runtime should provide a hardware abstraction layer for accessing the native device
interfaces. Additionally, in order to reduce the damage to a physical WoT device in cases a WoT
script gets compromised, it is important to minimize the number of interfaces that are exposed or
accessible to a particular WoT script based on its functionality.
<span class="rfc2119-assertion" id="scripting-sec-interface-min">
Therefore the WoT Runtime SHOULD only expose a minimal set of interfaces to a WoT script based
on its intended functionality.
</span>
</li>
<li>If the WoT runtime supports post-manufacturing provisioning or update of WoT scripts, WoT runtime
or any related data (including security credentials), it can be a major attack vector. An attacker
can try to modify any above described part during the update or provisioning process or simply
provision attacker's code and data directly.
<span class="rfc2119-assertion" id="scripting-sec-update">
Therefore, if WoT Runtime supports post-manufacturing provisioning or update of WoT scripts, WoT
runtime or any related data, such operations SHOULD be done in a secure fashion.
</span>
A set of recommendations for secure update and post-manufacturing provisioning can be found in
[[!WOT-SECURITY-BEST-PRACTICES]].
</li>
<li>Typically the WoT runtime needs to store the security credentials that are provisioned to a WoT
device to operate in WoT network. The confidentiality or integrity of these credentials should not
be compromised.
<span class="rfc2119-assertion" id="scripting-sec-creds1">
Therefore the WoT runtime SHOULD securely store the provisioned security credentials,
guaranteeing their integrity and confidentiality.
</span>
<span class="rfc2119-assertion" id="scripting-sec-creds2">
In case there are more than one tenant on a single WoT-enabled device, a WoT Runtime SHOULD
guarantee isolation of each tenant provisioned security credentials.
</span>
Additionally, in order to minimize a risk that provisioned security credentials get compromised,
the WoT runtime should not have any way for WoT scripts to query these credentials.
<span class="rfc2119-assertion" id="scripting-sec-creds3">
Therefore, the WoT Runtime SHOULD NOT expose any API for WoT scripts to query the provisioned
security credentials.
</span>
</li>
</ul>
<section id="sec-security-consideration-script"> <h3>Scripts Security and Privacy Risks</h3>
<p>This section contains specific risks relevant for script developers.
</p>

<p>Some additional specific recommendations relevant for WoT script developers:
<ul>
<li>A typical way to compromise any process is to send it a corrupted input via one of the exposed
interfaces.
<span class="rfc2119-assertion" id="scripting-sec-inputs">
Therefore developers SHOULD perform validation on all WoT script inputs, including
<a href="https://en.wikipedia.org/wiki/Fuzzing">fuzzing</a>.
</span>
There are many tool and techniques in existence to do such validation.
More details can be found in [[!WOT-SECURITY-TESTING]].
<section id="sec-security-consideration-script-input">
<h5>Corrupted Input Security and Privacy Risk</h5>
<p>
A typical way to compromise any process is to send it a corrupted input via one of the exposed
interfaces. This can be done to a script instance using WoT interface it exposes.
</p>
<dl><dt>Mitigation:</dt><dd>
Developers should perform validation on all script inputs.
In addition to input validation,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine to mention, but we'd need to group separately which statements target 1) API implementors, 2) script developers.

The Scripting API spec primarily targets the API implementors (using the Runtime) and at least some of the security statements should be normative text.

The recommendations for developers should be informative text and would be preferably grouped separately.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, let's discuss this at the next's week security call, if you can make it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or it might be simpler to merge this PR and then I can modify it. This way all versions will be recorded in history and you lose less time shuffling things around following other people's ideas.
Then of course we can discuss the modified version PR in the next security call.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would certainly work for me! Thank you Zoltan!

<a href="https://en.wikipedia.org/wiki/Fuzzing">fuzzing</a> should be used
to verify that the input processing is done correctly.
There are many tools and techniques in existence to do such validation.
More details can be found in [[!WOT-SECURITY-TESTING]].
</dd></dl>
</section>

</li>
<li>As any software, complex scripts with a lot of functionality presents a higher risk of
development mistakes. Such scripts are also hard to verify and test appropriately.
<span class="rfc2119-assertion" id="scripting-sec-complexity">
Therefore developers SHOUD minimize the functionality and complexity of WoT scripts.
</span>
</li>
<li>If a WoT script performs a heavy functional processing on received requests before the request
is authenticated, it presents a great risk for Denial-Of-Service (DOS) attacks.
<span class="rfc2119-assertion" id="scripting-sec-dos">
Therefore WoT scripts SHOULD avoid heavy functional processing without prior successful
authentication of requestor.
</span>
The set of recommended authentication mechanisms can be found in [[!WOT-SECURITY-BEST-PRACTICES]].
</li>
<li>WoT developers should remember that a content of a TD can change, including its identified, id,
which is not an immutable identifier.
<span class="rfc2119-assertion" id="scripting-sec-id">
Therefore WoT scripts SHOULD use the provided WoT script API to subscribe for notifications
on TD changes.
</span>
</li>
</ul>
<section id="sec-security-consideration-script-processing">
<h5>Denial Of Service Security Risk</h5>
<p>
If a script performs a heavy functional processing on received requests before the request
is authenticated, it presents a great risk for Denial-Of-Service (DOS) attacks.
</p>
<dl><dt>Mitigation:</dt><dd>
Scripts should avoid heavy functional processing without prior successful
authentication of requestor. The set of recommended authentication mechanisms
can be found in [[!WOT-SECURITY-BEST-PRACTICES]].
</dd></dl>
</section>

<section id="sec-security-consideration-script-stale-td">
<h5>Stale TD Security Risk</h5>
<p>
During the lifetime of a WoT network, a content of a TD can change.
This includes its identifier,
id, which may not be an immutable one and updated periodically.
</p>
<dl><dt>Mitigation:</dt><dd>
Scripts should use the provided script API to subscribe for notifications
on TD changes and do not rely on TD values to remain persistent.
</dd></dl>
<p class="ednote">
While stale TDs can present a potential problem for WoT network operation,
it might not be a security risk.
</p>
</section>
</section>

<section id="sec-security-consideration-runtime"> <h3>WoT Scripting Runtime Security and Privacy Risks</h3>
<p>This section contains specific risks relevant for the WoT Scripting Runtime itself.
While the following risks are strictly speaking out of the scope
for the WoT Scripting API, a script needs a secure runtime to
execute and therefore we present these risks and recommended mitigations here.
</p>
</section>

<section id="sec-security-consideration-cross-script">
<h5>Cross-Script Security and Privacy Risk</h5>
<p>
In basic WoT setups, all scripts running inside the WoT Scripting Runtime
are considered trusted, and therefore there is no strong need to
perform strict isolation between each running script instance.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should maybe explain or link to the rationale for that trust: what makes scripts trusted in a runtime, and what are the recommended practices for script provisioning into a runtime.

However, depending on device capabilities and deployment use case
scenario risk level it might be desirable to do so.
For example, if one script handles sensitive privacy-related
data and well-audited, it might be desirable to separate it
from the rest of the script instances to minimize the risk of data
exposure in case some other script inside WoT gets compromised during runtime.
Another example is mutual co-existence of different tenants on a
single WoT device. In this case each WoT Scripting Runtime instance will
be hosting a different tenant, and isolation between them is required.
</p>
<dl><dt>Mitigation:</dt><dd>
The WoT Scripting Runtime should perform isolation of script instances and
their data in cases when scripts handle privacy-related or other
critical security data. Similarly, the WoT Scripting Runtime
should perform isolation of WoT Scripting Runtime instances and their data
if a WoT device has more than one tenant.
Such isolation can be performed within the WoT Scripting Runtime using
platform security mechanisms available on the device. For more
information see Sections "WoT Servient Single-Tenant" and
"WoT Servient Multi-Tenant" of [[!WOT-SECURITY-CONSIDERATIONS]].
</dd></dl>
</section>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Scripting API is agnostic about multi-tenancy. If we speak about isolation and multi-tenancy, it is best placed in the document that also discusses how to provision scripts into a runtime: something that is out of scope for this document. Provisioning service can indeed be an application using the Scripting API, and these considerations apply to that application.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am pondering whether to make a separate documents for WoT Runtime implementation notes, provisioning best practices, etc. Probably this text would better suit that kind of document.


<section id="sec-security-consideration-device-direct-access">
<h5>Physical Device Direct Access Security and Privacy Risk</h5>
<p>
In case a script is compromised or misbehaving, the underlying physical device
(and potentially surrounded environment) can be damaged if a script can use directly exposed
native device interfaces. If such interfaces lack safety checks on their inputs, they might
bring the underlying physical device (or environment) to an unsafe state
(i.e. device overheats and explodes).
</p>
<dl><dt>Mitigation:</dt><dd>
The WoT Scripting Runtime should avoid directly exposing the native device interfaces
to the script developers. Instead a WoT Scripting Runtime should provide a hardware abstraction
layer for accessing the native device interfaces. Such hardware abstraction layer should
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Scripting API itself does not expose any lower layer native interfaces. Usually in a W3C spec the generic runtime implementation is not detailed, only the specific internal slots and policies eventually used by algorithms.

refuse to execute commands that might put the device (or environment) to an unsafe state.
Additionally, in order to reduce the damage to a physical WoT device in cases a script
gets compromised, it is important to minimize the number of interfaces that are exposed
or accessible to a particular script based on its functionality.
</dd></dl>
</section>

<section id="sec-security-consideration-update-provisioning">
<h5>Provisioning and Update Security Risk</h5>
<p>
If the WoT Scripting Runtime supports post-manufacturing provisioning
or updates of scripts, WoT Scripting Runtime or any related data
(including security credentials), it can be a major attack vector.
An attacker can try to modify any above described element
during the update or provisioning process or simply
provision attacker's code and data directly.
</p>
<dl><dt>Mitigation:</dt><dd>
Post-manufacturing provisioning or update of scripts,
WoT Scripting Runtime or any related data should be done in a secure fashion.
A set of recommendations for secure update and post-manufacturing
provisioning can be found in [[!WOT-SECURITY-CONSIDERATIONS]].
</dd></dl>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this section, as well as all text regarding provisioning, should perhaps be in the Security Note.
I am not sure whether to handle runtime related issues in this API spec.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, perhaps a separate Runtime implementation notes doc would be a better place.

</section>

<section id="sec-security-consideration-credentials-storage">
<h5>Security Credentials Storage Security and Privacy Risk</h5>
<p>
Typically the WoT Scripting Runtime needs to store the security credentials that are provisioned to a WoT
device to operate in WoT network. If an attacker can compromise the confidentiality or integrity
of these credentials, then it can obtain access to the WoT assets, impersonate WoT things or devices
or create Denial-Of-Service (DoS) attacks.
</p>
<dl><dt>Mitigation:</dt><dd>
The WoT Scripting Runtime should securely store the provisioned security credentials,
guaranteeing their integrity and confidentiality.
In case there are more than one tenant on a single WoT-enabled device, a WoT Scripting Runtime should
guarantee isolation of each tenant provisioned security credentials.
Additionally, in order to minimize a risk that provisioned security credentials get compromised,
the WoT Scripting Runtime should not expose any API for scripts to query the provisioned
security credentials.
</dd></dl>
</section>
</section>
</section>
zolkis marked this conversation as resolved.
Show resolved Hide resolved



<section> <h2>Terminology and conventions</h2>
Expand Down