# SmartThings Security Approach - Abstract

**URL:** <https://community.smartthings.com/t/smartthings-security-approach-abstract/19916>\
**Category:** Announcements\
**Created:** [July 30, 2015, 9:16pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916 "2015-07-30T21:16:10Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![dlieberman](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/dlieberman/32/11827_2.png) [@dlieberman](https://community.smartthings.com/u/dlieberman)\
**Post date:** [July 30, 2015, 9:16pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/1 "2015-07-30T21:16:10Z")

</div>

Hi all –

I know there’s been some questions and discussion around the security approaches that we’ve taken in building the SmartThings Platform, so I wanted to make [this paper](https://docs.google.com/document/d/1NWc8PTNbwcPwb9xiFHGMMm3ZxaMtw06A5kpN9VqUEwM/) available to all of you. It’s an abstract that describes our security approach at a high-level, and we’ll release a much more detailed paper in the Fall.

[Abstract - SmartThings Security Strategy & Approach](https://docs.google.com/document/d/1NWc8PTNbwcPwb9xiFHGMMm3ZxaMtw06A5kpN9VqUEwM/)

Thanks,  
Dan Lieberman  
SmartThings, Inc.

---

<div class="post-metadata">

**Author:** ![dlieberman](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/dlieberman/32/11827_2.png) [@dlieberman](https://community.smartthings.com/u/dlieberman)\
**Post date:** [July 30, 2015, 9:17pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/2 "2015-07-30T21:17:57Z")

</div>

Pinned on July 30, 2015, 9:17pm UTC



---

<div class="post-metadata">

**Author:** ![pstuart](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/pstuart/32/82936_2.png) [@pstuart](https://community.smartthings.com/u/pstuart)\
**Post date:** [July 30, 2015, 9:41pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/3 "2015-07-30T21:41:23Z")

</div>

Quick question. Since this document only addresses physical devices and their virtual representation in the physical graph. Would it be fair to assume that virtual devices and smartapp data is also owned by the user?

Example, my location isn’t tied to a device (maybe the hub) is that data private?

Is using another cloud based service that has no physical device also protected user data?

How is that data protected from ST employees and contractors or 3rd party providers?

What audit trail exists to show who accessed my private data, since it is considered private by SmartThings, will you be compliant with all state laws regarding user data privacy?

If I suspect my data has been compromised what is the proper way to file a complaint and what would be the resolution to these incidents, if/when they would occur?

What is SmartThings policy on unauthorized data access disclosure? Will you publicly announce it or just notify the effected users or keep it quiet?

Thanks for your answers in advance…

---

<div class="post-metadata">

**Author:** ![tgauchat](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/tgauchat/32/49516_2.png) [@tgauchat](https://community.smartthings.com/u/tgauchat)\
**Post date:** [July 30, 2015, 10:21pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/4 "2015-07-30T22:21:04Z")

</div>

It may be useful to note (as has come up in various discussions / feature requests), that Access Control granularity is limited to the “Device Instance” resolution.

As an example, a user can authorize a SmartApp to have full access to a particular Lock, but cannot limit that access to only the read-only Attributes, nor to particular Commands such as “`lock()`”, but not “`unlock()`”.

The read-only functionality would be useful, as then the Lock could be used as an “`open/closed`” Sensor while protecting the Lock from manipulation.

The Command level granularity is less critical, but the use case I gave (lock but not unlock) is quite conceivable. For example, folks have been discussing the obvious risks of granting access to their door locks to their Amazon **Echo** – someone could yell “`Alexa, unlock the front door.`” … But note, if I am able to only grant Command “`lock()`”, then we still can use Echo to make sure the front-door **_is locked_** via voice control. (And the read-only example applies here too … “`Alexa, are all my doors locked?`”).

---

<div class="post-metadata">

**Author:** ![chuckles](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/chuckles/32/12146_2.png) [@chuckles](https://community.smartthings.com/u/chuckles)\
**Post date:** [July 31, 2015, 2:27am UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/5 "2015-07-31T02:27:24Z")

</div>

And thus we’d be one step closer…

“Alexa, unlock the pod bay doors.”

“I’m sorry Dave, I’m afraid I can’t do that.”

😆

---

<div class="post-metadata">

**Author:** ![pstuart](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/pstuart/32/82936_2.png) [@pstuart](https://community.smartthings.com/u/pstuart)\
**Post date:** [August 5, 2015, 7:27pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/6 "2015-08-05T19:27:24Z")

</div>

@dlieberman Can you please let us know you intentions on answering the above questions that are not addressed in the document you shared?

Or will we just have to wait till the fall when a more detailed paper is released?

Also, I will ask again, since it was several months ago that I asked for it.

Is there an official channel (besides [support@smartthings.com](mailto:support@smartthings.com)) to submit potential vulnerabilities or suspected private data breaches we can report our concerns to?

---

<div class="post-metadata">

**Author:** ![tgauchat](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/tgauchat/32/49516_2.png) [@tgauchat](https://community.smartthings.com/u/tgauchat)\
**Post date:** [August 5, 2015, 7:55pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/7 "2015-08-05T19:55:02Z")

</div>

> [@pstuart](#):
>
> Is there an official channel (besides [support@smartthings.com](mailto:support@smartthings.com)) to submit potential vulnerabilities or suspected private data breaches we can report our concerns to?

It would be great if we really felt that SmartThings takes serious vulnerabilities as professional / industry conventions have set precedent.

EG:

> **[RFPolicy](https://en.m.wikipedia.org/wiki/RFPolicy)**
>
> The RFPolicy states a method of contacting vendors about security vulnerabilities found in their products. It was originally written by hacker and security consultant Rain Forest Puppy.
> The policy gives the vendor five working days to respond to the reporter of the bug. If the vendor fails to contact the reporter in those five days, the issue is recommended to be disclosed to the general community. The reporter should help the vendor reproduce the bug and work out a fix. The reporter should del...

---

<div class="post-metadata">

**Author:** ![schettj](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/schettj/32/12194_2.png) [@schettj](https://community.smartthings.com/u/schettj)\
**Post date:** [August 5, 2015, 10:25pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/8 "2015-08-05T22:25:51Z")

</div>

> [@tgauchat](#):
>
> As an example, a user can authorize a SmartApp to have full access to a particular Lock, but cannot limit that access to only the read-only Attributes, nor to particular Commands such as “lock()”, but not “unlock()”.

You could do this with a special device type (kinda like the big switch) which only passes on the lock() request to the physical lock. Then only grant your 3rd party services access to that device.

Also gives you the “revoke” ability since you could either delete or set the virtual device to nothing.

But yeah, would be messy.

---

<div class="post-metadata">

**Author:** ![tgauchat](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/tgauchat/32/49516_2.png) [@tgauchat](https://community.smartthings.com/u/tgauchat)\
**Post date:** [August 5, 2015, 10:35pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/9 "2015-08-05T22:35:48Z")

</div>

> [@schettj](#):
>
> But yeah, would be messy.

It doesn’t _have to be messy_, in theory.

The shadow Devices and virtual Devices are useful in so many ways that it would be great if they were seamlessly integrated into the platform (i.e. could be created on the fly by the UI and API / SmartApps, and could be organized… hidden or linked to their related physical devices in a nice UX).

A very workable design challenge that actually doesn’t require an architectural change to the underlying platform.

---

<div class="post-metadata">

**Author:** ![dlieberman](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/dlieberman/32/11827_2.png) [@dlieberman](https://community.smartthings.com/u/dlieberman)\
**Post date:** [August 7, 2015, 8:54pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/10 "2015-08-07T20:54:09Z")

</div>

@pstuart - Sorry for the delay in getting back to you - I’m on vacation and haven’t really been online.

I’ll block off some time next week to compile and answer as many of the questions as I can. As for a forum for reporting, I’d continue to suggest using [support@smartthings.com](mailto:support@smartthings.com), as we can then track issues using the support ticketing system. Is there a reason that you’d prefer for there to be a separate channel?

Thanks,  
-d

---

<div class="post-metadata">

**Author:** ![tgauchat](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/tgauchat/32/49516_2.png) [@tgauchat](https://community.smartthings.com/u/tgauchat)\
**Post date:** [August 7, 2015, 9:13pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/11 "2015-08-07T21:13:15Z")

</div>

> [@dlieberman](#):
>
> as we can then track issues using the support ticketing system

I’ve been personally told by your support team management that they have to move tickets into the “Resolved” status as soon as possible in order to keep the queues manageable and their metrics favorable.

As a result, issues are often “resolved” by _just_ informing the Customer it is a known issue with an undetermined fix date.

This interaction is discussed in various Forum posts.

Due to your internal process described above, the Support ticket channel is not appropriate for potentially critical security discoveries.

---

<div class="post-metadata">

**Author:** ![pstuart](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/pstuart/32/82936_2.png) [@pstuart](https://community.smartthings.com/u/pstuart)\
**Post date:** [August 7, 2015, 11:18pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/12 "2015-08-07T23:18:14Z")

</div>

The last time I submitted a security flaw to support they told me to bring it to the community. Unless things have changed and support has the appropriate protocol to escalate potential security issues properly, it would be nice to skip the first level support. Especially if they are the source of a potential security breach.

---

<div class="post-metadata">

**Author:** ![jody.albritton](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/jody.albritton/32/220661_2.png) [@jody.albritton](https://community.smartthings.com/u/jody.albritton)\
**Post date:** [August 7, 2015, 11:41pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/13 "2015-08-07T23:41:03Z")

</div>

Maybe in the new developer portal we could have a page like this.

[https://technet.microsoft.com/en-us/security/ff852094.aspx](https://technet.microsoft.com/en-us/security/ff852094.aspx)

or this

[https://www.google.com/about/appsecurity/](https://www.google.com/about/appsecurity/)

or this

> **[Contact Apple About Security Issues](https://support.apple.com/en-us/HT201220)**
>
> This page includes information about Apple product security and how security researchers, developers, law enforcement personnel, and journalists can contact Apple to report or ask about a security issue.

Every one of those have PGP keys to encrypt a security issue report and a separate email address specifically for tracking security concerns.

---

<div class="post-metadata">

**Author:** ![dlieberman](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/dlieberman/32/11827_2.png) [@dlieberman](https://community.smartthings.com/u/dlieberman)\
**Post date:** [August 12, 2015, 7:16pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/14 "2015-08-12T19:16:15Z")

</div>

> [@pstuart](#):
>
> Quick question.

Again, sorry for the delay in getting answers to your questions here. I’ll do my best to answer them one by one:

> Since this document only addresses physical devices and their virtual representation in the physical graph. Would it be fair to assume that virtual devices and smartapp data is also owned by the user? Example, my location isn’t tied to a device (maybe the hub) is that data private?

Yes - this policy doesn’t apply ONLY to devices that are connected to the hub, but to all event and account data for a given Location.

There are specific policies governing the use of anonymized and aggregated data, as well as the sharing of data with third-party businesses opted-in to by the user available in our [Terms of Use](http://www.smartthings.com/terms) and [Privacy Policy](http://www.smartthings.com/privacy/) available on the [SmartThings website](http://www.smartthings.com).

> Is using another cloud based service that has no physical device also protected user data?

There’s some nuance here since we don’t have any control over the remote system and how they use your data. As above, event data that is stored in the SmartThings Platform is treated by SmartThings as protected user data, but once that information leaves the SmartThings Platform - say, because the user linked their SmartThings account to a remote cloud service or accepted incremental Terms and Conditions associated with a third-party business - that data becomes governed by the Terms of Use and Privacy Policies of the remote service. This is also detailed in our [Privacy Policy](http://www.smartthings.com/privacy/) available on the [SmartThings website](http://www.smartthings.com).

> How is that data protected from ST employees and contractors or 3rd party providers?

There are instances in which SmartThings operations and support personnel must gain access to databases to ensure the operation of the service and to support users in solving issues that arise. There are internal policies in place to minimize access to data including limiting the number of employees who have direct access to databases for the purposes of maintaining and operating the service, and requiring that any support personnel be granted explicit permission from users before accessing their data through our support tools. We are currently working on documenting all of the specific policies and procedures around our information security and privacy programs and additional detail will be included in the more detailed white paper when it is published. In the meantime, our [Terms of Use](http://www.smartthings.com/terms) and [Privacy Policy](http://www.smartthings.com/privacy/) are always available on the [SmartThings website](http://www.smartthings.com).

> What audit trail exists to show who accessed my private data, since it is considered private by SmartThings, will you be compliant with all state laws regarding user data privacy?

SmartThings always endeavors to maintain compliance with all regulatory requirements for the regions in which we operate. As above, additional detail around specific policies and procedures will be included in the white paper when it is published.

> If I suspect my data has been compromised what is the proper way to file a complaint and what would be the resolution to these incidents, if/when they would occur?

If you suspect that your data has been compromised, please reach out to [support@smartthings.com](mailto:support@smartthings.com) to begin an investigation. Resolution would be dependent on the specifics of each case, though as above, additional documentation around policies and procedures is under development.

> What is SmartThings policy on unauthorized data access disclosure? Will you publicly announce it or just notify the effected users or keep it quiet?

As always, we’ll comply with local regulations - though again, there’s a lot of nuance here and beyond that it’ll depend entirely on the specifics of the case. This is also another area that will be addressed in more detail in the development of the documentation of policies and procedures.

As for security / vulnerability disclosures, we’ve had disclosures from third-party security research firms come through our [support@smartthings.com](mailto:support@smartthings.com) channel, and we’ve always taken them seriously and made sure to quickly validate submissions, remediate any issues, and re-test once patches are in place. This has been the the case with disclosures from companies like [Gotham Digital Science](https://blog.gdssecurity.com/labs/2015/3/4/smartthings-ssl-certificate-validation-vulnerability.html), [Tripwire VERT](http://www.eweek.com/security/hubs-driving-smart-homes-are-vulnerable-security-firm-finds.html), and the [NCC Group](https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/ncc_group_intern_whitepaper_2014_internet_of_things_research.pdf) who have all worked with us to ensure that we patch discovered vulnerabilities before they publish their reports.

In all of these cases, support has escalated these disclosures and we’ve exchanged keys with the submitter to manage secure communications, but I do like the suggestion to make available a public key specifically for these types of submissions. We’ll look into that further.

Thanks,  
-d

---

<div class="post-metadata">

**Author:** ![pstuart](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/pstuart/32/82936_2.png) [@pstuart](https://community.smartthings.com/u/pstuart)\
**Post date:** [August 12, 2015, 8:26pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/15 "2015-08-12T20:26:35Z")

</div>

Thanks for the reply. Looking forward to the further details.

I would highly doubt any other company in this space would take the time or consideration to detail this level of data and user protections in place or will be in place.

With anything involving users and employees / contractors, there are always risks with data and security issues.

Two more questions. I’ve been told that 2 stage authentication for the mobile app and IDE are NOT on the roadmap and not considered a priority.

Can this be looked at again and see if 2 stage (optional) authentication can be implemented ASAP for mobile and the IDE?

This would go along way into shoring up the weakest part of the ST ecosystem, the user and their password.

Also, since there seems to be a significant oversight / ommission in the OAUTH2 implementation in SmartApps, where there is no exposed method to revoke a security token for installed SmartApps.

Can this also be prioritized to be fixed ASAP (as it was first identified in Oct 14) to give developers the ability to revoke or expire OUATH security tokens?

These two items would improve security dramatically at the user level.

Thanks!

---

<div class="post-metadata">

**Author:** ![sborsch](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/sborsch/32/6198_2.png) [@sborsch](https://community.smartthings.com/u/sborsch)\
**Post date:** [August 20, 2015, 1:47pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/16 "2015-08-20T13:47:13Z")

</div>

Hey Ben. While I’m _very_ enthusiastically anticipating V2 of the hub, I continually am disappointed with the reality of devices I buy, especially new ones, that have what I consider to be security and privacy-breaching built-in to them as their default. So before I pre-order, I thought I’d ask about this since I can’t find anything detailed on the ST site, forums, etc…

As a company, Samsung is clearly accelerating what they do with connected device data collection. As an example, I ended up setting my Samsung TV as a monitor-only—and am using my various other media devices to drive content to it—since the constant updating and phoning home the TV did while connected were violations I viewed as insanely intrusive.

As such, I am intentionally seeking out devices which **_I_** can control over what (and how much) data is released. I’ve done that by buying direct-connect cameras (vs. using cloud-service-only cameras), for example, and will do so with IoT devices whenever I can.

Thoughts?

---

<div class="post-metadata">

**Author:** ![geko](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/geko/32/34862_2.png) [@geko](https://community.smartthings.com/u/geko)\
**Post date:** [August 20, 2015, 4:16pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/17 "2015-08-20T16:16:44Z")

</div>

> [@SmartThings Hub V2 now available for pre-order](https://community.smartthings.com/t/smartthings-hub-v2-now-available-for-pre-order/20607/179):
>
> As such, I am intentionally seeking out devices which I can control over what (and how much) data is released. I’ve done that by buying direct-connect cameras (vs. using cloud-service-only cameras), for example, and will do so with IoT devices whenever I can.

In this case, I’m afraid any cloud-based system is not for you. SmartThings, Wink, Alexa, they all use the cloud extensively and you have no control over what data is shared with the cloud. If this is a concern for you, there’re alternatives that can work without the Internet connection, for example Staples Connect and Vera Edge.

---

<div class="post-metadata">

**Author:** ![sborsch](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/sborsch/32/6198_2.png) [@sborsch](https://community.smartthings.com/u/sborsch)\
**Post date:** [August 20, 2015, 4:59pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/18 "2015-08-20T16:59:40Z")

</div>

Geko, did you note that I was clear about describing those devices/services “I can control” and choose what is and is not captured? I know how the cloud works and I know that the sort of control I expect is also limited.

At the same time when I go out and spend $2k+ on a Samsung TV and they have built-in draconian data capturing, I expect a higher level of control than when I opt to use a SaaS service (e.g., Google services) where I know that I’m the product since they’re giving me all of that stuff for free. There’s a difference and I asked the question mainly to discover if ST’s new Samsung overlords have “guided” them toward modest, or extreme, levels of data capture.

---

<div class="post-metadata">

**Author:** ![JDRoberts](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/jdroberts/32/56577_2.png) [@JDRoberts](https://community.smartthings.com/u/JDRoberts)\
**Post date:** [August 20, 2015, 5:10pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/19 "2015-08-20T17:10:39Z")

</div>

This might be of interest on the security and privacy questions:

> [@SmartThings Security Approach - Abstract](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916):
>
> Hi all – I know there’s been some questions and discussion around the security approaches that we’ve taken in building the SmartThings Platform, so I wanted to make [this paper](https://docs.google.com/document/d/1NWc8PTNbwcPwb9xiFHGMMm3ZxaMtw06A5kpN9VqUEwM/) available to all of you. It’s an abstract that describes our security approach at a high-level, and we’ll release a much more detailed paper in the Fall. [Abstract - SmartThings Security Strategy & Approach](https://docs.google.com/document/d/1NWc8PTNbwcPwb9xiFHGMMm3ZxaMtw06A5kpN9VqUEwM/) Thanks, Dan Lieberman SmartThings, Inc.

---

<div class="post-metadata">

**Author:** ![Benji](https://yyz2.discourse-cdn.com/smartthings/user_avatar/community.smartthings.com/benji/32/74764_2.png) [@Benji](https://community.smartthings.com/u/Benji)\
**Post date:** [August 20, 2015, 5:14pm UTC](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916/20 "2015-08-20T17:14:45Z")

</div>

Good grief, put the tin foil hat away, I sincerely hope you don’t have any Google or Apple devices, ALL of these are reporting back and listening.

Samsung got busted about their TV’s, everyone lost their proverbial poo and acted like they were the only one that could be accused of doing it…

If you are GENUINELY concerned, I hope your ‘tcpdump’/wireshark skills are up to snuff…

[Next page](https://community.smartthings.com/t/smartthings-security-approach-abstract/19916.md?page=2)
